Re: [osg-users] Basic whitepaper on LOD in OpenSceneGraph

2013-01-18 Thread Sebastian Messerschmidt

Hello Chris,

A useful concentrate. Thank you for providing it.

cheers
Sebastian


  I pulled out some material I developed for various training seminars 
in the past and polished it up a bit as a whitepaper:


http://alphapixel.com/content/level-detail-lod-openscenegraph

  If anyone has any corrections or comments, shoot me a note.

  I have another one about the structure and workings of VPB databases 
that I'll try to get out in the next couple of weeks.



--
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 
http://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


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] how to buildethe debug version of osg under Linux?

2013-01-18 Thread rocco martino
Hi,

move to the OSG folder and type:
 cmake . -DCMAKE_BUILD_TYPE=Debug


Have a nice day,
Martino


2013/1/18 Lv Qing donlvq...@msn.com

 Hi,

  When I cmake the osg source under Linux,it seems to bulid the release
 version by default.Just want to know how to bulid the debug version :)
 ...

 Thank you!

 Cheers,
 Lv

 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=52005#52005





 ___
 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] how to buildethe debug version of osg under Linux?

2013-01-18 Thread Jan Ciger
On Fri, Jan 18, 2013 at 5:24 AM, Lv Qing donlvq...@msn.com wrote:

 Hi,

  When I cmake the osg source under Linux,it seems to bulid the release
 version by default.Just want to know how to bulid the debug version :)


Run ccmake or cmake-gui and change build type variable to Debug. You can
also do it using regular cmake using a command line argument/define, but I
don't recall the syntax from memory. However, I believe that, unless OSG
sets this explicitly, the CMake default is a debug build if nothing is
specified explicitly.

Regards,

Jan
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


[osg-users] Picking child node results in parent node returned first

2013-01-18 Thread michael kapelko
Hi.

I'm trying to pick a child node of another node.
Here's the example source code:

https://dl.dropbox.com/u/12634473/osg/osg_pick.tar.bz2

Here's the log of running it: http://pastie.org/5715829

First, you can see my scene structer.

And then goes 2 clicks:
1) I click cessna and MatrixTransform named 'cessna' is first in the
returned nodePath.
2) I click cessna's child cow, and somehow first MatrixTransform named
'cessna' is returned in nodePath, and only then 'cow'.

Why is that? And how do I get 'cow' as the first in the nodePath?
Thanks.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] how to buildethe debug version of osg under Linux?

2013-01-18 Thread Cary, Karl A.
Remember that by default OSG will append a 'd' to the library name so
make sure your build system for your application handles that when
building in debug mode, otherwise it will continue to link to the normal
libraries. To make myself clearer, for example, you would normally use
libosg.so, but the debug library will be libosgd.so.  If you have it set
up to handle this already great, but if not, like I had to, you will
need to account for it.

 

From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jan
Ciger
Sent: Friday, January 18, 2013 4:31 AM
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] how to buildethe debug version of osg under
Linux?

 

 

On Fri, Jan 18, 2013 at 5:24 AM, Lv Qing donlvq...@msn.com wrote:

Hi,

 When I cmake the osg source under Linux,it seems to bulid the
release version by default.Just want to know how to bulid the debug
version :)


Run ccmake or cmake-gui and change build type variable to Debug. You can
also do it using regular cmake using a command line argument/define, but
I don't recall the syntax from memory. However, I believe that, unless
OSG sets this explicitly, the CMake default is a debug build if nothing
is specified explicitly.

Regards,

Jan

 

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] how to buildethe debug version of osg under Linux?

2013-01-18 Thread Jan Ciger
On Fri, Jan 18, 2013 at 1:01 PM, Cary, Karl A. karl.a.c...@saic.com wrote:

 Remember that by default OSG will append a ‘d’ to the library name so make
 sure your build system for your application handles that when building in
 debug mode, otherwise it will continue to link to the normal libraries. To
 make myself clearer, for example, you would normally use libosg.so, but the
 debug library will be libosgd.so.  If you have it set up to handle this
 already great, but if not, like I had to, you will need to account for it.


Does it actually do that in Linux? I don't think it does, but I may be
wrong - I haven't rebuilt mine in a while. This is necessary in Windows
because you must not mix debug and release builds, but in Linux it is no
problem.

Jan
___
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

2013-01-18 Thread Limberger, Daniel


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] [osgPlugins] osgShadow LiSPSM culling problem

2013-01-18 Thread Garrett Cope
Hi Robert,

This is a super-delayed follow-up but I've finally circled back around to this 
issue.

Using the standard osgshadow example I can reproduce the general problem I'm 
having (shadows being clipped prior to the edge of the screen) by running with 
the following parameters:

osgshadow --directionalLight --light-dir 0.969358 -0.218775 -0.111722 
--noUpdate --vdsm -3

Then if you hit '3' to change navigation mode and move the mouse right such 
that the models move towards the left edge of the screen, you will see that 
near the edge shadows on the sphere get clipped out entirely.

This is the behavior that I am seeing in many other instances in my own testing 
and have narrowed it down to the clipping but not made it much farther than 
that.

Any insight you have would be greatly appreciated.

... 

Thank you!

Cheers,
Garrett

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=52013#52013





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] [osgPlugins] osgShadow LiSPSM culling problem

2013-01-18 Thread Robert Osfield
Hi Garret,

I used your suggestion command line options but haven't spotted the
clipping issue yet.  I'm using svn/trunk version of the OSG.  Which
version are you using?

Could you record an animation path by pressing 'z' to start and again
'z' to stop and save to a saved_animation.path file.  This file can be
passed to osgshadow on the command line by adding -p
saved_animation.path.  Using this method it's possible to reproduce
exactly the same camera angles, and can be attached to an email so
that others can reproduce exactly what you are testing.

Thanks,
Robert.

On 18 January 2013 15:25, Garrett Cope
garrett.cope@simcen.usuhs.edu wrote:
 osgshadow --directionalLight --light-dir 0.969358 -0.218775 -0.111722 
 --noUpdate --vdsm -3
___
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

2013-01-18 Thread Robert Osfield
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] [osgPlugins] osgShadow LiSPSM culling problem

2013-01-18 Thread Garrett Cope
Hi Robert,

Thanks for the quick reply.

I am using 3.1.1 with the hopes of remaining somewhat stable. ;)
Perhaps I should try the svn/trunk version.

Attached is the animation path that shows the clipping on my installation. The 
forum would not allow the *.path extension so I change it to .txt

Thanks again.

Cheers,
Garrett

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=52016#52016




Attachments: 
http://forum.openscenegraph.org//files/saved_animation_139.txt


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] how to buildethe debug version of osg under Linux?

2013-01-18 Thread Cary, Karl A.
Yes. You can change it, but by default it appends the 'd' to the name.

 

From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jan
Ciger
Sent: Friday, January 18, 2013 8:50 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] how to buildethe debug version of osg under
Linux?

 

 

On Fri, Jan 18, 2013 at 1:01 PM, Cary, Karl A. karl.a.c...@saic.com
wrote:

Remember that by default OSG will append a 'd' to the library name so
make sure your build system for your application handles that when
building in debug mode, otherwise it will continue to link to the normal
libraries. To make myself clearer, for example, you would normally use
libosg.so, but the debug library will be libosgd.so.  If you have it set
up to handle this already great, but if not, like I had to, you will
need to account for it.

 

Does it actually do that in Linux? I don't think it does, but I may be
wrong - I haven't rebuilt mine in a while. This is necessary in Windows
because you must not mix debug and release builds, but in Linux it is no
problem. 

Jan

___
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

2013-01-18 Thread Thrall, Bryan
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

2013-01-18 Thread Christian Buchner
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

2013-01-18 Thread Jordi Torres
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

2013-01-18 Thread Chris Hanson
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


Re: [osg-users] Basic whitepaper on LOD in OpenSceneGraph

2013-01-18 Thread Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC
Both would be great to have. Thank you...

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Chris
Hanson
Sent: Thursday, January 17, 2013 5:35 PM
To: OpenSceneGraph Users
Subject: [osg-users] Basic whitepaper on LOD in OpenSceneGraph


  I pulled out some material I developed for various training seminars
in the past and polished it up a bit as a whitepaper:

http://alphapixel.com/content/level-detail-lod-openscenegraph


  If anyone has any corrections or comments, shoot me a note.

  I have another one about the structure and workings of VPB databases
that I'll try to get out in the next couple of weeks.


-- 

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