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