Re: [osg-users] Texture Questions
Hi You can use compressed textures in dds format, as they support dxtc texture compression. You can create those with ati compressonator tool, nvidia texture tools, or in photoshop using nvidia plugin. For rgb images you'll get 6x compression ratio. Also, you can save textures in dds format with pre-generated mipmaps, if you need those. Cheers. 24.08.2012, 21:13, Cary, Karl A. karl.a.c...@saic.com: I do have the ability to pre-process. The question is, what file formats support openGL compression and how do I take them from jpeg to these formats? As for mipmapping, you mentioned that it can be done CPU side. How do I initiate this? Since the texture load is happening in a separate thread, I can afford CPU time to do this rather than pushing more on to the GPU. I can test out to see if it is worthwhile. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Friday, August 24, 2012 11:40 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Texture Questions Hi Karl, On 24 August 2012 14:40, Cary, Karl A. karl.a.c...@saic.com wrote: I have an application that loads several 2048x2048 textures in a separate thread before passing off to the main to be applied to the geometry. I am trying to do anything and everything I can to improve performance on them as the number of textures will increase from several to quite a lot. So I am looking at every option I can and have run in to several questions that I was hoping to get some advice on. I am creating osg::Texture2D and loading them with an osg::Image read in from a jpg file. Excatly how many textures are you talking about? Will of the texture reside in memory and be rendered at the same time? Do you have an flexibility w.r.t pre-processing the image data into other file formats? What pixel format do the textures have? RGB? 1) Is mipmapping enabled by default? Or do I need to call allocateMipmapLevels? By default the osg::Texture* will use trilinear mipmapping, if the osg::Image doesn't contain the mipmaps then it'll either generate them on demand in the rendering thread either done by the GL driver or GPU using OpenGL extensions for generating mipmaps, or on the CPU using GLU functions when the driver doesn't support the generate mipmap extensions. You can switch the mipmapping off by just setting the texture-setFilter(Texture::MIN_FILTER, Texture::LINEAR); 2) If it is enabled, how many levels are created by default? osg::Texture* will automatically work out how many levels are required based on the dimensions of the texture. 3) Would changing the internal format mode to one of the compression formats actually perform the compression or does that need to be done manually? If the source imagery is not in an OpenGL compressed format then the driver will do the compression for you, however this is an expensive operation so generally not one you'd during rendering, rather OpenGL compression is something you'd want to do in pre-processing step. 4) If I do need to do the compression, how can I do it without applying it to geometry in my separate thread? I have only seen it done via the CompressTexturesVisitor applied to a node (as in osgconv), would I have to make some empty node and apply the texture to it to do this? To compress in a background thread you can use the OSG's now support for compressing textures using NVTT (there is plugin for this when you compile the OSG when the NVTT SDK is available). You'll need OSG-3.x for this. 5) Is there any way to send a texture down to the graphics card prior to applying it to geometry? You can pre-compile objects using the IncrementalCompileOperator, however, this is still done as part of the rendering thread so depending upon your requirements might not make a difference. 6) Any other efficiency things I should be looking at? Pre-processing data so that it's pre-mipmapped and using OpenGL compressed texture is the best way if you want to maximize performance throughput of textures as this reduces how much work the CPU and GPU need to do to download and use the data. OpenGL compression is less aggressive than compression supported by conventional image formats so the files on disk will be bigger. Robert. ___ 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Resetting OSG state when managing own context
Hi, Neil I feel like (b) option is a clear winner here.If it is possible to make osg context shared with CAOpenGLLayer, you'll be in good shape and running without gpu-ram-gpu transfers. Otherwise it all depends on texture roundabout impact on framerate. Cheers, Sergey. 24.08.2012, 18:36, Neil Clayton n...@shinywhitebox.com: Hi All, I've a question or two regarding rendering contexts. While the usage is OSX specific, the question is not. I'm rendering into a CAOpenGLLayer (I can't render directly to a NSOpenGLView because I'm also using CALayer objects within the view - and these conflict with the NSOpenGLView, at least in my experience). In essence this means I manage the OpenGL context, create an osg::Viewer and use the setupViewerAsEmbeddedInWindow method. I have no problem using the context created by CAOpenGLLayer (I'm basing my code on the existing CocoaViewer which essentially does the same thing), I do have problems when the context which OSG is now using needs to be reset. In CAOpenGLLayer, a context reset can be caused by (for example) a user moving the window to another screen. In this case the context might be recreated because CAOpenGLLayer wants to use either a different graphics card or a different pixel format. From what I can gather, while I'm managing the real OpenGL context myself, OSG is managing it's own texture ID's (and I presume other scene OpenGL resources). When the real OpenGL context is reset, OSG still believes all of it's existing resources to be valid, because I've not explicitly told it otherwise. From this I have two questions: a) How do I tell OSG to throw away it's managed resources (texture ID's, etc), such that they are recreated at the next render pass? Can I do this? Is it even wise? Or should I be looking to throw away the viewer and recreate it? b) Instead of the above, should I rather have OSG manage it's own context and then after each OSG render pass copy the rendered result to the layer? For (b) I was considering rendering to a texture backed FBO, then DMA'ing that texture to RAM. I'd then DMA that back into the CAOpenGLLayer context. Thus OSG wouldn't have to be concerned at all with what the layer is with it's context, nor context resets. This (to me) sounds like a reasonable idea. It'd keep the OSG engine separated from the CAOpenGLLayer side of things, and would allow OSG to manage everything about it's rendering pipeline. The only part I don't like is the additional texture-copy to get the result into another context. p.s: The scene being drawn is small, with only many hundreds of vertices and 100 textures. Thank you! Cheers, Neil -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=49508#49508 ___ 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] How to know that two OSG models are touch each other
Hi, I have two OSG models. The first is constant about rotation and translation about Z. This model is just translating about X and Y axis. The second model is variable about translation and rotation. Now I want to call a function when first model come across second model. That is when first and second models are touch each other I need to call a function. To do this, I calculated the screen coordinates for both models. Formed a rectangles for both with these coordinates. If these two rectangles intersect then I called the function. But this not working perfectly as second model is free about rotation and translation. Can any one please help me how to solve this problem. ... Thank you! Cheers, Koduri -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=49547#49547 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to know that two OSG models are touch each other
Hi, Koduri If you need to do this precisely, you can use (or write your own) some collision detection algo working with flat 2d polygones (get those by transforming model vertices to screenspace). Also you can get somewhat good results using some stencil buffer magic (the point is to write some distinct value to stencil when both objects are drawn at same pixel, then readback stencil buffer and check if it contains this value). Cheers, Sergey. 27.08.2012, 10:46, Koduri Lakshmi ankiredd...@gmail.com: Hi, I have two OSG models. The first is constant about rotation and translation about Z. This model is just translating about X and Y axis. The second model is variable about translation and rotation. Now I want to call a function when first model come across second model. That is when first and second models are touch each other I need to call a function. To do this, I calculated the screen coordinates for both models. Formed a rectangles for both with these coordinates. If these two rectangles intersect then I called the function. But this not working perfectly as second model is free about rotation and translation. Can any one please help me how to solve this problem. ... Thank you! Cheers, Koduri -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=49547#49547 ___ 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] (Android) Translucent background and visibility of model on OSG 3 (GLES1).
Hi and good day!
Preface (scroll down for my problem):
I'm developing an App based on OSG 3.0 for Android and i'm having a problem
with translucent backgrounds and models.
please bear with me if it's a stupid question. i'll try to explain my problem
in detail and not too confusing.
the source code i'm basing this on is from the osgAndroidExampleGLES1
(http://forum.openscenegraph.org/viewtopic.php?t=10076).
i've already changed a lot of things. it's an augmented reality app, meaning
that i'll stream from the camera to a GLSurfaceView and have the EGLview
overlayed on this surfaceview. so far so good. to see the stream from the
camera i obviously need to make the background from the osg part translucent.
to do so, i changed the EGLview.java to initialize the context with
translucent = true: (from EGLview.java, line 59)
Code:
public EGLview(Context context, AttributeSet attrs) {
super(context,attrs);
// we need to initialize it with translucent = true.
init(true, 16, 8);
Log.d(TAG, EGLview(Context, AttributeSet) called);
}
this will make the whole background translucent, which is what i want. to
actually see the background i followed the advice i got from this thread
http://forum.openscenegraph.org/viewtopic.php?t=9472
and in the OsgMainApp.cpp i added this line in the function
OsgMainApp::initOsgWindow(x, y, width, height):
Code:
_viewer-getCamera()-setClearColor(osg::Vec4(0.0f,0.0f,0.0f,0.0f));
which set the backgroundcolor to black with alpha = 0.
again, this is what i want, but it's not an option for me to stream the video
into the osg.
when i load a model and turn off the camera (as in the GLSurfaceView with the
videostream is removed) it looks like this (and this is how it should look
like):
(click the screenshots to go to bigger versions with higher quality)
[Image: http://i.imgur.com/wRpbxl.jpg ] (http://i.imgur.com/wRpbx.jpg)
now here comes my problem:
when i turn on the camera the color of the model is lost whenever the camera is
showing something of a light color. like this:
[Image: http://i.imgur.com/BnukZl.jpg ] (http://i.imgur.com/BnukZ.jpg)
in the following screenshot i tried to cover half of the camera with a book:
[Image: http://i.imgur.com/ebF9Pl.jpg ] (http://i.imgur.com/ebF9P.jpg)
now i'm honestly desperate to find a solution to this, but everything i've
tried so far didn't yield the desired results. has anyone come across a similar
problem or maybe even a solution on this? could it be an error in the model i'm
using? i thank everyone who took the time reading through this.
some more information on the model i used:
Code:
Geode {
name siemens1_aligned_geo.ply
nodeMask 0x
cullingActive TRUE
num_drawables 1
Geometry {
DataVariance STATIC
useDisplayList TRUE
useVertexBufferObjects TRUE
PrimitiveSets 1
{
DrawArrays POINTS 0 1317508
}
VertexArray Vec3Array 1317508
{
93.6877 -51.5449 20.8001
//... more data
}
NormalBinding PER_VERTEX
NormalArray Vec3Array 1317508
{
0.998192 -0.053112 0.0281376
// ... again, more data
}
ColorBinding PER_VERTEX
ColorArray Vec4Array 1317508
{
0.363281 0.363281 0.359375 0
// ... yes, more data
}
Thank you in advance for the smallest hint!
Cheers,
Bernd[/i]
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=49550#49550
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] download osg smart pointer package
Hi Tang, On 27 August 2012 04:19, tang tangjiqiang1...@qq.com wrote: I see, osg smart pointer in osg site individually extracted a package, But now can not find it, please help! I don't know of what you refer, osg::ref_ptr and osg::observer_ptr are and have always been a component of the core OpenSceneGraph library and as far as I'm away have never been distributed separately on OpenSceneGraph websites. I can't rule out that some 3rd party has packaged them separately but I've never come across this. Is there a reason why you aren't thinking about the OSG package? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Transparent objects distorsion
Hi Andrey, On 27 August 2012 06:02, Andrey Zubarev azb...@gmail.com wrote: Here is a picture that explains the problem: [Image: http://s12.postimage.org/t6lnevl19/Distor.png ] Thanks for the image, this confirms it's the very common and expected result of depth sorting of transparent objects when using a depth buffer. This topic has been covered many times on the OSG so have a look through the archives on the topic of transparency. A quick answer would be simply break the object down into small parts so that the OSG's depth sorting can make sure that the far parts of the object are rendered before the nearer parts. Another approach would be to render the problem objects twice, first the back faces using CullFace to select only rendering of the back faces, then render the front faces using CullFace to select the back faces. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Weird polygons on nVidia NVS cards
HI Carsten, Does the new view have the two views sharing the same graphics context, or are you creating a new context? If you are creating a new context how are your creating the new context? Robert. On 27 August 2012 10:13, Carsten Scharfe cscha...@dspace.de wrote: Hi. I’ve come across a strange behaviour regarding NVS cards from nVidia. On some occasions I get corrupted polygons, when initializing and showing a new view, which is rendered by a composite viewer. I’ve attached 2 screenshots showing the corrupted rendering and how it should be. Strange enough, this behavior can be observed only on NVS cards. Quadro Fx, Quadro and GeForce cards do not show this issue. Has anybody had the same or similar problem and can give me some hints on what went wrong? I definitely need help here. I use OSG 3.0 on Win7. The scene is rendered with some shaders. Our application has an edit mode for scene assembly integrated, which, if activated, creates a new view for editing purposes and adds this view to the composite viewer. Our edit mode is rendered in a different window and thus requires it’s own view. The polygon corruption occurs on this occasion. If the edit mode is deactivated and activated again (the view is only created once on the first activation) the rendering is as expected. Any comment is welcome. Thanks in advance. Carsten The correctd rendering: The corrupted rendering: ___ 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] which version od Autodesk FBX SDK is used
Hi Community, Anyone has clue which version of the FBX SDK is used in the osg fbx plugin? The one that is actual seams is not FBX SDK 2013.2. Also any hint from where it can be downloaded? Thanks a bunch Cheers, Nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture Questions
Will I need to do anything in osg to make sure it uses the pre-generated mipmaps stored in the DDS file and not recreate new ones? Working on saving the textures out as dds now. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Sergey Polischuk Sent: Monday, August 27, 2012 2:23 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Texture Questions Hi You can use compressed textures in dds format, as they support dxtc texture compression. You can create those with ati compressonator tool, nvidia texture tools, or in photoshop using nvidia plugin. For rgb images you'll get 6x compression ratio. Also, you can save textures in dds format with pre-generated mipmaps, if you need those. Cheers. 24.08.2012, 21:13, Cary, Karl A. karl.a.c...@saic.com: I do have the ability to pre-process. The question is, what file formats support openGL compression and how do I take them from jpeg to these formats? As for mipmapping, you mentioned that it can be done CPU side. How do I initiate this? Since the texture load is happening in a separate thread, I can afford CPU time to do this rather than pushing more on to the GPU. I can test out to see if it is worthwhile. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Friday, August 24, 2012 11:40 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Texture Questions Hi Karl, On 24 August 2012 14:40, Cary, Karl A. karl.a.c...@saic.com wrote: I have an application that loads several 2048x2048 textures in a separate thread before passing off to the main to be applied to the geometry. I am trying to do anything and everything I can to improve performance on them as the number of textures will increase from several to quite a lot. So I am looking at every option I can and have run in to several questions that I was hoping to get some advice on. I am creating osg::Texture2D and loading them with an osg::Image read in from a jpg file. Excatly how many textures are you talking about? Will of the texture reside in memory and be rendered at the same time? Do you have an flexibility w.r.t pre-processing the image data into other file formats? What pixel format do the textures have? RGB? 1) Is mipmapping enabled by default? Or do I need to call allocateMipmapLevels? By default the osg::Texture* will use trilinear mipmapping, if the osg::Image doesn't contain the mipmaps then it'll either generate them on demand in the rendering thread either done by the GL driver or GPU using OpenGL extensions for generating mipmaps, or on the CPU using GLU functions when the driver doesn't support the generate mipmap extensions. You can switch the mipmapping off by just setting the texture-setFilter(Texture::MIN_FILTER, Texture::LINEAR); 2) If it is enabled, how many levels are created by default? osg::Texture* will automatically work out how many levels are required based on the dimensions of the texture. 3) Would changing the internal format mode to one of the compression formats actually perform the compression or does that need to be done manually? If the source imagery is not in an OpenGL compressed format then the driver will do the compression for you, however this is an expensive operation so generally not one you'd during rendering, rather OpenGL compression is something you'd want to do in pre-processing step. 4) If I do need to do the compression, how can I do it without applying it to geometry in my separate thread? I have only seen it done via the CompressTexturesVisitor applied to a node (as in osgconv), would I have to make some empty node and apply the texture to it to do this? To compress in a background thread you can use the OSG's now support for compressing textures using NVTT (there is plugin for this when you compile the OSG when the NVTT SDK is available). You'll need OSG-3.x for this. 5) Is there any way to send a texture down to the graphics card prior to applying it to geometry? You can pre-compile objects using the IncrementalCompileOperator, however, this is still done as part of the rendering thread so depending upon your requirements might not make a difference. 6) Any other efficiency things I should be looking at? Pre-processing data so that it's pre-mipmapped and using OpenGL compressed texture is the best way if you want to maximize performance throughput of textures as this reduces how much work the CPU and GPU need to do to download and use the data. OpenGL compression is less aggressive than compression supported by conventional image formats so the files on disk will be bigger. Robert. ___ osg-users mailing list
Re: [osg-users] Transparent objects distorsion
Thank you, Robert! The second advice helps a lot :D Cheers, Andrey -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=49558#49558 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Weird polygons on nVidia NVS cards
Hi Robert, Both views share the same context. This context is created first, with no inherited window data. When I create a new view, I create a new context for this view and set the sharedContext member to the shared context. I set the inherited window data too for embedding the view in the desired window. Carsten. From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Monday, August 27, 2012 11:41 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Weird polygons on nVidia NVS cards HI Carsten, Does the new view have the two views sharing the same graphics context, or are you creating a new context? If you are creating a new context how are your creating the new context? Robert. On 27 August 2012 10:13, Carsten Scharfe cscha...@dspace.demailto:cscha...@dspace.de wrote: Hi. I've come across a strange behaviour regarding NVS cards from nVidia. On some occasions I get corrupted polygons, when initializing and showing a new view, which is rendered by a composite viewer. I've attached 2 screenshots showing the corrupted rendering and how it should be. Strange enough, this behavior can be observed only on NVS cards. Quadro Fx, Quadro and GeForce cards do not show this issue. Has anybody had the same or similar problem and can give me some hints on what went wrong? I definitely need help here. I use OSG 3.0 on Win7. The scene is rendered with some shaders. Our application has an edit mode for scene assembly integrated, which, if activated, creates a new view for editing purposes and adds this view to the composite viewer. Our edit mode is rendered in a different window and thus requires it's own view. The polygon corruption occurs on this occasion. If the edit mode is deactivated and activated again (the view is only created once on the first activation) the rendering is as expected. Any comment is welcome. Thanks in advance. Carsten The correctd rendering: Fehler! Es wurde kein Dateiname angegeben. The corrupted rendering: Fehler! Es wurde kein Dateiname angegeben. ___ osg-users mailing list osg-users@lists.openscenegraph.orgmailto: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(terrain) krasches on a double delete
Hi Robert et al., I finally got the time to investigate the code (osgTerrain/Terrain.cpp). As I see it, it is not necessary to introduce a new data structure to hold the list of update tiles. The issue was that a TerrainTile could be partly destructed but not unregisterTile:ed, when an Terrain::update call was made. Then, a TerrainTile could get its refcount bumped while being destructed and be deleted with a dangling ref_ptr to deleted memory. My solution is inspired by the code in ObserverSet::addRefLock and only modifies Terrain::traverse. I bump the raw Terrain-pointers in the update list to ref_ptr and check their status before doing any work on them. TerrainTiles with a refcount of 1 should be discarded (but not deleted). I have attached the complete file. Should this conversation be continued at osg-submissions also/instead? Cheers, Ola Hi Ola et. al, I've looked at the problem Terrain containers and they present an interesting issue - the std::setTerrainTile* that is used can't easily be converted into an std::set osg::observer_ptrTerrainTile as the observer_ptr can have it's value changed to NULL by another thread when destructing the observed TerrainTile and std::set require their values to be const. What will be required is a custom container of osg::oberserver_ptr along the lines of osg::OberservedNodePath but written to manage it's contents in a similar way to a std::set. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Using Opera's revolutionary email client: http://www.opera.com/mail/ Terrain.cpp Description: Binary data ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] (Android) Translucent background and visibility of model on OSG 3 (GLES1).
Hi, Bernd.
Either you are drawing your model with some kind of additive blending enabled
(if background and model drawn into same framebuffer or whatever it is), or it
is overlay working this way.
How you set up blending function? Do you need blending for your model at all?
If you dont need to draw transparent model - try to disable blending on your
model with setMode(GL_BLEND, osg::StateAttribute::OFF) on stateset of a node at
the top of the graph. Also your model have per-vertex colors assigned with
transparent alpha values, do you need those?
Cheers,
Sergey.
27.08.2012, 13:21, Bernd Kampl bernd.ka...@gmail.com:
Hi and good day!
Preface (scroll down for my problem):
I'm developing an App based on OSG 3.0 for Android and i'm having a problem
with translucent backgrounds and models.
please bear with me if it's a stupid question. i'll try to explain my problem
in detail and not too confusing.
the source code i'm basing this on is from the osgAndroidExampleGLES1
(http://forum.openscenegraph.org/viewtopic.php?t=10076).
i've already changed a lot of things. it's an augmented reality app, meaning
that i'll stream from the camera to a GLSurfaceView and have the EGLview
overlayed on this surfaceview. so far so good. to see the stream from the
camera i obviously need to make the background from the osg part translucent.
to do so, i changed the EGLview.java to initialize the context with
translucent = true: (from EGLview.java, line 59)
Code:
public EGLview(Context context, AttributeSet attrs) {
super(context,attrs);
// we need to initialize it with translucent = true.
init(true, 16, 8);
Log.d(TAG, EGLview(Context, AttributeSet) called);
}
this will make the whole background translucent, which is what i want. to
actually see the background i followed the advice i got from this thread
http://forum.openscenegraph.org/viewtopic.php?t=9472
and in the OsgMainApp.cpp i added this line in the function
OsgMainApp::initOsgWindow(x, y, width, height):
Code:
_viewer-getCamera()-setClearColor(osg::Vec4(0.0f,0.0f,0.0f,0.0f));
which set the backgroundcolor to black with alpha = 0.
again, this is what i want, but it's not an option for me to stream the video
into the osg.
when i load a model and turn off the camera (as in the GLSurfaceView with the
videostream is removed) it looks like this (and this is how it should look
like):
(click the screenshots to go to bigger versions with higher quality)
[Image: http://i.imgur.com/wRpbxl.jpg ] (http://i.imgur.com/wRpbx.jpg)
now here comes my problem:
when i turn on the camera the color of the model is lost whenever the camera
is showing something of a light color. like this:
[Image: http://i.imgur.com/BnukZl.jpg ] (http://i.imgur.com/BnukZ.jpg)
in the following screenshot i tried to cover half of the camera with a book:
[Image: http://i.imgur.com/ebF9Pl.jpg ] (http://i.imgur.com/ebF9P.jpg)
now i'm honestly desperate to find a solution to this, but everything i've
tried so far didn't yield the desired results. has anyone come across a
similar problem or maybe even a solution on this? could it be an error in the
model i'm using? i thank everyone who took the time reading through this.
some more information on the model i used:
Code:
Geode {
name siemens1_aligned_geo.ply
nodeMask 0x
cullingActive TRUE
num_drawables 1
Geometry {
DataVariance STATIC
useDisplayList TRUE
useVertexBufferObjects TRUE
PrimitiveSets 1
{
DrawArrays POINTS 0 1317508
}
VertexArray Vec3Array 1317508
{
93.6877 -51.5449 20.8001
//... more data
}
NormalBinding PER_VERTEX
NormalArray Vec3Array 1317508
{
0.998192 -0.053112 0.0281376
// ... again, more data
}
ColorBinding PER_VERTEX
ColorArray Vec4Array 1317508
{
0.363281 0.363281 0.359375 0
// ... yes, more data
}
Thank you in advance for the smallest hint!
Cheers,
Bernd[/i]
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=49550#49550
___
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] Texture Questions
I believe osg dds plugin uses stored ones, if there any. At least there are some code that takes care of mipmaps in dds plugin. 27.08.2012, 14:32, Cary, Karl A. karl.a.c...@saic.com: Will I need to do anything in osg to make sure it uses the pre-generated mipmaps stored in the DDS file and not recreate new ones? Working on saving the textures out as dds now. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Sergey Polischuk Sent: Monday, August 27, 2012 2:23 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Texture Questions Hi You can use compressed textures in dds format, as they support dxtc texture compression. You can create those with ati compressonator tool, nvidia texture tools, or in photoshop using nvidia plugin. For rgb images you'll get 6x compression ratio. Also, you can save textures in dds format with pre-generated mipmaps, if you need those. Cheers. 24.08.2012, 21:13, Cary, Karl A. karl.a.c...@saic.com: I do have the ability to pre-process. The question is, what file formats support openGL compression and how do I take them from jpeg to these formats? As for mipmapping, you mentioned that it can be done CPU side. How do I initiate this? Since the texture load is happening in a separate thread, I can afford CPU time to do this rather than pushing more on to the GPU. I can test out to see if it is worthwhile. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Friday, August 24, 2012 11:40 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Texture Questions Hi Karl, On 24 August 2012 14:40, Cary, Karl A. karl.a.c...@saic.com wrote: I have an application that loads several 2048x2048 textures in a separate thread before passing off to the main to be applied to the geometry. I am trying to do anything and everything I can to improve performance on them as the number of textures will increase from several to quite a lot. So I am looking at every option I can and have run in to several questions that I was hoping to get some advice on. I am creating osg::Texture2D and loading them with an osg::Image read in from a jpg file. Excatly how many textures are you talking about? Will of the texture reside in memory and be rendered at the same time? Do you have an flexibility w.r.t pre-processing the image data into other file formats? What pixel format do the textures have? RGB? 1) Is mipmapping enabled by default? Or do I need to call allocateMipmapLevels? By default the osg::Texture* will use trilinear mipmapping, if the osg::Image doesn't contain the mipmaps then it'll either generate them on demand in the rendering thread either done by the GL driver or GPU using OpenGL extensions for generating mipmaps, or on the CPU using GLU functions when the driver doesn't support the generate mipmap extensions. You can switch the mipmapping off by just setting the texture-setFilter(Texture::MIN_FILTER, Texture::LINEAR); 2) If it is enabled, how many levels are created by default? osg::Texture* will automatically work out how many levels are required based on the dimensions of the texture. 3) Would changing the internal format mode to one of the compression formats actually perform the compression or does that need to be done manually? If the source imagery is not in an OpenGL compressed format then the driver will do the compression for you, however this is an expensive operation so generally not one you'd during rendering, rather OpenGL compression is something you'd want to do in pre-processing step. 4) If I do need to do the compression, how can I do it without applying it to geometry in my separate thread? I have only seen it done via the CompressTexturesVisitor applied to a node (as in osgconv), would I have to make some empty node and apply the texture to it to do this? To compress in a background thread you can use the OSG's now support for compressing textures using NVTT (there is plugin for this when you compile the OSG when the NVTT SDK is available). You'll need OSG-3.x for this. 5) Is there any way to send a texture down to the graphics card prior to applying it to geometry? You can pre-compile objects using the IncrementalCompileOperator, however, this is still done as part of the rendering thread so depending upon your requirements might not make a difference. 6) Any other efficiency things I should be looking at? Pre-processing data so that it's pre-mipmapped and using OpenGL compressed texture is the best way if you want to maximize performance throughput of textures as this reduces how much work the CPU and GPU need to do to download and use the data.
Re: [osg-users] which version od Autodesk FBX SDK is used
Hi, Nick. You can check it in ReaderWriterFBX.h header in osgPlugins/fbx dir.I use 2012.2 with some half recent osg svn version (osgversion says its 3.1.3). Cheers,Sergey.27.08.2012, 13:48, "Trajce Nikolov NICK" trajce.nikolov.nick@gmail.com:Hi Community,Anyone has clue which version of the FBX SDK is used in the osg fbx plugin? The one that is actual seams is not FBX SDK 2013.2. Also any hint from where it can be downloaded?Thanks a bunchCheers,Nick___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] which version od Autodesk FBX SDK is used
Hi Sergey, any idea from where can I get 2012.2 ? I tried to build it against the recent FBX SDK which is 2013.2 and it failed - the sdk is different (as expected). I am using OSG-3.0.1 Thanks Nick On Mon, Aug 27, 2012 at 1:59 PM, Sergey Polischuk pol...@yandex.ru wrote: Hi, Nick. You can check it in ReaderWriterFBX.h header in osgPlugins/fbx dir. I use 2012.2 with some half recent osg svn version (osgversion says its 3.1.3). Cheers, Sergey. 27.08.2012, 13:48, Trajce Nikolov NICK trajce.nikolov.nick@gmail.com: Hi Community, Anyone has clue which version of the FBX SDK is used in the osg fbx plugin? The one that is actual seams is not FBX SDK 2013.2. Also any hint from where it can be downloaded? Thanks a bunch Cheers, Nick ___ 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] (Android) Translucent background and visibility of model on OSG 3 (GLES1).
Hi, Bernd. Hi, and thank you for your quick answer. Either you are drawing your model with some kind of additive blending enabled (if background and model drawn into same framebuffer or whatever it is), or it is overlay working this way. I don't think i changed anything on the blending functions. How you set up blending function? Do you need blending for your model at all? If you dont need to draw transparent model - try to disable blending on your model with setMode(GL_BLEND, osg::StateAttribute::OFF) on stateset of a node at the top of the graph. i probably don't need blending for my model at all. i guess my model can always be in front of the cameraview. i tried your advice, but it didn't change anything. the model is still translucent. i implemented it like this in the OsgMainApp.cpp function OsgMainApp::loadModels(): http://pastebin.com/ksA89mbx i hope i'm not making a mistake there. Also your model have per-vertex colors assigned with transparent alpha values, do you need those? the thing is that the model i have here was autogenerated and i have no way of creating it myself. i only have half an idea what the data in the model tells me and i couldn't find a comprehensive source online how to understand it. how would i need to change it if i don't need it per-vertex colors assigned with transparent alpha values? Cheers, Sergey. thanks sergey, i greatly appreciate you taking your time to help me! Cheers, Bernd. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=49565#49565 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture Questions
I have my code loading dds now, but the mapping is all screwed up as a result. All I did was change the extension on the filename from jpg to dds and left everything else alone. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Sergey Polischuk Sent: Monday, August 27, 2012 7:55 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Texture Questions I believe osg dds plugin uses stored ones, if there any. At least there are some code that takes care of mipmaps in dds plugin. 27.08.2012, 14:32, Cary, Karl A. karl.a.c...@saic.com: Will I need to do anything in osg to make sure it uses the pre-generated mipmaps stored in the DDS file and not recreate new ones? Working on saving the textures out as dds now. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Sergey Polischuk Sent: Monday, August 27, 2012 2:23 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Texture Questions Hi You can use compressed textures in dds format, as they support dxtc texture compression. You can create those with ati compressonator tool, nvidia texture tools, or in photoshop using nvidia plugin. For rgb images you'll get 6x compression ratio. Also, you can save textures in dds format with pre-generated mipmaps, if you need those. Cheers. 24.08.2012, 21:13, Cary, Karl A. karl.a.c...@saic.com: I do have the ability to pre-process. The question is, what file formats support openGL compression and how do I take them from jpeg to these formats? As for mipmapping, you mentioned that it can be done CPU side. How do I initiate this? Since the texture load is happening in a separate thread, I can afford CPU time to do this rather than pushing more on to the GPU. I can test out to see if it is worthwhile. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Friday, August 24, 2012 11:40 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Texture Questions Hi Karl, On 24 August 2012 14:40, Cary, Karl A. karl.a.c...@saic.com wrote: I have an application that loads several 2048x2048 textures in a separate thread before passing off to the main to be applied to the geometry. I am trying to do anything and everything I can to improve performance on them as the number of textures will increase from several to quite a lot. So I am looking at every option I can and have run in to several questions that I was hoping to get some advice on. I am creating osg::Texture2D and loading them with an osg::Image read in from a jpg file. Excatly how many textures are you talking about? Will of the texture reside in memory and be rendered at the same time? Do you have an flexibility w.r.t pre-processing the image data into other file formats? What pixel format do the textures have? RGB? 1) Is mipmapping enabled by default? Or do I need to call allocateMipmapLevels? By default the osg::Texture* will use trilinear mipmapping, if the osg::Image doesn't contain the mipmaps then it'll either generate them on demand in the rendering thread either done by the GL driver or GPU using OpenGL extensions for generating mipmaps, or on the CPU using GLU functions when the driver doesn't support the generate mipmap extensions. You can switch the mipmapping off by just setting the texture-setFilter(Texture::MIN_FILTER, Texture::LINEAR); 2) If it is enabled, how many levels are created by default? osg::Texture* will automatically work out how many levels are required based on the dimensions of the texture. 3) Would changing the internal format mode to one of the compression formats actually perform the compression or does that need to be done manually? If the source imagery is not in an OpenGL compressed format then the driver will do the compression for you, however this is an expensive operation so generally not one you'd during rendering, rather OpenGL compression is something you'd want to do in pre-processing step. 4) If I do need to do the compression, how can I do it without applying it to geometry in my separate thread? I have only seen it done via the CompressTexturesVisitor applied to a node (as in osgconv), would I have to make some empty node and apply the texture to it to do this? To compress in a background thread you can use the OSG's now support for compressing textures using NVTT (there is plugin for this when you compile the OSG when the NVTT SDK is available). You'll need OSG-3.x for this. 5) Is there any way to send a texture down to the graphics card prior to applying it to geometry? You can pre-compile objects using the
Re: [osg-users] (Android) Translucent background and visibility of model on OSG 3 (GLES1).
Also your model have per-vertex colors assigned with transparent alpha
values, do you need those?
the thing is that the model i have here was autogenerated and i have no way
of creating it myself. i only have half an idea what the data in the model
tells me and i couldn't find a comprehensive source online how to understand
it. how would i need to change it if i don't need it per-vertex colors
assigned with transparent alpha values?
i just replaced all the zeroes in the alpha values with ones and now everything
behaves like it should. i suppose the error wasn't with osg (which rather
behaved like it should) but with the model i have. thanks so much for the time.
solution: going from
Code:
...
ColorBinding PER_VERTEX
ColorArray Vec4Array 1317508
{
0.363281 0.363281 0.359375 0
// ... yes, more data
}
to:
Code:
...
ColorBinding PER_VERTEX
ColorArray Vec4Array 1317508
{
0.363281 0.363281 0.359375 1
// ... yes, more data
}
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=49567#49567
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture Questions
Ok, think I found the problem. DDS, being designed for DirectX, defines (0,0) as top left whereas OpenGL defines it as bottom left. So all I should need to do is flip it. On to do that -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Cary, Karl A. Sent: Monday, August 27, 2012 8:39 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Texture Questions I have my code loading dds now, but the mapping is all screwed up as a result. All I did was change the extension on the filename from jpg to dds and left everything else alone. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Sergey Polischuk Sent: Monday, August 27, 2012 7:55 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Texture Questions I believe osg dds plugin uses stored ones, if there any. At least there are some code that takes care of mipmaps in dds plugin. 27.08.2012, 14:32, Cary, Karl A. karl.a.c...@saic.com: Will I need to do anything in osg to make sure it uses the pre-generated mipmaps stored in the DDS file and not recreate new ones? Working on saving the textures out as dds now. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Sergey Polischuk Sent: Monday, August 27, 2012 2:23 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Texture Questions Hi You can use compressed textures in dds format, as they support dxtc texture compression. You can create those with ati compressonator tool, nvidia texture tools, or in photoshop using nvidia plugin. For rgb images you'll get 6x compression ratio. Also, you can save textures in dds format with pre-generated mipmaps, if you need those. Cheers. 24.08.2012, 21:13, Cary, Karl A. karl.a.c...@saic.com: I do have the ability to pre-process. The question is, what file formats support openGL compression and how do I take them from jpeg to these formats? As for mipmapping, you mentioned that it can be done CPU side. How do I initiate this? Since the texture load is happening in a separate thread, I can afford CPU time to do this rather than pushing more on to the GPU. I can test out to see if it is worthwhile. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Friday, August 24, 2012 11:40 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Texture Questions Hi Karl, On 24 August 2012 14:40, Cary, Karl A. karl.a.c...@saic.com wrote: I have an application that loads several 2048x2048 textures in a separate thread before passing off to the main to be applied to the geometry. I am trying to do anything and everything I can to improve performance on them as the number of textures will increase from several to quite a lot. So I am looking at every option I can and have run in to several questions that I was hoping to get some advice on. I am creating osg::Texture2D and loading them with an osg::Image read in from a jpg file. Excatly how many textures are you talking about? Will of the texture reside in memory and be rendered at the same time? Do you have an flexibility w.r.t pre-processing the image data into other file formats? What pixel format do the textures have? RGB? 1) Is mipmapping enabled by default? Or do I need to call allocateMipmapLevels? By default the osg::Texture* will use trilinear mipmapping, if the osg::Image doesn't contain the mipmaps then it'll either generate them on demand in the rendering thread either done by the GL driver or GPU using OpenGL extensions for generating mipmaps, or on the CPU using GLU functions when the driver doesn't support the generate mipmap extensions. You can switch the mipmapping off by just setting the texture-setFilter(Texture::MIN_FILTER, Texture::LINEAR); 2) If it is enabled, how many levels are created by default? osg::Texture* will automatically work out how many levels are required based on the dimensions of the texture. 3) Would changing the internal format mode to one of the compression formats actually perform the compression or does that need to be done manually? If the source imagery is not in an OpenGL compressed format then the driver will do the compression for you, however this is an expensive operation so generally not one you'd during rendering, rather OpenGL compression is something you'd want to do in pre-processing step. 4) If I do need to do the compression, how can I do it without applying it to geometry in my separate thread? I have only seen it done via the CompressTexturesVisitor applied to a node (as in osgconv), would I
Re: [osg-users] Weird polygons on nVidia NVS cards
Oh. I forgot to mention that I'm using the composite viewer in single threaded mode. Carsten _ Carsten Scharfe Software Developer Experiment Software ESIM dSPACE GmbH Rathenaustraße 26 33102 Paderborn Germany Tel.: +49 5251 1638-1920 http://www.dspace.com mailto:cscha...@dspace.de _ From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Carsten Scharfe Sent: Monday, August 27, 2012 12:58 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] Weird polygons on nVidia NVS cards Hi Robert, Both views share the same context. This context is created first, with no inherited window data. When I create a new view, I create a new context for this view and set the sharedContext member to the shared context. I set the inherited window data too for embedding the view in the desired window. Carsten. From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Monday, August 27, 2012 11:41 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Weird polygons on nVidia NVS cards HI Carsten, Does the new view have the two views sharing the same graphics context, or are you creating a new context? If you are creating a new context how are your creating the new context? Robert. On 27 August 2012 10:13, Carsten Scharfe cscha...@dspace.demailto:cscha...@dspace.de wrote: Hi. I've come across a strange behaviour regarding NVS cards from nVidia. On some occasions I get corrupted polygons, when initializing and showing a new view, which is rendered by a composite viewer. I've attached 2 screenshots showing the corrupted rendering and how it should be. Strange enough, this behavior can be observed only on NVS cards. Quadro Fx, Quadro and GeForce cards do not show this issue. Has anybody had the same or similar problem and can give me some hints on what went wrong? I definitely need help here. I use OSG 3.0 on Win7. The scene is rendered with some shaders. Our application has an edit mode for scene assembly integrated, which, if activated, creates a new view for editing purposes and adds this view to the composite viewer. Our edit mode is rendered in a different window and thus requires it's own view. The polygon corruption occurs on this occasion. If the edit mode is deactivated and activated again (the view is only created once on the first activation) the rendering is as expected. Any comment is welcome. Thanks in advance. Carsten The correctd rendering: Fehler! Es wurde kein Dateiname angegeben. The corrupted rendering: Fehler! Es wurde kein Dateiname angegeben. ___ osg-users mailing list osg-users@lists.openscenegraph.orgmailto: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] Texture Questions
Alright, so I am calling flipVertical() and setOrigin(osg::Image::TOP_LEFT) on the image before setting it in the Texture2D. In my current example I am loading 4 textures. As jpgs they always work fine. As dds, sometimes all 4 show up, and sometimes a different one will not show up. And it is a different one each time. Any clues? -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Cary, Karl A. Sent: Monday, August 27, 2012 9:05 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Texture Questions Ok, think I found the problem. DDS, being designed for DirectX, defines (0,0) as top left whereas OpenGL defines it as bottom left. So all I should need to do is flip it. On to do that -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Cary, Karl A. Sent: Monday, August 27, 2012 8:39 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Texture Questions I have my code loading dds now, but the mapping is all screwed up as a result. All I did was change the extension on the filename from jpg to dds and left everything else alone. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Sergey Polischuk Sent: Monday, August 27, 2012 7:55 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Texture Questions I believe osg dds plugin uses stored ones, if there any. At least there are some code that takes care of mipmaps in dds plugin. 27.08.2012, 14:32, Cary, Karl A. karl.a.c...@saic.com: Will I need to do anything in osg to make sure it uses the pre-generated mipmaps stored in the DDS file and not recreate new ones? Working on saving the textures out as dds now. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Sergey Polischuk Sent: Monday, August 27, 2012 2:23 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Texture Questions Hi You can use compressed textures in dds format, as they support dxtc texture compression. You can create those with ati compressonator tool, nvidia texture tools, or in photoshop using nvidia plugin. For rgb images you'll get 6x compression ratio. Also, you can save textures in dds format with pre-generated mipmaps, if you need those. Cheers. 24.08.2012, 21:13, Cary, Karl A. karl.a.c...@saic.com: I do have the ability to pre-process. The question is, what file formats support openGL compression and how do I take them from jpeg to these formats? As for mipmapping, you mentioned that it can be done CPU side. How do I initiate this? Since the texture load is happening in a separate thread, I can afford CPU time to do this rather than pushing more on to the GPU. I can test out to see if it is worthwhile. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Friday, August 24, 2012 11:40 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Texture Questions Hi Karl, On 24 August 2012 14:40, Cary, Karl A. karl.a.c...@saic.com wrote: I have an application that loads several 2048x2048 textures in a separate thread before passing off to the main to be applied to the geometry. I am trying to do anything and everything I can to improve performance on them as the number of textures will increase from several to quite a lot. So I am looking at every option I can and have run in to several questions that I was hoping to get some advice on. I am creating osg::Texture2D and loading them with an osg::Image read in from a jpg file. Excatly how many textures are you talking about? Will of the texture reside in memory and be rendered at the same time? Do you have an flexibility w.r.t pre-processing the image data into other file formats? What pixel format do the textures have? RGB? 1) Is mipmapping enabled by default? Or do I need to call allocateMipmapLevels? By default the osg::Texture* will use trilinear mipmapping, if the osg::Image doesn't contain the mipmaps then it'll either generate them on demand in the rendering thread either done by the GL driver or GPU using OpenGL extensions for generating mipmaps, or on the CPU using GLU functions when the driver doesn't support the generate mipmap extensions. You can switch the mipmapping off by just setting the texture-setFilter(Texture::MIN_FILTER, Texture::LINEAR); 2) If it is enabled, how many levels are created by default? osg::Texture* will automatically work out how many levels are required based on the dimensions of the texture. 3) Would changing the internal format mode to one of the compression
Re: [osg-users] osg(terrain) krasches on a double delete
Hi Ola, I don't think your suggested change will help as you are taking a reference to a potentially deleted object, the Terrain::_mutex that is locked doesn't effected the children just the management of the Terrain::_terrainTileMap and _updateTerrainTileSet. My current thought is that we'll need to introduce a form of set that manages a list of observer_ptr much in the same way that the ObserverNodePath is managed, so we'll need an equivalent ObserverNodeSet class. Robert. On 27 August 2012 12:46, Ola Nilsson o...@weatherone.tv wrote: Hi Robert et al., I finally got the time to investigate the code (osgTerrain/Terrain.cpp). As I see it, it is not necessary to introduce a new data structure to hold the list of update tiles. The issue was that a TerrainTile could be partly destructed but not unregisterTile:ed, when an Terrain::update call was made. Then, a TerrainTile could get its refcount bumped while being destructed and be deleted with a dangling ref_ptr to deleted memory. My solution is inspired by the code in ObserverSet::addRefLock and only modifies Terrain::traverse. I bump the raw Terrain-pointers in the update list to ref_ptr and check their status before doing any work on them. TerrainTiles with a refcount of 1 should be discarded (but not deleted). I have attached the complete file. Should this conversation be continued at osg-submissions also/instead? Cheers, Ola Hi Ola et. al, I've looked at the problem Terrain containers and they present an interesting issue - the std::setTerrainTile* that is used can't easily be converted into an std::set osg::observer_ptrTerrainTile as the observer_ptr can have it's value changed to NULL by another thread when destructing the observed TerrainTile and std::set require their values to be const. What will be required is a custom container of osg::oberserver_ptr along the lines of osg::OberservedNodePath but written to manage it's contents in a similar way to a std::set. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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] Weird polygons on nVidia NVS cards
Hi Carsten, On 27 August 2012 11:57, Carsten Scharfe cscha...@dspace.de wrote: Both views share the same context. This context is created first, with no inherited window data. When I create a new view, I create a new context for this view and set the sharedContext member to the shared context. I set the inherited window data too for embedding the view in the desired window. I think you are a little confused by what is a context and what is a shared context. You description implies that you have two graphics context, the second graphics context sharing OpenGL objects with the first context (this is what a shared context means), but is still a separate graphics context. It could be that there is an issue with the viewer setup, but equally is could be an issue in the OpenGL driver with sharing GL objects between contexts. Personally I would avoid sharing contexts historically has been be problematic with some drivers, and brings up limitations in the way that you can use the OSG i.e. you can't use it multi-threaded and you have to be careful about cleanup. The OSG can handle multiple contexts just fine, just don't set the sharedContext info when setting up your new context. Alternatively just share the same graphics context with both view's viewports on the same window - this approach will lead to the best performance. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] which version od Autodesk FBX SDK is used
There is a SDK archive here http://usa.autodesk.com/adsk/servlet/pc/item?siteID=123112id=10775892 but the 2012.2 link seems to point to 2013.2. Maybe ping them about it, this used to work before. /Per On 27 August 2012 14:07, Trajce Nikolov NICK trajce.nikolov.nick@gmail.com wrote: Hi Sergey, any idea from where can I get 2012.2 ? I tried to build it against the recent FBX SDK which is 2013.2 and it failed - the sdk is different (as expected). I am using OSG-3.0.1 Thanks Nick On Mon, Aug 27, 2012 at 1:59 PM, Sergey Polischuk pol...@yandex.ru wrote: Hi, Nick. You can check it in ReaderWriterFBX.h header in osgPlugins/fbx dir. I use 2012.2 with some half recent osg svn version (osgversion says its 3.1.3). Cheers, Sergey. 27.08.2012, 13:48, Trajce Nikolov NICK trajce.nikolov.nick@gmail.com: Hi Community, Anyone has clue which version of the FBX SDK is used in the osg fbx plugin? The one that is actual seams is not FBX SDK 2013.2. Also any hint from where it can be downloaded? Thanks a bunch Cheers, Nick ___ 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(terrain) krasches on a double delete
Hi Robert, Hm, there is probably something I don't see. I am new to the code... I assumed that a TerrainTile cannot be _completely_ deleted in the Terrain::update call, because if it were it _must_ have passed through Terrain::unregisterTile and then it wouldn't be in the update set to begin with. Therefore it is still safe to investigate the raw pointers in the _updateTerrainTileSet in Terrain::update. Do you agree on the assumption? If not can you exemplify when it doesn't hold? Cheers, Ola On Mon, 27 Aug 2012 15:49:47 +0200, Robert Osfield robert.osfi...@gmail.com wrote: Hi Ola, I don't think your suggested change will help as you are taking a reference to a potentially deleted object, the Terrain::_mutex that is locked doesn't effected the children just the management of the Terrain::_terrainTileMap and _updateTerrainTileSet. My current thought is that we'll need to introduce a form of set that manages a list of observer_ptr much in the same way that the ObserverNodePath is managed, so we'll need an equivalent ObserverNodeSet class. Robert. On 27 August 2012 12:46, Ola Nilsson o...@weatherone.tv wrote: Hi Robert et al., I finally got the time to investigate the code (osgTerrain/Terrain.cpp). As I see it, it is not necessary to introduce a new data structure to hold the list of update tiles. The issue was that a TerrainTile could be partly destructed but not unregisterTile:ed, when an Terrain::update call was made. Then, a TerrainTile could get its refcount bumped while being destructed and be deleted with a dangling ref_ptr to deleted memory. My solution is inspired by the code in ObserverSet::addRefLock and only modifies Terrain::traverse. I bump the raw Terrain-pointers in the update list to ref_ptr and check their status before doing any work on them. TerrainTiles with a refcount of 1 should be discarded (but not deleted). I have attached the complete file. Should this conversation be continued at osg-submissions also/instead? Cheers, Ola Hi Ola et. al, I've looked at the problem Terrain containers and they present an interesting issue - the std::setTerrainTile* that is used can't easily be converted into an std::set osg::observer_ptrTerrainTile as the observer_ptr can have it's value changed to NULL by another thread when destructing the observed TerrainTile and std::set require their values to be const. What will be required is a custom container of osg::oberserver_ptr along the lines of osg::OberservedNodePath but written to manage it's contents in a similar way to a std::set. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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 -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg(terrain) krasches on a double delete
Hi Ola, On 27 August 2012 15:23, Ola Nilsson o...@weatherone.tv wrote: Hm, there is probably something I don't see. I am new to the code... I assumed that a TerrainTile cannot be _completely_ deleted in the Terrain::update call, because if it were it _must_ have passed through Terrain::unregisterTile and then it wouldn't be in the update set to begin with. unregisterTile only gets called in the TerrainTile destructor after it's ref count has gone to zero. It'd be safe if unregisterTile was called prior to the TerrailTile object's ref count goes to zero. Therefore it is still safe to investigate the raw pointers in the _updateTerrainTileSet in Terrain::update. Do you agree on the assumption? If not can you exemplify when it doesn't hold? Nope it's not safe as explained above. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] KdTree issue...
Robert, Thanks for the feedback. After I had posted my problem, I did find a previous thread of discussion that addressed a somewhat similar problem to what I've been seeing. It too was related to memory or a lack thereof. I can certainly look into it further to see if that is the problem. On moving to OSG 3.0.1, I can try it and move on from there. I'm assuming that there is a version of VPB that is in lockstep to the 3.0.1 release? Thanks for your help. -Shayne -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Saturday, August 25, 2012 1:53 AM To: OpenSceneGraph Users Subject: Re: [osg-users] KdTree issue... HI Shayne, The stack trace suggests an allocation issue when building a KdTree leaf. Any chance you are running out of memory? As a general comment I would suggest that you try OSG-3.0.1 rather than a old 2.9.x developer release as there is chance that bug fixes will have fixed bugs that are relevant to you. If moving to OSG-3.0.1 doesn't fix the issue then I would work on isolate which tile causes the KdTree builder to crash, to do this I'd write out each tile to a .osg(t) file prior to doing the KdTree build so if it crashes you have a record of the problem tile and can then test it stand alone. Robert. On 25 August 2012 00:16, Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC shayne.tuel...@hill.af.mil wrote: All, I have a terrain database built with VPB that I'm currently doing visibility tests on based on ten different locations on the terrain. The tests are using the osgSim::LineOfSight class to determine intersection with the terrain between each location. Things appear to run fine until I use KdTrees to speed up the intersection testing (which is quite slow) with the terrain. I use the call osgDB::Registry::instance()-setBuildKdTreesHint(osgDB::ReaderWriter:: Options::BUILD_KDTREES); to do this. Unfortunately doing this causes the application to crash when doing the intersection tests. I've attached a debug stack trace after the crash has occurred (KdTreeCrash.txt). I've also turned on VERBOSE_OUTPUT in the KdTree.cpp file to gather more information on why this is happening (KdTreeOut.txt). I'm not familiar enough with the pertinent code to determine why KdTrees is causing the application to blow up. I'm running with OSG 2.9.11 on Windows 7, Visual Studio 2008. Any ideas on what's going on? Is there a limitation on what KdTrees will handle? Thanks, -Shayne ___ 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.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Chicken Egg Problem: BoundingBoxes
Hello all! I'm working on a NodeKit (that is coming along nicely, btw) for using the NVidia NV_path_rendering extension with OSG. This new extension has an interesting--and, AFAIK, hitherto unseen--rendering model. When using NV_path_rendering (which I will call NVPR), one must feed path coordinate data into the OpenGL driver and it will compile this data for you into resources the graphics context identifies by number. This work fairly well in OSG using the Drawable override of compileGLObjects(), since I am given a valid and active graphics context which I can use to build the renderable objects. (As a side node, for the uninitiated, a path in this context is a N-order series of 2D coordinates that you use to draw vectors graphics; for example, fonts. NVPR is an extension that uses your Cuda cores to drastically speed this process up and create incredibly fast and high-quality 2D graphics.) I mentioned earlier that compiling these objects and making them available to OSG (even as displayLists) is straightforward. HOWEVER, there is an issue with regards to properly informing OSG of the bounding boxes of these objects, a kind of chicken-and-egg problem. :) Up until now, Drawable objects in OSG have had some kind of 3D geometric data associated with them. This lets the object calculate the bounding box on the CPU as the object is created, and inform the scenegraph almost immediately what to expect with regards to its bounds. In NVPR, we need the GPU to compute these bounds, but it cannot do so until AFTER it has compiled the objects internally. This means it needs a valid graphics context an should ideally do so towards the end of the compileGLObjects method. As before, this is straightforward to execute, but the order of operations here makes things tricky with OSG. Consider the following: osg::Geode*g = new osg::Geode(); osgNVPR::Path* p = new osg::PathCommands(); p-doStuff(); g-addDrawable(p); // DOH! OSG wants to do bounding calculations here, but we // haven't yet compiled or calculated the path internally // until compileGLObjects is called! I've come up with some workarounds, such as calling: viewer.realize(); viewer.frame(); ...and then manually calling dirtyBound(), but these feels very wrong to me. I wanted to quickly as the OSG community if they had any advice on how I should best approach this problem. Drawble::dirtyBound() isn't a const method, and so can't be easily called from compileGLObjects. Perhaps there may be some way to pre-compile these paths with a valid rendering context shortly after creating the Viewer? At any rate, hope everyone has a great week! LABOR DAY EXTENDED WEEKEND! ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg(terrain) krasches on a double delete
On Mon, 27 Aug 2012 16:40:39 +0200, Robert Osfield robert.osfi...@gmail.com wrote: Hi Ola, On 27 August 2012 15:23, Ola Nilsson o...@weatherone.tv wrote: Hm, there is probably something I don't see. I am new to the code... I assumed that a TerrainTile cannot be _completely_ deleted in the Terrain::update call, because if it were it _must_ have passed through Terrain::unregisterTile and then it wouldn't be in the update set to begin with. unregisterTile only gets called in the TerrainTile destructor after it's ref count has gone to zero. It'd be safe if unregisterTile was Yes, the ref count is zero but the destructor chain has not yet completed, by induction it hasn't passed ~TerrainTile. (If it had unregisterTile would have been called and completed.) Right? In this situation memory is not yet recycled and the object's parents data (Referenced) should be safe to access and even manipulate. Right? Ola Btw. the new code passes my modified osgterrain test, which of course doesn't prove anything... called prior to the TerrailTile object's ref count goes to zero. Therefore it is still safe to investigate the raw pointers in the _updateTerrainTileSet in Terrain::update. Do you agree on the assumption? If not can you exemplify when it doesn't hold? Nope it's not safe as explained above. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Chicken Egg Problem: BoundingBoxes
Hi Jeremy, The OSG uses a compile traversal that is called on the first frame of rendering (Renderer.cpp's Renderer::compile() method) and this will call your Drawable::compileGLObjects(), this can then set the dirty bound so that on the next cull traversal it'll update bounding box automatically for you. The other thing to do would be to estimate the bounding box based on the input parameters to your Drawable, or let the use define this or leave it up to the compile method. Robert. On 27 August 2012 16:22, Jeremy Moles cubic...@gmail.com wrote: Hello all! I'm working on a NodeKit (that is coming along nicely, btw) for using the NVidia NV_path_rendering extension with OSG. This new extension has an interesting--and, AFAIK, hitherto unseen--rendering model. When using NV_path_rendering (which I will call NVPR), one must feed path coordinate data into the OpenGL driver and it will compile this data for you into resources the graphics context identifies by number. This work fairly well in OSG using the Drawable override of compileGLObjects(), since I am given a valid and active graphics context which I can use to build the renderable objects. (As a side node, for the uninitiated, a path in this context is a N-order series of 2D coordinates that you use to draw vectors graphics; for example, fonts. NVPR is an extension that uses your Cuda cores to drastically speed this process up and create incredibly fast and high-quality 2D graphics.) I mentioned earlier that compiling these objects and making them available to OSG (even as displayLists) is straightforward. HOWEVER, there is an issue with regards to properly informing OSG of the bounding boxes of these objects, a kind of chicken-and-egg problem. :) Up until now, Drawable objects in OSG have had some kind of 3D geometric data associated with them. This lets the object calculate the bounding box on the CPU as the object is created, and inform the scenegraph almost immediately what to expect with regards to its bounds. In NVPR, we need the GPU to compute these bounds, but it cannot do so until AFTER it has compiled the objects internally. This means it needs a valid graphics context an should ideally do so towards the end of the compileGLObjects method. As before, this is straightforward to execute, but the order of operations here makes things tricky with OSG. Consider the following: osg::Geode*g = new osg::Geode(); osgNVPR::Path* p = new osg::PathCommands(); p-doStuff(); g-addDrawable(p); // DOH! OSG wants to do bounding calculations here, but we // haven't yet compiled or calculated the path internally // until compileGLObjects is called! I've come up with some workarounds, such as calling: viewer.realize(); viewer.frame(); ...and then manually calling dirtyBound(), but these feels very wrong to me. I wanted to quickly as the OSG community if they had any advice on how I should best approach this problem. Drawble::dirtyBound() isn't a const method, and so can't be easily called from compileGLObjects. Perhaps there may be some way to pre-compile these paths with a valid rendering context shortly after creating the Viewer? At any rate, hope everyone has a great week! LABOR DAY EXTENDED WEEKEND! ___ 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] Texture Questions
Alright to add what I have found thus far. We went back and reconverted the images using an option when we saved to flip the images vertically. By doing this I don't have to do anything in the code. The only difference between loading jpgs and ddss now is the extension at the end of the filename. I ran my code 100 times with jpgs and it always worked fine. When I ran it 100 times with ddss, it averaged to every other run one of the textures would be screwed up. The other runs all of them were fine. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Cary, Karl A. Sent: Monday, August 27, 2012 9:44 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Texture Questions Alright, so I am calling flipVertical() and setOrigin(osg::Image::TOP_LEFT) on the image before setting it in the Texture2D. In my current example I am loading 4 textures. As jpgs they always work fine. As dds, sometimes all 4 show up, and sometimes a different one will not show up. And it is a different one each time. Any clues? -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Cary, Karl A. Sent: Monday, August 27, 2012 9:05 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Texture Questions Ok, think I found the problem. DDS, being designed for DirectX, defines (0,0) as top left whereas OpenGL defines it as bottom left. So all I should need to do is flip it. On to do that -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Cary, Karl A. Sent: Monday, August 27, 2012 8:39 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Texture Questions I have my code loading dds now, but the mapping is all screwed up as a result. All I did was change the extension on the filename from jpg to dds and left everything else alone. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Sergey Polischuk Sent: Monday, August 27, 2012 7:55 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Texture Questions I believe osg dds plugin uses stored ones, if there any. At least there are some code that takes care of mipmaps in dds plugin. 27.08.2012, 14:32, Cary, Karl A. karl.a.c...@saic.com: Will I need to do anything in osg to make sure it uses the pre-generated mipmaps stored in the DDS file and not recreate new ones? Working on saving the textures out as dds now. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Sergey Polischuk Sent: Monday, August 27, 2012 2:23 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Texture Questions Hi You can use compressed textures in dds format, as they support dxtc texture compression. You can create those with ati compressonator tool, nvidia texture tools, or in photoshop using nvidia plugin. For rgb images you'll get 6x compression ratio. Also, you can save textures in dds format with pre-generated mipmaps, if you need those. Cheers. 24.08.2012, 21:13, Cary, Karl A. karl.a.c...@saic.com: I do have the ability to pre-process. The question is, what file formats support openGL compression and how do I take them from jpeg to these formats? As for mipmapping, you mentioned that it can be done CPU side. How do I initiate this? Since the texture load is happening in a separate thread, I can afford CPU time to do this rather than pushing more on to the GPU. I can test out to see if it is worthwhile. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Friday, August 24, 2012 11:40 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Texture Questions Hi Karl, On 24 August 2012 14:40, Cary, Karl A. karl.a.c...@saic.com wrote: I have an application that loads several 2048x2048 textures in a separate thread before passing off to the main to be applied to the geometry. I am trying to do anything and everything I can to improve performance on them as the number of textures will increase from several to quite a lot. So I am looking at every option I can and have run in to several questions that I was hoping to get some advice on. I am creating osg::Texture2D and loading them with an osg::Image read in from a jpg file. Excatly how many textures are you talking about? Will of the texture reside in memory and be rendered at the same time? Do you have an flexibility w.r.t pre-processing the image data into other file formats? What pixel format do the textures have? RGB? 1) Is mipmapping enabled by default? Or do I need to call
Re: [osg-users] osg(terrain) krasches on a double delete
Hi Ola, On 27 August 2012 16:31, Ola Nilsson o...@weatherone.tv wrote: Yes, the ref count is zero but the destructor chain has not yet completed, by induction it hasn't passed ~TerrainTile. (If it had unregisterTile would have been called and completed.) Right? Thinking about your explanation, I think you are correct,the Terrain::unregisterTile won't be allowed to complete because the Terrain::traverse() will be holding the Terrain::_mutex so the destructor won't be able to finish and have the memory fully deleted and be able to be recycled. In this situation memory is not yet recycled and the object's parents data (Referenced) should be safe to access and even manipulate. Right? Safe... possible, it still doesn't feel robust though. Btw. the new code passes my modified osgterrain test, which of course doesn't prove anything... It's an encouraging start though. I do wonder if in your changes there is a need to take a ref_ptr and then check for a referenceCount() of 1, as if the ref count is zero to start with then just checking against 0 without the ref_ptr should be sufficient a test to see if the object has been deleted. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Trouble with LightSpacePerspectiveShadowMap artifacts.
Hi, I've tried to use the CASTS_SHADOW_TRAVERSAL_MASK on my terrain but the final result is pretty the same. Code: GfxTerr-setNodeMask(m_GfxTerr-getNodeMask() ~CASTS_SHADOW_TRAVERSAL_MASK); hummmartifacts don't go away... Thank you! Cheers, Dario -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=49585#49585 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Chicken Egg Problem: BoundingBoxes
On Mon, 2012-08-27 at 16:50 +0100, Robert Osfield wrote: Hi Jeremy, The OSG uses a compile traversal that is called on the first frame of rendering (Renderer.cpp's Renderer::compile() method) and this will call your Drawable::compileGLObjects(), this can then set the dirty bound so that on the next cull traversal it'll update bounding box automatically for you. The other thing to do would be to estimate the This isn't currently possible because of the dirtyBound() prototypes on Drawable and Node (they are not const). However, if this is an API change you'd be agreeable to, I'd be happy to submit it. :) bounding box based on the input parameters to your Drawable, or let the use define this or leave it up to the compile method. Robert. On 27 August 2012 16:22, Jeremy Moles cubic...@gmail.com wrote: Hello all! I'm working on a NodeKit (that is coming along nicely, btw) for using the NVidia NV_path_rendering extension with OSG. This new extension has an interesting--and, AFAIK, hitherto unseen--rendering model. When using NV_path_rendering (which I will call NVPR), one must feed path coordinate data into the OpenGL driver and it will compile this data for you into resources the graphics context identifies by number. This work fairly well in OSG using the Drawable override of compileGLObjects(), since I am given a valid and active graphics context which I can use to build the renderable objects. (As a side node, for the uninitiated, a path in this context is a N-order series of 2D coordinates that you use to draw vectors graphics; for example, fonts. NVPR is an extension that uses your Cuda cores to drastically speed this process up and create incredibly fast and high-quality 2D graphics.) I mentioned earlier that compiling these objects and making them available to OSG (even as displayLists) is straightforward. HOWEVER, there is an issue with regards to properly informing OSG of the bounding boxes of these objects, a kind of chicken-and-egg problem. :) Up until now, Drawable objects in OSG have had some kind of 3D geometric data associated with them. This lets the object calculate the bounding box on the CPU as the object is created, and inform the scenegraph almost immediately what to expect with regards to its bounds. In NVPR, we need the GPU to compute these bounds, but it cannot do so until AFTER it has compiled the objects internally. This means it needs a valid graphics context an should ideally do so towards the end of the compileGLObjects method. As before, this is straightforward to execute, but the order of operations here makes things tricky with OSG. Consider the following: osg::Geode*g = new osg::Geode(); osgNVPR::Path* p = new osg::PathCommands(); p-doStuff(); g-addDrawable(p); // DOH! OSG wants to do bounding calculations here, but we // haven't yet compiled or calculated the path internally // until compileGLObjects is called! I've come up with some workarounds, such as calling: viewer.realize(); viewer.frame(); ...and then manually calling dirtyBound(), but these feels very wrong to me. I wanted to quickly as the OSG community if they had any advice on how I should best approach this problem. Drawble::dirtyBound() isn't a const method, and so can't be easily called from compileGLObjects. Perhaps there may be some way to pre-compile these paths with a valid rendering context shortly after creating the Viewer? At any rate, hope everyone has a great week! LABOR DAY EXTENDED WEEKEND! ___ 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] Texture Questions
Hi Karl, I haven't heard of dds specific problems like this, it might just be co-incidence that it's happening to the dds route, or perhaps something is happening on the OSG or OpenGL driver side. Unfortunately there isn't much we can do directly, you'll need to try and isolate the issue yourself. Things to look at would be whether the dds files are correct on disk, whether corruption happens on loading - perhaps you could do a hash of some kind of the images and check these on load to make sure that the loading is correct. Also try cutting down the number of textures used. Also try different hardware/OpenGL drivers. Robert. On 27 August 2012 16:55, Cary, Karl A. karl.a.c...@saic.com wrote: Alright to add what I have found thus far. We went back and reconverted the images using an option when we saved to flip the images vertically. By doing this I don't have to do anything in the code. The only difference between loading jpgs and ddss now is the extension at the end of the filename. I ran my code 100 times with jpgs and it always worked fine. When I ran it 100 times with ddss, it averaged to every other run one of the textures would be screwed up. The other runs all of them were fine. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Cary, Karl A. Sent: Monday, August 27, 2012 9:44 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Texture Questions Alright, so I am calling flipVertical() and setOrigin(osg::Image::TOP_LEFT) on the image before setting it in the Texture2D. In my current example I am loading 4 textures. As jpgs they always work fine. As dds, sometimes all 4 show up, and sometimes a different one will not show up. And it is a different one each time. Any clues? -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Cary, Karl A. Sent: Monday, August 27, 2012 9:05 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Texture Questions Ok, think I found the problem. DDS, being designed for DirectX, defines (0,0) as top left whereas OpenGL defines it as bottom left. So all I should need to do is flip it. On to do that -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Cary, Karl A. Sent: Monday, August 27, 2012 8:39 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Texture Questions I have my code loading dds now, but the mapping is all screwed up as a result. All I did was change the extension on the filename from jpg to dds and left everything else alone. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Sergey Polischuk Sent: Monday, August 27, 2012 7:55 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Texture Questions I believe osg dds plugin uses stored ones, if there any. At least there are some code that takes care of mipmaps in dds plugin. 27.08.2012, 14:32, Cary, Karl A. karl.a.c...@saic.com: Will I need to do anything in osg to make sure it uses the pre-generated mipmaps stored in the DDS file and not recreate new ones? Working on saving the textures out as dds now. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Sergey Polischuk Sent: Monday, August 27, 2012 2:23 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Texture Questions Hi You can use compressed textures in dds format, as they support dxtc texture compression. You can create those with ati compressonator tool, nvidia texture tools, or in photoshop using nvidia plugin. For rgb images you'll get 6x compression ratio. Also, you can save textures in dds format with pre-generated mipmaps, if you need those. Cheers. 24.08.2012, 21:13, Cary, Karl A. karl.a.c...@saic.com: I do have the ability to pre-process. The question is, what file formats support openGL compression and how do I take them from jpeg to these formats? As for mipmapping, you mentioned that it can be done CPU side. How do I initiate this? Since the texture load is happening in a separate thread, I can afford CPU time to do this rather than pushing more on to the GPU. I can test out to see if it is worthwhile. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Friday, August 24, 2012 11:40 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Texture Questions Hi Karl, On 24 August 2012 14:40, Cary, Karl A. karl.a.c...@saic.com wrote: I have an application that loads several 2048x2048 textures in a separate thread before passing off to the main to be
Re: [osg-users] Texture Questions
Opps.. I wrote: On 27 August 2012 17:22, Robert Osfield robert.osfi...@gmail.com wrote: Also try cutting down the number of textures used. I meant to say try cutting down the number THREADS used. :-) ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg(terrain) krasches on a double delete
Hi Robert, On Mon, 27 Aug 2012 17:58:58 +0200, Robert Osfield robert.osfi...@gmail.com wrote: Hi Ola, On 27 August 2012 16:31, Ola Nilsson o...@weatherone.tv wrote: Yes, the ref count is zero but the destructor chain has not yet completed, by induction it hasn't passed ~TerrainTile. (If it had unregisterTile would have been called and completed.) Right? Thinking about your explanation, I think you are correct,the Terrain::unregisterTile won't be allowed to complete because the Terrain::traverse() will be holding the Terrain::_mutex so the destructor won't be able to finish and have the memory fully deleted and be able to be recycled. In this situation memory is not yet recycled and the object's parents data (Referenced) should be safe to access and even manipulate. Right? Safe... possible, it still doesn't feel robust though. Agree. If someone registered a tile that wasn't ref counted it wouldn't work. There are some assumptions on usage, but I think most of them apply with the current code. Please advise if you have any specific scenarios that should be respected. Btw. the new code passes my modified osgterrain test, which of course doesn't prove anything... It's an encouraging start though. I do wonder if in your changes there is a need to take a ref_ptr and then check for a referenceCount() of 1, as if the ref count is zero to start with then just checking against 0 without the ref_ptr should be sufficient a test to see if the object has been deleted. That was also my initial version. But thinking about worst case I realized that there is a possibility that between a call to getReferenceCount() and the call to ref() or ref_ptr constructor another thread might drop the reference count and trigger destruction. Unlikely, but I think possible. By using the ref_ptr the operations should be atomic and safe. Cheers, Ola Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Trouble with LightSpacePerspectiveShadowMap artifacts.
Hi Dario, On 27 August 2012 17:13, Dario Minieri para...@cheapnet.it wrote: I've tried to use the CASTS_SHADOW_TRAVERSAL_MASK on my terrain but the final result is pretty the same. Code: GfxTerr-setNodeMask(m_GfxTerr-getNodeMask() ~CASTS_SHADOW_TRAVERSAL_MASK); Run the debug shadow view to see if it's taking into account the terrain. Or... just try the ViewDependentShadowMap technique that now is available in svn/trunk. This new technique is more robust than LispSM and offers similar functionality w.r.t projections. It may or may not solve your problem, but as I'm the author of this particular technique I have a better chance of understand and helping address the issues. I'm not the author or or the implementator the OSG's LispSM technique so am a bit of disadvantage here. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Chicken Egg Problem: BoundingBoxes
Hi Jeremy, On 27 August 2012 17:21, Jeremy Moles cubic...@gmail.com wrote: This isn't currently possible because of the dirtyBound() prototypes on Drawable and Node (they are not const). However, if this is an API change you'd be agreeable to, I'd be happy to submit it. :) As you have a subclass from Drawable you should be able to set the dirty flag directly. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Chicken Egg Problem: BoundingBoxes
On Mon, 2012-08-27 at 17:30 +0100, Robert Osfield wrote: Hi Jeremy, On 27 August 2012 17:21, Jeremy Moles cubic...@gmail.com wrote: This isn't currently possible because of the dirtyBound() prototypes on Drawable and Node (they are not const). However, if this is an API change you'd be agreeable to, I'd be happy to submit it. :) As you have a subclass from Drawable you should be able to set the dirty flag directly. You can (and in fact you have to!), but it won't set the dirty flags of the parent Geode, so you're forced to call dirtyBound() on it as well. This can be tough to do because you need to be sure it has already compiled the Paths, which is why I made the initial post. Robert. ___ 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] Camera manipulator velocity and home() calculation affected after scaling nodes
Hello, I was hoping someone could help me with a camera manipulator/scaling problem that I have been having. I have a scene graph that contains geometry representing a hydraulic fracture. The fracture length is of the order 1000ft, the height is of the order 100ft, and the width is of the order .01ft. I am trying to appy a width exaggeration factor to the model in order to artificially inflate the geometry along the width axis (in my case it is along the z-axis). To accomplish this, I call osg::PositionAttitudeTransform::setScale(osg::Vec3d(1.0, 1.0, 100.0)) on the PAT node that I use to orient the fracture in the model. This works as expected, and the fracture width is exaggerated. However, the camera manipulator (osgGA::TrackballManipulator) does not return to the same home position. The larger the scale value, the further the home position seems to be from the model. Also, the velocity of the camera (model distance / screen pixel distance) when manipulated via the mouse increases with the scale value. That is, dragging the mouse an inch on the screen results in a larger camera manipulation when the scale value is increased. Perhaps I am making some false assumptions regarding how the camera manipulators and scaling operations interact? Is the scaling operation messing up a bounding box calculation somewhere? I tried computing then drawing the bounding box of the root node, but it did not seem to change for either case. That is, the exaggerated fracture width does not make the overall volume of the scene any larger (as far as I can tell). Additional information: Lib Version: OpenSceneGraph 3.1.2 (Compiled with VS2010 on Windows 7 64-bit) Manipulator: osgGA::TrackballManipulator Any hints/tips would be greatly appreciated. Thank you, Judson Weissert ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to know that two OSG models are touch each other
There's always Bullet/osgBullet, but that might be overkill. -- 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 • Telemetry • Cryptography • Digital Audio • LIDAR • Kinect • Embedded • Mobile • iPhone/iPad/iOS • Android ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Camera manipulator velocity and home() calculation affected after scaling nodes
On Mon, 2012-08-27 at 13:54 -0400, Judson Weissert wrote: Hello, I was hoping someone could help me with a camera manipulator/scaling problem that I have been having. I have a scene graph that contains geometry representing a hydraulic fracture. The fracture length is of the order 1000ft, the height is of the order 100ft, and the width is of the order .01ft. I am trying to appy a width exaggeration factor to the model in order to artificially inflate the geometry along the width axis (in my case it is along the z-axis). To accomplish this, I call osg::PositionAttitudeTransform::setScale(osg::Vec3d(1.0, 1.0, 100.0)) on the PAT node that I use to orient the fracture in the model. This works as expected, and the fracture width is exaggerated. However, the camera manipulator (osgGA::TrackballManipulator) does not return to the same home position. The larger the scale value, the further the home position seems to be from the model. Also, the velocity of the camera (model distance / screen pixel distance) when manipulated via the mouse increases with the scale value. That is, dragging the mouse an inch on the screen results in a larger camera manipulation when the scale value is increased. Perhaps I am making some false assumptions regarding how the camera manipulators and scaling operations interact? Is the scaling operation messing up a bounding box calculation somewhere? I tried computing then drawing the bounding box of the root node, but it did not seem to change for either case. That is, the exaggerated fracture width does not make the overall volume of the scene any larger (as far as I can tell). I've been working on a custom OrthographicCameraManipulator (and have done FirstPersonShooter and other kinds of CameraManipulators in the past) and I've never seen this behave OTHER than how you're describing. Scaling the PAT will definitely affect the home position of the osgGA::StandardManipulator, so you may end up having to do something like: osgGA::CameraManipulator* cm = viewer.getCameraManipulator(); cm-setHomePosition(...); That should also set autoComputeHomePosition to false, so it'll stick. I could, of course, be misunderstanding the question. :) Additional information: Lib Version: OpenSceneGraph 3.1.2 (Compiled with VS2010 on Windows 7 64-bit) Manipulator: osgGA::TrackballManipulator Any hints/tips would be greatly appreciated. Thank you, Judson Weissert ___ 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] Switch inactive children callback
Hello, My current challenge seems to be a hard one ;-) In my pipeline I effectively removed all lightsources from the original scenegraph and copied to a separate graph. Instead of the original lightsources I install an update callback to transform the lightsources like in the original graph, so I can render them as light-volumes with the correct pose in another pass. This is working very well, even with dynamic transforms as childs of the original light sources. Now the problem with this approach is, that light sources below a switch or osgSim::Multiswitch node will not work as expected. As the update callback is called for every node, regardless of being active or inactive, the light source will be transformed an active in my case. Has anybody an idea how to find out if the current traversal originated from an inactive parent? I don't see a simple solution, but maybe the experts here can help me out. Does the NodeVisitor somehow collect this state, or is there any way to install a callback on the parental switches to find out when a subgraph is disabled? cheers Sebastian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Camera manipulator velocity and home() calculation affected after scaling nodes
On Mon, 2012-08-27 at 15:12 -0400, Judson Weissert wrote: On 8/27/2012 2:22 PM, Jeremy Moles wrote: On Mon, 2012-08-27 at 13:54 -0400, Judson Weissert wrote: Hello, I was hoping someone could help me with a camera manipulator/scaling problem that I have been having. I have a scene graph that contains geometry representing a hydraulic fracture. The fracture length is of the order 1000ft, the height is of the order 100ft, and the width is of the order .01ft. I am trying to appy a width exaggeration factor to the model in order to artificially inflate the geometry along the width axis (in my case it is along the z-axis). To accomplish this, I call osg::PositionAttitudeTransform::setScale(osg::Vec3d(1.0, 1.0, 100.0)) on the PAT node that I use to orient the fracture in the model. This works as expected, and the fracture width is exaggerated. However, the camera manipulator (osgGA::TrackballManipulator) does not return to the same home position. The larger the scale value, the further the home position seems to be from the model. Also, the velocity of the camera (model distance / screen pixel distance) when manipulated via the mouse increases with the scale value. That is, dragging the mouse an inch on the screen results in a larger camera manipulation when the scale value is increased. Perhaps I am making some false assumptions regarding how the camera manipulators and scaling operations interact? Is the scaling operation messing up a bounding box calculation somewhere? I tried computing then drawing the bounding box of the root node, but it did not seem to change for either case. That is, the exaggerated fracture width does not make the overall volume of the scene any larger (as far as I can tell). I've been working on a custom OrthographicCameraManipulator (and have done FirstPersonShooter and other kinds of CameraManipulators in the past) and I've never seen this behave OTHER than how you're describing. Scaling the PAT will definitely affect the home position of the osgGA::StandardManipulator, so you may end up having to do something like: osgGA::CameraManipulator* cm = viewer.getCameraManipulator(); cm-setHomePosition(...); That should also set autoComputeHomePosition to false, so it'll stick. I could, of course, be misunderstanding the question. :) Thank you. After thinking about what you said, I figured I would revisit my bounding box code. I must have made a mistake the first time around because this time I do get a completely different bounding box for the scene when the scale changes. Therefore, the code that is computing the home position thinks that it needs to view a huge volume, even though most of that volume does not actually contain any drawables. Therefore, I think I need to fix the bounds calculation and then I will still be able to rely on the default ComputeHomePosition algorithm. So far I have just relied on the default bounds() calculations. Thanks, A Drawable can have a special ComputeBoundsCallback() (something like that, I'm on my phone right now and can't look it up), so you could use that as well... Judson ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Camera manipulator velocity and home() calculation affected after scaling nodes
On 8/27/2012 2:22 PM, Jeremy Moles wrote: On Mon, 2012-08-27 at 13:54 -0400, Judson Weissert wrote: Hello, I was hoping someone could help me with a camera manipulator/scaling problem that I have been having. I have a scene graph that contains geometry representing a hydraulic fracture. The fracture length is of the order 1000ft, the height is of the order 100ft, and the width is of the order .01ft. I am trying to appy a width exaggeration factor to the model in order to artificially inflate the geometry along the width axis (in my case it is along the z-axis). To accomplish this, I call osg::PositionAttitudeTransform::setScale(osg::Vec3d(1.0, 1.0, 100.0)) on the PAT node that I use to orient the fracture in the model. This works as expected, and the fracture width is exaggerated. However, the camera manipulator (osgGA::TrackballManipulator) does not return to the same home position. The larger the scale value, the further the home position seems to be from the model. Also, the velocity of the camera (model distance / screen pixel distance) when manipulated via the mouse increases with the scale value. That is, dragging the mouse an inch on the screen results in a larger camera manipulation when the scale value is increased. Perhaps I am making some false assumptions regarding how the camera manipulators and scaling operations interact? Is the scaling operation messing up a bounding box calculation somewhere? I tried computing then drawing the bounding box of the root node, but it did not seem to change for either case. That is, the exaggerated fracture width does not make the overall volume of the scene any larger (as far as I can tell). I've been working on a custom OrthographicCameraManipulator (and have done FirstPersonShooter and other kinds of CameraManipulators in the past) and I've never seen this behave OTHER than how you're describing. Scaling the PAT will definitely affect the home position of the osgGA::StandardManipulator, so you may end up having to do something like: osgGA::CameraManipulator* cm = viewer.getCameraManipulator(); cm-setHomePosition(...); That should also set autoComputeHomePosition to false, so it'll stick. I could, of course, be misunderstanding the question. :) Thank you. After thinking about what you said, I figured I would revisit my bounding box code. I must have made a mistake the first time around because this time I do get a completely different bounding box for the scene when the scale changes. Therefore, the code that is computing the home position thinks that it needs to view a huge volume, even though most of that volume does not actually contain any drawables. Therefore, I think I need to fix the bounds calculation and then I will still be able to rely on the default ComputeHomePosition algorithm. So far I have just relied on the default bounds() calculations. Thanks, Judson ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Chicken Egg Problem: BoundingBoxes
Hi Jeremy, On 27 August 2012 17:34, Jeremy Moles cubic...@gmail.com wrote: You can (and in fact you have to!), but it won't set the dirty flags of the parent Geode, so you're forced to call dirtyBound() on it as well. This can be tough to do because you need to be sure it has already compiled the Paths, which is why I made the initial post. Interesting issue... The thing to be careful about allow a const dirtyBound() is that it opens the door to multi-threading issues where multiple threads could call dirty at one time - for instance from multiple cull traversals all running at the same time. There is also the problem that calling dirtyBound() would force a computeBound() on the next getBound() call which again could present a multi-threading issue where multiple threads could potentially be reading and writing from the data structures. Now... if the drawable can only be managed from a single context or from a single cull thread at one time then this multi-threading issue wouldn't be an issue, but it's a restriction that is very domain specific. Rather than relax the core OSG for a niche case might the better solution just to cast away constness from your subclass with a note that it should just be used on single thread cull. There might be a better solution down the line but for now this is route I'd prefer to take. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Chicken Egg Problem: BoundingBoxes
On Mon, 2012-08-27 at 21:04 +0100, Robert Osfield wrote: Hi Jeremy, On 27 August 2012 17:34, Jeremy Moles cubic...@gmail.com wrote: You can (and in fact you have to!), but it won't set the dirty flags of the parent Geode, so you're forced to call dirtyBound() on it as well. This can be tough to do because you need to be sure it has already compiled the Paths, which is why I made the initial post. Interesting issue... The thing to be careful about allow a const dirtyBound() is that it opens the door to multi-threading issues where multiple threads could call dirty at one time - for instance from multiple cull traversals all running at the same time. There is also the problem that calling dirtyBound() would force a computeBound() on the next getBound() call which again could present a multi-threading issue where multiple threads could potentially be reading and writing from the data structures. Now... if the drawable can only be managed from a single context or from a single cull thread at one time then this multi-threading issue wouldn't be an issue, but it's a restriction that is very domain specific. Rather than relax the core OSG for a niche case might the better solution just to cast away constness from your subclass with a note that it should just be used on single thread cull. There might be a better solution down the line but for now this is route I'd prefer to take. I find myself 100% in agreement and shall proceed thusly! :) Robert. ___ 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] Problem with GUIEventAdapter mouse wheel event in Qt
Hi Robert,
After debugging a bit more it appears that the issue begins when the event is
taken off the event queue inside CompositeViewer. There is the following case
statement inside CompositeViewer::eventTraversal() (line 755 in version 3.0.0):
Code:
case(osgGA::GUIEventAdapter::PUSH):
case(osgGA::GUIEventAdapter::RELEASE):
case(osgGA::GUIEventAdapter::DOUBLECLICK):
case(osgGA::GUIEventAdapter::DRAG):
case(osgGA::GUIEventAdapter::MOVE):
{
pointerEvent = true;
Note that SCROLL is not included in these cases. If I force the scroll event
through this code path in the debugger then the input range and y orientation
are correct when the event is passed to my GUIEventHandler. Is this a bug, or
is there some reason that scroll events need to be treated differently here?
In any case, I was able to work around this in my application, but maybe this
will help out the next person.
...
Thank you!
Cheers,
Michael
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=49603#49603
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
