On Fri, 2005-02-11 at 16:20 +0100, Manfred Weiler wrote: > 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. >
We totally agree on all of the above. > > 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. I agree with you here also. It is the viewport that sets the field in the DVRVolume, thus determining the type of rendering. > > 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. > What I meant by reusing the functionality of the DVRVolume was to use the existing code for the rendering of the full volume (the OSGDVRVolume::draw() ). This leaves the problem of how to deciding what rendering mode should be used. One solution is to use a function which determines whether the normal (full) rendering mode or one of the extended modes is requested. In the former case let OSGDVRVolume::draw() render the object. Otherwise use a custom rendering function with extended bricks and texturemanager. Since OSGDVRVolume::draw() does it's own initialization, this way will only work if one can determine whether the initialization has happened or not. This is not possible since shadingInitialized is private. Another solution is to extend the OSGBrick and OSGTextureManager by inheritance. The use of virtual functions would make this possible. From what you say above I understand that this is not possible since the Brick is not a real OSG class. > > 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. Sounds good. I'll look into it. > 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. This is also considered. > Manfred. So, all combined I gather I have to edit the OSGBrick and OSGTexturemanager within the Sources/System/Nodecores/Drawables/VolRen, thus ending with my own personal version of OSG. I don't like this. What is needed to make the volume rendering fully flexible, besides making Brick part of OSG? I will gladly assist in making the vol. rend. fully flexible, but I need some guidance. /Allan ------------------------------------------------------- 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
