Dirk Reiners wrote:
Hi Allan,
On Fri, 2005-08-26 at 12:56 +0200, Allan Rasmusson wrote:
Here's what I do (I removed error handling):
...
_myDVRVolumePtr->setRenderMaterial(_simpleMaterial);
Interesting! Your're not supposed to be able to do that, because the
method is protected. Did you derive your own Volume from DVRVolume?
That renderMaterial is not really used to render the volume, it is
primarily a placeholder so that the RenderAction knows what to do with
the node.
I am not using any classes derived from DVRVolume. If one looks at
OSGDVRVolumeBase.h you are quite right that setRenderMaterial is
protected, but in OSGDVRVolume.h it is made public (around line 90).
Conflict of interests...
Okay then; instead of using the setRenderMaterial, I tried to attach
my OSGFragmentProgramChunk to the DVRAppearance which is just a
specialized version of the ChunkMaterial. I should mention that all
volume rendering is setup and renderer BEFORE the fragment program is
added. In order to add the fragment program I do:
... initialize fragment program chunk...
DVRAppearancePtr app = myVolume->getAppearance();
beginEditCP(app);
app->addAttachment(_myFragmentProgram);
endEditCP (app);
The fragment program is completely ignored, but just after adding
this the dbg version starts complaining:
WARNING:
(/users/alras/code/OpenSG/Source/System/State/OSGTextureChunk.cpp,1907):
TextureChunk::deactivate precheck failed: invalid enumerant (0x500)
Hm... Does all this mean that the only way to render the vol. rend.
using a fragment program is to write a custom shader?
1: As you know I have multiple graphs containing OSGDVRVolumes which are
rendered in different viewports. Assume that I have three graphs, a,b
and c rendered in seperate viewports. All graphs contains an
OSGDVRVolume node, the viewport which renders graph b has a statistics
foreground and graph c has a fragment program attached as described
above. The odd thing is that all volumes renders correctly, but the
statistics foreground is rendered with the fragment program. This always
happens no matter what order the graphs are rendered in.
That does sound like a bug. The RenderAction should disable everything
after it's done rendering the Material. The problem is that I have no
good idea how to approach it right now. Do you have a simple test
program that could demonstrate the problem? If not, could you run a
frame through an OpenGL debugger like glIntercept or bugle and send me
the output?
I haven't had time to do a test program, but should be able to do so in
a day or two.
2: I was just wondering if I could disable the fragment program for a
few frames of rendering. I've been looking for something like
enable()/disable() like the OSGClipPlaneChunk has.
Uhm.... why has some chunks got the enable/disable operations while
others don't?
The only chunk that really has it is the ClipPlaneChunk, the DepthChunk
has it too, but there it has a slightly different meaning. I'm not sure
why the ClipPlaneChunk has it, I got that code from Manfred and didn't
want to mess with it. But it's not used in the VolRend anyway, so I'm
probably going to remove it for 2.0. The way to disable a chunk is to
remove it from the Material/State. ;)
Do you plan to remove the enable/disable feature from the clipPlane? I
ask because I may have 4 or 5 clipPlanes attached to several graphs, and
allow the user to choose which ones are enabled for each graph.
/Allan
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
