Hi Dirk,
> On Thu, 2005-02-10 at 07:40, Manfred Weiler wrote:
> > That's an interesting problem. Maybe the best way to do this is to
> > expose Brick as a OSGDrawable. So make it a smaller version of the
> > DVRVolume and to built a small drawtree of these bricks for the volume.
> > For the application programmer this could be transparent, since the
> > DVRVolume could create this drawtree automatically. But with the
> > right interfaces the user would also be able to specify it according
> > to his needs. I see a good chance that the functionality of DVRVolume
> > could be pushed down to the Brick without sacrificing any feature.
>
> Ok, that's an interesting alternative I hadn't thought about. I'm not
> sure if the Bricks are independent enough that they work be embedded in
> the DrawTree right now, as there is no additional information passed to
> the node in the DT. But that should be fixable.
I am not exactly sure whether we have a common understanding about this
drawtree stuff. I was rather thinking about DVRVolume being some kind
of smart Group object which creates a list of Bricks, that are supposingly
Drawables. As this pretty closely resembles the relation between DVRVolume
and Brick already, modifications should not be too difficult. The actual
rendering is done by the Brick anyway. However, the real object structure
should be mostly hidden from the application programmers and he should not
have too much influence internal Object relation. But I am open for
discussion about the actual base class for Volume and Brick.
The big advantage of this solution would be, that in this structure you
could easily distribute the data between different machines. For the
DVRVolume on some server node would not need to create all bricks.
You could also use something like ProxyBricks which might fit in the
concept of ProxyGroups. All other mechanism like DrawMask, or
view frustum cullun could also work transparently. The more I think
about it the more appealing this solution looks.
> > A workaround which should work right now is to decompose the 3D data
> > yourself and to build different volume nodes from this image.
> > (osg::Image) has already some routines for doing that. Adjusting the
> > different Volume nodes correctly should give seamless images in the
> > output, for the sort last rendering should do a correct depth sorting
> > based on the bounding boxes. Maybe there is some issue with the
> > slicing planes which should be aligned in different volumes but
> > this should be easy to fix. In order to make this work the sort last
> > rendering would have to perform alpha compositing, which I am currently
> > not sure, whether this is also implemented.
>
> The software SortLast does it, not sure how to make Sepia do it.
I would be rather surprised, all the hardware solutions I saw so far
supported z-compositing at best. And the later was pretty slow since
it required 2 rendering passes to read out depth via DVI output.
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
