Hi, > > 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?
Well, not really (not going to construct some really strange case) :) > I > don't see how, honestly. Therefore I'd prefer putting it in the second > TC, seems to be more consistent. OK, fine. I can change it back next week. > 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. Agree. SliceDistance would be more flexible. You only have to be carefull that the sliceDistance is used int geo-bbox-space and not in the 0-1 range of the texture date. Maybe we can provide the current sliceDistane in tex-space as axtra parameter (e.g. stored in the 'q' values of the second tex coord) regards, Johannes BTW: If you are experimenting with advanced volume allgos: I have some simple code which generates gradients (with a 3d-sobel) from a scalar volume and stores it as normalmap in the same image. I could include the code in the Image class. Something like: void Image::createNormalMap (void) Works on scalar (OSG_L_PF) volume and creates a normalmap + scalar in Alpha volume (OSG_RGBAL_PF). Could be extended to work also on 2d-images to create a 2D-normalmap. Should we include it as Image method or is this really out of scope for the image class? ------------------------------------------------------- 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
