Re: [osg-users] How can I get the viewer's camera to 'ignore' a node's geometry?

[Preet]

On Sat, Oct 6, 2012 at 1:02 AM, Preet  wrote:
> Sergey's suggestion (invalidating the geometry's bounds with a custom
> compute bounds callback) sort of worked, but led into another issue.
> If I zoom out far enough, the Earth surface geometry disappears.
> Specifically, if the camera is pointing at the center of the Earth,
> the Earth geometry disappears when the camera eye is further than
> ~5.13E6m from the surface of the Earth. Changing the near and far
> planes don't have any effect here.
>
> However, if I disable culling I don't have this problem (but disabling
> culling kills the framerate):
> myCam->setCullingMode(osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR);

Sorry, typo above, I meant to write:
myCam->setCullingMode(osg::CullSettings::NO_CULLING);

>
> So right now I'm:
>
> * Setting the near and far plane manually
> (myCam->setComputeNearFarMode is set to DO_NOT_COMPUTE) whenever the
> camera is updated to ensure my desired view volume is correct
> * Setting the Earth surface geometry compute bounds callback to disabled
>
> And that works fine up until I move the camera out far enough as I
> described previously. Something happens at that causes the geometry to
> disappear unless I disable culling altogether.
>
>
> Preet
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] How can I get the viewer's camera to 'ignore' a node's geometry?

[Preet]

Sergey's suggestion (invalidating the geometry's bounds with a custom
compute bounds callback) sort of worked, but led into another issue.
If I zoom out far enough, the Earth surface geometry disappears.
Specifically, if the camera is pointing at the center of the Earth,
the Earth geometry disappears when the camera eye is further than
~5.13E6m from the surface of the Earth. Changing the near and far
planes don't have any effect here.

However, if I disable culling I don't have this problem (but disabling
culling kills the framerate):
myCam->setCullingMode(osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR);

So right now I'm:

* Setting the near and far plane manually
(myCam->setComputeNearFarMode is set to DO_NOT_COMPUTE) whenever the
camera is updated to ensure my desired view volume is correct
* Setting the Earth surface geometry compute bounds callback to disabled

And that works fine up until I move the camera out far enough as I
described previously. Something happens at that causes the geometry to
disappear unless I disable culling altogether.


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

Re: [osg-users] Backward compatibility with custom serializers

[Farshid Lashkari]

Hi Wang,

On Fri, Oct 5, 2012 at 10:19 AM, Wang Rui  wrote:
>
> Oh, this seems to be already discussed in another thread. I was
> thinking of implementing a user version macro at that time but then I
> was a little too busy to worked on it. I will consider adding a new
> UPDATE_TO_USER_VERSION macro to allow version control of custom
> serializers as soon as possible, maybe tomorrow. :-)
>


Sorry, I missed that thread. That sounds excellent!



> Yes, this is a bug just found in osgWrappers/serializers/osg/Node.cpp,
> which uses UPDATE_TO_VERSION incorrectly so it also affects the
> following StateSet serializer. I think the brackets after the macro
> really confuses us and will do something soon to make it more
> readable.
>

Great news, I was worried there for a second :)

Cheers,
Farshid



>
> Thanks,
>
> Wang Rui
> ___
> 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] osg::PPU texel 0,0 in depthbuffer is wrong

[Peterakos]

Hello.

This is what i use for depth texture creation:

osg::Texture2D* texture2D = new osg::Texture2D;
texture2D->setTextureSize(tex_width, tex_height);
texture2D->setInternalFormat(GL_RGBA);
texture2D->setFilter(osg::Texture2D::MIN_FILTER,osg::Texture2D::LINEAR);
texture2D->setFilter(osg::Texture2D::MAG_FILTER,osg::Texture2D::LINEAR);
texture2D->setWrap( osg::Texture::WRAP_S, osg::Texture::REPEAT );
texture2D->setWrap( osg::Texture::WRAP_R, osg::Texture::REPEAT );
texture2D->setInternalFormat(GL_DEPTH_COMPONENT);

I have also attached an image which shows that the fragment shader result.
If you watch closely in the middle, you will notice that the image is
separated into 4 pieces.

What i do is creating a UnitInOut which receives the depth buffer and
writing each pixel result to gl_FragData[0].
As you can see in the picture, i paint as red the pixels which have depth
value 1.
But when i access these pixels while another pixel is being iterated, i get
different depth value.

Why is this happening ?

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

Re: [osg-users] How can I get the viewer's camera to 'ignore' a node's geometry?

[Glenn Waldron]

Indeed, my mistake.

Glenn Waldron / @glennwaldron


On Fri, Oct 5, 2012 at 4:07 PM, Sergey Polischuk  wrote:

> Hi
>
> I'm talking about setting this bounds callbacks on geometry(drawable)
> leaves.
>
> 05.10.2012, 17:20, "Glenn Waldron" :
>
> Is that true? Setting an invalid bounding sphere will indeed suppress
> node-level culling, but I believe the near/far calculation is done at the
> Drawable level. See CullVisitor::apply(Geode&).
> The usual approach for terrain rendering is to subdivide your globe into
> tiles. Then OSG can cull out the tiles that are not in the view, including
> far-off tiles or back-facing tiles (by means of the
> ClusterCullingCallback). That will bring the far clip plane closer and give
> you the z-buffer resolution you need in order to visualize surface
> features.
> In addition, you can decrease the Camera's near/far ratio; this will give
> you a little more near clip space if you still need it.
>
> Glenn Waldron / @glennwaldron
>
>
> On Fri, Oct 5, 2012 at 7:28 AM, Sergey Polischuk  wrote:
>
> Hi
>
> You can set ComputeBoundingBoxCallback on a geometry to specify whatever
> bounds you want. In your case to ignore earth geometry bound you can set
> its bound to uninitialized bounding box, and it will not make any
> difference to near\far calculations. Note that this thing completely
> disable view frustum culling on a geometry! In order to get it working you
> should write your cull callback and do check vs actual bounds there, if you
> need it.
>
> Code looks like:
>
> class UseInitialBoundsCallback : public
> osg::Drawable::ComputeBoundingBoxCallback
> {
> public:
> osg::BoundingBox computeBound (const osg::Drawable & drawable)
> {
> osg::BoundingBox brand_new_uninitialized_bbox;
> return brand_new_uninitialized_bbox;
> }
> };
>
> geometry->setComputeBoundingBoxCallback(new UseInitialBoundsCallback);
>
> Cheers, Sergey.
>
> 05.10.2012, 05:11, "Preet" :
> > On Thu, Oct 4, 2012 at 5:37 PM, Chris Hanson 
> wrote:
> >
> >>  I wanted to avoid specifying the near/far planes manually since the
> >>>  behaviour without the Earth surface geometry is perfect as is. I don't
> >>>  care about the overhead of drawing the surface geometry since its so
> >>>  simple, and I don't want the scene graph to account for the surface
> >>>  geometry (outside of rendering it); the other objects in the scene
> >>>  should determine the camera frustum.
> >>Due to the way OGL works with near/far, if you want it drawn, you
> need it
> >>  taken into account when computing the near/far planes.
> >>
> >>Are you just worried about the far plane being set too far?
> >>>  Including geometry for the
> >>  Earth's surface makes the other stuff disappear (and reappear at
> >>  certain angles).
> >>
> >>It sounds to me like you're not trying to solve the right problem.
> You
> >>  should first determine WHY these other items aren't displayed at times.
>
> >
> > Sorry if it wasn't clear; the items aren't being displayed because the
> > near and far planes that osg sets creates a frustum that doesn't
> > include them. I need to manually set the near and far planes to see
> > everything.
> >
> > The near and far planes that osg sets without the earth surface
> > geometry is fine. Once you add the surface geometry though, the near
> > and far planes are set such that the items are no long in the view
> > frustum.
> >
> > I was looking for a flag or something that basically tells osg "hey,
> > don't include this node when you do your view frustum calculations"
>
> > ___
> > 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
>
> ,
>
> ___
> 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
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] [vpb] osgdem --image-ext option working

[Paul Leopard]

So I have failed in getting the '--image-ext' option to work on osgdem. I have 
tried changing the outfile format to ive, osgb, etc ... still it doesn't output 
any individual image files. Here is the syntax I am using :


Code:
osgdem -d heightmap.tif -t texture.tif -l 3 -o test.ive --image-ext png



There are no .png files in the model output. Am I doing something wrong or does 
this feature just not work?

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





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

Re: [osg-users] How can I get the viewer's camera to 'ignore' a node's geometry?

[Sergey Polischuk]

Hi I'm talking about setting this bounds callbacks on geometry(drawable) leaves. 05.10.2012, 17:20, "Glenn Waldron" :Is that true? Setting an invalid bounding sphere will indeed suppress node-level culling, but I believe the near/far calculation is done at the Drawable level. See CullVisitor::apply(Geode&). The usual approach for terrain rendering is to subdivide your globe into tiles. Then OSG can cull out the tiles that are not in the view, including far-off tiles or back-facing tiles (by means of the ClusterCullingCallback). That will bring the far clip plane closer and give you the z-buffer resolution you need in order to visualize surface features. In addition, you can decrease the Camera's near/far ratio; this will give you a little more near clip space if you still need it.Glenn Waldron / @glennwaldron On Fri, Oct 5, 2012 at 7:28 AM, Sergey Polischuk  wrote:Hi  You can set ComputeBoundingBoxCallback on a geometry to specify whatever bounds you want. In your case to ignore earth geometry bound you can set its bound to uninitialized bounding box, and it will not make any difference to near\far calculations. Note that this thing completely disable view frustum culling on a geometry! In order to get it working you should write your cull callback and do check vs actual bounds there, if you need it.  Code looks like:  class UseInitialBoundsCallback : public osg::Drawable::ComputeBoundingBoxCallback { public:         osg::BoundingBox computeBound (const osg::Drawable & drawable)         {                 osg::BoundingBox brand_new_uninitialized_bbox;                 return brand_new_uninitialized_bbox;         } };  geometry->setComputeBoundingBoxCallback(new UseInitialBoundsCallback);  Cheers, Sergey.  05.10.2012, 05:11, "Preet" : > On Thu, Oct 4, 2012 at 5:37 PM, Chris Hanson  wrote: > >>  I wanted to avoid specifying the near/far planes manually since the >>>  behaviour without the Earth surface geometry is perfect as is. I don't >>>  care about the overhead of drawing the surface geometry since its so >>>  simple, and I don't want the scene graph to account for the surface >>>  geometry (outside of rendering it); the other objects in the scene >>>  should determine the camera frustum. >>    Due to the way OGL works with near/far, if you want it drawn, you need it >>  taken into account when computing the near/far planes. >> >>    Are you just worried about the far plane being set too far? >>>  Including geometry for the >>  Earth's surface makes the other stuff disappear (and reappear at >>  certain angles). >> >>    It sounds to me like you're not trying to solve the right problem. You >>  should first determine WHY these other items aren't displayed at times. > > Sorry if it wasn't clear; the items aren't being displayed because the > near and far planes that osg sets creates a frustum that doesn't > include them. I need to manually set the near and far planes to see > everything. > > The near and far planes that osg sets without the earth surface > geometry is fine. Once you add the surface geometry though, the near > and far planes are set such that the items are no long in the view > frustum. > > I was looking for a flag or something that basically tells osg "hey, > don't include this node when you do your view frustum calculations" > ___ > 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,___osg-users mailing listosg-users@lists.openscenegraph.orghttp://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

[osg-users] [vpb] vpbsizes interpretation

[Paul Leopard]

Hi, I'm sort of new to vpb, having used it heavily for a few weeks now. Anyway, 
I am trying to understand the vpbsizes utility and what it means. Below is the 
output of the command 'vpbsizes --size 256 128', can anyone interpret these 
numbers for me or point me to a reference that will explain it?

Thanks,
Paul


Code:
source data resolution = 156543m
Source width = 256 height = 128
 level 1 dimension = (2, 1) numLevels = 1 finalSize = (510 255) efficiency = 
3.96881numLevels = 0 finalSize = (255 255) undersampling = 1.98441
 level 1 dimension = (4, 2) numLevels = 1 finalSize = (1020 510) efficiency = 
15.8752   numLevels = 0 finalSize = (255 255) undersampling = 1.98441
 level 1 dimension = (6, 3) numLevels = 1 finalSize = (1530 765) efficiency = 
35.7193   numLevels = 0 finalSize = (255 255) undersampling = 1.98441
 level 1 dimension = (8, 4) numLevels = 1 finalSize = (2040 1020) efficiency = 
63.501   numLevels = 0 finalSize = (255 255) undersampling = 1.98441
 level 1 dimension = (10, 5) numLevels = 1 finalSize = (2550 1275) efficiency = 
99.2203 numLevels = 0 finalSize = (255 255) undersampling = 1.98441
 level 1 dimension = (12, 6) numLevels = 1 finalSize = (3060 1530) efficiency = 
142.877 numLevels = 0 finalSize = (255 255) undersampling = 1.98441
 level 1 dimension = (14, 7) numLevels = 1 finalSize = (3570 1785) efficiency = 
194.472 numLevels = 0 finalSize = (255 255) undersampling = 1.98441
 level 1 dimension = (16, 8) numLevels = 1 finalSize = (4080 2040) efficiency = 
254.004 numLevels = 0 finalSize = (255 255) undersampling = 1.98441
 level 1 dimension = (18, 9) numLevels = 1 finalSize = (4590 2295) efficiency = 
321.474 numLevels = 0 finalSize = (255 255) undersampling = 1.98441
 level 1 dimension = (20, 10) numLevels = 1 finalSize = (5100 2550) efficiency 
= 396.881numLevels = 0 finalSize = (255 255) undersampling = 1.98441
 level 1 dimension = (22, 11) numLevels = 1 finalSize = (5610 2805) efficiency 
= 480.226numLevels = 0 finalSize = (255 255) undersampling = 1.98441
 level 1 dimension = (24, 12) numLevels = 1 finalSize = (6120 3060) efficiency 
= 571.509numLevels = 0 finalSize = (255 255) undersampling = 1.98441
 level 1 dimension = (26, 13) numLevels = 1 finalSize = (6630 3315) efficiency 
= 670.729numLevels = 0 finalSize = (255 255) undersampling = 1.98441
 level 1 dimension = (28, 14) numLevels = 1 finalSize = (7140 3570) efficiency 
= 777.887numLevels = 0 finalSize = (255 255) undersampling = 1.98441
 level 1 dimension = (30, 15) numLevels = 1 finalSize = (7650 3825) efficiency 
= 892.982numLevels = 0 finalSize = (255 255) undersampling = 1.98441
 level 1 dimension = (32, 16) numLevels = 1 finalSize = (8160 4080) efficiency 
= 1016.02numLevels = 0 finalSize = (255 255) undersampling = 1.98441
 level 1 dimension = (34, 17) numLevels = 1 finalSize = (8670 4335) efficiency 
= 1146.99numLevels = 0 finalSize = (255 255) undersampling = 1.98441
 level 1 dimension = (36, 18) numLevels = 1 finalSize = (9180 4590) efficiency 
= 1285.89numLevels = 0 finalSize = (255 255) undersampling = 1.98441
 level 1 dimension = (38, 19) numLevels = 1 finalSize = (9690 4845) efficiency 
= 1432.74numLevels = 0 finalSize = (255 255) undersampling = 1.98441



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





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

[osg-users] Building on Android

[Eduardo Poyart]

Hello,

I'm having a problem building for Android. I can build OSG, but when I
try to build the GLES1 example I have these linker errors:

/home/eduardo/src/osg/osg-android/obj/local/armeabi-v7a/libosgdb_osg.a(ReaderWri
terOSG.o): In function `OSGReaderWriter::setPrecision(osgDB::Output&, osgDB::Opt
ions const*) const':
/home/eduardo/src/osg/OpenSceneGraph/src/osgPlugins/osg/ReaderWriterOSG.cpp:295:
 undefined reference to `std::basic_istringstream,
std::allocator >::basic_istringstream(std::basic_string, std::allocator > const&, std::_Ios_Openmode)'
/home/eduardo/src/osg/OpenSceneGraph/src/osgPlugins/osg/ReaderWriterOSG.cpp:313:
 undefined reference to `std::basic_istringstream,
std::allocator >::~basic_istringstream()'
/home/eduardo/src/osg/OpenSceneGraph/src/osgPlugins/osg/ReaderWriterOSG.cpp:313:
 undefined reference to `std::basic_istringstream,
std::allocator >::~basic_istringstream()'

There are several other errors related to basic_istringstream,
basic_stringbuf, type_info and others.

It seems like there is a STL incompatibility. I checked, but both osg
and the example seem to be being built with the correct STL include
path. The linker command is:

/usr/local/android-ndk-r8b/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x
86/bin/arm-linux-androideabi-g++ -Wl,-soname,libosgNativeLib.so -shared --sysroo
t=/usr/local/android-ndk-r8b/platforms/android-5/arch-arm ./obj/local/armeabi-v7
a/objs/osgNativeLib/osgNativeLib.o ./obj/local/armeabi-v7a/objs/osgNativeLib/Osg
MainApp.o ./obj/local/armeabi-v7a/objs/osgNativeLib/OsgAndroidNotifyHandler.o ./
obj/local/armeabi-v7a/libgnustl_static.a  -Wl,--fix-cortex-a8 -L /home/eduardo/s
rc/osg/osg-android/obj/local/armeabi-v7a -losgdb_tga -losgdb_osg -losgdb_depreca
ted_osgviewer -losgdb_deprecated_osgvolume -losgdb_deprecated_osgtext -losgdb_de
precated_osgterrain -losgdb_deprecated_osgsim -losgdb_deprecated_osgshadow -losg
db_deprecated_osgparticle -losgdb_deprecated_osgfx -losgdb_deprecated_osganimati
on -losgdb_deprecated_osg -losgdb_serializers_osgvolume -losgdb_serializers_osgt
ext -losgdb_serializers_osgterrain -losgdb_serializers_osgsim -losgdb_serializer
s_osgshadow -losgdb_serializers_osgparticle -losgdb_serializers_osgmanipulator -
losgdb_serializers_osgfx -losgdb_serializers_osganimation -losgdb_serializers_os
g -losgViewer -losgVolume -losgText -losgSim -losgManipulator -losgGA -losgFX -l
osgDB -losgUtil -losg -lOpenThreads -Wl,--no-undefined -Wl,-z,noexecstack -Wl,-z
,relro -Wl,-z,now -L/usr/local/android-ndk-r8b/platforms/android-5/arch-arm/usr/
lib -llog -lGLESv1_CM -ldl -lz -lc -lm -o obj/local/armeabi-v7a/libosgNativeLib.
so

I have the latest OSG SVN version and the latest SDK and NDK. I'm
following the instructions in both
http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpecifics/Android
and 
http://www.openscenegraph.com/index.php/documentation/platform-specifics/android/43-building-openscenegraph-for-android-3-0-2.

I had to change a few "false" to "NULL" in osgNativeLib.cpp to stop
gcc from complaining.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [build] _OPEN_THREADS_ATOMIC_USE_GCC_BUILTINS

[Jason Daly]

On 10/05/2012 04:55 AM, paul graham wrote:

Hi all, we've been having some intermittent deadlock issues and as part of my 
investigation I noticed that our (albeit quite old - 2.9.8, we shall be 
upgrading imminently) OSG libs were being compiled with 
_OPENTHREADS_ATOMIC_USE_MUTEX.

On further investigation, it appears that the test for availability of 
_OPEN_THREADS_ATOMIC_USE_GCC_BUILTINS on our particular architecture (Linux RH 5.6) 
requires the additional compiler argument "-march=i686" in order to pass and 
hence not default to using mutexes.


Hi, Paul,

Coming from previous RHEL 5 experience, yes, you are correct.  The gcc 
version on RHEL5 doesn't assume a 686 architecture, and hence, won't 
enable the atomic builtins unless you explicitly ask.




Would I be right in thinking that building with 
_OPEN_THREADS_ATOMIC_USE_GCC_BUILTINS instead of _OPENTHREADS_ATOMIC_USE_MUTEX 
should provide significant 'general' performance improvement?


It certainly won't hurt.  Whether you see a noticeable improvement will 
depend on your application.




On a related note - our investigations into these deadlocks has proved very 
difficult since typically the thread stacktraces recorded at the point of 
deadlock can't be traced further back beyond libGL.so - if anyone has 
experience of similar situations, I'd welcome any advice.


Sorry, can't help with this, other than to say that an upgrade to 
version 3.0.1 (or later) would be a good idea, as there have been some 
fixes related to intermittent deadlocks since the version you're running.


--"J"

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

Re: [osg-users] How can I get the viewer's camera to 'ignore' anode's geometry?

[Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC]

We specify the near & far planes manually and we don't have z-buffer
issues with models on the earth's surface. Perhaps you should select the
option DO_NOT_COMPUTE_NEAR_FAR for cull settings...

-Shayne

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Thrall,
Bryan
Sent: Friday, October 05, 2012 8:55 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] How can I get the viewer's camera to 'ignore'
anode's geometry?

Preet wrote on 2012-10-04: 
> Sorry if it wasn't clear; the items aren't being displayed because the

> near and far planes that osg sets creates a frustum that doesn't
include
> them. I need to manually set the near and far planes to see
everything.
> 
> The near and far planes that osg sets without the earth surface
geometry
> is fine. Once you add the surface geometry though, the near and far 
> planes are set such that the items are no long in the view frustum.

If the surface geometry is in view but the calculated frustum doesn't
contain it, then that sounds like a bug that should be investigated
further. Are you certain the frustum really doesn't contain the surface
geometry?

It seems more likely that the problem is with z buffer precision due to
the earth geometry pushing the far plane out so far that the surface
geometry is getting buried, as other people in the thread have
suggested.
--
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.or
g
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Backward compatibility with custom serializers

[Wang Rui]

Hi Farshid,

2012/10/5 Farshid Lashkari :
> Thanks Wang, Robert.
>
> How would I go about using the UPDATE_TO_VERSION macro in this scenario? My
> understanding is that the macro is used when the version of OSG is updated.
> However, the version of OSG is the same between the two versions of my
> application, it's just that the serialization support for my custom object
> was added in the newer version.
>

Oh, this seems to be already discussed in another thread. I was
thinking of implementing a user version macro at that time but then I
was a little too busy to worked on it. I will consider adding a new
UPDATE_TO_USER_VERSION macro to allow version control of custom
serializers as soon as possible, maybe tomorrow. :-)

> Could this be a bug with current loader? I've attached a zip file that
> contains an ive, osgt, and osgb version of the same model. The ive loads and
> displays fine in 3.0.1, but as I mentioned, the osgt/osgb files do not
> display anything.
>

Yes, this is a bug just found in osgWrappers/serializers/osg/Node.cpp,
which uses UPDATE_TO_VERSION incorrectly so it also affects the
following StateSet serializer. I think the brackets after the macro
really confuses us and will do something soon to make it more
readable.

Thanks,

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

[osg-users] Help:why does renderbin affect the display of textures ?

[wang shuiying]

Hello,

I have two drawable nodes A and B under the same main group node. I 
mapped two different textures on the drawables respectively. Those two 
drawables do not have any overlappings in terms of pixels on the screen. 
Drawable A is described using open scene graph library while drawable B 
is described using openGL terms. Depth test is disabled by Drawable A 
and enabled by drawable B. Texture display on A uses a shader while B 
does not.


When the renderbin of drawable A is set to be -1 and that of drawable B 
is 1, the two textures cannot show at the same time. That is to say, 
when I toggle on both drawable A and drawable B and make them both seen 
on the screen, the texture on drawable B doesn't show, but the color of 
B is correct. Under such circumstance, when I manipulate the view in a 
way such that drawable A is out of sight, then the texture on drawable B 
will appear.


If I reverse the renderbins of those two drawables, then the textures 
can show at the same time.


I just cannot figure out why this happens.

 If it is due to depth test, why should such conflicts happen, since 
they have no overlapped pixels on the screen? Even it is due to depth 
test, why is the color  correct?


Would someone please be so kind enough as to explain that to me?

Thanks millions in advance!

Best regards
Shuiying

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

[osg-users] Cannot load models with user's data on iOS.

[Alessandro Terenzi]

Hi,
when reading a model (osgb) into my iOS app, I get the following error:


Code:
InputStream::readObject(): Unsupported wrapper class 
osg::DefaultUserDataContainer
InputStream::readObject(): Unsupported wrapper class 




As far as I understood this is because that model defines some user's data for 
certain nodes, but on iOS this seems to be not supported or, at least, there is 
something missing among the static libraries I'm linking to.

Is there something I have to do (perhaps adding a USE_DOTOSGWRAPPER macro...) 
in order to be able to read models with user's data on iOS?

Thanks.
Alessandro

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





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

Re: [osg-users] How can I get the viewer's camera to 'ignore' a node's geometry?

[Thrall, Bryan]

Preet wrote on 2012-10-04: 
> Sorry if it wasn't clear; the items aren't being displayed because the
> near and far planes that osg sets creates a frustum that doesn't
include
> them. I need to manually set the near and far planes to see
everything.
> 
> The near and far planes that osg sets without the earth surface
geometry
> is fine. Once you add the surface geometry though, the near and far
> planes are set such that the items are no long in the view frustum.

If the surface geometry is in view but the calculated frustum doesn't
contain it, then that sounds like a bug that should be investigated
further. Are you certain the frustum really doesn't contain the surface
geometry?

It seems more likely that the problem is with z buffer precision due to
the earth geometry pushing the far plane out so far that the surface
geometry is getting buried, as other people in the thread have
suggested.
--
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] How can I get the viewer's camera to 'ignore' a node's geometry?

[Glenn Waldron]

Is that true? Setting an invalid bounding sphere will indeed suppress
node-level culling, but I believe the near/far calculation is done at the
Drawable level. See CullVisitor::apply(Geode&).

The usual approach for terrain rendering is to subdivide your globe into
tiles. Then OSG can cull out the tiles that are not in the view, including
far-off tiles or back-facing tiles (by means of the
ClusterCullingCallback). That will bring the far clip plane closer and give
you the z-buffer resolution you need in order to visualize surface
features.

In addition, you can decrease the Camera's near/far ratio; this will give
you a little more near clip space if you still need it.

Glenn Waldron / @glennwaldron


On Fri, Oct 5, 2012 at 7:28 AM, Sergey Polischuk  wrote:

> Hi
>
> You can set ComputeBoundingBoxCallback on a geometry to specify whatever
> bounds you want. In your case to ignore earth geometry bound you can set
> its bound to uninitialized bounding box, and it will not make any
> difference to near\far calculations. Note that this thing completely
> disable view frustum culling on a geometry! In order to get it working you
> should write your cull callback and do check vs actual bounds there, if you
> need it.
>
> Code looks like:
>
> class UseInitialBoundsCallback : public
> osg::Drawable::ComputeBoundingBoxCallback
> {
> public:
> osg::BoundingBox computeBound (const osg::Drawable & drawable)
> {
> osg::BoundingBox brand_new_uninitialized_bbox;
> return brand_new_uninitialized_bbox;
> }
> };
>
> geometry->setComputeBoundingBoxCallback(new UseInitialBoundsCallback);
>
> Cheers, Sergey.
>
> 05.10.2012, 05:11, "Preet" :
> > On Thu, Oct 4, 2012 at 5:37 PM, Chris Hanson 
> wrote:
> >
> >>  I wanted to avoid specifying the near/far planes manually since the
> >>>  behaviour without the Earth surface geometry is perfect as is. I don't
> >>>  care about the overhead of drawing the surface geometry since its so
> >>>  simple, and I don't want the scene graph to account for the surface
> >>>  geometry (outside of rendering it); the other objects in the scene
> >>>  should determine the camera frustum.
> >>Due to the way OGL works with near/far, if you want it drawn, you
> need it
> >>  taken into account when computing the near/far planes.
> >>
> >>Are you just worried about the far plane being set too far?
> >>>  Including geometry for the
> >>  Earth's surface makes the other stuff disappear (and reappear at
> >>  certain angles).
> >>
> >>It sounds to me like you're not trying to solve the right problem.
> You
> >>  should first determine WHY these other items aren't displayed at times.
> >
> > Sorry if it wasn't clear; the items aren't being displayed because the
> > near and far planes that osg sets creates a frustum that doesn't
> > include them. I need to manually set the near and far planes to see
> > everything.
> >
> > The near and far planes that osg sets without the earth surface
> > geometry is fine. Once you add the surface geometry though, the near
> > and far planes are set such that the items are no long in the view
> > frustum.
> >
> > I was looking for a flag or something that basically tells osg "hey,
> > don't include this node when you do your view frustum calculations"
> > ___
> > 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
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osg::PPU texel 0,0 in depthbuffer is wrong

[Sergey Polischuk]

Hi Check texture wrap mode, it can be set to clamp_to_border, with some border color. Does it work okay when sampling other texture areas? Dont know if it can cause problem, but texture(...) call returns vec4, and you are sampling single component texture. I believe it returns (depth, 0, 0, 1), but who knows. And you'd better use #version directive, as nvidia drivers can compile a lot of stuff without it, but it can work not the way you would expect. 05.10.2012, 15:36, "Peterakos" :Hello.i use UnitCameraAttachmentBypass to retrieve depth buffer from camera, while rendering cow.osg.After that i pass it to a UnitInOut which uses fragment shader to change the result.I have noticed there is a problem when i try to retrieve the 0,0 texel from depth texture in fragment shader.Even though the cow is in the middle of the screen, the texel's 0,0 depth is always grey.Here is the frag shader code which shows the problem:uniform sampler2D depth_texture;void main(){gl_FragColor = texture(depth_texture, vec2(0.0, 0.0));}I attach the depth buffer.thnx.,___osg-users mailing listosg-users@lists.openscenegraph.orghttp://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 can I get the viewer's camera to 'ignore' a node's geometry?

[Sergey Polischuk]

Hi

You can set ComputeBoundingBoxCallback on a geometry to specify whatever bounds 
you want. In your case to ignore earth geometry bound you can set its bound to 
uninitialized bounding box, and it will not make any difference to near\far 
calculations. Note that this thing completely disable view frustum culling on a 
geometry! In order to get it working you should write your cull callback and do 
check vs actual bounds there, if you need it.

Code looks like:

class UseInitialBoundsCallback : public 
osg::Drawable::ComputeBoundingBoxCallback
{
public:
osg::BoundingBox computeBound (const osg::Drawable & drawable)
{
osg::BoundingBox brand_new_uninitialized_bbox;
return brand_new_uninitialized_bbox;
}
};

geometry->setComputeBoundingBoxCallback(new UseInitialBoundsCallback);

Cheers, Sergey.

05.10.2012, 05:11, "Preet" :
> On Thu, Oct 4, 2012 at 5:37 PM, Chris Hanson  wrote:
>
>>  I wanted to avoid specifying the near/far planes manually since the
>>>  behaviour without the Earth surface geometry is perfect as is. I don't
>>>  care about the overhead of drawing the surface geometry since its so
>>>  simple, and I don't want the scene graph to account for the surface
>>>  geometry (outside of rendering it); the other objects in the scene
>>>  should determine the camera frustum.
>>    Due to the way OGL works with near/far, if you want it drawn, you need it
>>  taken into account when computing the near/far planes.
>>
>>    Are you just worried about the far plane being set too far?
>>>  Including geometry for the
>>  Earth's surface makes the other stuff disappear (and reappear at
>>  certain angles).
>>
>>    It sounds to me like you're not trying to solve the right problem. You
>>  should first determine WHY these other items aren't displayed at times.
>
> Sorry if it wasn't clear; the items aren't being displayed because the
> near and far planes that osg sets creates a frustum that doesn't
> include them. I need to manually set the near and far planes to see
> everything.
>
> The near and far planes that osg sets without the earth surface
> geometry is fine. Once you add the surface geometry though, the near
> and far planes are set such that the items are no long in the view
> frustum.
>
> I was looking for a flag or something that basically tells osg "hey,
> don't include this node when you do your view frustum calculations"
> ___
> 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

[osg-users] [build] _OPEN_THREADS_ATOMIC_USE_GCC_BUILTINS

[paul graham]

Hi all, we've been having some intermittent deadlock issues and as part of my 
investigation I noticed that our (albeit quite old - 2.9.8, we shall be 
upgrading imminently) OSG libs were being compiled with 
_OPENTHREADS_ATOMIC_USE_MUTEX.

On further investigation, it appears that the test for availability of 
_OPEN_THREADS_ATOMIC_USE_GCC_BUILTINS on our particular architecture (Linux RH 
5.6) requires the additional compiler argument "-march=i686" in order to pass 
and hence not default to using mutexes.

Would I be right in thinking that building with 
_OPEN_THREADS_ATOMIC_USE_GCC_BUILTINS instead of _OPENTHREADS_ATOMIC_USE_MUTEX 
should provide significant 'general' performance improvement?

On a related note - our investigations into these deadlocks has proved very 
difficult since typically the thread stacktraces recorded at the point of 
deadlock can't be traced further back beyond libGL.so - if anyone has 
experience of similar situations, I'd welcome any advice.

Any feedback on the above would be appreciated.

Many thanks

Paul

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





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