Re: [osg-users] Integration of a NodeKit for Sky Rendering
Hi Daniel, On 21 January 2013 11:44, Daniel Limberger daniel.limber...@hpi.uni-potsdam.de wrote: Yes, I would like that. Can someone provide my openscenegraph account with the required rights or is there a special procedure of adding new content there? For code submissions we have a couple of writers to particular portions of the OSG source code tree that are of there particular expertise, and if your NodeKit looks appropriate to merge this might be the way to go. I haven't yet reviewed your project so can't say how close it might be to being appropriate for merging as part of the core OSG. Not all NodeKits are appropriate for the core OSG, some work best as part of the core OSG others work well outside. Good examples of vibrant external NodeKits/Projects are osgEarth and osgWorks. I'm not sure if i understand your question correct. osgHimmel makes no assumptions of the node or terrain type it is used with, except that the provided altitude should be within the atmosphere or is at ground level (for now, i plan to change this). It further needs date, time, longitude, and latitude. Would it be possible to provide the date, time, long and lats during the cull traversal? This way if the application has multiple views from different locations then the sky model can be set up correctly for each. If this isn't possible then buffering elements that need to have specific location information would be required. Integrating with an ECEF model would be ideal, lots of OSG users have applications where whole earth models are used and viewpoints go from within the atmosphere to outside it. One needn't solve all these problems right away, but you'd want to have a scheme where a the path to support this would be possible. For my idea sky model NodeKit users would be able to enable the atmosphere for these world and then let the NodeKit worry about the specifics of what to render for each view that the viewer is running. A viewer might be running on multiple contexts, multiple views with multiple threads so one has to code with this in mind. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Integration of a NodeKit for Sky Rendering
I would sort of advocate keeping it an external project, like osgEarth. On Tue, Feb 12, 2013 at 4:55 AM, Robert Osfield robert.osfi...@gmail.comwrote: Hi Daniel, On 21 January 2013 11:44, Daniel Limberger daniel.limber...@hpi.uni-potsdam.de wrote: Yes, I would like that. Can someone provide my openscenegraph account with the required rights or is there a special procedure of adding new content there? For code submissions we have a couple of writers to particular portions of the OSG source code tree that are of there particular expertise, and if your NodeKit looks appropriate to merge this might be the way to go. I haven't yet reviewed your project so can't say how close it might be to being appropriate for merging as part of the core OSG. Not all NodeKits are appropriate for the core OSG, some work best as part of the core OSG others work well outside. Good examples of vibrant external NodeKits/Projects are osgEarth and osgWorks. I'm not sure if i understand your question correct. osgHimmel makes no assumptions of the node or terrain type it is used with, except that the provided altitude should be within the atmosphere or is at ground level (for now, i plan to change this). It further needs date, time, longitude, and latitude. Would it be possible to provide the date, time, long and lats during the cull traversal? This way if the application has multiple views from different locations then the sky model can be set up correctly for each. If this isn't possible then buffering elements that need to have specific location information would be required. Integrating with an ECEF model would be ideal, lots of OSG users have applications where whole earth models are used and viewpoints go from within the atmosphere to outside it. One needn't solve all these problems right away, but you'd want to have a scheme where a the path to support this would be possible. For my idea sky model NodeKit users would be able to enable the atmosphere for these world and then let the NodeKit worry about the specifics of what to render for each view that the viewer is running. A viewer might be running on multiple contexts, multiple views with multiple threads so one has to code with this in mind. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com http://www.alphapixel.com/ Training • Consulting • Contracting 3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 • GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL Digital Imaging • GIS • GPS • osgEarth • Terrain • Telemetry • Cryptography • Digital Audio • LIDAR • Kinect • Embedded • Mobile • iPhone/iPad/iOS • Android @alphapixel https://twitter.com/alphapixel facebook.com/alphapixel (775) 623-PIXL [7495] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Integration of a NodeKit for Sky Rendering
Hi Daniel and Robert, 2013/2/12 Robert Osfield robert.osfi...@gmail.com Hi Daniel, On 21 January 2013 11:44, Daniel Limberger daniel.limber...@hpi.uni-potsdam.de wrote: Yes, I would like that. Can someone provide my openscenegraph account with the required rights or is there a special procedure of adding new content there? For code submissions we have a couple of writers to particular portions of the OSG source code tree that are of there particular expertise, and if your NodeKit looks appropriate to merge this might be the way to go. I haven't yet reviewed your project so can't say how close it might be to being appropriate for merging as part of the core OSG. Not all NodeKits are appropriate for the core OSG, some work best as part of the core OSG others work well outside. Good examples of vibrant external NodeKits/Projects are osgEarth and osgWorks. I believe Daniel was asking for permissions in the new web, not in the svn. So I have added Daniel to the publishers group. Take a look to the author's guideline in the login section once you are logged in. Cheers. -- Jordi Torres Fabra ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Integration of a NodeKit for Sky Rendering
Hi, On Tuesday, February 12, 2013 11:55:48 Robert Osfield wrote: Integrating with an ECEF model would be ideal, lots of OSG users have applications where whole earth models are used and viewpoints go from within the atmosphere to outside it. If there is a question how this can be achieved, I can probably help out in some corners. I have here an osg based elliptic paged whole earth model running with a combination of the INRIA paper and the weaker Oskar Elek tables for scattering. Still experimenting with this. And I do not have a that nice implementation. But my focus is as usual to be as modular as possible. So it's easily possible to have the more sophisticated scattering models implemented in the interresting environments. Greetings Mathias ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Integration of a NodeKit for Sky Rendering
Thanks a lot for all your positive feedback. Your interest in osgHimmel convinced me to allocate time and continue maintaining the project. Jordi Torres wrote: Great job! You may want to add your project to the community projects[1] section in the new web or/and post a new to the community news section[2]... :) Yes, I would like that. Can someone provide my openscenegraph account with the required rights or is there a special procedure of adding new content there? Chris Hanson wrote: Nice work. I'm going to try it out soon, and hopefully I can add it to our build system shortly. Sounds great. I'll provide any help you need to get this done. gwaldron wrote: Looks great. Does it work with geocentric terrain? I'm not sure if i understand your question correct. osgHimmel makes no assumptions of the node or terrain type it is used with, except that the provided altitude should be within the atmosphere or is at ground level (for now, i plan to change this). It further needs date, time, longitude, and latitude. For rendering whole planets, the astronomy part of osgHimmel provides basic coordinate transformations which might be useful. However, in its current status any astrophysical sky of osgHimmel is assumed to be seen from within the atmosphere. If not, moon, sun, and probably star positions need to be adjusted for that. The atmosphere model based on Bruneton and Neyret is limited to skies within the atmosphere, though the suggested model itself is capable of extraterrestrial views. For such use cases, osghimmel should provide an extended node in the future. Jean-Sébastien Guay wrote: In the past I have used osgEphemeris, which supports sky sphere, sun, moon, stars based on earth latitude/longitude and date/time. It gave OK results but had a few problems as well. ... Starting on this project, i evaluated various resources before creating a new library from scratch. osgEphemeris seemed unmaintained for several years. Its results are good in terms of correctness of star and planet positions, but lack of convincing image synthesis. osgHimmel features two astronomy calculations: One as reference impl. based on Meeus book, the second based on simpler models with fewer math. Further, osgHimmel provides correct star color, apparent magnitudes, correct lunar orientation and more. Jean-Sébastien Guay wrote: Just out of curiosity, how flexible is your library? For example, a long time ago I had to develop a lunar rover simulator, and I was able to easily use osgEphemeris' night-time sky (replacing the moon by a larger Earth, of course, and I didn't mind about exact positions of the stars ) to make the lunar sky. ... Is something like this easy with your library? Great work! If you are willing to neglect minor errors in star positions, you can create a sky just showing stars and background imagery. The problem however would be to provide an astronomically correct position taking lunar motion into account. Perhaps the easiest way is to take the earth at a specific date/time, calculate the lunar position, pick long and lat based on an earth reference system. osgHimmel probably provides most of this, but some interfaces and transformations have to be adjusted. This is a good use case to generalize the sky positioning more. If you are fine with convincing stars and recognizable star constellations despite correct positioning for the moon, just provide arbitrary longitude and latitude and it should work. Jean-Sébastien Guay wrote: Keep up the great work! I will! Thanks a lot again! If you like to play around with osgHimmel, just download the demo (windows binaries on the googlecode site): in skybox.exe you can drag and drop 3d models into the scene, play with all the parameters, and livecode all shaders from within the GUI. Note that this is still in development and there are some unadressed bugs left. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=52051#52051 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Integration of a NodeKit for Sky Rendering
On Mon, Jan 21, 2013 at 6:44 AM, Daniel Limberger daniel.limber...@hpi.uni-daniel.limber...@hpi.uni-potsdam.de gwaldron wrote: Looks great. Does it work with geocentric terrain? I'm not sure if i understand your question correct. osgHimmel makes no assumptions of the node or terrain type it is used with, except that the provided altitude should be within the atmosphere or is at ground level (for now, i plan to change this). It further needs date, time, longitude, and latitude. What I mean is: most terrain models (like those created by VPB or osgEarth) operate is either flat/projected mode (the +Z axis always points up away from the ground) or in geoentric/ECEF mode (the +Z axis points through the north pole), and the origin is at the center of the Earth. The old osgEphemeris library only worked in flat projected mode because it assumed +Z was up. Just wondering whether your SDK makes the same assumption, or whether you are rendering a celestial sphere. If the latter, I would be interested in the potential for integrating your SDK with osgEarth. Glenn Waldron / @glennwaldron / osgEarth.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Integration of a NodeKit for Sky Rendering
Looks great. Does it work with geocentric terrain? Glenn Waldron / @glennwaldron On Fri, Jan 18, 2013 at 1:15 PM, Chris Hanson xe...@alphapixel.com wrote: Nice work. I'm going to try it out soon, and hopefully I can add it to our build system shortly. On Fri, Jan 18, 2013 at 11:00 AM, Jordi Torres jtorresfa...@gmail.comwrote: Hi Daniel, Great job! You may want to add your project to the community projects[1] section in the new web or/and post a new to the community news section[2]... :) Cheers. [1]http://www.openscenegraph.com/index.php/community/projects [2]http://www.openscenegraph.com/index.php/community/news 2013/1/18 Christian Buchner christian.buch...@gmail.com This nodekit is a godsend! And the license seems pretty permissive, too. Christian 2013/1/18 Limberger, Daniel daniel.limber...@hpi.uni-potsdam.de ** ** ** ** *From:* Limberger, Daniel *Sent:* 18 January 2013 15:50 *To:* Engel, Juri *Subject:* Integration of a NodeKit for Sky Rendering into OSG ** ** Hi, ** ** I would like to present you my open source library osgHimmel that allows simple noninvasive rendering of background imagery (i.e., skies) within OSG. It currently is an OSG extending lib, that features two different techniques for sky rendering (or in traditional terms, skybox rendering): texture based (traditional) and computational (astrophysical). ** ** The first approach handles rendering of skies via common texture mapping techniques, extended by time based transitions, rotation around the zenith, horizon blending as well as an (experimental) faked sun. ** ** The second approach, renders astrophysical based skies with good results not only but especially at nightly scenes: correct star positions, atmosphere approximation, moon rendering including lunar eclipses and more. ** ** Further Contributions to OSG: **- **A useful, minimal astronomy library. **- **Good resources for both, texture based and physical based, approaches. **- **Solutions for common OSG issues, e.g., placing skies in arbitrary node structures, texture ping-ponging for post/pre processing, environment map rendering for reflection/illumination. **- **Starting point for cloud rendering. The current implementation is not very efficient though (TODO..) **- **Introduces no third parties, purely based on OSG (and optionally Qt for the editor)! ** ** For now, osgHimmel is mainly used internally at the Computer Graphics Systems group at the HPI (hpi3d.de), and the first integration into a commercial product is already in progress. We have two research projects, trying to extend the library by HDR, temporal-glare, Glare, simple as well as image based illumination. ** ** I would like to suggest an integration of osgHimmel into OSG, since a larger user base would convince me to keep osgHimmel alive and spent further development time on the library. What requirements must be met and what further steps have to be taken to make this integration possible (we can rename the lib to osgSky if this is a problem ;) )? Or is it better practice for such library to stay independent, without a direct OSG integration? ** ** I’m strongly interested in any ideas and concerns of this community concerning osgHimmel. ** ** ** ** All resources (including videos, demos, poster, my master’s thesis, and a recent vmv2012 paper) are available at: http://osghimmel.googlecode.com ** ** recent poster with some images: https://osghimmel.googlecode.com/files/Daniel_Limberger_Poster.pdf ** ** Thanks a lot! And also thanks to this mailing list, which was of great help during development of osghimmel. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Jordi ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com http://www.alphapixel.com/ Training • Consulting • Contracting 3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 • GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL Digital Imaging • GIS • GPS • osgEarth • Terrain • Telemetry • Cryptography • Digital Audio • LIDAR • Kinect • Embedded • Mobile • iPhone/iPad/iOS • Android @alphapixel https://twitter.com/alphapixel facebook.com/alphapixel (775) 623-PIXL [7495] ___ osg-users mailing list
Re: [osg-users] Integration of a NodeKit for Sky Rendering
Nice work Daniel, results look great! In the past I have used osgEphemeris, which supports sky sphere, sun, moon, stars based on earth latitude/longitude and date/time. It gave OK results but had a few problems as well. Its site is www.andesengineering.com/Projects/*OsgEphemeris*/ but it seems to be down at the moment. Just out of curiosity, how flexible is your library? For example, a long time ago I had to develop a lunar rover simulator, and I was able to easily use osgEphemeris' night-time sky (replacing the moon by a larger Earth, of course, and I didn't mind about exact positions of the stars ) to make the lunar sky. See the end of this video for an example: http://www.youtube.com/watch?v=b1tN2TpVIOM Is something like this easy with your library? Keep up the great work! J-S On 18/01/2013 10:13 AM, Limberger, Daniel wrote: *From:*Limberger, Daniel *Sent:* 18 January 2013 15:50 *To:* Engel, Juri *Subject:* Integration of a NodeKit for Sky Rendering into OSG Hi, I would like to present you my open source library osgHimmel that allows simple noninvasive rendering of background imagery (i.e., skies) within OSG. It currently is an OSG extending lib, that features two different techniques for sky rendering (or in traditional terms, skybox rendering): texture based (traditional) and computational (astrophysical). The first approach handles rendering of skies via common texture mapping techniques, extended by time based transitions, rotation around the zenith, horizon blending as well as an (experimental) faked sun. The second approach, renders astrophysical based skies with good results not only but especially at nightly scenes: correct star positions, atmosphere approximation, moon rendering including lunar eclipses and more. Further Contributions to OSG: -A useful, minimal astronomy library. -Good resources for both, texture based and physical based, approaches. -Solutions for common OSG issues, e.g., placing skies in arbitrary node structures, texture ping-ponging for post/pre processing, environment map rendering for reflection/illumination. -Starting point for cloud rendering. The current implementation is not very efficient though (TODO..) -Introduces no third parties, purely based on OSG (and optionally Qt for the editor)! For now, osgHimmel is mainly used internally at the Computer Graphics Systems group at the HPI (hpi3d.de), and the first integration into a commercial product is already in progress. We have two research projects, trying to extend the library by HDR, temporal-glare, Glare, simple as well as image based illumination. I would like to suggest an integration of osgHimmel into OSG, since a larger user base would convince me to keep osgHimmel alive and spent further development time on the library. What requirements must be met and what further steps have to be taken to make this integration possible (we can rename the lib to osgSky if this is a problem ;) )? Or is it better practice for such library to stay independent, without a direct OSG integration? I'm strongly interested in any ideas and concerns of this community concerning osgHimmel. All resources (including videos, demos, poster, my master's thesis, and a recent vmv2012 paper) are available at: http://osghimmel.googlecode.com recent poster with some images: https://osghimmel.googlecode.com/files/Daniel_Limberger_Poster.pdf Thanks a lot! And also thanks to this mailing list, which was of great help during development of osghimmel. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- __ Jean-Sebastien Guay jean_...@videotron.ca http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Integration of a NodeKit for Sky Rendering
From: Limberger, Daniel Sent: 18 January 2013 15:50 To: Engel, Juri Subject: Integration of a NodeKit for Sky Rendering into OSG Hi, I would like to present you my open source library osgHimmel that allows simple noninvasive rendering of background imagery (i.e., skies) within OSG. It currently is an OSG extending lib, that features two different techniques for sky rendering (or in traditional terms, skybox rendering): texture based (traditional) and computational (astrophysical). The first approach handles rendering of skies via common texture mapping techniques, extended by time based transitions, rotation around the zenith, horizon blending as well as an (experimental) faked sun. The second approach, renders astrophysical based skies with good results not only but especially at nightly scenes: correct star positions, atmosphere approximation, moon rendering including lunar eclipses and more. Further Contributions to OSG: - A useful, minimal astronomy library. - Good resources for both, texture based and physical based, approaches. - Solutions for common OSG issues, e.g., placing skies in arbitrary node structures, texture ping-ponging for post/pre processing, environment map rendering for reflection/illumination. - Starting point for cloud rendering. The current implementation is not very efficient though (TODO..) - Introduces no third parties, purely based on OSG (and optionally Qt for the editor)! For now, osgHimmel is mainly used internally at the Computer Graphics Systems group at the HPI (hpi3d.de), and the first integration into a commercial product is already in progress. We have two research projects, trying to extend the library by HDR, temporal-glare, Glare, simple as well as image based illumination. I would like to suggest an integration of osgHimmel into OSG, since a larger user base would convince me to keep osgHimmel alive and spent further development time on the library. What requirements must be met and what further steps have to be taken to make this integration possible (we can rename the lib to osgSky if this is a problem ;) )? Or is it better practice for such library to stay independent, without a direct OSG integration? I'm strongly interested in any ideas and concerns of this community concerning osgHimmel. All resources (including videos, demos, poster, my master's thesis, and a recent vmv2012 paper) are available at: http://osghimmel.googlecode.com recent poster with some images: https://osghimmel.googlecode.com/files/Daniel_Limberger_Poster.pdf Thanks a lot! And also thanks to this mailing list, which was of great help during development of osghimmel. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Integration of a NodeKit for Sky Rendering
Hi Daniel, Just had a look at the videos and poster. Very nice work :-) I haven't looked at the source code yet so can't comment on the suitability for merging with the core OSG, I am open to the idea if the code fits well with the rest of the OSG code base. It'd be great if others could dive and test out your NodeKit and provide feedback. Thanks, Robert. On 18 January 2013 15:13, Limberger, Daniel daniel.limber...@hpi.uni-potsdam.de wrote: From: Limberger, Daniel Sent: 18 January 2013 15:50 To: Engel, Juri Subject: Integration of a NodeKit for Sky Rendering into OSG Hi, I would like to present you my open source library osgHimmel that allows simple noninvasive rendering of background imagery (i.e., skies) within OSG. It currently is an OSG extending lib, that features two different techniques for sky rendering (or in traditional terms, skybox rendering): texture based (traditional) and computational (astrophysical). The first approach handles rendering of skies via common texture mapping techniques, extended by time based transitions, rotation around the zenith, horizon blending as well as an (experimental) faked sun. The second approach, renders astrophysical based skies with good results not only but especially at nightly scenes: correct star positions, atmosphere approximation, moon rendering including lunar eclipses and more. Further Contributions to OSG: - A useful, minimal astronomy library. - Good resources for both, texture based and physical based, approaches. - Solutions for common OSG issues, e.g., placing skies in arbitrary node structures, texture ping-ponging for post/pre processing, environment map rendering for reflection/illumination. - Starting point for cloud rendering. The current implementation is not very efficient though (TODO..) - Introduces no third parties, purely based on OSG (and optionally Qt for the editor)! For now, osgHimmel is mainly used internally at the Computer Graphics Systems group at the HPI (hpi3d.de), and the first integration into a commercial product is already in progress. We have two research projects, trying to extend the library by HDR, temporal-glare, Glare, simple as well as image based illumination. I would like to suggest an integration of osgHimmel into OSG, since a larger user base would convince me to keep osgHimmel alive and spent further development time on the library. What requirements must be met and what further steps have to be taken to make this integration possible (we can rename the lib to osgSky if this is a problem ;) )? Or is it better practice for such library to stay independent, without a direct OSG integration? I’m strongly interested in any ideas and concerns of this community concerning osgHimmel. All resources (including videos, demos, poster, my master’s thesis, and a recent vmv2012 paper) are available at: http://osghimmel.googlecode.com recent poster with some images: https://osghimmel.googlecode.com/files/Daniel_Limberger_Poster.pdf Thanks a lot! And also thanks to this mailing list, which was of great help during development of osghimmel. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Integration of a NodeKit for Sky Rendering
Looks very nice, Daniel! I especially like the lunar eclipse effect. Limberger, Daniel wrote on 2013-01-18: I would like to present you my open source library osgHimmel that allows simple noninvasive rendering of background imagery (i.e., skies) within OSG. It currently is an OSG extending lib, that features two different techniques for sky rendering (or in traditional terms, skybox rendering): texture based (traditional) and computational (astrophysical). The first approach handles rendering of skies via common texture mapping techniques, extended by time based transitions, rotation around the zenith, horizon blending as well as an (experimental) faked sun. The second approach, renders astrophysical based skies with good results not only but especially at nightly scenes: correct star positions, atmosphere approximation, moon rendering including lunar eclipses and more. Further Contributions to OSG: - A useful, minimal astronomy library. - Good resources for both, texture based and physical based, approaches. - Solutions for common OSG issues, e.g., placing skies in arbitrary node structures, texture ping-ponging for post/pre processing, environment map rendering for reflection/illumination. - Starting point for cloud rendering. The current implementation is not very efficient though (TODO..) - Introduces no third parties, purely based on OSG (and optionally Qt for the editor)! For now, osgHimmel is mainly used internally at the Computer Graphics Systems group at the HPI (hpi3d.de), and the first integration into a commercial product is already in progress. We have two research projects, trying to extend the library by HDR, temporal-glare, Glare, simple as well as image based illumination. I would like to suggest an integration of osgHimmel into OSG, since a larger user base would convince me to keep osgHimmel alive and spent further development time on the library. What requirements must be met and what further steps have to be taken to make this integration possible (we can rename the lib to osgSky if this is a problem ;) )? Or is it better practice for such library to stay independent, without a direct OSG integration? I'm strongly interested in any ideas and concerns of this community concerning osgHimmel. All resources (including videos, demos, poster, my master's thesis, and a recent vmv2012 paper) are available at: http://osghimmel.googlecode.com recent poster with some images: https://osghimmel.googlecode.com/files/Daniel_Limberger_Poster.pdf https://osghimmel.googlecode.com/files/Daniel_Limberger_Poster.pdf Thanks a lot! And also thanks to this mailing list, which was of great help during development of osghimmel. -- Bryan Thrall Principal Software Engineer FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Integration of a NodeKit for Sky Rendering
This nodekit is a godsend! And the license seems pretty permissive, too. Christian 2013/1/18 Limberger, Daniel daniel.limber...@hpi.uni-potsdam.de ** ** ** ** *From:* Limberger, Daniel *Sent:* 18 January 2013 15:50 *To:* Engel, Juri *Subject:* Integration of a NodeKit for Sky Rendering into OSG ** ** Hi, ** ** I would like to present you my open source library osgHimmel that allows simple noninvasive rendering of background imagery (i.e., skies) within OSG. It currently is an OSG extending lib, that features two different techniques for sky rendering (or in traditional terms, skybox rendering): texture based (traditional) and computational (astrophysical). ** ** The first approach handles rendering of skies via common texture mapping techniques, extended by time based transitions, rotation around the zenith, horizon blending as well as an (experimental) faked sun. ** ** The second approach, renders astrophysical based skies with good results not only but especially at nightly scenes: correct star positions, atmosphere approximation, moon rendering including lunar eclipses and more. ** ** Further Contributions to OSG: **- **A useful, minimal astronomy library. **- **Good resources for both, texture based and physical based, approaches. **- **Solutions for common OSG issues, e.g., placing skies in arbitrary node structures, texture ping-ponging for post/pre processing, environment map rendering for reflection/illumination. **- **Starting point for cloud rendering. The current implementation is not very efficient though (TODO..) **- **Introduces no third parties, purely based on OSG (and optionally Qt for the editor)! ** ** For now, osgHimmel is mainly used internally at the Computer Graphics Systems group at the HPI (hpi3d.de), and the first integration into a commercial product is already in progress. We have two research projects, trying to extend the library by HDR, temporal-glare, Glare, simple as well as image based illumination. ** ** I would like to suggest an integration of osgHimmel into OSG, since a larger user base would convince me to keep osgHimmel alive and spent further development time on the library. What requirements must be met and what further steps have to be taken to make this integration possible (we can rename the lib to osgSky if this is a problem ;) )? Or is it better practice for such library to stay independent, without a direct OSG integration? ** ** I’m strongly interested in any ideas and concerns of this community concerning osgHimmel. ** ** ** ** All resources (including videos, demos, poster, my master’s thesis, and a recent vmv2012 paper) are available at: http://osghimmel.googlecode.com ** ** recent poster with some images: https://osghimmel.googlecode.com/files/Daniel_Limberger_Poster.pdf ** ** Thanks a lot! And also thanks to this mailing list, which was of great help during development of osghimmel. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Integration of a NodeKit for Sky Rendering
Hi Daniel, Great job! You may want to add your project to the community projects[1] section in the new web or/and post a new to the community news section[2]... :) Cheers. [1]http://www.openscenegraph.com/index.php/community/projects [2]http://www.openscenegraph.com/index.php/community/news 2013/1/18 Christian Buchner christian.buch...@gmail.com This nodekit is a godsend! And the license seems pretty permissive, too. Christian 2013/1/18 Limberger, Daniel daniel.limber...@hpi.uni-potsdam.de ** ** ** ** *From:* Limberger, Daniel *Sent:* 18 January 2013 15:50 *To:* Engel, Juri *Subject:* Integration of a NodeKit for Sky Rendering into OSG ** ** Hi, ** ** I would like to present you my open source library osgHimmel that allows simple noninvasive rendering of background imagery (i.e., skies) within OSG. It currently is an OSG extending lib, that features two different techniques for sky rendering (or in traditional terms, skybox rendering): texture based (traditional) and computational (astrophysical). ** ** The first approach handles rendering of skies via common texture mapping techniques, extended by time based transitions, rotation around the zenith, horizon blending as well as an (experimental) faked sun. ** ** The second approach, renders astrophysical based skies with good results not only but especially at nightly scenes: correct star positions, atmosphere approximation, moon rendering including lunar eclipses and more. ** ** Further Contributions to OSG: **- **A useful, minimal astronomy library. **- **Good resources for both, texture based and physical based, approaches. **- **Solutions for common OSG issues, e.g., placing skies in arbitrary node structures, texture ping-ponging for post/pre processing, environment map rendering for reflection/illumination. **- **Starting point for cloud rendering. The current implementation is not very efficient though (TODO..) **- **Introduces no third parties, purely based on OSG (and optionally Qt for the editor)! ** ** For now, osgHimmel is mainly used internally at the Computer Graphics Systems group at the HPI (hpi3d.de), and the first integration into a commercial product is already in progress. We have two research projects, trying to extend the library by HDR, temporal-glare, Glare, simple as well as image based illumination. ** ** I would like to suggest an integration of osgHimmel into OSG, since a larger user base would convince me to keep osgHimmel alive and spent further development time on the library. What requirements must be met and what further steps have to be taken to make this integration possible (we can rename the lib to osgSky if this is a problem ;) )? Or is it better practice for such library to stay independent, without a direct OSG integration? ** ** I’m strongly interested in any ideas and concerns of this community concerning osgHimmel. ** ** ** ** All resources (including videos, demos, poster, my master’s thesis, and a recent vmv2012 paper) are available at: http://osghimmel.googlecode.com ** ** recent poster with some images: https://osghimmel.googlecode.com/files/Daniel_Limberger_Poster.pdf ** ** Thanks a lot! And also thanks to this mailing list, which was of great help during development of osghimmel. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Jordi ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Integration of a NodeKit for Sky Rendering
Nice work. I'm going to try it out soon, and hopefully I can add it to our build system shortly. On Fri, Jan 18, 2013 at 11:00 AM, Jordi Torres jtorresfa...@gmail.comwrote: Hi Daniel, Great job! You may want to add your project to the community projects[1] section in the new web or/and post a new to the community news section[2]... :) Cheers. [1]http://www.openscenegraph.com/index.php/community/projects [2]http://www.openscenegraph.com/index.php/community/news 2013/1/18 Christian Buchner christian.buch...@gmail.com This nodekit is a godsend! And the license seems pretty permissive, too. Christian 2013/1/18 Limberger, Daniel daniel.limber...@hpi.uni-potsdam.de ** ** ** ** *From:* Limberger, Daniel *Sent:* 18 January 2013 15:50 *To:* Engel, Juri *Subject:* Integration of a NodeKit for Sky Rendering into OSG ** ** Hi, ** ** I would like to present you my open source library osgHimmel that allows simple noninvasive rendering of background imagery (i.e., skies) within OSG. It currently is an OSG extending lib, that features two different techniques for sky rendering (or in traditional terms, skybox rendering): texture based (traditional) and computational (astrophysical). ** ** The first approach handles rendering of skies via common texture mapping techniques, extended by time based transitions, rotation around the zenith, horizon blending as well as an (experimental) faked sun. ** ** The second approach, renders astrophysical based skies with good results not only but especially at nightly scenes: correct star positions, atmosphere approximation, moon rendering including lunar eclipses and more. ** ** Further Contributions to OSG: **- **A useful, minimal astronomy library. **- **Good resources for both, texture based and physical based, approaches. **- **Solutions for common OSG issues, e.g., placing skies in arbitrary node structures, texture ping-ponging for post/pre processing, environment map rendering for reflection/illumination. **- **Starting point for cloud rendering. The current implementation is not very efficient though (TODO..) **- **Introduces no third parties, purely based on OSG (and optionally Qt for the editor)! ** ** For now, osgHimmel is mainly used internally at the Computer Graphics Systems group at the HPI (hpi3d.de), and the first integration into a commercial product is already in progress. We have two research projects, trying to extend the library by HDR, temporal-glare, Glare, simple as well as image based illumination. ** ** I would like to suggest an integration of osgHimmel into OSG, since a larger user base would convince me to keep osgHimmel alive and spent further development time on the library. What requirements must be met and what further steps have to be taken to make this integration possible (we can rename the lib to osgSky if this is a problem ;) )? Or is it better practice for such library to stay independent, without a direct OSG integration? ** ** I’m strongly interested in any ideas and concerns of this community concerning osgHimmel. ** ** ** ** All resources (including videos, demos, poster, my master’s thesis, and a recent vmv2012 paper) are available at: http://osghimmel.googlecode.com ** ** recent poster with some images: https://osghimmel.googlecode.com/files/Daniel_Limberger_Poster.pdf ** ** Thanks a lot! And also thanks to this mailing list, which was of great help during development of osghimmel. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Jordi ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com http://www.alphapixel.com/ Training • Consulting • Contracting 3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 • GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL Digital Imaging • GIS • GPS • osgEarth • Terrain • Telemetry • Cryptography • Digital Audio • LIDAR • Kinect • Embedded • Mobile • iPhone/iPad/iOS • Android @alphapixel https://twitter.com/alphapixel facebook.com/alphapixel (775) 623-PIXL [7495] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
