Hi Johannes,
On Tue, 2004-11-09 at 06:30, Johannes Behr wrote:
>
> OK, I commited the code. I changed the source again,
> since I would not like to limit the code to multitexture-HW.
> I store the tex-coord for the next slice in the first
> GL color (glColor).
Hm, can you do pre-integrated volume rendering without MT hardware? I
don't see how, honestly. Therefore I'd prefer putting it in the second
TC, seems to be more consistent.
> There is still one problem. The slice-distance must be known
> to calculate the pre-integred lookup table.
>
> You can not set the slice-distance directly,
> only the slice-number. The slice-distance is calculated
> by dividing the volume-box-diagonal with the slice-number.
> (Just look at the OSGSlices.cpp around like number 540)
>
> I would like to change the implementation
> but I'm on road right now and I do not really have
> access to my dev-machine.
That sounds like something we can do, then.
> There are two solutions right now:
>
> 1. Choose the Slices.size and Slices.numberOfSlices
> carefully to get the desired sliceDistance.
>
> 2. Use a 3DTexture for the pre-integraded color lookup
> and the sliceDistance as third dimension. :)
That sounds a little overkill, IMHO. ;)
IMHO it would make more sense to add the sliceDistance as a parameter
for the slicer and add some provisions for using 3D volumes that have
have non-cubic voxels. That should be simple enough to add to not get
into VolRen turf but make the Slicer more usable as an experimentation
testbed.
Comments?
Dirk
-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
