[osg-users] Bounding Box

Hi, I have a stupid question. What is a bounding box and how to use it? Thank you! Cheers, Julie -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=65003#65003 ___ osg-users mailing list osg-users@list

Re: [osg-users] Oculus+OSG

cbuchner1 wrote: > Trying to build the current osgoculus master branch against Oculus SDK > 0.7.0.0 using OSG 3.2.1 > > > the following code from oculusdevice.cpp is making trouble. For OSG 3.2  the > variable "ctx" is undefined. > > void OculusTextureBuffer::setRenderSurface(const osg::State

Re: [osg-users] OSG BOF at SIGGRAPH was a SUCCESS

The presentation I did is on-line at http://www.nist.gov/itl/math/hpcvg/pubs.cfm I added a narration, so its now a 9 minute video. -Steve Satterfield st...@nist.gov On Fri, 14 Aug 2015, John Richardson wrote: Hello, Thanks to Robert for his "future of OSG" slides. Thanks to David Gle

Re: [osg-users] Floating point depth buffer

I also recommend using the Triton height map support to make the shorelines look better. It will fade out the ocean geometry as the bathymetry slopes up towards sea level. Logarithmic depth buffer is handy for various Triton use cases. If you go that route, remember to also reduce your near/far ra

Re: [osg-users] Floating point depth buffer

Hi Mike, On 2 September 2015 at 16:09, Mike Greene wrote: > Having problems with Z-fighting when using a very large terrain database > and mixing it with Triton ocean - seeing lots of z-fighting along the coast > line where the water and the terrain depths are nearly the same. I can > alleviate

Re: [osg-users] Floating point depth buffer

Hi Mike, http://sundog-soft.com/sds/2015/06/using-an-opengl-logarithmic-depth-buffer-in-silverlining-and-triton/ It will help alot with high z-ranges, but I had trouble inverting the function in my deferred pipeline, so I cannot use it right now. Initial tests however yielded great results. H

Re: [osg-users] Floating point depth buffer

Hi Mike, have you tried using of height map with Triton? I am aware of the same issue and considering logarithmic depth buffer ... Suggested by Frank Nick On Wed, Sep 2, 2015 at 5:09 PM, Mike Greene wrote: > Having problems with Z-fighting when using a very large terrain database > and mixing

[osg-users] Floating point depth buffer

Having problems with Z-fighting when using a very large terrain database and mixing it with Triton ocean - seeing lots of z-fighting along the coast line where the water and the terrain depths are nearly the same. I can alleviate the problem by reducing the near/far clip boundaries, but this is

Re: [osg-users] Qt5 integration

Hi James, sorry for the late reply! Please, feel free to review and merge my code, let me know if you need clarifications. Ricky On Mon, Aug 24, 2015 at 4:03 PM, James Turner wrote: > > On 17 Aug 2015, at 17:33, Riccardo Corsi > wrote: > > > Thanks Ricky. > > From my point of view the most de

Re: [osg-users] Oculus+OSG

A followup: inserting the following line into both #else branches fixes it const unsigned int ctx = state.getContextID(); 2015-09-02 11:06 GMT+02:00 Christian Buchner : > > Trying to build the current osgoculus master branch against Oculus SDK > 0.7.0.0 using OSG 3.2.1 > > the following code fr

Re: [osg-users] Oculus+OSG

Trying to build the current osgoculus master branch against Oculus SDK 0.7.0.0 using OSG 3.2.1 the following code from oculusdevice.cpp is making trouble. For OSG 3.2 the variable "ctx" is undefined. void OculusTextureBuffer::setRenderSurface(const osg::State& state) { #if(OSG_VERSION_GREATER_OR_

[osg-users] shadows in an GL 3.2 / glsl 1.5 environment

Dear all, I need to do shadows in an GL 3.2 / glsl 1.5 environment. I was using osgShadow with LightSpacePerspectiveShadowMapCB technique before moving to 3.2/1.5. I tried to track down the necessary actions and I think I have to solve 3 items: 1) Assigning new shaders to the technique (Standa

Re: [osg-users] Quat::makeRotate potential division by zero

Thanks guys. Personally I third your opinions, but wanted to bring it up. cheers Mattias On Wed, Sep 2, 2015 at 9:56 AM, Sebastian Messerschmidt wrote: > Hi Matthias, > > I second Robert's opinion. Passing a zero-length vector simply causes in > invalid results to be calculated. > My vote would b

Re: [osg-users] Quat::makeRotate potential division by zero

Hi Matthias, I second Robert's opinion. Passing a zero-length vector simply causes in invalid results to be calculated. My vote would be towards using an assert, so the user is noticed in debug builds about the potentially wrong results. Thats what some other libraries do to hint invalid parame

Re: [osg-users] Quat::makeRotate potential division by zero

Hi Mattias, On 2 September 2015 at 08:24, Mattias Helsing wrote: > I guess it's to old performance vs user-friendliness problem, and > that's why I wanted to bring it up here before submitting anything. > > What do you think? > For code that used in inner loops I generally prefer to avoid extr

[osg-users] Quat::makeRotate potential division by zero

Hi Our team chased down a bug where we passed an invalid rotation vector to: void osg::Quat::makeRotate(const osg::Vec3d& from, const osg::Vec3d& to) we passed an all zeroes Vec3d in the from parameter. This is then used to normalize the vector, which causes INF values and lots of bad things fur

Re: [osg-users] Open Scene Graph 3.4.0 has bug when using two monitor setup

Hi Thomas, Only see the osgviewer.zip.002, was there an .001. I'm a bit perplexed by needing to zip a stack trace up. I work predominatly under Linux so Windows specific files are far less useful than straight text outputs for things like stack traces. Aside for the stack trace issues, one thing