Hi Dirk, all,
First of all, thanks for the reply !! :)
The OpenSG VolRen lib is written in a way that can use 2D textures as an
alternative to the 3D textures normally used. It takes more texture
memory, and is not quite a good visually, but it works. Note that this
will probably go away in the future, though, so enjoy it while you
can. ;)
Very good to know - I'll keep a copy of 1.6.0 as an alternative to
target lower
end graphic cards :)
I would recommend buying a new graphics card if possible
It's good to know that the one I have is slowly going out of the
standard - I'll
try to replace it as soon as possible.. But I'll try to do with this one if I
can as well :)
The most interesting data you can get from the debugger is the Stack
Trace, which shows you exactly in which line it crashed, otherwise it's
pretty hard to see what might be going wrong.
Thanks for this - I tried to mess with WinDbg a little, and I managed
to get, I
hope, a more meaningful stack trace. I use the Call Stack window in
WinDbg, and
for some reason I had to enter the start directory as well whenever I
wanted to
open an executable.. The symbols were missing, I tried entering the paths for
the compiled libs for both VR Juggler and OpenSG but then it still complains -
though in the end, I got to the following call stack trace from when the
example crashes:
http://www.smilen.net/VolrenJuggler/DebugTrace01.txt
The same text file has the call stack for the corresponding point (I guess) in
the non crashing simple volume render example.
From what I can see, when the time comes for the volume to be rendered,
OSGSystemD!osg::DVRVolume::draw is called, and as part of that it iterates
through OSGSystemD!osg::FieldContainerPtr::FieldContainerPtr, and when
it comes
to OSGSystemD!osg::FieldContainerPtrBase::FieldContainerPtrBase+0x29 it
crashes
(the non crashing OpenSG volume example simply continues beyond this point
iterating through further FieldContainerPtr-s).
The only thing different in the two threads is that
- the working one goes through OSGSystemD!osg::SimpleSceneManager::redraw and
executes OSGSystemD!osg::Viewport::render
- and the crashing VR Juggler one executes
OSGSystemD!osg::PassiveViewport::render, which is called through
OpenSGNav!vrj::OpenSGApp::draw.
This is unfortunately completely unknown teritorry for me, so I hope for some
comments and help in understanding what this means.
I would also be grateful if some of you, with VR Juggler and OpenSG,
can look at
the source code (VS 7.1 project and solution included)
http://www.smilen.net/VolrenJuggler/VolrenJugglerSend.zip
and maybe try to compile it on your machines, and let me know if it crashes
there as well. I am suspicious at the possibility that the NodePtr that
makeVolume returns is maybe not encapsulated right in one or another way for
the scene context as the VR Juggler lays it out (whereas it is right if
you use
it as a root with SimpleSceenManager)?
Thanks again for the assistance,
Cheers
smilen
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
