Hi Allan,
> I guess I have been a bit vague about what I'm trying to achive.
>
> 1. One viewport will show a normal vol.rend. of an object. However, it
> will be cut by a plane. This helps one determining the position of the
> cut-plane.
>
> 2. Another viewport will render an opaque plane through the surface. The
> plane is the one cutting the object and the camera will view along
> -1*plane normal.
>
> 3. A third viewport will render the exact same thing as viewport 2, but
> will process other 3d textures representing some physical properties,
> e.g. flow, while rendering. For clarity, there are 3 of these each
> representing flow along x,y and z axis respectively. A fragment program
> combines these into a vector which is visualized by using the projection
> of the vector onto the cut-plane as a color.
>
> My intention was to have different rendering routines in the specialized
> DVRVolume, all selectable via setDrawMode(UInt32).
in my opinion there is no real need for different draw modes since
different rendering modes could be achieved on one hand by switching
between volume rendering and single slice reconstruction in the volume
and on the other hand by switching between different shaders.
So what I would do is:
1. Extend the volume node so that it can do single slice reconstruction
instead of full volume reconstruction. This would probably require
an extension of OSGBrick and possibly also of TextureManager.
One obvious solution is to implement something like
Brick::renderSingleSlice and to borrow some code from
Brick::render3DSlices. Maybe there could also be a way to unify
both or to use renderSingleSlice in render3DSlices.
Another field in DVRVolume could allow switching between slice
rendering and volume rendering.
2. Write a DVROpaqueSlice shader which inherits DVRSimpleLutShader
but uses overwrite instead of alpha blending or alternatively change
the blend function to GL_ONE, GL_ZERO. This should be pretty
easy. See e.g. DVRMtexLUTShader for an example of a derived shader.
3. Write any fragment program based shader you like in order to achieve
your desired shading.
> Different types of viewports have been created to choose the apropriate
> mode. Thus one can choose the appropriate mode simply by adding the
> proper viewport to a window.
I would rather put the intelligence of switching between different
render modes into the viewport. Since it is only a few field changes
of the volume node I don't really see the need for a convenience function
in the volume node.
> Regarding the rendering: yes, I do need my own rendering routine, but I
> don't see why it should be a major problem to put it in the DVRVolume.
> The texture is also located here. I may need to extend the OSGBrick with
> the actual rendering code, but there ought to be no problems here
> either.
>
> I'm stuck, however, since the volume renderer has been implemented using
> private instead of protected and only the the OSG specific code is
> virtual, besides the shader.
I still don't see how you intend to reuse functionality of the volume node.
As stated above you would at least need a derived Brick class and you would
need to switch between different rendering methods of the brick. Since Brick
is no real OSG class and therefor doesn't provide the prototyping mechanism
the only way to create objects of the new class is to reimplement the
initialization of DVRVolume and of the TextureManager. If you do so this
private member of DVRVolume should not bother you. Just use your own variable.
> Regarding the use of multiple 3d volumes during a rendering pass, I'm
> not to sure how to do it. Since I haven't looked into it yet I'm not
> sure whether there is a problem at all.
Actually the TextureManager was intended to use a several textures for the
rendering. You just need to register several textures in your shader.
However this functionality has only been tested roughly.
Anyway the better solution would be to combine the three fields into one
single RGB texture, since this significantly reduces the number of fragment
program instructions (in particular lookups) and should therefore lead to
better performance.
Manfred.
======================================================================
Manfred Weiler [EMAIL PROTECTED]
Visualisierung und Interaktive Systeme Telefon: 0711/7816-208
Universitaet Stuttgart, IfI FAX: 0711/7816-340
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
