Discussion:
Volume Rendering and VR Juggler
(too old to reply)
Smilen Dimitrov
2005-11-26 13:48:01 UTC
Permalink
Hi all,

I am quite new with the OpenSG platform, but I have a specific task for a school
project - I need to use volume rendering for a VR platform. So, what I want to
use is the volRen library together with VR Juggler - and I tried to make a
simple example, but it crashes always. So I am not realy sure in which list to
post this, but as the error is reported in osgsystem(d).dll I will try i here
first - le me know if I should move it..

I have previously had problems to get OpenSG's volume rendering examples to work
on my PC, bur since then, I have discovered that my RAM was not set up OK (after
my computer was not able to handle some online games). That problem was fixed,
the games could run, and I started with a fresh XP install, using VS 7.1, Open
SG 1.6.0 and VR Juggler 2.0.1 (latrest stable releases). By the way, i also
have 512 MB RAM and Nvidia GeForce4 MX 440 with AGP 8X. I also installed the
latest NVIDIA drivers (which I assume contain the latest OpenGL drivers).

So, it first I tried compiling the simplest examples individually, which I
identified as
- testSimpleVolumeNodeRender as example for VolRen
- OpenSGNav as example for VR Juggler.

Both of these compiled and ran fine, except for the WARNING:
Window::getFunctionByName: Couldn't get function 'glCombinerStageParame
terfvNV' for Window 01700340 - but I have read elsewhere on this list that I
shouldn't be too concerned about it?... An interesting thing may be, that when
testSimpleVolumeNodeRender is compiled and run in debug mode, it fails to
render the volume - renders only a white cube, and in addition to the above
warning, there is also a WARNING: TextureChunk::initialize: 3D textures not
supported for this window!

Then I tried merging these two - the idea was to replace the default torus
model in OpenSGNav:

mModelRoot = OSG::makeTorus(.5, 2, 16, 16);

with the volume model from testSimpleVolumeNodeRender. As I could see that
mModelRoot is of type OSG::NodePtr, and also the function makeVolume, which
parses the dat file in testSimpleVolumeNodeRenderm, returns OSG::NodePtr, I
simply incuded that function and the necesarry includes into OpenSGNav, and
replaced the above line with

mModelRoot = makeVolume("00_data64x64x64.dat");

Like this, the project compiles, although I get the warnings:

c:\Program Files\OpenSG\include\OpenSG\OSGTextureManager.h(150) : warning C4099:
'osg::BrickSet' : type name first seen using 'class' now seen using 'struct'
c:\Program Files\OpenSG\include\OpenSG\OSGTextureManager.h(24) : see declaration
of 'osg::BrickSet'

These are due to the inclusion of <OpenSG/OSGDVRVolume.h>, but the funny thing
is, when the original testSimpleVolumeNodeRender is compiled it does no produce
this warning, although it does include OSGDVRVolume as well.

Well, you can download those project files from here:
http://www.smilen.net/VolrenJuggler/VolrenJugglerSend.zip
and try compiling them on their own - I basically have no idea whether my
programming is wrong, my settings or whether my computer simply cannot handle
this.

When the compiled combined program is run,it comes up to a white window and then
it crashes saying:
AppName: opensgnav.exe AppVer: 0.0.0.0 ModName: osgsystemd.dll
ModVer: 0.0.0.0 Offset: 00009db9

(for the release version it is osgsystem.dll and different offset)
If I debug in the development environment, it says
Unhandled exception at 0x00bd9db9 in OpenSGNav.exe: 0xC0000005: Access violation
reading location 0x00000064.

dissasembly shows:

00BD9DB9 mov dx,word ptr [ecx]
(not that I know any assembler but this might help ??? :) )

I also tried compile/run with the torus command, and all the new inclusions
remaining, runs OK as expected.

I tried to step through the program in both the working torus and non working
volume case, and I noted down the order of execution of functions, see them
here:

http://www.smilen.net/VolrenJuggler/JugglerVolrenStep.txt

I also saw a similar post which says a debugger should be used for more info. I
used MS Windows WinDbg:6.5.0003.7, and again I did a compare trace for the
working torus and non working model, here they are

http://www.smilen.net/VolrenJuggler/JugglerVolrenDbgTrace.txt

I am really not good with this debugger, so if additional info is needed with
other settings, just let me know what to do with it.

As I really can't figure out what to do, I really hope someone will be able to
help.

Thanks in advance,
smilen
Smilen Dimitrov
2005-11-28 01:18:01 UTC
Permalink
PS:

I tried some other plain C volume rendering examples. Most of them complained
about not being able to find GL_EXT_texture3D, an OpenGL extension, and would
refuse to run, if I forced them, crashes are experienced.

I downloaded OpenGL Extensions Viewer from http://www.realtech-vr.com/glview/,
and I could see that for my card and drivers (NVIDIA GeForce MX 440) , this
extension appears as GL_EXT_texture3D (GL_VERSION 1.5) under 1.2 Core
features,
but is not reported in the report, and the following is also given in
the report

GL_EXT_texture3D not in list but has the entry point glTexImage3DEXT

In relation to this, I have found the following discussion about my NVIDIA:

http://www.gamedev.net/community/forums/topic.asp?topic_id=332346\

Where it says that 3D Textures are not hardware supported.

So I guess this is the reason why these other volume rendering C
examples do not
want to run. But then, it makes it even more surprising how is it possible to
run the OpenSG volume renderer examples. Even stranger - after a suggestion on
the forum above (that it will be possible to run in software mode - slow), I
found a software emulation key in the OpenGL Extensions Viewer and I
tried it -
the other C volume rendering examples would still not run, OpenSG volume
rendering examples would run slow - if I turned off software emulation again,
OpenSG volume rendering examples would again run smooth!!

Well, after knowing this, I am very pleasantly surprised that OpenSG volume
renderer examples can run at all on my machine :) But how come? Is this
hardware problem possibly a reason for not being able to run VR Juggler and
OpenSG volme rendering together ?

Cheers
smilen
Dirk Reiners
2005-11-28 15:07:02 UTC
Permalink
Hi Smilen,
Post by Smilen Dimitrov
So I guess this is the reason why these other volume rendering C
examples do not
want to run.
Yup.
Post by Smilen Dimitrov
But then, it makes it even more surprising how is it possible to
run the OpenSG volume renderer examples. Even stranger - after a suggestion on
the forum above (that it will be possible to run in software mode - slow), I
found a software emulation key in the OpenGL Extensions Viewer and I
tried it -
the other C volume rendering examples would still not run, OpenSG volume
rendering examples would run slow - if I turned off software emulation again,
OpenSG volume rendering examples would again run smooth!!
Well, after knowing this, I am very pleasantly surprised that OpenSG volume
renderer examples can run at all on my machine :) But how come?
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. ;)
Post by Smilen Dimitrov
Is this
hardware problem possibly a reason for not being able to run VR Juggler and
OpenSG volme rendering together ?
No, that shouldn't be. I'm more inclined to think about different
rendering modes. Different Volume Shaders use different modes, and not
all of them work with 2D textures.

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.

But honestly I would recommend buying a new graphics card if possible.
Even a low-end card like an FX5200 should be faster than your GF4, and
they are pretty affordable these days (starting at around $30).

Yours

Dirk
Smilen Dimitrov
2005-12-01 11:41:27 UTC
Permalink
Hi Dirk, all,

First of all, thanks for the reply !! :)
Post by Dirk Reiners
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 :)
Post by Dirk Reiners
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 :)
Post by Dirk Reiners
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.
Dirk Reiners
2005-12-02 10:12:09 UTC
Permalink
Hi Smilen,
Post by Smilen Dimitrov
First of all, thanks for the reply !! :)
that's part of what we're here for. ;)
Post by Smilen Dimitrov
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 -
Hm, that's weird. Not sure what you need to do to make it work right, I
only use Windows if I really can't avoid it.
Post by Smilen Dimitrov
though in the end, I got to the following call stack trace from when the
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.
Smilen Dimitrov
2005-12-04 21:24:02 UTC
Permalink
Hi Dirk,

Thanks so much for the patch! I got the dailybuild from 04 Dec 05, and
there is
an improvement - at least now I get a window rendered, with the VR Juggler
avatar, in release versions! However, as soon as the volume object comes in
sight (it is by default a little off, so the avatar has to be moved a little
back until it starts being rendered) it crashes again.

I took some screenshots as well, to hopefully explain my problem
better. I also
tried to move makeVolume so it's a class method, so now everything is in
OpenSGNav.cpp. Also, I should node that I have made the volume node to be a
child of the torus node - if this line mModelRoot->addChild(cModelRoot); is
commented, torus is rendered no problem. Here is the source

http://www.smilen.net/VolrenJuggler/Volren04JugglerSend.zip

So, in debug version, it crashes at a white screen:
Loading Image...

resulting with the following window trace
http://www.smilen.net/VolrenJuggler/windowTrace04_debug.txt

and the stack trace
http://www.smilen.net/VolrenJuggler/stacktrace04_debug.TXT

For debug, I get the message WARNING: TextureChunk::initialize: 3D
textures not
supported for this window! which is the same that I get when I run
simpleVolumeNodeRender in Debug mode (Release versions do not have this
problem) - So I ran some tests on the regular VolRen examples and
included them
below.

In any case, the stack trace in debug mode shows the crash at exactly the same
point FieldContainerPtrBase+0x29, though now, for instance
osg::Slicer::getSlicingDirection shows up in the trace.

The same program, in release version, crashes only when the volume comes into
the scene:
Loading Image...

resulting with the following window trace
http://www.smilen.net/VolrenJuggler/windowTrace04_release.txt

and the stack trace (having of course only one line, no symbols - so I
cant get
any more information from this) says it crashes at
OSGSystem!osg::FieldContainerPtr::FieldContainerPtr+0x6:
http://www.smilen.net/VolrenJuggler/stacktrace04_release.TXT

As the tests from the regular VolRen examples below will show, using the
DVRSimpleShader in debug mode results with TextureChunk::initialize: 3D
textures not supported for this window! so, as I ran these tests, I figured
that DVRMtexLUTShader works fine for me in debug mode (although it
takes like 4
seconds to render a frame), so I tried to make a version that uses this
shader,
in hope to skip the crash, but still the same. The source is here:

http://www.smilen.net/VolrenJuggler/Volren05JugglerSend.zip

It behaves the same as the Volren04Juggler, so the same screenshots from above
are valid, and the traces are here:

http://www.smilen.net/VolrenJuggler/windowTrace05_debug.txt
http://www.smilen.net/VolrenJuggler/stacktrace05_debug.TXT
http://www.smilen.net/VolrenJuggler/windowTrace05_release.txt
http://www.smilen.net/VolrenJuggler/stacktrace05_release.TXT

Just a wild guess - maybe in a VR Juggler context, it is not obvious to the
rendering system which way the slices should be oriented - since for instance,
they would have to be oriented differently if say you have to render for 6
screens (the slice orientation should change?) - although here I use the
standalone.jconf so I render for only one screen??

Well, it started going somewhere, but not there yet - so hope I will get some
more help to make this example work :)

Immense thanks
smilen

---------
PS: Screenshots from regular VolRen examples:

TestSimpleVolumeNodeRender (uses DVRSimpleShader)

in Debug - white box, textures not supported message
Loading Image...

in Release = all is fine
Loading Image...


TestVolumeShadersRender

in Debug for DVRSimpleShader - white box, no message
Loading Image...

in Debug for DVRMtexLUTShader - all fine, takes a lot of time to render
Loading Image...

in Release for DVRSimpleShader - all fine
Loading Image...

in Release for DVRMtexLUTShader - all fine
Loading Image...
Dirk Reiners
2005-12-05 09:01:01 UTC
Permalink
Hi Smilen,
Post by Smilen Dimitrov
and the stack trace
http://www.smilen.net/VolrenJuggler/stacktrace04_debug.TXT
thanks for the trace! Looks like I was a little too optimistic about the
use of the camera beacon in the VolRen. I think I fixed all occurrences
now, please give it another try.

Yours

Dirk
Smilen Dimitrov
2005-12-08 09:39:03 UTC
Permalink
Hi Dirk,
Post by Dirk Reiners
I think I fixed all occurrences
now, please give it another try.
I downloaded the dailybuild 051208, installed, recompiled the example, and ...
It's working !!!!!!! Dirk, you are *THE MAN* !!!!!! Thanks so much!

After few months of trouble, it was so pleasant to see the OpenSG
example model
together with the VRJuggler avatar, I thought I'd never see it ! I must
therefore drop some screenshots of the previously linked examples:

This is the simpleVolumeNodeRender in VR Juggler - the one which
anyways bugs on
my machine in debug. Still bugs (white screen), but the avatar is
there, and no
crash
Loading Image...

The release is of course fine:
Loading Image...

This is the example with DVRMtexLUTShader, which on my machine works fine both
in debug and release mode
Loading Image...
Loading Image...

I couldn't imagine the model is so big in the VR Juggler environment,
so I tried
to scale it - it was not totally straightforward for me, so I thought
I'd share
the code for makeVolume below, with the scaling stuff included - maybe
it helps
someone:

// Create a volume rendering node with all desired attachments
OSG::NodePtr OpenSGNav::makeVolume( const char * datFile)
{
OSG::DVRVolumePtr vol = OSG::DVRVolume::create();
OSG::DVRAppearancePtr app = OSG::DVRAppearance::create();
OSG::DVRVolumeTexturePtr tex = OSG::DVRVolumeTexture::create();

// Load the 3D-image and store it in the volume texture attachment
OSG::ImagePtr datImage = OSG::Image::create();
if (false == datImage->read(datFile)) {
SLOG << "File: " << datFile << " not found" << std::endl;
//exit (-1);
exit();
}

OSG::beginEditCP(tex);
tex->setImage(datImage);
tex->setFileName(datFile);
OSG::endEditCP(tex);

// Attach the volume texture to the appearance
OSG::beginEditCP(app, OSG::Node::AttachmentsFieldMask);
app->addAttachment(tex);
OSG::endEditCP (app, OSG::Node::AttachmentsFieldMask);

// Assign the appearance to the volume core
OSG::beginEditCP(vol);
vol->setFileName(datFile);
vol->setAppearance(app);
vol->setShader(OSG::DVRSimpleShader::create());
OSG::endEditCP(vol);

// Create a node for the volume core
OSG::NodePtr newGeom = OSG::Node::create();
OSG::beginEditCP(newGeom);
newGeom->setCore(vol);
OSG::endEditCP(newGeom);

//scale it a bit
OSG::TransformPtr mVolTransform = OSG::Transform::create();
gmtl::Vec3f scaler = gmtl::Vec3f(0.05f, 0.05f, 0.05f);
OSG::Matrix scale_mat(OSG::Matrix::identity());
scale_mat.setScale(scaler[0], scaler[1], scaler[2]);

OSG::beginEditCP(vol);
mVolTransform->getMatrix().multLeft(scale_mat);
OSG::endEditCP(vol);

OSG::NodePtr scaledGeom = OSG::Node::create();
OSG::beginEditCP(scaledGeom);
scaledGeom->setCore(mVolTransform);
scaledGeom->addChild(newGeom);
OSG::endEditCP(scaledGeom);

//return newGeom;
return scaledGeom;
}

Thanks again,
Cheers
smilen

Loading...