Re: [osg-users] Problem with corrupted textures when sharing instances of models loaded from IVE format.
Hi Robert, Yep, I can confirm the return value of gc-getState()-getContextID() is increasing as you describe for each brower plugin instance created. Does that mean I should be ok sharing scengraph between viewers? It certainly seems ok now I've disabled the unref images after apply flag on the textures. Chris Denham. robertosfield wrote: Hi Chris, On 14 January 2012 09:30, Chris Denham wrote: Hi Robert, To answer your question about how I manage the graphics contexts. I just create a new one for the window handle provided by each instance of my browser plugin e.g Code: traits-inheritedWindowData = new WindowData(hWnd); gc = osg::GraphicsContext::createGraphicsContext(traits); After gc is assigned check the value of gc-getState()-getContextID() for each of the contexts created. In theory for multiple contexts they should read 0,1,2,etc. Robert. ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Post generated by Mail2Forum -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44855#44855 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with corrupted textures when sharing instances of models loaded from IVE format.
Hi Hybr, Corrupted vertex arrays? Do you mean the OpenSceneGraph geometry data, or a problem with the OGL compiled display list? I've not seen that, and I hope I don't. ;-) I'll keep an eye out for trouble though. Cheers, Chris. hybr wrote: Hi all I'm gonna add my 5 cents on this topic. I was having similar problems in app which recreates viewer in runtime (there are preview window and viewer created when widget shows up), using osg version 3.0(?). In my case problem was not only with textures - i was getting corrupted vertex arrays after viewer re-creation. I tried some voodoo magic with osgDB::Registry and caching settings, tried to clear gl objects with osg::deleteAllGLObjects() osg::flushAllDeletedGLObjects() etc, but without any luck. I've had different graphics context ids after viewer recreation. In my case problem was solved when using vertex buffer objects instead of display lists, i didnt dig any further after that. IIRC problem was showing itself only on windows, but i cant say for sure now. Cheers -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44857#44857 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with corrupted textures when sharing instances of models loaded from IVE format.
Hi Robert, robertosfield wrote: Is it that you are creating one viewer and context then drawing frames, then later creating a new context and draw more frames. In the later case I can certainly see that if the first frames draw will release the osg::Image resources assigned to osg::Texture if they are set up to unref the images, so disabling the unref of images makes sense. Yes, that's correct, other instances of the viewer may be created after an instance of the viewer has rendered a model, and those later instances may in turn need to render the same cached models. So, mystery solved I think. :-) Thanks. Chris Denham. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44866#44866 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with corrupted textures when sharing instances of models loaded from IVE format.
Hi Jp, Thanks for this info. I wrote a node visitor to change the texture setting after load by calling texture-setUnRefImageDataAfterApply(false); and that does indeed seem to fix the problem, so I'm pleased others have come up with the same fix. Though I'm now wondering if I still need to consider the potential problems sharing of opengl objectids between contexts that Robert suggested might have been the problem. i.e. is sharing scene graph data between viewers running on different threads intrinsically safe? It seems stable for me, but I'm wondering if it would be better to implement my own per viewer object cache instead of using the shared one that results from using the cache provided by osg registry singleton. Regards. Chris. J.P. Delport wrote: Hi, On 13/01/2012 18:37, Chris Denham wrote: Ah ha, Another interesting experiment doing the round trip from osg to ive and back. e.g. osgconv -O noTexturesInIVEFile cow.osg cow.ive osgconv cow.ive cow2.osg cow2.osg has the same problem and cow.ive, and on comparison on cow.osg and cow2.osg I noticed the image definition has grown an unRefImageDataAfterApply TRUE I get the same texture problem when I load cow2.osg, and it behaves normally again when I set the 'unRefImageDataAfterApply' flag to false. So my guess is that the image data may getting released before the other viewer instance has finished with it? Yes, I think so. See here for changing the unref setting after load: http://article.gmane.org/gmane.comp.graphics.openscenegraph.user/52034 http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/71893 rgds jp Chris Denham -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44816#44816 ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Post generated by Mail2Forum -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44828#44828 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with corrupted textures when sharing instances of models loaded from IVE format.
Hi Robert, To answer your question about how I manage the graphics contexts. I just create a new one for the window handle provided by each instance of my browser plugin e.g Code: traits-inheritedWindowData = new WindowData(hWnd); gc = osg::GraphicsContext::createGraphicsContext(traits); Regards, Chris Denham. robertosfield wrote: Hi Chris, Um... in this type of usage it may well be the easier to have multiple viewers. When you are doing your browser plugin how to you manage the graphics contexts? I suspect the problem may well be down to the OpenGL object ID's for the texture objects being shared inappropriately in your application. The is designed to use a different osg::State::ContextID value for each context, if different contexts use the same value for ContextID then they will share the same OpenGL object ID's which will introduce errors like you've seen. It's not the only way to create the errors, so it's only a hunch on my part. Anyway I don't think there is anything particularly wrong with .ive plugin or the models, all they will be doing is providing us with hints as to what is wrong at a higher level. Robert. ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Post generated by Mail2Forum -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44829#44829 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Problem with corrupted textures when sharing instances of models loaded from IVE format.
I'm having some problems connected with the use of textures embedded within IVE
files. The problem arises when I use the same IVE model instance from within
two instances of osgViewer::Viewer which results in unpredictable rendering of
textures in one of the viewer instances, usually the texture goes white when I
delete one viewer instance. If the embedded textures were also compressed, then
I also get some GL errors, typically:
Warning: detected OpenGL error 'invalid enumerant' at after
RenderBin::draw(..)
To be honest, I'm not surprised that this sharing of scene graph data between
osg Viewer instances causes a problem. In fact, I’m surprised that more things
don’t break. However, the reason this scenario crops up is that my osg viewer
is running inside a web based plugin, and hence I get an osg viewer instance
within each instance of the plugin that the web browser creates. You might
now be wondering why the browser plugin instances share any scene graph data,
and in fact I was a bit surprised that they were. I didn’t want them to share
data! It turns out that the reason the browser plugin instances share data is
because of the cache provided by the osg Registry singleton. It would have been
nice if each browser plugin instance ended up with their own osg Registry
singleton, but they don’t!
(I don’t really want to get on my hobby horse about all the pains that the
singleton pattern can cause, but this is certainly one to add to my list)
So, my questions boil down to :
If viewer instance 1 caches “cow.ive” in Registry singleton, how do I prevent
viewer instance 2 from using it?
If it does use the cached version, why does cause a problem (seemingly only
with textures that were embedded in IVE)?
Is there a way to “tweak” the IVE embedded textures so they can be shared
successfully in this scenario?
I have reduced the problem down to a simple example (20 lines or so) that
exhibits the same symptoms:
Code:
static osg::ref_ptrosg::Node model = NULL;
class ViewerThread : public OpenThreads::Thread
{
public:
ViewerThread(int x, int y) : x(x), y(y) { }
void run()
{
osgViewer::Viewer viewer;
viewer.setUpViewInWindow(x, y, 400, 300);
viewer.setSceneData(model);
viewer.run();
}
int x, y;
};
int main(int argc, char* argv[])
{
model = osgDB::readNodeFile(cow.ive);
ViewerThread* thread1 = new ViewerThread(100, 100);
thread1-start();
ViewerThread* thread2 = new ViewerThread(500, 100);
thread2-start();
while(true);
return 0;
}
Chris Denham
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=44810#44810
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with corrupted textures when sharing instances of models loaded from IVE format.
Hi Robert,
My example code was only meant to show the symtoms of the problem I get it in
my real world code. How can I use a composite viewer to implement views
within multiple browser plugin instances, potentially on different web pages?
Would I have to make the composite viewer a singleton that holds references to
the embedded windows created for each plugin instance? It's never gonna fly!
Interesting update to the problem though; it seems not related to the embedding
of the textures within the IVE, but more to do with the way IVE reader creates
images. The reason being that if I convert cow.osg using osgconv -O
noTexturesInIVEFile cow.osg cow.ive I still get the problem, but if I load
cow.osg into my example, it seems fine.
Chris Denham.
robertosfield wrote:
Hi Chris,
Using two independent viewers in an application is not normal or
recommended. I would recommend that you use a single CompositeViewer
with two Views. See the osgcompositeviewer example.
Robert.
On 13 January 2012 14:18, Chris Denham wrote:
I'm having some problems connected with the use of textures embedded within
IVE files. The problem arises when I use the same IVE model instance from
within two instances of osgViewer::Viewer which results in unpredictable
rendering of textures in one of the viewer instances, usually the texture
goes white when I delete one viewer instance. If the embedded textures were
also compressed, then I also get some GL errors, typically:
Warning: detected OpenGL error 'invalid enumerant' at after
RenderBin::draw(..)
To be honest, I'm not surprised that this sharing of scene graph data
between osg Viewer instances causes a problem. In fact, I’m surprised that
more things don’t break. However, the reason this scenario crops up is that
my osg viewer is running inside a web based plugin, and hence I get an osg
viewer instance within each instance of the plugin that the web browser
creates. You might now be wondering why the browser plugin instances
share any scene graph data, and in fact I was a bit surprised that they
were. I didn’t want them to share data! It turns out that the reason the
browser plugin instances share data is because of the cache provided by the
osg Registry singleton. It would have been nice if each browser plugin
instance ended up with their own osg Registry singleton, but they don’t!
(I don’t really want to get on my hobby horse about all the pains that the
singleton pattern can cause, but this is certainly one to add to my list)
So, my questions boil down to :
If viewer instance 1 caches “cow.ive” in Registry singleton, how do I
prevent viewer instance 2 from using it?
If it does use the cached version, why does cause a problem (seemingly only
with textures that were embedded in IVE)?
Is there a way to “tweak” the IVE embedded textures so they can be shared
successfully in this scenario?
I have reduced the problem down to a simple example (20 lines or so) that
exhibits the same symptoms:
Code:
static osg::ref_ptrosg::Node model = NULL;
class ViewerThread : public OpenThreads::Thread
{
public:
ViewerThread(int x, int y) : x(x), y(y) { }
void run()
{
osgViewer::Viewer viewer;
viewer.setUpViewInWindow(x, y, 400, 300);
viewer.setSceneData(model);
viewer.run();
}
int x, y;
};
int main(int argc, char* argv[])
{
model = osgDB::readNodeFile(cow.ive);
ViewerThread* thread1 = new ViewerThread(100, 100);
thread1-start();
ViewerThread* thread2 = new ViewerThread(500, 100);
thread2-start();
while(true);
return 0;
}
Chris Denham
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=44810#44810
___
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Post generated by Mail2Forum
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=44813#44813
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with corrupted textures when sharing instances of models loaded from IVE format.
Ah ha, Another interesting experiment doing the round trip from osg to ive and back. e.g. osgconv -O noTexturesInIVEFile cow.osg cow.ive osgconv cow.ive cow2.osg cow2.osg has the same problem and cow.ive, and on comparison on cow.osg and cow2.osg I noticed the image definition has grown an unRefImageDataAfterApply TRUE I get the same texture problem when I load cow2.osg, and it behaves normally again when I set the 'unRefImageDataAfterApply' flag to false. So my guess is that the image data may getting released before the other viewer instance has finished with it? Chris Denham -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44816#44816 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] Revisions plugin class name oddity.
Thanks Robert. :-) Though just to extend the height of my pedantry to one more irritating level: I noticed that your recent change left the word Font in the className() function. Sorry, I want to pinch myself for even feeling the need to mention it. lol. Cheers. Chris. robertosfield wrote: Hi Chris, On Fri, Sep 16, 2011 at 5:10 PM, Chris Denham wrote: I'm not sure if it affects anything, but I just noticed what seems to be a plugin class name clash. It looks as though ReaderWriterRevisions.cpp started its life as ReaderWriterFreeType.cpp, but class name and registration were not changed to suit the repurposing. Ooops... Classic example of the Copy and Paste Anti-Pattern. I'm guessing this class name conflict is harmless when plugins are used as independent dlls, but not 100% sure about effect on plugin registration. Probably still worth correcting in any case, if only to avoid future puzzlement. I could submit a correction, but as I've never used the revisions plugin, not sure I'd be a good person to test the result. It think it's just benign mistake that won't effect end users. The revisions plugin is a niche plugin associated with VirtualPlanetBuilder patched databases so probably hasn't had much attention from the community. I've now fixed this and checked it into svn/trunk. Robert. ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Post generated by Mail2Forum -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42859#42859 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [osgPlugins] Revisions plugin class name oddity.
Hi, Just for info really: I'm not sure if it affects anything, but I just noticed what seems to be a plugin class name clash. It looks as though ReaderWriterRevisions.cpp started its life as ReaderWriterFreeType.cpp, but class name and registration were not changed to suit the repurposing. I'm guessing this class name conflict is harmless when plugins are used as independent dlls, but not 100% sure about effect on plugin registration. Probably still worth correcting in any case, if only to avoid future puzzlement. I could submit a correction, but as I've never used the revisions plugin, not sure I'd be a good person to test the result. Cheers, Chris Denham -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42836#42836 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problems with computeIntersections
I'm not 100% sure, but I think I remember we had an odd problem with our qt osg
integration where we had to reverse the 'y' direction of the event, so that may
be worth a try.
Also, I don't think it's unusual to get two intersections for one geometry if
it's a closed convex shape because the ray will intersect two triangles, and
you would typically ignore the triangle whose normal is facing away from you.
Chris Denham.
Hartmut Leister wrote:
Hello all,
I got a problem with osgUtil::computeIntersections(). I wanted to include it
in my application (which is nested into the osgviewerQT example). I took the
code for picking from the osgpick example.
However, when I click on my view, there's the following possibilities
- the picked node/drawable is correct, but listed twice
- no intersection is computed, although I clicked on a drawable
- an intersection is computed, although i clicked into empty space
I can't explain, what I could be doing wrong. Perhaps it's that event comes
from QMouseEvent and has another coordinate system than osgviewer?
Any hints where to go from here?
Best wishes
Hartmut
Code:
void ViewerQT::mouseReleaseEvent( QMouseEvent* event )
{
// default mouse control
AdapterWidget::mouseReleaseEvent(event);
// continue with picking
osgUtil::LineSegmentIntersector::Intersections intersections;
float x = event-x();
float y = event-y();
std::cout ( x , y );
std::cout std::endl;
if (computeIntersections(x,y,intersections))
{
for(osgUtil::LineSegmentIntersector::Intersections::iterator hitr =
intersections.begin();
hitr != intersections.end();
++hitr)
{
if (!hitr-nodePath.empty() !(hitr-nodePath.back()-getName().empty()))
{
// the geodes are identified by name.
std::cout Object \
hitr-nodePath.back()-getName()
\
std::endl;
}
else if (hitr-drawable.valid())
{
std::cout Object \
hitr-drawable-getName()
\
std::endl;
}
}
}
--
frag nicht - du könntest eine antwort erhalten
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!
Jetzt informieren: http://www.gmx.net/de/go/freephone
___
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Post generated by Mail2Forum
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=42546#42546
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Skipping nodes in serialization
I was pondering this the other day and it occurred to me that the problem
boiled down to the fact that some (if not all) serializers do not write via a
subclass of NodeVisitor, and hence are unaffected by nodemasks.
I wondered if you could simply make your node so it is ONLY visible to
NodeVisitor traversal by subclassing the node and overriding the traverse
function. e.g.
Code:
class NonSerializedGroup : public osg::Group
{
public:
UnserializedGroup(osg::Group* unserializedGroup)
: _unserializedGroup(unserializedGroup) { }
void traverse(osg::NodeVisitor nv)
{
_unserializedGroup-traverse(nv);
}
osg::ref_ptrosg::Group _unserializedGroup;
}
graffy wrote:
Hi,
I have a graph that I serialize with a simple call to osgDB::writeNodeFile(),
but it contains a node that is auto-generated when the application starts.
Is there a way to exclude that node from serialization? I'm familiar with
the setNodeMask() / setTraversalMask() mechanism used in visitor classes, but
wasn't finding something similiar for serialization - nothing jumped out at
me in the ReaderWriter docs, anyway.
...
Thank you!
Cheers,
Joel
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=42491#42491
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] small memory leak in SceneCache?
Hi Robert,
Sorry to dredge this one up again, but I think there may be a flaw in the logic
of osgViewer::Scene destructor. The intention of the code seems clear, i.e. to
remove the Scene being destroyed from the scene cache.
For me at least (on Windows VC 2005) the removal *NEVER* happens.
The reason for this appears to be that the code itr-get() returns NULL when
itr refers to the object currently being destroyed. Which is logical, since if
itr is observing 'this' and 'this' is being destroyed, then there must be no
remaining ref_ptrs to 'this', and therefore the observer_ptr get function,
quite correctly, returns NULL.
I think this means that the scene cache vector will continually grow as new
scenes are constructed, but not emptied until program termination destroys the
static instance of the cache.
I'm not quite sure of the best solution to this is, but the current code is
definately not working for me.
Cheers.
Chris.
Code:
Scene::~Scene()
{
OpenThreads::ScopedLockOpenThreads::Mutex lock(getSceneCacheMutex());
for(SceneCache::iterator itr = getSceneCache().begin();
itr != getSceneCache().end();
++itr)
{
Scene* scene = itr-get();
if (scene==this)
{
getSceneCache().erase(itr);
break;
}
}
}
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=41155#41155
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Extending CURL plugin to implement write functions.
Hi, Just for info, incase anyone wants to give a writable curl a whirl, I've posted a modified plugin to the submissions group. Post subject: Implementation of write functions in CURL plugin. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=40832#40832 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Extending CURL plugin to implement write functions.
Hi, I have just been pondering the idea of extending the curl plugin so that it can perform http upload for write operations. In principle at least, it seems like this might be relatively easy to implement using existing functionality within the curl library. So, my questions are: 1. Has anyone already looked into this? 2. Does anyone except me think it's a good idea? 3. Any alternative suggestions for programatically uploading OSG objects? Thanks. Chris D. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=40707#40707 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Extending CURL plugin to implement write functions.
Hi Torben, Well, I'd like to avoid writing files on the local system (as I'm running inside a multi platform web browser plugin), but I suppose it would be possible to get the object format's plugin to write the object to a memory based std::ostream, then use curl library to upload the content. But once I've done that, it feels like the result would fit oh so neatly into the curl reader writer plugin for all the happy osg'ers to use. :-) Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=40709#40709 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Decompressing Compressed Textures
Hi, I have a question about extracting images from an IVE with compressed textures. I have a some IVE format files that have been created using a command line e.g. OSGCONV --compressed input.flt output.ive This works fine, but the problem I have is that I want to be able to reverse the process, e.g. OSGCONV -O OutputTextureFiles input.ive output.osg The problem being, the original JPG texture images referred to by input.flt can not be written out because the OSG JPG writer only seems to support image pixel format GL_LUMINANCE, GL_ALPHA GL_RGB. That is, it doesn't convert from the compressed DDS type images that are embedded in the IVE file when using the --compressed option. My question is, can anyone provide any tips on how to extract JPG images from an IVE with emeddeded compressed textures? In other words, is there a way to reverse the compression applied in osgconv by its CompressTexturesVisitor code? Thank you! Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=40679#40679 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Decompressing Compressed Textures
Thanks for the tip Torben, When I call osgDB::Registry::instance()-getImageProcessor(), I get NULL coming back. Digging a bit deeper, OSGs image processor relies on NVTT plugin, which relies on Nvidias NVTT SDK, which I'm struggling to find on the interweb. If you have a link to NVTT SDK download handy, could you send it to me. I'm sensing I might need to pass through the flaming gauntlet just to get to a point where I can get a feeling for whether this is going to help me. ;-) BTW. Does this reliance on NVTT mean it would only work in NVidia hardware? Cheers. Chris. zonk wrote: Hi, OSG provides an image processor class, it is used to compress and decompress image, maybe you can use it. Thank you! Cheers, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=40682#40682 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Decompressing Compressed Textures
Hi Torben, On Windows, we are using Visual Studio 2005. But I eventually found the link to NVTT download: http://developer.nvidia.com/gpu-accelerated-texture-compression I'll see if I have any success with that. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=40686#40686 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Decompressing Compressed Textures
Hi Torben, I've managed to build the NVTT plugin using that download, but now I'm still a bit stumped. The plugin and NVTT api seems to work, but it all seems geared towards compression rather than decompression. I was hoping that I would be able to use it like: Code: osg::ref_ptrosgDB::ImageProcessor processor = osgDB::Registry::instance()-getImageProcessor(); processor-compress(osgImage, osg::Texture::USE_IMAGE_DATA_FORMAT, false, false, osgDB::ImageProcessor::USE_GPU, osgDB::ImageProcessor::NORMAL); i.e. with second parameter with an uncompressed format. But this doesn't really work because the input image appears to be required to be in uncompressed RGB or RGBA. In fact, looking at the nvtt.h header file the ONLY option for input format appear to be BRGA_8UB, and the plugin always converts to that assuming that input osg image is RGB or RGBA, and makes a dogs breakfast of anything else. Ho hum... any more thoughts? Thanks. Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=40689#40689 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Decompressing Compressed Textures
Hi Torben, Yes, I was thinking along the same lines. I was just having a peep at the source of decompress.cpp that comes with the NVIDIA texture tools that might give a clue about the best way to do it. Which seemed to boil down to: Code: nv::DirectDrawSurface dds(inputImageFile); nv::StdOutputStream stream(outputTGAfile); nv::Image img; dds.mipmap(img, 0, 0); // get first image nv::ImageIO::saveTGA(stream, img); Though it's not clear exactly whether the mipmap function, or saveTGA does the decompression. I can't help wondering if we are missing a trick with OSG's DDS plugin? It looks as though it might contain some reusable magic for these kind of compression formats. :-) Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=40691#40691 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Decompressing Compressed Textures
Hi Robert, Thanks for the clarification. I hadn't realised the compression was particulary lossy as viewing the IVE files we are using (with compressed textures) seem to have an acceptable quality for our purposes. But you are right, ideally it would be better to keep the original textures, but it is also nice to avoid file management headaches. The problem is that our clients create catlogues of models using IVE files, and once they are happy with the results, we need to pass the catalogue through a conversion process to allow it to be used in a non-osg based application. Hence the need to extract the embedded textures. We can tell them not to compress the textures, but then that would make their catalogues at least twice the size. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=40697#40697 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PagedLOD/DatabasePager retry problem.
Ok, I seem to have found a workaround if anyone's interested:
Basically I add a read file callback that simply records in a map the
ReadResult for each file that is requested.
I then subclass the DatabasePager class to override the requestNodeFile
function so that it only calls the base class function for files that not been
recorded with a failed readresult.
Code:
class CustomDatabasePager : public osgDB::DatabasePager
{
public:
virtual void requestNodeFile(const std::string fileName,osg::Group*
group,
float priority, const osg::FrameStamp*
framestamp,
osg::ref_ptrosg::Referenced
databaseRequest,
const osg::Referenced* options)
{
osgDB::ReaderWriter::ReadResult::ReadStatus status;
if (CustomReadFileCallback::getCachedReadStatus(fileName, status))
{
if (status != osgDB::ReaderWriter::ReadResult::FILE_LOADED
status !=
osgDB::ReaderWriter::ReadResult::FILE_LOADED_FROM_CACHE)
{
// If we have requested this file and it failed, there is no
// point requesting it again, so bypassing normal request
// mechanism here.
return;
}
}
osgDB::DatabasePager::requestNodeFile(fileName, group, priority,
framestamp, databaseRequest, options);
}
};
chrisd wrote:
I'm using the function:
viewer-getDatabasePager()-getFileRequestListSize()
to determine whether background processing of PagedLOD objects is complete.
e.g I wait until it returns zero before performing screen grab.
This normally works fine, but if there are any files referred to by the
PagedLOD nodes are missing, then the files seem to keep getting added back to
the database pager file request list by the cull visitor.
This means (a) It is continuallly retrying to find each missing file, and (b)
the file request queue is never empty and so I can't determine when the
loading is as complete as it can get.
My questions are:
1. Should this be happening?
2. How do I avoid it?
I suppose I could check for file existence before constructing the PagedLOD
object, but I wanted to avoid that because this check is relatively expensive
over http, and would prefer that to be deferred to the db pager thread.
Cheers,
Chris
Code:
Code:
Code:
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=35404#35404
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] PagedLOD/DatabasePager retry problem.
I'm using the function: viewer-getDatabasePager()-getFileRequestListSize() to determine whether background processing of PagedLOD objects is complete. e.g I wait until it returns zero before performing screen grab. This normally works fine, but if there are any files referred to by the PagedLOD nodes are missing, then the files seem to keep getting added back to the database pager file request list by the cull visitor. This means (a) It is continuallly retrying to find each missing file, and (b) the file request queue is never empty and so I can't determine when the loading is as complete as it can get. My questions are: 1. Should this be happening? 2. How do I avoid it? I suppose I could check for file existence before constructing the PagedLOD object, but I wanted to avoid that because this check is relatively expensive over http, and would prefer that to be deferred to the db pager thread. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35376#35376 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] TexGen for screen coordinates.
chrisd wrote:
Paul Martz wrote:
On 12/10/2010 5:21 AM, Chris Denham wrote:
I've been trying to apply a 2d texture to an object where I want the UVs
to correspond to screen position. A bit like using EYE_LINEAR texgen, but
with the texture projected 'orthographically' through the screen.
What I want would in effect be like applying the texture so it always
spans the window, but without applying the perspective of the camera. I
guess, a bit like using the texture as a stencil.
I've tried using EYE_LINEAR, and that very nearly does what I want, but I
want to remove the effect of perspective on the way the texcoords are
calculated.
In other words, I think I want calculated texture UV's to be something
like:
texcoord.x = (worldPosition * (projectionMatrix * modelViewMatrix)).x
texcoord.y = (worldPosition * (projectionMatrix * modelViewMatrix)).y
What's the best way to implement this without using stencil buffer or
shaders?
Is there a way to do it by adjusting the texture matrix object to remove
the perspective projection?
Or would it be better to recalculate texCoords on geometries prior to
each frame?
Hope this makes some kind of sense.
With those restrictions, it seems like the texture matrix is your only path
to a
solution, though I couldn't type it here off the top of my head. It would
take
some dev time to get it right.
What you want to do would be trivial with a shader. Is there a reason why
you've
ruled out use of shaders for this problem?
--
-Paul Martz Skew Matrix Software
http://www.skew-matrix.com/
Thanks Paul,
I may use a shader if it comes down to it, but I was trying (if possible) to
get a solution that works on Joe Public's bargin basement laptop that
probably has poor (if any) shader support.
I have experimented with texmat object to get the projection right, but I
can't seem to get the matrix right (probably cos of my flakey maths). Maybe
I'll post a cut down example an someone can see if they spot the problem.
I've had some success with recalculating the texcoords on geometries and
assigning them with UVs based on screen coords. It's very nearly what I want
but I'm getting some odd distortions due to uv interpolation (I think).
Possibly a result of the texture mapping perspective correction, though I
tried switching that off with GL_PERSPECTIVE_CORRECTION_HINT = GL_FASTEST to
no avail :(
Ho hum maybe as you say, a shader is the answer, well, if I can make it
fail tidy on old craptops.
Cheers
Chris.
Well... I gave up on trying to do it that hard way, and as Paul suggested, it
was fairly trivial to do in a shader. e.g.
Code:
osg::Program* programShader = new osg::Program();
stateSet-setAttribute(programShader, osg::StateAttribute::ON);
stateSet-addUniform(new osg::Uniform(viewport, osg::Vec4(0, 0, 800, 600)));
stateSet-addUniform(new osg::Uniform(screen_texture, 0));
stateSet-addUniform(new osg::Uniform(tinge, osg::Vec4(0.9, 0.9, 0.9, 1.0)));
stateSet-setUpdateCallback(new ViewportTracker(pViewer-getCamera()));
osg::Shader *frag = new osg::Shader(osg::Shader::FRAGMENT);
frag-setShaderSource(
uniform sampler2D screen_texture; \
uniform vec4 viewport; \
uniform vec4 tinge; \
void main() \
{ \
vec2 origin = vec2(viewport[0], viewport[1]); \
vec2 size = vec2(viewport[2], viewport[3]); \
vec2 coord = (gl_FragCoord.xy - origin) / size; \
vec4 color = texture2D(screen_texture, coord); \
gl_FragColor = color * tinge; \
if (!gl_FrontFacing) gl_FragColor = tinge; \
});
programShader-addShader(frag);
Though I did wonder if there was a better way to get or convert to normalized
screen units because otherwise I have to put in a callback to track the
viewport definition and transfer it to the Uniform attribute?
Not a big issue, but any ideas on how to avoid needing to do that?
Chris Denham
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=34765#34765
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] TexGen for screen coordinates.
I've been trying to apply a 2d texture to an object where I want the UVs to correspond to screen position. A bit like using EYE_LINEAR texgen, but with the texture projected 'orthographically' through the screen. What I want would in effect be like applying the texture so it always spans the window, but without applying the perspective of the camera. I guess, a bit like using the texture as a stencil. I've tried using EYE_LINEAR, and that very nearly does what I want, but I want to remove the effect of perspective on the way the texcoords are calculated. In other words, I think I want calculated texture UV's to be something like: texcoord.x = (worldPosition * (projectionMatrix * modelViewMatrix)).x texcoord.y = (worldPosition * (projectionMatrix * modelViewMatrix)).y What's the best way to implement this without using stencil buffer or shaders? Is there a way to do it by adjusting the texture matrix object to remove the perspective projection? Or would it be better to recalculate texCoords on geometries prior to each frame? Hope this makes some kind of sense. Cheers, Chris Denham -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34694#34694 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] TexGen for screen coordinates.
Paul Martz wrote: On 12/10/2010 5:21 AM, Chris Denham wrote: I've been trying to apply a 2d texture to an object where I want the UVs to correspond to screen position. A bit like using EYE_LINEAR texgen, but with the texture projected 'orthographically' through the screen. What I want would in effect be like applying the texture so it always spans the window, but without applying the perspective of the camera. I guess, a bit like using the texture as a stencil. I've tried using EYE_LINEAR, and that very nearly does what I want, but I want to remove the effect of perspective on the way the texcoords are calculated. In other words, I think I want calculated texture UV's to be something like: texcoord.x = (worldPosition * (projectionMatrix * modelViewMatrix)).x texcoord.y = (worldPosition * (projectionMatrix * modelViewMatrix)).y What's the best way to implement this without using stencil buffer or shaders? Is there a way to do it by adjusting the texture matrix object to remove the perspective projection? Or would it be better to recalculate texCoords on geometries prior to each frame? Hope this makes some kind of sense. With those restrictions, it seems like the texture matrix is your only path to a solution, though I couldn't type it here off the top of my head. It would take some dev time to get it right. What you want to do would be trivial with a shader. Is there a reason why you've ruled out use of shaders for this problem? -- -Paul Martz Skew Matrix Software http://www.skew-matrix.com/ Thanks Paul, I may use a shader if it comes down to it, but I was trying (if possible) to get a solution that works on Joe Public's bargin basement laptop that probably has poor (if any) shader support. I have experimented with texmat object to get the projection right, but I can't seem to get the matrix right (probably cos of my flakey maths). Maybe I'll post a cut down example an someone can see if they spot the problem. I've had some success with recalculating the texcoords on geometries and assigning them with UVs based on screen coords. It's very nearly what I want but I'm getting some odd distortions due to uv interpolation (I think). Possibly a result of the texture mapping perspective correction, though I tried switching that off with GL_PERSPECTIVE_CORRECTION_HINT = GL_FASTEST to no avail :( Ho hum maybe as you say, a shader is the answer, well, if I can make it fail tidy on old craptops. Cheers Chris. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34722#34722 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with glass door in front of glass shelf.
Thanks Paul, I'll look into that. I was also wondering if it was possible to use kd tree to solve ordering problem, but not got round to investigating yet. I know there's code already in osg for dealing with bsp and kd trees, so, is there an easy way to use that code to solve my glass problem? Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25304#25304 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Problem with glass door in front of glass shelf.
I'm guessing that this is an old computer graphics problem to do with depth sorting the drawing sequence of transparent objects, but I'm a bit puzzled why OSG is having a problem with this little example. Basically, in some views of a this example scene, the transparency is not working properly. See attached JPG screen grab and OSG model. I suspect the root cause that in some views, the depthsort is causing a door to be drawn before a shelf even though the door is nearer. Is the depthsort ordered by depth of the midpoint of geometries? That would certainly explain the issue because the midpoint of a shelf could certainly be infront of the midpoint of a door even though ALL of the door polys are infront of ALL the shelf polys. (yes, read that last sentence again! lol.) I was wondering if the depthsorting algorithm could be improved to fix this problem, maybe by sorting by deepest geometry vertex rather than geometry midpoint (if that's what it's doing) ? Is there way to override render bin depthsort to provide it with different depth values for each geometry/drawable? I know I can also tweak things for special cases e.g. by putting the door and shelf in different render bins but that's not a general or practical solution. How are others solving this problem? Regards. Chris D. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25040#25040 Attachments: http://forum.openscenegraph.org//files/glassproblem_994.osg http://forum.openscenegraph.org//files/glassproblem_137.jpg ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with glass door in front of glass shelf.
Thanks for the speedy reply Robert. :) Have you got any tips on how to tweak the sort algorithm? Would I have to change OSG, or are there options or callbacks I can set from outside. I'm sure you are right that the best thing to do would be to split the shelf, but the problem is that we have many catalogues of models that would not be practical to edit. Interestingly, I don't seem to get the problem in our older WorldTookit based system, so that must be using a different algorithm or sort parameter (but got no src code for that). Thank you! Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25044#25044 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with glass door in front of glass shelf.
Hi Maxim, Thanks for the link, a very interesting description of depth peeling technique (it's new to me). Though now I'm feeling a bit out of my own depth ;-) Am I right in thinking the implementation described here will only work on NVidia GeForce3 hardware? Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25047#25047 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with glass door in front of glass shelf.
Question 2: If, in a simple scene consisting of two non intersecting transparent triangles, it is always possible to find a correct order to draw them, then what is the algorithm that sorts them? Given that a single depth value for each triangle is insufficent to determine the correct order, it feels like there ought to be a simple geometric solution using all three vertices. Unfortunately my maths head seems to be in the wash today. Chris. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25055#25055 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Getting the effective stateset for a nodepath.
Given a nodepath, what is the correct way to extract the effective material
that will be used to render the node? i.e. to take into account the attribute
inheritance and overrides etc.
My first stab looked like the code below, which seemed to work for simple
cases, but not when the graph contained overrides etc.
Cheers
Chris.
Code:
osg::ref_ptrosg::StateSet stateSet = new osg::StateSet();
osg::NodePath::const_iterator i = getNodePath().begin();
for (; i != getNodePath().end(); i++)
{
osg::Node* node = *i;
const osg::StateSet* merge = node-getStateSet();
if (merge) stateSet-merge(*merge);
}
const osg::Material* material = NULL;
material = dynamic_castconst
osg::Material*(stateSet-getAttribute(osg::StateAttribute::MATERIAL));
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=19709#19709
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] memory leak in osg 2.8.2 ?
Hi Sebastien,
Hmmm, just looking my code again and realized I didn't actually perform the
check directly. I delay the leak check until nearer termination using
_CrtSetDbgFlag. e.g.:
Code:
~TheEnd() { _CrtSetDbgFlag(_CRTDBG_LEAK_CHECK_DF); }
Seems to work ok for me in VS2005.
Cheers,
Chris
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=18380#18380
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] memory leak in osg 2.8.2 ?
The trick, if I can call it that, is to perform the leak check in the
destructor of the last destroyed object. Works for me!
You just need to make sure your global heap check object is created before OSG
gets to make its evil singletons ;-) . e.g.
Code:
struct TheEnd
{
~TheEnd() { CheckForLeaks(); }
};
TheEnd theEnd;
int main(int argc, char* argv[])
{
osgViewer::Viewer viewer;
viewer.run();
return 0;
}
Cheers,
Chris
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=18328#18328
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ReaderWriters : Does the writer use libcurl?
Hi, I was wondering recently whether curl should always be tried FIRST for server addresses, for both read and write. The reason I picked up on this was that I noticed a slight oddity with the existing reader plugin selection, which can end up unneccessarily trying the curl plugin twice when the server being accessed is down. It tries once when curl is one of the available plugins and then curl again when those all fail. Not a huge problem but it makes my program fail twice as slowly lol. Of course to work round your problem, you can alway use the plugin directly via osgDB::Registry::instance()-getReaderWriterForExtension(curl); Though I think that bypasses caching mechanisms in registry. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=17384#17384 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Reference count catcher?
Hi Ufuk, You don't need to know the address of your geometry at compile time. Put a break point on the place where you create the geometry. Run to that point and make a note of its address (or copy it to clipboard). Set a break point in Referenced::ref and right click on the red breakpoint blob. Choose conditional break point and set it to 'this=0xblahblah' (substituting blahblah with your object address). Run again, and then it should break each time ref is called for your geometry. Beware that it may be called a few more times than you might expect as pushing to arrays of ref counted objects may create temporary ref ptr objects as the array is reallocated. It does work.. just tried it in VS2005. Cheers. Chris. Date: Wed, 19 Aug 2009 16:36:58 +0300 From: Ufuk ufuk@gmail.com Subject: Re: [osg-users] Reference count catcher? To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Message-ID: b76c8c6d0908190636k2236a0b6r6f8519bbdfe60...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 Hi Gordon, i cant place a break point into osg::Referenced class. if i put i get every classes which are referenced. and since the compile time, i can not know the address of my geometry i cant add such an if. anyway it is the whole rebuild of osg library. if i venture this, i do the method that ismail has told before... it seems a better idea.. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Reference count catcher?
Of course you spotted the deliberate mistake... should be this==0xblahblah C. - Original Message - From: Chris Denham c.m.den...@gmail.com To: osg-users@lists.openscenegraph.org Cc: ufuk@gmail.com Sent: Wednesday, August 19, 2009 5:10 PM Subject: Re: [osg-users] Reference count catcher? Hi Ufuk, You don't need to know the address of your geometry at compile time. Put a break point on the place where you create the geometry. Run to that point and make a note of its address (or copy it to clipboard). Set a break point in Referenced::ref and right click on the red breakpoint blob. Choose conditional break point and set it to 'this=0xblahblah' (substituting blahblah with your object address). Run again, and then it should break each time ref is called for your geometry. Beware that it may be called a few more times than you might expect as pushing to arrays of ref counted objects may create temporary ref ptr objects as the array is reallocated. It does work.. just tried it in VS2005. Cheers. Chris. Date: Wed, 19 Aug 2009 16:36:58 +0300 From: Ufuk ufuk@gmail.com Subject: Re: [osg-users] Reference count catcher? To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Message-ID: b76c8c6d0908190636k2236a0b6r6f8519bbdfe60...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 Hi Gordon, i cant place a break point into osg::Referenced class. if i put i get every classes which are referenced. and since the compile time, i can not know the address of my geometry i cant add such an if. anyway it is the whole rebuild of osg library. if i venture this, i do the method that ismail has told before... it seems a better idea.. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Processing input events without calling Viewer::frame?
Background: In a particular durr-brain day yesterday, I was struggling to get a small windowed OSG app working properly. The problem with it was that OSG was not processing the keyboard and mouse events for the window hosting the OSG viewer. As it turns out, this was simply the result of me ONLY calling viewer-frame from within the paint function of the window. Eventually, in a flash of common sense, I decided to also call viewer-frame from within a timer function running at 60Hz, and now it is working nicely. The Question: It occured to me to wonder.. Why do I need to call 'frame' in order to process user events? If I happen to know that my view only needs updating as a RESULT of a user event, how do I process the event without updating the view? Do I have to hammer the CPUGPU with calls to frame while waiting for user input? In a nutshell, is it possible to get OSG to process events without calling frame? Or is it something I shouldn't want to do? Chris. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Processing input events without calling Viewer::frame?
Hi Robert, I think the thing that still puzzles me though is this: Why can't an event be processed on receipt of the event instead of putting it in a queue for processing at the next event traversal? It seems that in order to make it work the way I want, I have to intercept user events outside OSG and to call frame/eventTraversal to get it to process the event that OSG just received and queued. Thanks for the tip on breaking up frame() method. Chris. - Original Message - From: Robert Osfield robert.osfi...@gmail.com To: Chris Denham c.m.den...@gmail.com; OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Tuesday, June 02, 2009 2:46 PM Subject: Re: [osg-users] Processing input events without calling Viewer::frame? Hi Chris, The osgViewer in it's default configuration is built for realtime apps so is focused on doing a continuous frame loop. You aren't tied to this, and can call viewer-frame() when you app wants, and you can even break the viewer::frame() method out into it constituent parts for advance(), eventTraversal(), updateTraversal() and renderingTraversals(). Lots has been written about this in the past so please check the archives. Robert. On Tue, Jun 2, 2009 at 2:31 PM, Chris Denham c.m.den...@gmail.com wrote: Background: In a particular durr-brain day yesterday, I was struggling to get a small windowed OSG app working properly. The problem with it was that OSG was not processing the keyboard and mouse events for the window hosting the OSG viewer. As it turns out, this was simply the result of me ONLY calling viewer-frame from within the paint function of the window. Eventually, in a flash of common sense, I decided to also call viewer-frame from within a timer function running at 60Hz, and now it is working nicely. The Question: It occured to me to wonder.. Why do I need to call 'frame' in order to process user events? If I happen to know that my view only needs updating as a RESULT of a user event, how do I process the event without updating the view? Do I have to hammer the CPUGPU with calls to frame while waiting for user input? In a nutshell, is it possible to get OSG to process events without calling frame? Or is it something I shouldn't want to do? Chris. ___ 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] Processing input events without calling Viewer::frame?
Hi Robert, I see, that makes sense. In my example, I just have, in effect, a simple scene editor. So process the event, then update the view is all I need in this case. Just for info: I'm running the osgviewer attached to the hWnd of a WinForms Panel in a .NET app. So I guess the events are getting into OSG via the replacement WndProc that OSG assigns to Panel window handle. Chris. - Original Message - From: Robert Osfield robert.osfi...@gmail.com To: Chris Denham c.m.den...@gmail.com Sent: Tuesday, June 02, 2009 5:18 PM Subject: Re: [osg-users] Processing input events without calling Viewer::frame? Hi Chris, On Tue, Jun 2, 2009 at 5:07 PM, Chris Denham c.m.den...@gmail.com wrote: I think the thing that still puzzles me though is this: Why can't an event be processed on receipt of the event instead of putting it in a queue for processing at the next event traversal? The OSG isn't event driven by default, it's frame driven. In real-time apps and games you absolutely don't want ever to be event driven, it would totally mess up getting a consistent frame rate. Instead the OSG polls for events, and this polling is done in Viewer::eventTraversal(). However, if you are using an event driven apps such as one based on Qt etc. then it'll be pushing the events to the viewer. it does sound like you are using the OSG's inbuilt event support though... Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Possible dangling deleted pointer problem with Dragger/Manipulator
I've just tracked down a problem with my osg application crashing and was
wondering about the correct place to put the fix.
I can fix it outside osg but it occured to me that it might be better to fix
it within osg because I think its a bug that has the potential for causing
memory corruption.
The problematic code (pasted annotated below) is in
osgManipulator::CommandManager::disconnect() which removes a dragger object
from two STL maps.
The problem occurs when _draggerSelectionMap contains the last reference to
the passed dragger object. In this scenario, _draggerConstraintMap.erase is
called with a pointer to a deleted object, which actually results in a call
to ref for the deleted dragger object; this is very bad!
The fix I suggest is to change CommandManager::disconnect to take
'ref_ptrDragger' parameter rather than a 'C++ reference'.
Happy to post to submissions list if this seems sensible.
bool CommandManager::disconnect(Dragger dragger)
{
_draggerSelectionMap.erase(dragger);
_draggerConstraintMap.erase(dragger); // dragger may be deleted at
this point
return true;
}
Cheers.
Chris.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Possible dangling deleted pointer problem with Dragger/Manipulator
Thanks J-S,
Yes, your first suggestion certainly fixes the problem (I tried it earlier!)
and I agree, its probably and advantage to keep the interface the same. I
think I just had a niggling feeling that it probably wasn't a good idea in
principle to pass around C++ references to ref counted objects.
I think your second suggestion however, might suffer the same fate as the
original code because I suspect your second call to 'find' can still be
passed a pointer to a deleted object, and so when the stl map template
converts the dead pointer to a ref pointer before it does the find, so this
probably still results in a call to ref for the deleted object and so
incremenets the ref count in released space of the heap.
Cheers.
Chris.
- Original Message -
From: Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com
To: Chris Denham c.m.den...@gmail.com; OpenSceneGraph Users
osg-users@lists.openscenegraph.org
Sent: Tuesday, May 05, 2009 3:41 PM
Subject: Re: [osg-users] Possible dangling deleted pointer problem with
Dragger/Manipulator
Hi Chris,
Why not:
bool CommandManager::disconnect(Dragger dragger)
{
osg::ref_ptrDragger localDragger(dragger);
_draggerSelectionMap.erase(dragger);
_draggerConstraintMap.erase(dragger); // may be deleted at this
point
return true;
}
or just:
bool CommandManager::disconnect(Dragger dragger)
{
if (_draggerSelectionMap.find(dragger) !=
_draggerSelectionMap.end())
_draggerSelectionMap.erase(dragger);
if (_draggerConstraintMap.find(dragger) !=
_draggerConstraintMap.end())
_draggerConstraintMap.erase(dragger); // may be deleted at this
point
return true;
}
Then the interface doesn't change and it should be safe.
J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] swapBuffers warning when window minimized
Bit of a late reply to this one, but just arrived at the same problem.
For me, on Windows, I also get a slew of these warnings when I move the
window off screen.
So, might be a bit fiddly to try and prevent frame update in all situations
that SwapBuffers retuns false.
I wondered if we could address this issue by only reporting the error if
GetLastError is also non zero. Works for me!
The value returned by GetLastError is zero when SwapBuffers is called for a
minimized or off screen window, so we could just add a check for this.
Just say the word, and I'll post my modified GraphicsWindowWin32.cpp to the
submissions list. ;-)
Cheers.
Chris.
e.g.
//- OSG- 2..8 --
void GraphicsWindowWin32::swapBuffersImplementation()
{
if (!_realized) return;
if (!::SwapBuffers(_hdc))
{
reportErrorForScreen(GraphicsWindowWin32::swapBuffersImplementation()
- Unable to swap display buffers, _traits-screenNum, ::GetLastError());
}
}
//- Modification to remove redundant warnings --
void GraphicsWindowWin32::swapBuffersImplementation()
{
if (!_realized) return;
if (!::SwapBuffers(_hdc) ::GetLastError() != 0)
{
reportErrorForScreen(GraphicsWindowWin32::swapBuffersImplementation()
- Unable to swap display buffers, _traits-screenNum, ::GetLastError());
}
}
Robert Osfield
Tue, 01 Jul 2008 11:05:14 -0700
Hi John,
I have just checked on linux box and it works fine, so I presume it's
a windowing specific issue. What windowing setup are you using?
If swap buffers is failing then it suggest the best thing that could
be done would be to detect the window iconise event and stop the frame
loop from executing till the window opens up again. This could
possible be something put into osgViewer itself, although there is
probably multiple ways one could handle it - for instance keep the
frame loop running but stop the rendering dispatch the problem
windows.
Robert.
On Tue, Jul 1, 2008 at 5:36 PM, Argentieri, John-P63223
[EMAIL PROTECTED] wrote:
All,
When an osg application is minimized, osg complains about swapbuffers
failing, on every frame. This output can be overwhelming. Can we fix
this
somehow? Is there some kind of verbosity level? Is that even a word?
John
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Dragger rendering issue
Hi Ruqin, Which version of OSG are you building my example against? It sounds like you may be having the 'subgraph relative camera problem' I hinted at below. This problem can affect the location and picking of things below the subgraph camera, so you won't be able to use the example with an unmodified OSG2.6 I think Robert put in a fix to help with this after OSG 2.6 but I can't remember the detail. I could probably did out the OSG changes required if necessary, but best to avoid patching OSG if possible. Cheers. Chris. - Original Message - From: Ruqin Zhang To: Chris Denham ; OpenSceneGraph Users Sent: Friday, February 13, 2009 10:56 PM Subject: Re: [osg-users] Dragger rendering issue Hi Chris, Thanks for the example code. It's really good that I can see the dragger rendered on top of the scene. While, seems I cannot move or even juct select the dragger. Is there any problem with it? Anyone know the problem? Thanks a lot! Ruqin On Wed, Jan 28, 2009 at 3:46 AM, Chris Denham c.m.den...@gmail.com wrote: Hi Ruqin, I have attached an example VC2005 project that I put together whilst working on this. At some point I'd like to formally submit it as an example to OSG but it probably needs a bit more 'polishing' before Robby would be let in ;-). I built the example against a modified OSG 2.6 so you may need to build against the trunk to get the fix for subgraph relative camara problems. But in any case, I hope the source code gives you food for thought. Note that if you get my example to work, the translate, rotate and scale draggers are activated by pressing 'w' 'e' 'r' respectively, and view rotation is enabled by holding down alt key. My objective in the project was to create an interface similar to my favourite 3D modelling pakage... Maya. Chris.___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Dragger rendering issue
Hi Ruqin, Just wanted to add to this as Robert and JS suggested switching off the depth test for the dragger. I have actually tried that and found the results less than ideal for the normal dragger geometries. The problem is that the parts of the dragger geometries may not render correctly over each other with depth test off. Chris. - Original Message - From: Chris Denham c.m.den...@gmail.com To: osg-users@lists.openscenegraph.org Sent: Tuesday, January 27, 2009 9:33 AM Subject: Re: [osg-users] Dragger rendering issue Hi Ruqin, I had the same problem with Draggers, and the solution was to put the dragger object in the scenegraph below a post render camera. This works well for me as I can now also drag the selected object when it is behind other objects in the scene. To do this you may need a version of OSG later that 2.6 though, because I had some problems in relation to transforms and subgraph cameras which Robert helped me to fix. The other 'enhancement' I made was to add an autotransform node to keep the dragger geometry the same size on the screen regardless of the size/scale of the object. Chris. Date: Mon, 26 Jan 2009 17:47:44 -0600 From: Ruqin Zhang ruzh...@gmail.com Subject: [osg-users] Dragger rendering issue To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Message-ID: e72eee3a0901261547p65185c2bs72f4dff743737...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 Hi, I got an issue about osgManipulator::dragger. When I set up a dragger, sometime it just hide (totally or partially) inside the selected object. So, I am wondering if there is some sort of way that I could always force the dragger rendered on top of the selected object to make it fully visible to user? Thanks a lot! Ruqin ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Dragger rendering issue
Have you tried my earlier suggestion?i.e. adding a post render camera just above the dragger. Can be a bit fiddly to manage the scenegraph, so might be worth trying any other ideas first. But I can give you some code snippets if you want to try it. Chris. - Original Message - From: Ruqin Zhang To: Chris Denham ; osg-users@lists.openscenegraph.org Sent: Tuesday, January 27, 2009 4:45 PM Subject: Re: [osg-users] Dragger rendering issue Thank you guys! I tried the idea of turning off the depth test. It works ok but not perfect. Just as Chris mentioned, there is some rendering problem of the dragger geometries. Anyone has idea of solving this problem? Thanks again! Ruqin On Tue, Jan 27, 2009 at 9:20 AM, Chris Denham c.m.den...@gmail.com wrote: Hi Ruqin, Just wanted to add to this as Robert and JS suggested switching off the depth test for the dragger. I have actually tried that and found the results less than ideal for the normal dragger geometries. The problem is that the parts of the dragger geometries may not render correctly over each other with depth test off. Chris. - Original Message - From: Chris Denham c.m.den...@gmail.com To: osg-users@lists.openscenegraph.org Sent: Tuesday, January 27, 2009 9:33 AM Subject: Re: [osg-users] Dragger rendering issue Hi Ruqin, I had the same problem with Draggers, and the solution was to put the dragger object in the scenegraph below a post render camera. This works well for me as I can now also drag the selected object when it is behind other objects in the scene. To do this you may need a version of OSG later that 2.6 though, because I had some problems in relation to transforms and subgraph cameras which Robert helped me to fix. The other 'enhancement' I made was to add an autotransform node to keep the dragger geometry the same size on the screen regardless of the size/scale of the object. Chris. Date: Mon, 26 Jan 2009 17:47:44 -0600 From: Ruqin Zhang ruzh...@gmail.com Subject: [osg-users] Dragger rendering issue To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Message-ID: e72eee3a0901261547p65185c2bs72f4dff743737...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 Hi, I got an issue about osgManipulator::dragger. When I set up a dragger, sometime it just hide (totally or partially) inside the selected object. So, I am wondering if there is some sort of way that I could always force the dragger rendered on top of the selected object to make it fully visible to user? Thanks a lot! Ruqin ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 4m 36 seconds!
Hmm, I sorry to have to tell you Robert. This looks like top of the range model, but I'm afraid it won't perfrom any better than an Ex-Box. Chris. Date: Fri, 5 Dec 2008 14:38:04 + From: Robert Osfield [EMAIL PROTECTED] Subject: Re: [osg-users] 4m 36 seconds! To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 Hi All, I've taken a picture of my latest computer jut to make you all jealous :-) Robert. -- next part -- A non-text attachment was scrubbed... Name: NewComputer.jpg Type: image/jpeg Size: 191797 bytes Desc: not available URL: http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20081205/8069c4c1/attachment.jpg ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Getting a value calculated by a GLSL shader once per frame.
I have been trying to work out how/if you can use a shader to compute a value (once per frame) and use that value as a constant in the shader for the rest of the frame. For example, I want to use a shader to find the minimum value in a texture once at the beginning of a each frame, then use that minimum value (probably as a uniform) in a fragment shader. It seemed to me I have two problems: 1. How do I get a shader (or part of a shader) to only execute once per frame? 2. How do I get the minimum value out of the shader in order to get the application to put it in a uniform? The only way I could think of to get a value out of a shader was to render its result to a texture and pick the data out of the texture in the application. Urgg.. there must be a better way. I had the idea that people may be using shaders as a general purpose 'rocket powered' implementation for all kinds of general algorithms, but I can't see how to use them in that way. Does OSG provide a way to use GLSL for anything other than 'colouring pixels' ;-) ? Chris. - The answers to stupid questions are often more enlightening than the answers to smart ones. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Getting a value calculated by a GLSL shader once per frame.
Hi Mike, I hadn't heard of CUDA, sounds interesting. Though shame it requires Nvidia hardware. What was in my mind when I said part of a shader was the idea that maybe there was a way to have a function in a shader that was only executed once per frame to setup some variables used by the rest of the shader. I guess a bit like a some kind of lazy initialization method. Hmmm, now I spelt it out, I just had a thought. Could I implement lazy per frame initialization within the fragment shader using the value of a pixel in frame buffer that the shader is writing? i.e. can the shader read pack a pixel that was written by a previous execution? Can you explain what you mean by geometry feedback path? Not heard of that. I'm still a bit puzzled about how to get a shader to execute once per frame, do I need to apply it to something that only has one vertex or renders to one pixel? The reason I say urgg about returning data via information embedded in a texture is the same reason I don't like any kind of blind type casting. But you are right, in my case may not be too bad as I probably just want to return a single float in the red component of a pixel, so I'll give it go. Cheers. Chris. - Original Message - From: Mike Weiblen [EMAIL PROTECTED] To: Chris Denham [EMAIL PROTECTED]; OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Sunday, November 23, 2008 6:49 PM Subject: Re: [osg-users] Getting a value calculated by a GLSL shader once per frame. Hi Chris, comments inline... On Sun, Nov 23, 2008 at 9:47 AM, Chris Denham [EMAIL PROTECTED] wrote: I have been trying to work out how/if you can use a shader to compute a value (once per frame) and use that value as a constant in the shader for the rest of the frame. For example, I want to use a shader to find the minimum value in a texture once at the beginning of a each frame, then use that minimum value (probably as a uniform) in a fragment shader. Yes, a uniform would be the right path in. It seemed to me I have two problems: 1. How do I get a shader (or part of a shader) to only execute once per frame? (Not sure what you mean by part of a shader.) But you could use two passes, with the scene you're analyzing under your special shader, the other pass would render using the result from the first pass 2. How do I get the minimum value out of the shader in order to get the application to put it in a uniform? There are three ways I can think of: 1) the usual way: readback final fragment values written to some render target, like a texture or FBO. 2) use the geometry feedback path (I have little experience with this path, so dont know its limitations etc) 3) use CUDA The only way I could think of to get a value out of a shader was to render its result to a texture and pick the data out of the texture in the application. Urgg.. there must be a better way. it's not that distasteful is it? I had the idea that people may be using shaders as a general purpose 'rocket powered' implementation for all kinds of general algorithms, but I can't Sure, NV's CUDA does all sorts of general-purpose computing on the GPU, hiding implementation details behind a parallel compute abstraction. At NVISION there was a cool demo using CUDA and GL together to render a scene using both raytracing and rasterization (used raytracing only on a shiny car, used rasterization for the road and other background features, a nice approach for quality/performance tradeoffs) see how to use them in that way. Does OSG provide a way to use GLSL for anything other than 'colouring pixels' ;-) ? afaik OSG doesn't have any direct support for CUDA, but that doesn't stop you from interpreting a framebuffer result as something other than colored pixels. cheers -- mew Chris. - The answers to stupid questions are often more enlightening than the answers to smart ones. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Mike Weiblen -- Boulder Colorado USA -- http://mew.cx/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osg-submissions] Patch for Philips WOWvx Displays
Hi Robert, Do you get that error on exit? The comments on the code around the place it fails under windows suggests there are threading issues to do with deleting the PixelBuffers, and setting single threaded mode on the viewer made the problem go away. But in any case, I think you are right, (although WOWvx is pretty unusable for my scenes without that change), I agree it needs some more thought to do it in a better way. I have stuggled in the past with solutions involving near and far planes, but the problem seemed to be that OSG would often use a near plane distance where all the pixels actually rendered to the depth map get a value close to 1.0. I think this effect is shown clearly with my go inside the box example. I did have an earlier discussion about near-far planes on the user list in relation to this problem, but we didn't come up with anything that helped (well, apart from my understanding of the 'depth' of the problem lol.) I think your idea for using shaders to calculate the min depth is the right way to go, indeed I did consider that, but I couldn't work out how to do it. Shaders have two types right? One type for vertices and one for pixels, I need the minimum depth value in the pixel shader, but neither type seemed the right place to sample all the depth values to calculate the minimum value. CCing osg-users for ideas! Cheers Chris. - Original Message - From: Robert Osfield [EMAIL PROTECTED] To: Chris Denham [EMAIL PROTECTED]; OpenSceneGraph Submissions [EMAIL PROTECTED] Sent: Friday, November 21, 2008 4:57 PM Subject: Re: [osg-submissions] Patch for Philips WOWvx Displays Hi Chris, I can reproduce the problem with going inside the box reliably so thumbs up on a good test case. I've merged and test the code and under Kubuntu 7.10 and get the error: Got an X11ErrorHandling call display=0x70a410 event=0x7fffb8f1bd70 GLXBadPbuffer Major opcode: 128 Minor opcode: 28 Error code: 138 Request serial: 56 Current serial: 57 ResourceID: 4294967295 Got an X11ErrorHandling call display=0x70a410 event=0x7fffb8f1c460 Which is not too dissimilar the error you've see under Windows. This strongly suggests that the is problem with the visuals that are been requested for this window. Having reviewed the wider algorothim that you are using here, I can't help but feel that doing a read back to main memory and then analysing depth this data on the CPU is really poor solution performance wise. Could one not use the computed near/far planes of the RTT camera handling the rendering of the scene? Or if you really have to analyse the depth data then this really should be done using a shader down on the GPU. Given that the submission produces known errors on two platforms, and implements are very inefficient technique I feel that this submission is not ready to merge - it introduces more problems than is solves. Perhaps a discussion on osg-users might strike us some different ideas on how to tackle the issues with the current implementation. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] A very simple ref_ptr memory leak example.
Thanks Simon, I think you are right. In my application, the member pointers causing the problem are really 'users' rather than 'owners'. One of my objectives is to protect myself from my own programming, and so avoiding raw pointers and moving into a style of programming that is more like Java or C# helps me a lot. If I had noticed the existance of osg::observer_ptr earlier, I think maybe I would have used it instead of ref_ptr for the class members in this case, and thus avoided the problem. On the other hand, if I had done that, my understanding of the problem would now be less complete ;-) Chris. Date: Tue, 18 Nov 2008 23:37:00 + From: Simon Hammett [EMAIL PROTECTED] Subject: Re: [osg-users] A very simple ref_ptr memory leak example. To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 Don't forget that these reference counted pointers (of all types) actually conflate two completely different concepts. That is: Ownership - vs - Uses / Has a relationship with If you break down your use of these pointers into these two concepts it's usually easy to work out what to do. Many objects make use of many different other objects, but ownership is usually a much more straight forward proposition. i.e. It rarely makes sense for object A to own object B and object B to own object A. but it's quite common for A to use B and B to use A. In general, use ref_ptr for owner ship and raw pointer (or better yet references) for uses. Of course there are exceptions to every rule of thumb, but the only times I've seen significant differences are when people are implementing interpreted languages and other relatively obscure corner cases. -- The truth is out there. Usually in header files. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] A very simple ref_ptr memory leak example.
I'm probably treading very old ground here to do with circular usage of
ref_ptr, but it's new to me and I couldn't find any references in the mail
archive about users with similar problems.
I have pasted below, a very simple example of my usage of ref_ptr that leaks
memory.
I can see why it leaks and the destructors are never called, but I am
looking for any good tips on how best to guard against such a scenario.
Do I need to use weak ref pointers to implement this scenario properly? Can
that be done with ref_ptr? I could call unref but that seems like a bad
idea.
It seemed such an easy trap to fall into, I wondered why it doesn't crop up
more often? And if it does, how others have dealt with circular problems of
this type in OSG?
Chris Denham
//--
#include osg/ref_ptr
#include osg/Referenced
#include iostream
int main(int argc, char* argv[])
{
struct B;
struct A : public osg::Referenced
{
~A() { std::cout A::~A() called std::endl; }
osg::ref_ptrB b;
};
struct B : public osg::Referenced
{
~B() { std::cout B::~B() called std::endl; }
osg::ref_ptrA a;
};
osg::ref_ptrA a = new A();
osg::ref_ptrB b = new B();
a-b = b;
b-a = a;
return 0;
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] A very simple ref_ptr memory leak example.
Thanks, but that is not the problem. They are already implicitly virtual because of inheriting from Referenced. And protecting destructors will only help preventing making the Referenced derived objects on the stack... which I'm not doing here. I've just discovered osg::observer_ptr, so I'm having a look at that. Looks like it may be the ticket! Cheers. Chris. - Original Message - From: Enrique Parodi To: Chris Denham ; OpenSceneGraph Users Sent: Tuesday, November 18, 2008 5:26 PM Subject: Re: [osg-users] A very simple ref_ptr memory leak example. Try using virtual protected destructors ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] A very simple ref_ptr memory leak example.
Hmm, not sure why it wouldn't compile for you, I'm using VisualStudio 2005
with OSG 2.6.
Thanks for the link.
Chris.
- Original Message -
From: Paul Melis [EMAIL PROTECTED]
To: Chris Denham [EMAIL PROTECTED]; OpenSceneGraph Users
osg-users@lists.openscenegraph.org
Sent: Tuesday, November 18, 2008 5:37 PM
Subject: Re: [osg-users] A very simple ref_ptr memory leak example.
What compiler are you using? The snippet doesn't compile for me with gcc
4.1.2.
It's not hard indeed to create cycles, and handling them robustly would
mean checking for every reference stored in a Referenced instance if
there isn't a cycle.
Which is not impossible, but adds a lot of overhead I suspect.
See Caveat #4 in
http://andesengineering.com/OSG_ProducerArticles/RefPointers/RefPointers.html
Paul
Chris Denham wrote:
I'm probably treading very old ground here to do with circular usage
of ref_ptr, but it's new to me and I couldn't find any references in
the mail archive about users with similar problems.
I have pasted below, a very simple example of my usage of ref_ptr that
leaks memory.
I can see why it leaks and the destructors are never called, but I am
looking for any good tips on how best to guard against such a scenario.
Do I need to use weak ref pointers to implement this scenario
properly? Can that be done with ref_ptr? I could call unref but that
seems like a bad idea.
It seemed such an easy trap to fall into, I wondered why it doesn't
crop up more often? And if it does, how others have dealt with
circular problems of this type in OSG?
Chris Denham
//--
#include osg/ref_ptr
#include osg/Referenced
#include iostream
int main(int argc, char* argv[])
{
struct B;
struct A : public osg::Referenced
{
~A() { std::cout A::~A() called std::endl; }
osg::ref_ptrB b;
};
struct B : public osg::Referenced
{
~B() { std::cout B::~B() called std::endl; }
osg::ref_ptrA a;
};
osg::ref_ptrA a = new A();
osg::ref_ptrB b = new B();
a-b = b;
b-a = a;
return 0;
}
___
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] A very simple ref_ptr memory leak example.
Thanks for the tips everyone. I suppose as Paul suggests, it's best to avoid doing things that hurt. The problem is that when we accidentally implemented this pattern in a more complex application, it was a bit fiddly to track down. I only noticed the problem because of the memory leak that resulted from it. I suppose the lesson I learn is that I need to be more careful when using ref_ptr than blindly applying it to every Referenced object whose lifetime is less than obvious to me. Which I have to confess, was my previous rather flawed logic. Chris. Date: Tue, 18 Nov 2008 10:56:03 -0700 From: Paul Martz [EMAIL PROTECTED] Subject: Re: [osg-users] A very simple ref_ptr memory leak example. To: 'OpenSceneGraph Users' osg-users@lists.openscenegraph.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Using ref_ptr's is far cheaper than a garbage collector we don't have (... until ISO C++ 2009 ?). osg::observer_ptr could be used to solve the problem, but you can also simply try to avoid circular references... how ? Well, you could try to define an object to be slave of another one. For instance, if 'B' is slave, then A has a ref_ptr to B, and B has only a raw pointer (A*). In most cases it's enough because the raw pointer is used only when A is allocated. That's how I'd handle it. The posted code would behave the same for any type of reference-counted memory management system, I imagine, so isn't really an issue with OSG ref_ptr classes. It's simply an aspect of the algorithm, which programmers must be aware of and be careful to avoid. Or, to put it another way: I went to the doctor and said, 'hey doc, it hurts when I do this' and he replied 'don't do that'. :-) -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with computeIntersections for nodes below post render camera
Hi Robert,
For my usage of computeIntersections, as I said, I put the test scene into
the osgpick example. From there it is quite clear that the picking results
do not return what I believe most people will expect for that scene.
I was aware that the computeIntersections method is a wrapper for the
IntersectionVisitor class, but this class shows the same symptoms when used
directly. My intention was to give the most condensed example of the problem
in the hope the people would clearly understand the scenario that I think is
misbehaving. Ho hum. ;-)
So, I decided to put my miners helmet on and deleve into the subterranean
depths of the osg machine. I think I have discovered that something is
missing from 'IntersectionVisitor::accept(Camera)' because is makes the
assumption that all cameras have an absolute coordinate frame. This is an
assumption that neither PickVisitor::appy(Camera) or
CullVisitor::apply(Camera) makes. So I have merged the relevant code from
CullVistor into IntersectionVisitor and this now seems to function
correctly.
Please can you check the attached file with changes appied to
IntersectionVisitor.cpp (from osg 2.6).
[Also posted to submissions list]
Chris.
Date: Sun, 26 Oct 2008 15:53:19 +
From: Robert Osfield [EMAIL PROTECTED]
Subject: Re: [osg-users] Problem with computeIntersections for nodes
below post render camera.
To: OpenSceneGraph Users osg-users@lists.openscenegraph.org
Message-ID:
[EMAIL PROTECTED]
Content-Type: text/plain; charset=ISO-8859-1
Hi Chris,
There isn't enough info about how you are calling computeIntersections
to really know what is going on - there are several
computeIntersections methods, so I can't say whether it's a bug, or
code misuse.
As a general note, the computeIntersections methods are just
convenience methods for the most common needs, but they are just
implemented on top the general purpose
IntersectionVisitor/*Intersector classes. These classes aren't
difficult to use so you just implement your work on these.
Robert.
On Sun, Oct 26, 2008 at 10:28 AM, Chris Denham [EMAIL PROTECTED]
wrote:
I have a problem with Viewer:computeIntersections for nodes below a
subgraph
rendering camera that doesn't have the ABSOLUTE_RF reference frame. In
fact,
computeIntersections results are exactly as though an ABSOLUTE_RF has
been
set on the camera, even though it has not. The code below creates a
simple
scene the exhibits the problem. I used this in the osgpick example to
show
computed intersections.
Is this a bug, or is this to be expected? If it is to be expected, how
can I
get picking to work for nodes below my post render camera?
Chris.
osg::Group* group = new osg::Group();
osg::Geode* sphere = new osg::Geode();
sphere-setName(Sphere);
sphere-addDrawable(new osg::ShapeDrawable(new osg::Sphere()));
osg::Geode* cube = new osg::Geode();
cube-setName(Cube);
cube-addDrawable(new osg::ShapeDrawable(new osg::Box()));
osg::Camera* camera = new osg::Camera();
camera-setRenderOrder(osg::Camera::POST_RENDER);
camera-setClearMask(GL_DEPTH_BUFFER_BIT);
//camera-setReferenceFrame(osg::Transform::ABSOLUTE_RF);
group-addChild(sphere);
group-addChild(camera);
camera-addChild(cube);
___
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield
*
* This library is open source and may be redistributed and/or modified under
* the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or
* (at your option) any later version. The full license is in LICENSE file
* included with this distribution, and on the openscenegraph.org website.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* OpenSceneGraph Public License for more details.
*/
#include osgUtil/IntersectionVisitor
#include osg/PagedLOD
#include osg/Transform
#include osg/Projection
#include osg/Camera
#include osg/Geode
#include osg/Billboard
#include osg/Geometry
#include osg/Notify
#include osg/io_utils
using namespace osgUtil;
///
//
// IntersectorGroup
//
IntersectorGroup::IntersectorGroup()
{
}
void IntersectorGroup::addIntersector(Intersector* intersector)
{
_intersectors.push_back(intersector);
}
void IntersectorGroup::clear()
{
_intersectors.clear();
}
Intersector* IntersectorGroup::clone(osgUtil::IntersectionVisitor iv)
{
IntersectorGroup* ig = new IntersectorGroup;
// now copy across all intersectors that arn't disabled.
for(Intersectors::iterator itr = _intersectors.begin();
itr != _intersectors.end();
++itr)
{
if (!(*itr)-disabled())
{
ig-addIntersector( (*itr)-clone(iv) );
}
}
return ig;
}
bool IntersectorGroup::enter(const osg::Node node
[osg-users] Problem with computeIntersections for nodes below post render camera.
I have a problem with Viewer:computeIntersections for nodes below a subgraph rendering camera that doesn't have the ABSOLUTE_RF reference frame. In fact, computeIntersections results are exactly as though an ABSOLUTE_RF has been set on the camera, even though it has not. The code below creates a simple scene the exhibits the problem. I used this in the osgpick example to show computed intersections. Is this a bug, or is this to be expected? If it is to be expected, how can I get picking to work for nodes below my post render camera? Chris. osg::Group* group = new osg::Group(); osg::Geode* sphere = new osg::Geode(); sphere-setName(Sphere); sphere-addDrawable(new osg::ShapeDrawable(new osg::Sphere())); osg::Geode* cube = new osg::Geode(); cube-setName(Cube); cube-addDrawable(new osg::ShapeDrawable(new osg::Box())); osg::Camera* camera = new osg::Camera(); camera-setRenderOrder(osg::Camera::POST_RENDER); camera-setClearMask(GL_DEPTH_BUFFER_BIT); //camera-setReferenceFrame(osg::Transform::ABSOLUTE_RF); group-addChild(sphere); group-addChild(camera); camera-addChild(cube); ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] The best way to make some object in a scene render after and infront everything else.
Yep, putting the extra post render camera just above the Dragger gives exactly the right visual effect. Yippe! I might try adding a stencil to give it a stipply effect, then it'll look just like Maya, lol. However (note to self: stop using the word 'However'), this gives rise to a new problem. Tthe picking does not seem to work correctly for the Dragger object below the camera. I'm using osgViewer::computeIntersections(). It seems as though it is detecting the intersections with the dragger geometry but not at the screen location where it is drawn, more like around the origin. Just a guess, but it seemed as though computeIntersections was not including the transforms above the camera in the scene? SUMMARY: How do I make osgViewer::computeIntersections work properly for subgraphs below my postrender camera? Chris. - Original Message - From: Chris Denham [EMAIL PROTECTED] To: Robert Osfield [EMAIL PROTECTED]; OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Thursday, October 23, 2008 5:31 PM Subject: Re: [osg-users] The best way to make some object in a scene render after and infront everything else. Robert, Just read you message again realizing that you were suggesting putting the extra camera in the scene immediately above the Dragger node? Yes? I will try it. thanks again. Chris. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] The best way to make some object in a scene render after and infront everything else.
I am trying to acheive an effect whereby some geometry in a scene is rendered after and in front of everything else. What I want to be able to do is show an osgManipulator::Dragger node attached to an object in a scene, but show it infront of everything, I guess a bit like a HUD, but where only the Dragger is rendered on the HUD. For anyone that has used Maya, the effect I want is similar to the translation/rotation/scaling manipulators, i.e. where they can be used and seen regardless of what objects that would normally be obscuring them. What's the best way to implement that? The most obvious way seemed to me to create a HUD style postrender camera to render the manipulator on top of the normally rendered scene. But I'm not 100% sure how to get it to only render the manipulator in the scene. Do I need to use nodemasks, or do I need to move the manipulator into an empty HUD scene along with its local to world transform? Neither method seemed very elegant to me, so just wondering if anyone's got a better idea. Chris D. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] The best way to make some object in a scene render after and infront everything else.
Hi Robert, Excellent! That was too easy ;-) so I have a secondary question. Is there a way to get it clear the depth buffer between renderbins so I can render with depth test on? The manipulator geometry does not render correctly over itself with the depth test switched off. Cheers. Chris. Date: Thu, 23 Oct 2008 11:24:07 +0100 From: Robert Osfield [EMAIL PROTECTED] Subject: Re: [osg-users] The best way to make some object in a scene render after and infront everything else. To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 Hi Chris, You can achieve this affect several ways but the simplicist would probably be to state the RenderBin number of the subgraph that you want o overlay to a high figures, something like 11 or more to draw after the default transparent bin, then disable the depth test so the all fragments of the dragger are drawn. Robert. On Thu, Oct 23, 2008 at 10:39 AM, Chris Denham [EMAIL PROTECTED] wrote: I am trying to acheive an effect whereby some geometry in a scene is rendered after and in front of everything else. What I want to be able to do is show an osgManipulator::Dragger node attached to an object in a scene, but show it infront of everything, I guess a bit like a HUD, but where only the Dragger is rendered on the HUD. For anyone that has used Maya, the effect I want is similar to the translation/rotation/scaling manipulators, i.e. where they can be used and seen regardless of what objects that would normally be obscuring them. What's the best way to implement that? The most obvious way seemed to me to create a HUD style postrender camera to render the manipulator on top of the normally rendered scene. But I'm not 100% sure how to get it to only render the manipulator in the scene. Do I need to use nodemasks, or do I need to move the manipulator into an empty HUD scene along with its local to world transform? Neither method seemed very elegant to me, so just wondering if anyone's got a better idea. Chris D. ___ 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] The best way to make some object in a scene render after and infront everything else.
Hi David, Thanks for the suggestion... and the poetry! However, I think forcing the z-depth will suffer from the same rendering problems as switching off the depth test. i.e. the stuff in the overlay will not render correctly without depth value tests. With Roberts suggestion, if I can also work out a way to clear the depth buffer between renderbin passes, I might be in business! Chris. Date: Thu, 23 Oct 2008 12:39:10 +0100 From: David Spilling [EMAIL PROTECTED] Subject: Re: [osg-users] The best way to make some object in a scene render after and infront everything else. To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 Chris, You can achieve this affect several ways... (aside : http://www.netpoets.com/classic/poems/008003.htm ) Another way is to use osg::Depth to force the z value of your overlaid stuff to zero, hence ensuring it is always there. David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] The best way to make some object in a scene render after and infront everything else.
Hi Robert, Hmmm, now I seem to have come full circle back to the start of this thread. lol. If I use a hud camera, don't I then have the messy problem of making it only render the Dragger in the scene? Or perhaps there is a way to get main camera to render renderbins 0-10 and the other camera to render renderbin 11? I'm new to this render bin wizardry. Chris. - Original Message - From: Robert Osfield [EMAIL PROTECTED] To: Chris Denham [EMAIL PROTECTED]; OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Thursday, October 23, 2008 2:42 PM Subject: Re: [osg-users] The best way to make some object in a scene render after and infront everything else. Hi Chris, If you want to clear the depth buffer then you need to use a separate RenderStage rather than just a RenderBin. A RenderStage is a special RenderBin that adds the frame buffer clear prior to its traversal, and any copy to image/texture operations after traversal. By default the OSG has one RenderStage per Camera. So your case you'll want an extra Camera above the subgraph you want the clear. You may place this Camera in the scene graph or in the viewer. See the osghud example. Robert. On Thu, Oct 23, 2008 at 2:30 PM, Chris Denham [EMAIL PROTECTED] wrote: Hi Robert, Excellent! That was too easy ;-) so I have a secondary question. Is there a way to get it clear the depth buffer between renderbins so I can render with depth test on? The manipulator geometry does not render correctly over itself with the depth test switched off. Cheers. Chris. Date: Thu, 23 Oct 2008 11:24:07 +0100 From: Robert Osfield [EMAIL PROTECTED] Subject: Re: [osg-users] The best way to make some object in a scene render after and infront everything else. To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 Hi Chris, You can achieve this affect several ways but the simplicist would probably be to state the RenderBin number of the subgraph that you want o overlay to a high figures, something like 11 or more to draw after the default transparent bin, then disable the depth test so the all fragments of the dragger are drawn. Robert. On Thu, Oct 23, 2008 at 10:39 AM, Chris Denham [EMAIL PROTECTED] wrote: I am trying to acheive an effect whereby some geometry in a scene is rendered after and in front of everything else. What I want to be able to do is show an osgManipulator::Dragger node attached to an object in a scene, but show it infront of everything, I guess a bit like a HUD, but where only the Dragger is rendered on the HUD. For anyone that has used Maya, the effect I want is similar to the translation/rotation/scaling manipulators, i.e. where they can be used and seen regardless of what objects that would normally be obscuring them. What's the best way to implement that? The most obvious way seemed to me to create a HUD style postrender camera to render the manipulator on top of the normally rendered scene. But I'm not 100% sure how to get it to only render the manipulator in the scene. Do I need to use nodemasks, or do I need to move the manipulator into an empty HUD scene along with its local to world transform? Neither method seemed very elegant to me, so just wondering if anyone's got a better idea. Chris D. ___ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] The best way to make some object in a scene render after and infront everything else.
Robert, Just read you message again realizing that you were suggesting putting the extra camera in the scene immediately above the Dragger node? Yes? I will try it. thanks again. Chris. - Original Message - From: Chris Denham [EMAIL PROTECTED] To: Robert Osfield [EMAIL PROTECTED]; OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Thursday, October 23, 2008 3:40 PM Subject: Re: [osg-users] The best way to make some object in a scene render after and infront everything else. Hi Robert, Hmmm, now I seem to have come full circle back to the start of this thread. lol. If I use a hud camera, don't I then have the messy problem of making it only render the Dragger in the scene? Or perhaps there is a way to get main camera to render renderbins 0-10 and the other camera to render renderbin 11? I'm new to this render bin wizardry. Chris. - Original Message - From: Robert Osfield [EMAIL PROTECTED] To: Chris Denham [EMAIL PROTECTED]; OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Thursday, October 23, 2008 2:42 PM Subject: Re: [osg-users] The best way to make some object in a scene render after and infront everything else. Hi Chris, If you want to clear the depth buffer then you need to use a separate RenderStage rather than just a RenderBin. A RenderStage is a special RenderBin that adds the frame buffer clear prior to its traversal, and any copy to image/texture operations after traversal. By default the OSG has one RenderStage per Camera. So your case you'll want an extra Camera above the subgraph you want the clear. You may place this Camera in the scene graph or in the viewer. See the osghud example. Robert. On Thu, Oct 23, 2008 at 2:30 PM, Chris Denham [EMAIL PROTECTED] wrote: Hi Robert, Excellent! That was too easy ;-) so I have a secondary question. Is there a way to get it clear the depth buffer between renderbins so I can render with depth test on? The manipulator geometry does not render correctly over itself with the depth test switched off. Cheers. Chris. Date: Thu, 23 Oct 2008 11:24:07 +0100 From: Robert Osfield [EMAIL PROTECTED] Subject: Re: [osg-users] The best way to make some object in a scene render after and infront everything else. To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 Hi Chris, You can achieve this affect several ways but the simplicist would probably be to state the RenderBin number of the subgraph that you want o overlay to a high figures, something like 11 or more to draw after the default transparent bin, then disable the depth test so the all fragments of the dragger are drawn. Robert. On Thu, Oct 23, 2008 at 10:39 AM, Chris Denham [EMAIL PROTECTED] wrote: I am trying to acheive an effect whereby some geometry in a scene is rendered after and in front of everything else. What I want to be able to do is show an osgManipulator::Dragger node attached to an object in a scene, but show it infront of everything, I guess a bit like a HUD, but where only the Dragger is rendered on the HUD. For anyone that has used Maya, the effect I want is similar to the translation/rotation/scaling manipulators, i.e. where they can be used and seen regardless of what objects that would normally be obscuring them. What's the best way to implement that? The most obvious way seemed to me to create a HUD style postrender camera to render the manipulator on top of the normally rendered scene. But I'm not 100% sure how to get it to only render the manipulator in the scene. Do I need to use nodemasks, or do I need to move the manipulator into an empty HUD scene along with its local to world transform? Neither method seemed very elegant to me, so just wondering if anyone's got a better idea. Chris D. ___ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Near and far calculation and depth maps (and a questionabout WoWvx)
Thanks Wojtek,
That's very useful information. I must admit, the non linear relationship
between depth map values and view space z coordinates was something that
escaped me. I had assumed the depth value spread was linear between near and
far planes.
So that leaves me with a question about the wowvx disparity function. How do
I control its parameters so that it reliably generates a 'good' greyscale
rendering of the depthmap? By 'good' I mean one that has enough contrast to
allow the WoWvx display to show autostereoscopic effects.
The fragment shader code for the wowvx disparity function used in OSG look
like:
float disparity(float Z)
{
return
(wow_disparity_M*(1.0-(wow_disparity_vz/(Z-wow_disparity_Zd+wow_disparity_vz)))
+ wow_disparity_C) / 255.0;
}
Where:
return value: The greyscale value to render.
Z: The depth value from depth map texture.
Default uniforms for WoWvx 20inch display
wow_disparity_Zd = 0.459813f;
wow_disparity_vz = 6.180772f;
wow_disparity_M = -1586.34f;
wow_disparity_C = 127.5f;
If the depth map values from OSG are in general always optimal enough to
render the scene properly, then it seems that I need to dynamically adjust
(once per frame) the WowVX disparity constants to prevent the
autostereoscopic effect from fading in and out or disappearing as I move the
camera through a scene.
If that's true, I have no idea how to proceed other than perhaps a rather
kludgy idea of generating a histogram of depth values and somehow adjusting
the disparity constants based on ranges of the histogram that have 'detail'.
That's ugly and unreliable!
Having said that, I have actually looked at the histograms of the depthmap
values, and it did appear as though something might not be quite right about
the depth map because as I move through the scene, the values seem
occasionally get all bunched up at the far end (close to 1.0), and these are
the cases when I get problems.
Help!
Chris.
Date: Tue, 7 Oct 2008 11:11:46 +0200
From: Wojciech Lewandowski [EMAIL PROTECTED]
Subject: Re: [osg-users] Near and far calculation and depth maps (and
a questionabout WoWvx)
To: OpenSceneGraph Users osg-users@lists.openscenegraph.org
Message-ID: [EMAIL PROTECTED]
Content-Type: text/plain; format=flowed; charset=ISO-8859-1;
reply-type=response
Chris,
Please read following page, until final conclusion:
http://www.sjbaker.org/steve/omniv/love_your_z_buffer.html
So if you have gone to the conclusion you should now understand why
computeNearFar is added to OSG. It simply allows to better utilize depth
buffer range. Compute NearFar using primitives is simply more precise than
using bounding volumes so this may explain why you got better results with
COMPUTE_NEAR_FAR_USING_PRIMITIVES.
You should also know that depth buffer spread does not linearly correspond
to view space z coordinate. Thats why when displayed as grayscale some
objects may be hard to discern (especially if 24 bits are clamped to 8
bits). Depth buffer values are spread non linearly so when put into
monochrome image they often end up with so similar colors that image looks
completely flat (either white or black). You may want to add special
shader
to pseudo color depth buffer like in topographical maps to actually notice
variety of depth values.
I hope this helps a little ;-).
Cheers,
Wojtek
I have a few questions about the way OSG handles depth maps, and how the
range of depth values relates to the near and far calculation done by OSG.
Firstly, just to confirm my understanding. I have assumed that the
purpose of OSG calculating nearfar values is so that depth map values
will range between 0.0 and 1.0 for pixels rendered between the near and
far range. Oh.. and for clipping too!? Please shoot me now if that's not
correct. ;-)
As a test case, I constructed a very simple scene comprised of a large
cuboid with a number of smaller cuboids within it.
When I move the camera inside the large cuboid, I had expected the depth
map rendered by an RTT camera to show depth values of all the smaller
cuboids in the scene, but it doesn't, it just seems to contain a solid
black texture. (you can easily display an inverted representation of the
depth map of a scene using the osgViewer option '--wowvx-20')
Now, the odd thing is that if I change the nearfar calculation mode of
the RTT camera to:
camera-setComputeNearFarMode(osg::CullSettings::ComputeNearFarMode::COMPUTE_NEAR_FAR_USING_PRIMITIVES)
instead of the default, which is COMPUTE_NEAR_FAR_USING_BOUNDING_VOLUMES
,the smaller cubes now appear as I would have expected in the depthmap.
I have been looking for an explantion for this difference in the OSG code
in:
bool CullVisitor::updateCalculatedNearFar(const osg::Matrix matrix,const
osg::Drawable drawable, bool isBillboard)
It seemed to me that there may be an issue with the code:
---snip---
//if (d_near0.0) osg::notify(osg::WARN) 3) set near with
d_near=d_near std::endl;
_computed_znear = d_near;
---snip---
which allows
Re: [osg-users] Near and far calculation and depth maps (and a question about WoWvx)
Hmm, thinking about the implications of Wojtek's message in more detail
leads me to think that the only way to get this right is to make sure the
near plane doesn't get too close to the camera.
In my simple test, a scene with small cubes inside a large cube, once my
camera moves inside the large cube, the calculated near plane has a negative
z value, which is then adjusted (by clampProjectionMatrix) to
(nearFarRatio*zfar) because this is greater than calculated znear.
Effectively, I think this means that once inside the large cube, the near
plane is locked incredibly close to the camera, thus depth values for other
things within the scene get pushed way back. My suggested change in my first
message on this thread helps with this problem, but I seem to get the same
effect whenever any object gets very close to the camera.
I can workaround the problem by setting CullSettings::_nearFarRatio
(default=0.0005) to a much higher value e.g. (0.1), but this of course has
the unpleasant effect of clipping objects close to the camera.
Oh damn it, I sense that I am treading on a very old computer graphics
problem that human vision solves so well by being able to ignore near things
that are not of interest or insignificant.
Chris.
- Original Message -
From: Chris Denham [EMAIL PROTECTED]
To: osg-users@lists.openscenegraph.org
Cc: [EMAIL PROTECTED]
Sent: Wednesday, October 08, 2008 10:48 AM
Subject: Re: [osg-users] Near and far calculation and depth maps (and a
questionabout WoWvx)
Thanks Wojtek,
That's very useful information. I must admit, the non linear relationship
between depth map values and view space z coordinates was something that
escaped me. I had assumed the depth value spread was linear between near
and far planes.
So that leaves me with a question about the wowvx disparity function. How
do I control its parameters so that it reliably generates a 'good'
greyscale rendering of the depthmap? By 'good' I mean one that has enough
contrast to allow the WoWvx display to show autostereoscopic effects.
The fragment shader code for the wowvx disparity function used in OSG look
like:
float disparity(float Z)
{
return
(wow_disparity_M*(1.0-(wow_disparity_vz/(Z-wow_disparity_Zd+wow_disparity_vz)))
+ wow_disparity_C) / 255.0;
}
Where:
return value: The greyscale value to render.
Z: The depth value from depth map texture.
Default uniforms for WoWvx 20inch display
wow_disparity_Zd = 0.459813f;
wow_disparity_vz = 6.180772f;
wow_disparity_M = -1586.34f;
wow_disparity_C = 127.5f;
If the depth map values from OSG are in general always optimal enough to
render the scene properly, then it seems that I need to dynamically adjust
(once per frame) the WowVX disparity constants to prevent the
autostereoscopic effect from fading in and out or disappearing as I move
the camera through a scene.
If that's true, I have no idea how to proceed other than perhaps a rather
kludgy idea of generating a histogram of depth values and somehow
adjusting the disparity constants based on ranges of the histogram that
have 'detail'. That's ugly and unreliable!
Having said that, I have actually looked at the histograms of the depthmap
values, and it did appear as though something might not be quite right
about the depth map because as I move through the scene, the values seem
occasionally get all bunched up at the far end (close to 1.0), and these
are the cases when I get problems.
Help!
Chris.
Date: Tue, 7 Oct 2008 11:11:46 +0200
From: Wojciech Lewandowski [EMAIL PROTECTED]
Subject: Re: [osg-users] Near and far calculation and depth maps (and
a questionabout WoWvx)
To: OpenSceneGraph Users osg-users@lists.openscenegraph.org
Message-ID: [EMAIL PROTECTED]
Content-Type: text/plain; format=flowed; charset=ISO-8859-1;
reply-type=response
Chris,
Please read following page, until final conclusion:
http://www.sjbaker.org/steve/omniv/love_your_z_buffer.html
So if you have gone to the conclusion you should now understand why
computeNearFar is added to OSG. It simply allows to better utilize depth
buffer range. Compute NearFar using primitives is simply more precise
than
using bounding volumes so this may explain why you got better results
with
COMPUTE_NEAR_FAR_USING_PRIMITIVES.
You should also know that depth buffer spread does not linearly
correspond
to view space z coordinate. Thats why when displayed as grayscale some
objects may be hard to discern (especially if 24 bits are clamped to 8
bits). Depth buffer values are spread non linearly so when put into
monochrome image they often end up with so similar colors that image
looks
completely flat (either white or black). You may want to add special
shader
to pseudo color depth buffer like in topographical maps to actually
notice
variety of depth values.
I hope this helps a little ;-).
Cheers,
Wojtek
I have a few questions about the way OSG handles depth maps, and how the
range of depth values relates to the near and far
Re: [osg-users] Near and far calculation and depth maps (and aquestion about WoWvx)
Hi Gordon,
Yes, that's was what I was beginning to suspect. However, the extent to
which I think this is a new is the way the problem is amplified by the
requirements of WoWvx. An increase in z-depth resolution would probably not
help at all in this context because in order to transfer z-depth data to the
WoWvx you have to render a greyscale image to the screen, so, whatever depth
you start with, by the time the data gets to the display hardware I'm fairly
sure you only get 8-bits to play with, therefore if you have most of your
scene detail in the 'far' depth, nearly all the information is 'lost in
transit'. :-(
Chris.
- Original Message -
From: Tomlinson, Gordon [EMAIL PROTECTED]
To: Chris Denham [EMAIL PROTECTED]; OpenSceneGraph Users
osg-users@lists.openscenegraph.org
Sent: Wednesday, October 08, 2008 1:14 PM
Subject: RE: [osg-users] Near and far calculation and depth maps (and
aquestion about WoWvx)
This has been the problem and trade off since the inception of the
z-buffer :)
It will get a little better with when get OpenGL 3.0 out in the wild as
that has provision for a 32 bit Zbuffer which will extend the range 32
bit is still not great
Gordon
__
Gordon Tomlinson
Product Manager 3D
Email : gtomlinson @ overwatch.textron.com
__
Self defence is not a function of learning tricks
but is a function of how quickly and intensely one
can arouse one's instinct for survival
- Master Tambo Tetsura
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Chris
Denham
Sent: Wednesday, October 08, 2008 8:00 AM
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] Near and far calculation and depth maps (and
aquestion about WoWvx)
Hmm, thinking about the implications of Wojtek's message in more detail
leads me to think that the only way to get this right is to make sure
the near plane doesn't get too close to the camera.
In my simple test, a scene with small cubes inside a large cube, once my
camera moves inside the large cube, the calculated near plane has a
negative z value, which is then adjusted (by clampProjectionMatrix) to
(nearFarRatio*zfar) because this is greater than calculated znear.
Effectively, I think this means that once inside the large cube, the
near plane is locked incredibly close to the camera, thus depth values
for other things within the scene get pushed way back. My suggested
change in my first message on this thread helps with this problem, but I
seem to get the same effect whenever any object gets very close to the
camera.
I can workaround the problem by setting CullSettings::_nearFarRatio
(default=0.0005) to a much higher value e.g. (0.1), but this of course
has the unpleasant effect of clipping objects close to the camera.
Oh damn it, I sense that I am treading on a very old computer graphics
problem that human vision solves so well by being able to ignore near
things that are not of interest or insignificant.
Chris.
- Original Message -
From: Chris Denham [EMAIL PROTECTED]
To: osg-users@lists.openscenegraph.org
Cc: [EMAIL PROTECTED]
Sent: Wednesday, October 08, 2008 10:48 AM
Subject: Re: [osg-users] Near and far calculation and depth maps (and a
questionabout WoWvx)
Thanks Wojtek,
That's very useful information. I must admit, the non linear
relationship between depth map values and view space z coordinates was
something that escaped me. I had assumed the depth value spread was
linear between near and far planes.
So that leaves me with a question about the wowvx disparity function.
How do I control its parameters so that it reliably generates a 'good'
greyscale rendering of the depthmap? By 'good' I mean one that has
enough contrast to allow the WoWvx display to show autostereoscopic
effects.
The fragment shader code for the wowvx disparity function used in OSG
look
like:
float disparity(float Z)
{
return
(wow_disparity_M*(1.0-(wow_disparity_vz/(Z-wow_disparity_Zd+wow_disparit
y_vz)))
+ wow_disparity_C) / 255.0;
}
Where:
return value: The greyscale value to render.
Z: The depth value from depth map texture.
Default uniforms for WoWvx 20inch display wow_disparity_Zd =
0.459813f; wow_disparity_vz = 6.180772f; wow_disparity_M = -1586.34f;
wow_disparity_C = 127.5f;
If the depth map values from OSG are in general always optimal enough
to render the scene properly, then it seems that I need to dynamically
adjust (once per frame) the WowVX disparity constants to prevent the
autostereoscopic effect from fading in and out or disappearing as I
move the camera through a scene.
If that's true, I have no idea how to proceed other than perhaps a
rather kludgy idea of generating a histogram of depth values and
somehow adjusting the disparity constants based on ranges of the
histogram that have 'detail'. That's ugly and unreliable!
Having said that, I have actually looked
[osg-users] Near and far calculation and depth maps (and a question about WoWvx)
I have a few questions about the way OSG handles depth maps, and how the range of depth values relates to the near and far calculation done by OSG. Firstly, just to confirm my understanding. I have assumed that the purpose of OSG calculating nearfar values is so that depth map values will range between 0.0 and 1.0 for pixels rendered between the near and far range. Oh.. and for clipping too!? Please shoot me now if that's not correct. ;-) As a test case, I constructed a very simple scene comprised of a large cuboid with a number of smaller cuboids within it. When I move the camera inside the large cuboid, I had expected the depth map rendered by an RTT camera to show depth values of all the smaller cuboids in the scene, but it doesn't, it just seems to contain a solid black texture. (you can easily display an inverted representation of the depth map of a scene using the osgViewer option '--wowvx-20') Now, the odd thing is that if I change the nearfar calculation mode of the RTT camera to: camera-setComputeNearFarMode(osg::CullSettings::ComputeNearFarMode::COMPUTE_NEAR_FAR_USING_PRIMITIVES) instead of the default, which is COMPUTE_NEAR_FAR_USING_BOUNDING_VOLUMES ,the smaller cubes now appear as I would have expected in the depthmap. I have been looking for an explantion for this difference in the OSG code in: bool CullVisitor::updateCalculatedNearFar(const osg::Matrix matrix,const osg::Drawable drawable, bool isBillboard) It seemed to me that there may be an issue with the code: ---snip--- //if (d_near0.0) osg::notify(osg::WARN) 3) set near with d_near=d_near std::endl; _computed_znear = d_near; ---snip--- which allows negative values of 'd_near' to be assigned to '_computed_znear' and hence the near clipping plane to be behind the camera. In fact, the code a few lines above this snippet does ignore values of d_near 0.0, so I wondered if this snippet should have the same logic. In fact, if I change the snippet above (by removing the comment and putting in an else), ---new snip--- if (d_near0.0) osg::notify(osg::WARN) 3) set near with d_near=d_near std::endl; else _computed_znear = d_near; ---new snip--- the depth map seems correct for my test example, yippie! Let me know if I need to put this change on the submissions list. Ah ha nope.. I haven't finished with your attention yet ;-) What follows is a different issue, only loosely related to the above: I can see that I should expect to get a kind of 'popping' effect in a depth map range due to culling of objects as I move through as scene. It seemed to me that getting 'smooth' transitions in near/far calculations would be 'at least in concept' a difficult/impossible problem to solve. You are probably wondering why I care about this, when a even large jitters in depth map range does not seem to affect the rendered scene much. The answer is, because the depth map is used as part of the input to a WoWvx autostereoscopic display. The problem is that to transfer the depthmap data to the stereoscopic display, the depthmap gets rendered as a greyscale image, presumably losing a lot of precision in converting to int 0-255 range greyscale color value. The effect I get as I move through a scene is that the contrast in the depthmap image seems to fade in and out as I move the camera past objects in the scene, and this affects the 3D effect you get from the WoWvx. I can see that the WoWvx implementation in OSG does include some disparity calculation shader code that allows adjustment of the conversion from depthmap value to greyscale, but it is difficult to see how to calculate the parameters 'on the fly' as you move through a scene. Does anyone have any suggestions or advice on how dynamically keep more contrast in greyscale rendering of a depthmap? Chris. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DatabasePager - A little confused
Hello,
I'm not sure I completely understand the question here, so I hope this
answer is not too far off the point.. However, while this is fresh in my
head, I just spent some time puzzling over PagedLOD and ProxyNode because I
couldn't find any good examples. I think my initial confusion was do with
trying to use ProxyNode for a purpose that it was not intended. The purpose
being, to allow asynchronous loading of models while interacting with the
scene. ProxyNode kind of does that, but it only really seems to be intended
to 'proxy' the bounding box calculation, and does not provide a 'stand-in'
visual object to display during the asychronous load. Enter the PagedLOD
it seemed to me that everything I expected ProxyNode to do was actually
implemented in PagedLOD!
Here's my test example that loads 10 cows asynchronously and shows stand-in
cuboids for each cow until each cow model is loaded. (Note, I have specified
the stand-in object as a LOD in the very far distance which means that
hopefully it will only ever be seen until the 'real' model is loaded)
Chris.
static osg::Node* createCowLOD()
{
osg::Shape* shape = new osg::Box(osg::Vec3(0, 0, 0), 9, 3, 5);
osg::ShapeDrawable* shapeDrawable = new osg::ShapeDrawable(shape);
osg::Geode* geode = new osg::Geode();
geode-addDrawable(shapeDrawable);
return geode;
}
int main( int argc, char **argv )
{
osgViewer::Viewer viewer;
osg::Group* root = new osg::Group();
for (int y = 0; y 5; y++)
for (int x = 0; x 2; x++)
{
osg::MatrixTransform* transform = new
osg::MatrixTransform(osg::Matrix::translate(x * 10, y * 4, 0));
osg::PagedLOD* pagedLOD = new osg::PagedLOD();
pagedLOD-addChild(createCowLOD(), 1e29, 1e30);
pagedLOD-setFileName(1, cow.osg);
pagedLOD-setRange(1, 0, 1e29);
transform-addChild(pagedLOD);
root-addChild(transform);
}
viewer.setSceneData(root);
viewer.realize();
viewer.run();
return 0;
}
Date: Wed, 1 Oct 2008 12:22:14 +0800 (CST)
From: Simba [EMAIL PROTECTED]
Subject: Re: [osg-users] DatabasePager - A little confused
To: OpenSceneGraph Users osg-users@lists.openscenegraph.org
Message-ID:
[EMAIL PROTECTED]
Content-Type: text/plain; charset=gbk
Hi,
I'm not sure whether I have understood your problem. But I think that if
you
want to use databasepager, you just have to make sure you have pagedLOD
node in your models. If you do, then just use
viewer.setScenedata(model.get()), so the osgViewer::Viewer will
automatically do the rest.
Hope this infomation may help~~~ :)
Simbaforrest
?2008-10-01 07:06:58?Alan Ott [EMAIL PROTECTED] ???
Hello,
After much trying and failing, I think I have a fundamental
misunderstanding reagarding the DatabasePager. I have looked for
examples or code snippets and it seems that there are none. So here's
what I have.
I have a DatabasePager object that I use for terrain. When I need a new
chunk of terrain, I call requestNodeFile() with the name of the tile of
terrain that I want, and give it a group node to attach it to. Every
frame, I check my group nodes to see if they have a piece of terrain
attached to them (ie: see if the pager paged in the terrain and attached
it to my group). If a new piece of terrain has been loaded, I then
perform my initialization on it (lookup switch nodes, etc), and attach
it to my main scene. This gets the job done.
The problem now, is that every time a new tile is attached to the main
scene, the next frame takes a long time, and I have a missed frame. This
has to do with the new tile getting compiled (texture sent to OpenGL,
etc) when it's drawn the first time. To overcome this, I want
DatabasePager to do this for me, which it seems to be able to support,
but everything I try doesn't work in one way or another. I have
something like the following (roughly):
// Set up the pager
pager = osgDB::DatabasePager::create();
pager-setCompileGLObjectsForContextID (0, true);
pager-setDoPreCompile(true);
...
// My composite viewer
osgViewer::CompositeViewer *viewer = new osgViewer::CompositeViewer;
// Then for each View I have something like this.
view = new osgViewer::View;
view-setSceneData(root.get());
view-getScene()-setDatabasePager(pager);
So in this case, only what gets requested the first frame (before the
first draw) gets paged in. Anything requested after that never gets
loaded. If I take out the call to setCompileGLObjectsForContextID(), of
course, no precompiling happens. Other things happen if I take out the
getScene()-setDatabasePager().
From some of the code regarding PagedLOD's, I get the feeling I might
be going about this the wrong way entirely, and possibly using
DatabasePager in a way in which it was not designed.
So I guess my question is, does anyone have anything they can tell me
about how to use this class? Maybe some code snippets? Anything at all
would help. I've spent a lot of time searching
Re: [osg-users] Spatial View SVI autosteroscopic display
Hi Steffen, Thanks very much for the info. It did seem to me as though finding the right place to call the API from was the key issue, so your suggestion for using Postrender-CameraCallback is very useful. I was beginning to think along the lines of implementing a Drawable::drawImplementation() function, which is interesting because I notice the osgteapot example does that. However, looking at osgteapot example from OSG2.6, it doesn't seem to do anything with camera callbacks, so I am a bit puzzled as to exactly what you mean here. I found a couple of other examples that use Camera::setPostDrawCallback, so I will have a look at them too.Which version of OSG did you use for this? Have names examples changed since you did your integration? Regards. Chris. Date: Mon, 22 Sep 2008 22:01:20 +0200 From: Steffen Kim [EMAIL PROTECTED] Subject: Re: [osg-users] Spatial View SVI autosteroscopic display support. To: osg-users@lists.openscenegraph.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-15 Hi Chris. I spent quite some time on doing just what you are planning to do - getting an OpenSceneGraph-application to work with a Spatial View display. In the end I was successful. I don't know at the moment if I can provide you with any code but of course I can tell you how I am doing it. I have no idea if this is the best way but it works quite well. I use 5 RTT-cameras to save the five views in textures that later become input for the interlacer. You can position these 5 cameras using the SVI camera API or calculate the view and projection matrixes yourself. You then let the SVI interlacer render the result from the 5 textures. Everytime the master camera (the main osg camera) changes you also have to recalculate the matrixes of your slave cameras. The important part is that you take care on when you do call the API functions. You have to do this in a part of your program where the OpenGL context was set accordingly by OSG. You can use a PostRender-CameraCallback for this. See the osgteapot-example for some code on how to do this. Good luck. Schon geh?rt? Bei WEB.DE gibt' s viele kostenlose Spiele: http://games.entertainment.web.de/de/entertainment/games/free/index.html ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Spatial View SVI autosteroscopic display support.
I am currently looking at the feasibility of adding support for SVI
autostereoscopic display in OSG.
Does anyone know anything about this?
So far, I have been looking at an SDK that provides an OpenGL based API and
examples for driving the display.
I have also been looking at the different ways OSG implements stereo modes
with a view to seeing where might be the best place to perform the interlace
function required to support the SVI display.
I noticed that the WOWVX support is done by creating two slave cameras that
render to textures, then combining the textures and wowvx headers using a
pixel shader. So, at first, that seemed a good pattern to try and follow,
but on reflection it's difficult for me to see how to use the SVI API in
this way (even though internally I suspect something similar is going on).
I seem to be floundering a bit., so I wondered if I can trouble anyone on
the list to take a quick look at the attached OpenGL example code from the
SVILaceOGL SDK and make any suggestions about how and where the best place
to try and use the API from within OSG (or from an OSG application).
Of course, if I'm successful with the integration, I'll be happy to share
the result with the OSG community. ;-)
Cheers.
Chris.
/**
\file
SVILaceOgl Example 1
Initialize an interlacer.
Set an arbitary stereo mode and
provide anaglyph red cyan stereo
\author klaus.kesseleratspatialview.com
\author dietrich.johnatspatialview.com
\author (c) http://www.spatialview.com
*/
#include SVILaceOgl.h
#include OglCameras.h
#include vector
#include string
#include iostream
#include GL/glut.h
using namespace SVI;
using namespace SVI::OglCameras;
//==
namespace{
int g_rotation = 0;
int g_rotation_increment = 1;
struct IlaceData{
IlaceOgl::IlaceHandle interlacer;
std::vectorGLuint textures;
unsigned int texWidth;
unsigned int texHeight;
};
IlaceData g_data;
} // anonymous Namespace
//==
void cbDisplay();
void cbResize(int w, int h);
void cbIdle(void);
void cbTimer(int );
void cbKey(unsigned char k, int , int );
//==
// init Glut window
void initGlut(int *argc, char *argv[])
{
//Init window position and size:
int windowX = 100;
int windowY = 100;
int windowWidth = 680;
int windowHeight = 480;
glutInit(argc, argv);
glutInitDisplayMode(GLUT_DOUBLE | GLUT_RGB | GLUT_DEPTH);
glutInitWindowSize(windowWidth, windowHeight);
glutInitWindowPosition(windowX, windowY);
glutCreateWindow(argv[0]);
//call backs
glutDisplayFunc(cbDisplay);
glutReshapeFunc(cbResize);
glutIdleFunc(cbIdle);
glutTimerFunc(1/360, cbTimer, 0);
glutKeyboardFunc(cbKey);
}
//==
// create the interlacer
bool ilaceInit(){
// Check for OpenGL extensions, we need
if (!IlaceOgl::checkHardware())
{
std::cout Interlacing support is not available. Missing OpenGL
extensions: std::endl;
std::cout IlaceOgl::getMissingExt();
return false;
}
// Create an interlacer
g_data.interlacer=IlaceOgl::createInstance();
// Test for failure:
if (!g_data.interlacer)
{
std::cout Failure, can not create interlacer std::endl;
return false;
}
// Set an arbitrary Stereo Mode:
IlaceOgl::setCurrentStereoMode(g_data.interlacer,AnaglyphRedCyan);
// Query the number of camera views, we need for the stereo mode:
int camCount = IlaceOgl::getCameraCount(g_data.interlacer);
int windowWidth = glutGet(GLUT_WINDOW_WIDTH );
int windowHeight = glutGet(GLUT_WINDOW_HEIGHT);
//initialize input textures
g_data.textures.resize(camCount);
g_data.texWidth = windowWidth;
g_data.texHeight = windowHeight;
// use a helper function from IlaceOgl to request texture id's and
initialize the texture:
IlaceOgl::provideTextures(g_data.textures[0],camCount,g_data.texWidth,g_data.texHeight);
IlaceOgl::setTextures(g_data.interlacer, g_data.textures[0], camCount);
int screenX = 0; // Here we use 0,0 for x,y for the first display, but we should know
int screenY = 0; // the position of the display, if we use a second one.
int screenWidth = glutGet(GLUT_SCREEN_WIDTH);
int screenHeight = glutGet(GLUT_SCREEN_HEIGHT);
IlaceOgl::setScreen(g_data.interlacer, screenX, screenY, screenWidth,
screenHeight);
return true;
}
Re: [osg-users] Philips WOWvx technology and OpenSceneGraph
Hi Kim, I was wondering if you were able to share your code that does this? What occurred to me was that it would be pretty cool to see this functionality as an extra 'stereo' option for OSG. You make it sound easy... but in my experience, straight forward means different things to different people! ;-) Cheers Chris. Date: Wed, 2 Apr 2008 15:58:26 +0100 From: Kim C Bale [EMAIL PROTECTED] Subject: Re: [osg-users] Philips WOWvx technology and OpenSceneGraph To: OpenSceneGraph Users osg-users@lists.openscenegraph.org It's a fairly straight forward process, you have to send the display a custom image format. You split the screen in half horizontally, render your scene normally in the left half and then render a custom depth map format on the right, I did the depth version using a simple shader, but I'm sure there are other ways. You then have to encode a 32bit (i think?) pattern into the blue pixels in the first row of framebuffer so that it picks up the WOW format. You can do that by simply writing the pixels direct to the screen using osg::DrawPixels and a post render camera. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Philips WOWvx technology and OpenSceneGraph
Kim, Thanks very much for the tips and code snippet! Robert, nice to know we were thinking along the same lines for a wowvx stereo option built into OSG ;-) Chris. Date: Thu, 3 Apr 2008 12:37:44 +0100 From: Kim C Bale [EMAIL PROTECTED] Subject: Re: [osg-users] Philips WOWvx technology and OpenSceneGraph To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Hi Chris, I'm afraid the code was written as part of a research project, and we still haven't decided upon whether or not the code is going into the public domain or not so I can't really give out my classes. However, I have included a function that may help you. You'll have to fill in the rest I'm afraid. The white paper they supply is very good. If you've ever used multiple camera objects in an OSG program you shouldn't find it a problem. The trickiest part in my opinion was creating the class to generate the little header in the top left corner of the image, but that was only because it was fiddly bit shifting. I've only worked with the standard 50/50 stereo image, I believe Phillips support a couple of different formats, one of which splits the screen into 4 that allows you to compensate for the strange blurring effect you get on the edge of objects. As for the blurring in the distance, I get that too, but haven't attempted to fix it, I would imagine dynamically modifying the depth map calculation would go some way to solve this and it's easily done if you use the shader approach that I took. As Robert says there's no need to use any APIs etc, OSG provides all the tools to generate and modify the stereo format in the scene graph. Fire back if you need any further hints or tips. Kim. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Philips WOWvx technology and OpenSceneGraph
I've had some limited success with OSG and the wowvx display. I used the WowVX OpenGL control - demo downloadable from http://www.business-sites.philips.com/3dsolutions/Downloads/Index.html This control acts as a kind of proxy/wrapper around OpenGL, so in theory can support any OpenGL application without modification. In practice, there were a few problems: 1. The version I downloaded had some kind of incompatibility with the way OSG was initialising OpenGL, but they did send me a update to the control which cured the problem. (not sure if they have updated the download on the site yet) 2. I did need to modify the OSG application to use control's extended API that allows control over the depth map generation in order to get any reasonable 3D effect. 3. There seem to be problems as I zoom into a scene which results in loss range in the depthmap image, but this may be something that can be fixed by dynamically adjusting the parameters in their extended control API. 4. IMHO, the opengl wrapper control costs way too much money! I think it would be better to try and generate the 2d+depth map images directly from OSG, but I'm not sure what would be involved in this as it seems to rely on sending some kind of control information embedded in the first row of pixels sent to the display. There is documentation about this on the philips site, but didn't have time to look into it deeper. I would have liked to get hold of the sources for the combobulator demo from initon as that seems to use OSG without the OpenGL wrapper control, but again, haven't had time to pursue that either. :-( BTW. You don't need a special Wowvx display driver for it to work, but you do need a supported video card (I think it uses some kind of special DVI protocol that is not always supported) (I used NVidia 7600, but aparently some ATI cards work too) I'd be interested to know if you make any progress with OSG on the WOWvx. If you like, I can post you my changes to osgviewer that set some of the parameters for the Wowvx OpenGL wrapper control, but there was no rocket science involved here. The combobulator demo can be downloaded from: http://www.inition.com/inition/product.php?URL_=product_software_inition_combobulatorSubCatID_=72 Chris D. Message: 10 Date: Wed, 2 Apr 2008 16:11:02 +0200 From: Adrian Egli OpenSceneGraph (3D) [EMAIL PROTECTED] Subject: Re: [osg-users] Philips WOWvx technology and OpenSceneGraph To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 Thanks, but i can not find any of the inition.com demo program. was it hard to use osg with the display, does it work with linux ,windows, or osx. is it hard to use the monitor with osg, or just download a 3d display driver and the rest works regards 2008/4/2, Kim C Bale [EMAIL PROTECTED]: Yes I've worked with one and openscenegraph. If you go to the inition.comwebsite you can see a demo program I that looks very much like they've used OSG to render it. Do a search of the forum, there was a light discussion about the displays early last month I think. Regards, Kim. *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Adrian Egli OpenSceneGraph (3D) *Sent:* 02 April 2008 13:47 *To:* OpenSceneGraph Users *Subject:* [osg-users] Philips WOWvx technology and OpenSceneGraph Philips 3D displays -Philips WOWvx technology any experience in this forum adegli -- Adrian Egli ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] 3D Studio Max (3DS) Output
I'm looking for a way to export from OSG to 3DS format. I notice that OSG does provide a plugin for loading 3DS, but does not appear to support the output of that format. Looking at the sources for the 3DS plugin, I noticed that there is code that may support part of the process of 3DS output e.g. in c:\OpenSceneGraph\src\osgPlugins\3ds\file.cpp extern LIB3DSAPI Lib3dsBool lib3ds_file_write(Lib3dsFile *file, iostream *strm); extern LIB3DSAPI Lib3dsBool lib3ds_file_save(Lib3dsFile *file, const char *filename); These methods can write out the data structure created during model import, so I wondered how big a job it is to fill in that Lib3dsFile structure with an OSG scene. Has anyone has a go at this? If so, I can volunteer to help finish it off. Suggestions or pointers anyone? Chris Denham. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Scene renders black when replacing a ShadowedScene
Hi Mihai, I rebuilt OSG with your modifications to ShadowMap, but unfortunately I've still got problems with it. 1. The dummy texture seem to cause the scene to render blocky and dark. 2. If I set textureUnit=0 the shadows stop working completely. I've posted screen some dumps at: http://cmdenham.blogspot.com/ Cheers. Chris. On 02/11/2007, Chris Denham [EMAIL PROTECTED] wrote: Hi Mihai, Sorry I didn't see your postings earlier in the day, they could have saved me some time. Though I guess I learnt something on the way ;-) The reason I didn't see your messages was that gmail decided to relegate digest Vol5,Issues 23 to my spam folder, and I only realised things where missing when Issue4 arrived normally. hmph... No.. it's not funny. Thanks for the valuable tips and code. Will your modification to ShadowMap go into the next osg release? Chris. Date: Fri, 02 Nov 2007 10:41:20 -0700 From: Mihai Radu [EMAIL PROTECTED] Subject: Re: [osg-users] Scene renders black when replacing a ShadowedScene To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Cc: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 Hi Chris, Please check the thread for fixes. I'm attaching, again, the fixed version of ShadowMap.cpp Cheers Mihai Chris Denham wrote: After some serious digging and tweaking inside osgShadow::ShadowMap I have come up with a partial workaround for this problem. The problem seems to boil down to issues around the pushing and popping of statsets containing instance of: ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Scene renders black when replacing a ShadowedScene
Hmm... think this might me a video card/driver specific problem.
I just tried this test on my colleague's PC that has a matrox video
card and seemed to work ok.
Oh rats does that mean it not so easy/impossible to fix the problem? :-(
Chris.
Date: Thu, 1 Nov 2007 17:56:06 +
From: Chris Denham [EMAIL PROTECTED]
Subject: [osg-users] Scene renders black when replacing a
ShadowedScene
To: osg-users@lists.openscenegraph.org
I'm getting a problem when assigning a new shadowed scene to the viewer.
What seems to happen is that once the first scene has been rendered,
the assignment of a new shadowed scene results in a everything in the
scene being drawn black. Also odd is the fact that there doesn't seem
to be a problem when a texture is assigned to objects being drawn.
I have created a minimal example that exhibits the problem, and pasted
it below.
Any ideas what's going wrong? Can anyone reproduce the effect?
[I'm using osg2.2 on windowsXP with Radeon X300 with latest drivers.]
#include osg/ShapeDrawable
#include osg/Geode
#include osgGA/TrackballManipulator
#include osgShadow/ShadowedScene
#include osgShadow/ShadowMap
#include osgDB/ReadFile
#include osgViewer/Viewer
const int ReceivesShadowTraversalMask = 0x1;
const int CastsShadowTraversalMask = 0x2;
osg::Node* createShadowedScene(bool withTexture)
{
osgShadow::ShadowedScene* shadowedScene = new osgShadow::ShadowedScene;
shadowedScene-setReceivesShadowTraversalMask(ReceivesShadowTraversalMask);
shadowedScene-setCastsShadowTraversalMask(CastsShadowTraversalMask);
shadowedScene-setShadowTechnique(new osgShadow::ShadowMap());
osg::LightSource* lightSource = new osg::LightSource;
lightSource-getLight()-setPosition(osg::Vec4(0, 0.2, 1, 0));
osg::ShapeDrawable * shape = new osg::ShapeDrawable(new
osg::Sphere(osg::Vec3(0.0f, 0.0f, 0.0f), 200.0));
shape-setColor(osg::Vec4(0.8f, 0.8f, 0.8f, 1.0f));
osg::Geode* geode = new osg::Geode();
geode-addDrawable(shape);
if (withTexture)
{
geode-getOrCreateStateSet()-setTextureAttributeAndModes( 0,
new osg::Texture2D(osgDB::readImageFile(Images/lz.rgb)),
osg::StateAttribute::ON);
}
shadowedScene-addChild(geode);
shadowedScene-addChild(lightSource);
return shadowedScene;
}
int main(int argc, char** argv)
{
bool withTexture = false;
osgViewer::Viewer viewer;
viewer.setThreadingModel(osgViewer::Viewer::SingleThreaded);
viewer.setCameraManipulator(new osgGA::TrackballManipulator());
viewer.realize();
viewer.setSceneData(createShadowedScene(withTexture));
#if 1
// Drawing the frame then assigning a new shadowed scene
// seems to result in scene being rendered black.
// Although, seems ok when texture is assigned to the object.
viewer.frame();
viewer.setSceneData(createShadowedScene(withTexture));
#endif
viewer.run();
return 0;
}
#endif
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Scene renders black when replacing a ShadowedScene
After some serious digging and tweaking inside osgShadow::ShadowMap I
have come up with a partial workaround for this problem. The problem
seems to boil down to issues around the pushing and popping of
statsets containing instance of:
new osg::Uniform(osgShadow_shadowTexture,(int)_shadowTextureUnit);
ShadowMap uses a default value of 1 for _shadowTextureUnit
It seems that for geometries that have no texture assigned, I need to
set a value of 0 to _shadowTextureUnit, otherwise I get problems (as
least I do on my Radeon-X300)
So... my partial workaround is to setup my scene like:
osgShadow::ShadowMap* shadowMap = new osgShadow::ShadowMap();
shadowMap-setTextureUnit(0);
shadowedScene-setShadowTechnique(shadowMap);
For scenes that do not have textures, this is a perfect workround for
me, but for scenes containing textured AND untextured objects,
unfortunately the workround causes the textures to be lost.
I wonder if the PROPER solution to the problem requires some kind of
stateset override for nodes that is a function of whether the node has
textures?
Intersectingly the problem is a little bit bigger that I thought, as
untextured objects in shadowed scenes have strange artifacts on their
surfaces unless I setTextureUnit to zero (even the first time the
scene is assigned)
Is this info useful to anyone that actually knows what they are doing?
I'm begining to feel a bit out of my z-depth. ;-)
Chris.
On 02/11/2007, Chris Denham [EMAIL PROTECTED] wrote:
Hmm... think this might me a video card/driver specific problem.
I just tried this test on my colleague's PC that has a matrox video
card and seemed to work ok.
Oh rats does that mean it not so easy/impossible to fix the problem? :-(
Chris.
Date: Thu, 1 Nov 2007 17:56:06 +
From: Chris Denham [EMAIL PROTECTED]
Subject: [osg-users] Scene renders black when replacing a
ShadowedScene
To: osg-users@lists.openscenegraph.org
I'm getting a problem when assigning a new shadowed scene to the viewer.
What seems to happen is that once the first scene has been rendered,
the assignment of a new shadowed scene results in a everything in the
scene being drawn black. Also odd is the fact that there doesn't seem
to be a problem when a texture is assigned to objects being drawn.
I have created a minimal example that exhibits the problem, and pasted
it below.
Any ideas what's going wrong? Can anyone reproduce the effect?
[I'm using osg2.2 on windowsXP with Radeon X300 with latest drivers.]
#include osg/ShapeDrawable
#include osg/Geode
#include osgGA/TrackballManipulator
#include osgShadow/ShadowedScene
#include osgShadow/ShadowMap
#include osgDB/ReadFile
#include osgViewer/Viewer
const int ReceivesShadowTraversalMask = 0x1;
const int CastsShadowTraversalMask = 0x2;
osg::Node* createShadowedScene(bool withTexture)
{
osgShadow::ShadowedScene* shadowedScene = new osgShadow::ShadowedScene;
shadowedScene-setReceivesShadowTraversalMask(ReceivesShadowTraversalMask);
shadowedScene-setCastsShadowTraversalMask(CastsShadowTraversalMask);
shadowedScene-setShadowTechnique(new osgShadow::ShadowMap());
osg::LightSource* lightSource = new osg::LightSource;
lightSource-getLight()-setPosition(osg::Vec4(0, 0.2, 1, 0));
osg::ShapeDrawable * shape = new osg::ShapeDrawable(new
osg::Sphere(osg::Vec3(0.0f, 0.0f, 0.0f), 200.0));
shape-setColor(osg::Vec4(0.8f, 0.8f, 0.8f, 1.0f));
osg::Geode* geode = new osg::Geode();
geode-addDrawable(shape);
if (withTexture)
{
geode-getOrCreateStateSet()-setTextureAttributeAndModes( 0,
new osg::Texture2D(osgDB::readImageFile(Images/lz.rgb)),
osg::StateAttribute::ON);
}
shadowedScene-addChild(geode);
shadowedScene-addChild(lightSource);
return shadowedScene;
}
int main(int argc, char** argv)
{
bool withTexture = false;
osgViewer::Viewer viewer;
viewer.setThreadingModel(osgViewer::Viewer::SingleThreaded);
viewer.setCameraManipulator(new osgGA::TrackballManipulator());
viewer.realize();
viewer.setSceneData(createShadowedScene(withTexture));
#if 1
// Drawing the frame then assigning a new shadowed scene
// seems to result in scene being rendered black.
// Although, seems ok when texture is assigned to the object.
viewer.frame();
viewer.setSceneData(createShadowedScene(withTexture));
#endif
viewer.run();
return 0;
}
#endif
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Scene renders black when replacing a ShadowedScene
Hi Mihai, Sorry I didn't see your postings earlier in the day, they could have saved me some time. Though I guess I learnt something on the way ;-) The reason I didn't see your messages was that gmail decided to relegate digest Vol5,Issues 23 to my spam folder, and I only realised things where missing when Issue4 arrived normally. hmph... No.. it's not funny. Thanks for the valuable tips and code. Will your modification to ShadowMap go into the next osg release? Chris. Date: Fri, 02 Nov 2007 10:41:20 -0700 From: Mihai Radu [EMAIL PROTECTED] Subject: Re: [osg-users] Scene renders black when replacing a ShadowedScene To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Cc: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 Hi Chris, Please check the thread for fixes. I'm attaching, again, the fixed version of ShadowMap.cpp Cheers Mihai Chris Denham wrote: After some serious digging and tweaking inside osgShadow::ShadowMap I have come up with a partial workaround for this problem. The problem seems to boil down to issues around the pushing and popping of statsets containing instance of: ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Scene renders black when replacing a ShadowedScene
I'm getting a problem when assigning a new shadowed scene to the viewer.
What seems to happen is that once the first scene has been rendered,
the assignment of a new shadowed scene results in a everything in the
scene being drawn black. Also odd is the fact that there doesn't seem
to be a problem when a texture is assigned to objects being drawn.
I have created a minimal example that exhibits the problem, and pasted
it below.
Any ideas what's going wrong? Can anyone reproduce the effect?
[I'm using osg2.2 on windowsXP with Radeon X300 with latest drivers.]
#include osg/ShapeDrawable
#include osg/Geode
#include osgGA/TrackballManipulator
#include osgShadow/ShadowedScene
#include osgShadow/ShadowMap
#include osgDB/ReadFile
#include osgViewer/Viewer
const int ReceivesShadowTraversalMask = 0x1;
const int CastsShadowTraversalMask = 0x2;
osg::Node* createShadowedScene(bool withTexture)
{
osgShadow::ShadowedScene* shadowedScene = new osgShadow::ShadowedScene;
shadowedScene-setReceivesShadowTraversalMask(ReceivesShadowTraversalMask);
shadowedScene-setCastsShadowTraversalMask(CastsShadowTraversalMask);
shadowedScene-setShadowTechnique(new osgShadow::ShadowMap());
osg::LightSource* lightSource = new osg::LightSource;
lightSource-getLight()-setPosition(osg::Vec4(0, 0.2, 1, 0));
osg::ShapeDrawable * shape = new osg::ShapeDrawable(new
osg::Sphere(osg::Vec3(0.0f, 0.0f, 0.0f), 200.0));
shape-setColor(osg::Vec4(0.8f, 0.8f, 0.8f, 1.0f));
osg::Geode* geode = new osg::Geode();
geode-addDrawable(shape);
if (withTexture)
{
geode-getOrCreateStateSet()-setTextureAttributeAndModes( 0,
new osg::Texture2D(osgDB::readImageFile(Images/lz.rgb)),
osg::StateAttribute::ON);
}
shadowedScene-addChild(geode);
shadowedScene-addChild(lightSource);
return shadowedScene;
}
int main(int argc, char** argv)
{
bool withTexture = false;
osgViewer::Viewer viewer;
viewer.setThreadingModel(osgViewer::Viewer::SingleThreaded);
viewer.setCameraManipulator(new osgGA::TrackballManipulator());
viewer.realize();
viewer.setSceneData(createShadowedScene(withTexture));
#if 1
// Drawing the frame then assigning a new shadowed scene
// seems to result in scene being rendered black.
// Although, seems ok when texture is assigned to the object.
viewer.frame();
viewer.setSceneData(createShadowedScene(withTexture));
#endif
viewer.run();
return 0;
}
#endif
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Backface culling for a group containing a plane of linestrips
Just reposting with correct subject thread. ;-) On 26/10/2007, Chris Denham [EMAIL PROTECTED] wrote: Hi Michele, Thanks for this. You're probably right, I was floundering about a bit in that snippet of code I sent. Robert's suggestion contained a much neater solution - using the sign of the dot product of the vectors between eye point and face normal. i.e. cull when this is negative. (Convieniently, the node visitor gives you the eye point in local coordinates). All this is neatly wrapped up in ClusterCullingCallback class, so all I needed was one line of code to acheive my objective! Cheers. Chris. Date: Fri, 26 Oct 2007 13:32:53 +0200 From: Michele Bosi [EMAIL PROTECTED] Subject: Re: [osg-users] Backface culling for a group containing a plane oflinestrips. To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 Hi Chris, I did something similar once, I am not totally sure but I think that the vector should be multiplied before the matrix and that you need to multiply only the direction component without the position. Once you have the direction transformed in camera space to see if it faces the camera you should only need to test if the Z component is 0 (assuming a right handed reference system). Good luck, Michele ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Backface culling for a group containing a plane of linestrips
Hi Robert, A first class top tip! osg::ClusterCullingCallback does exactly what I was trying to do. Thanks very much. Chris. Date: Thu, 25 Oct 2007 19:20:15 +0100 From: Robert Osfield [EMAIL PROTECTED] Subject: Re: [osg-users] Backface culling for a group containing a plane oflinestrips. To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 Hi Chris, Have a look a the osg::ClusterCullingCallback. Robert. On 10/25/07, Chris Denham [EMAIL PROTECTED] wrote: I'm looking for the best way to make a collection of linestrips (which lie on plane) disappear when the plane is facing away from the screen. i.e. exactly like the way back face culling works for polygonal faces. My first attempt was to create a special kind of group that has a normal, then when the CullVistor visits the node, determine whether to accept the node based on the modelviewmatrix transformation of the normal vector. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg-users Digest, Vol 4, Issue 74
Hi Michele, Thanks for this. You're probably right, I was floundering about a bit in that snippet of code I sent. Robert's suggestion contained a much neater solution - using the sign of the dot product of the vectors between eye point and face normal. i.e. cull when this is negative. (Convieniently, the node visitor gives you the eye point in local coordinates). All this is neatly wrapped up in ClusterCullingCallback class, so all I needed was one line of code to acheive my objective! Cheers. Chris. Date: Fri, 26 Oct 2007 13:32:53 +0200 From: Michele Bosi [EMAIL PROTECTED] Subject: Re: [osg-users] Backface culling for a group containing a plane oflinestrips. To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 Hi Chris, I did something similar once, I am not totally sure but I think that the vector should be multiplied before the matrix and that you need to multiply only the direction component without the position. Once you have the direction transformed in camera space to see if it faces the camera you should only need to test if the Z component is 0 (assuming a right handed reference system). Good luck, Michele ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSG blocking on application exit.
Hi OSGers, I'm a bit of a newbie to OSG, but I've been developing an application based on the osgviewerMFC example in OSG2.0 (built using VS2005). The problem that I discovered with my application (and the unmodified example) is that once I have loaded in a model (e.g. cow.osg or glider.osg) the program does not terminate properly. It seems to close, but remains as a process consuming CPU resource until I manually terminate it using task manager. As a shot in the dark I guessed the problem might be something to do with threads, so I added the line: mViewer-setThreadingModel(osgViewer::Viewer::SingleThreaded); just before the call to: mViewer-realize() This seemed to cure the problem, so just thought someone might find this info useful. Why does this problem occur? What have I lost by setting single threaded mode? And.. has it been fixed in later versions? Thanks Chris D. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
