Re: [osg-users] Using another threading library with osg's openthreads?
Thanks for the info. ps: I'd prefer being called Nav. :-) will add it to my signature, if that's what you meant. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=50423#50423 ___ 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
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
Re: [osg-users] How can I get the viewer's camera to 'ignore' a node's geometry?
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 prismatic.proj...@gmail.com:
On Thu, Oct 4, 2012 at 5:37 PM, Chris Hanson xe...@alphapixel.com 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
Re: [osg-users] osg::PPU texel 0,0 in depthbuffer is wrong
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" hay...@gmail.com: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?
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 pol...@yandex.ru 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 prismatic.proj...@gmail.com:
On Thu, Oct 4, 2012 at 5:37 PM, Chris Hanson xe...@alphapixel.com
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] How can I get the viewer's camera to 'ignore' a node'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.org
[osg-users] Cannot load models with user's data on iOS.
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
[osg-users] Help:why does renderbin affect the display of textures ?
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
Re: [osg-users] Backward compatibility with custom serializers
Hi Farshid, 2012/10/5 Farshid Lashkari fla...@gmail.com: 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
Re: [osg-users] How can I get the viewer's camera to 'ignore' anode's geometry?
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] [build] _OPEN_THREADS_ATOMIC_USE_GCC_BUILTINS
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
[osg-users] Building on Android
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_istringstreamchar, std::char_traitschar, std::allocatorchar ::basic_istringstream(std::basic_stringchar, std::char_tr aitschar, std::allocatorchar const, std::_Ios_Openmode)' /home/eduardo/src/osg/OpenSceneGraph/src/osgPlugins/osg/ReaderWriterOSG.cpp:313: undefined reference to `std::basic_istringstreamchar, std::char_traitschar, std::allocatorchar ::~basic_istringstream()' /home/eduardo/src/osg/OpenSceneGraph/src/osgPlugins/osg/ReaderWriterOSG.cpp:313: undefined reference to `std::basic_istringstreamchar, std::char_traitschar, std::allocatorchar ::~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] How can I get the viewer's camera to 'ignore' a node's geometry?
Hi I'm talking about setting this bounds callbacks on geometry(drawable) leaves. 05.10.2012, 17:20, "Glenn Waldron" gwald...@gmail.com: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 pol...@yandex.ru 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" prismatic.proj...@gmail.com: On Thu, Oct 4, 2012 at 5:37 PM, Chris Hanson xe...@alphapixel.com 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] osgdem --image-ext option working
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?
Indeed, my mistake.
Glenn Waldron / @glennwaldron
On Fri, Oct 5, 2012 at 4:07 PM, Sergey Polischuk pol...@yandex.ru wrote:
Hi
I'm talking about setting this bounds callbacks on geometry(drawable)
leaves.
05.10.2012, 17:20, Glenn Waldron gwald...@gmail.com:
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 pol...@yandex.ru 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 prismatic.proj...@gmail.com:
On Thu, Oct 4, 2012 at 5:37 PM, Chris Hanson xe...@alphapixel.com
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
Re: [osg-users] osg::PPU texel 0,0 in depthbuffer is wrong
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] Backward compatibility with custom serializers
Hi Wang, On Fri, Oct 5, 2012 at 10:19 AM, Wang Rui wangra...@gmail.com 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] How can I get the viewer's camera to 'ignore' a node's geometry?
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] How can I get the viewer's camera to 'ignore' a node's geometry?
On Sat, Oct 6, 2012 at 1:02 AM, Preet prismatic.proj...@gmail.com 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
