Hello Jinghua, What you found is right, somehow I didn't thought about that myself.
Basic idea of slicer is that it can find intersection of a parallelepiped with a set of parallel planes (cube or parallelepiped is your volume and planes are view aligned cuts through your data), as a result it gives you set of hexagons (if you intersect a cube with a plane number of vertexes of resulted polygon will vary from 1 to 6 at most, slice clipping always returns 6 vertexes but some of final triangles when you render it with OpenGL will have zero square and not in fact rendered, so it is always optimal). The problem you have is this: when you intersect a quarter of a cube it will give less intersections than for the whole cube because the distance between these parallel planes is constant. Number of slices set for the whole cube, not per slab; it is done so, to be able to align same slices from neighboring data slabs in DB compositing. The algorithm itself is rather tricky to explain in a letter, you can find details in the book "Real-Time Volume Graphics", pages 70-79. There are also lots of other techniques as pre-integration and transfer functions explained. It would be good if you can get this book, it really helped me a lot. Unfortunately I couldn't find references to appropriate papers. But the source code which is used in eVolve I adapted from this one: http://www.real-time-volume-graphics.org/?page_id=5 There are also some tutorials: http://www.real-time-volume-graphics.org/?page_id=14 you might find "Part 04: GPU-Based Ray Casting" a bit useful. Best regards, Makhinya Maxim On Feb 19, 2009, at 11:44 PM, Jinghua Ge wrote: > Dear Maxim, > > I think I understand the difference of the performance on these two > setup now. > > 1. With the setup: data header: 1024x1024x256, range [0, 1], the > sliceclipping algorithm gives out small amount of valid polygons ( I > found that some polygons are "empty" with all (0, 0, 0) vertices), > even tho the slicenumber is 2048. > > 2. With the setup: data header 1024x1024x1024, range[0, 0.25], the > sliceclipping algorithm gives out more valid polygons, which end up > more workload in fragment shader. > > I think that's why render same amount of data shows different fps. > > 3. When I render the whole data 1024x1024x2048, I assume the same > situation happens. (Besides, the slice number will be set 4096). So > it get even slower. I got 2.3 fps. When I set the slice number to be > 2048, it runs at 5.4 fps. > > Unfortunately I didn't really understand how the sliceclipping code > works. Especially why scenario 1 and 2 gives out different number of > polygons when the slice number is set to be the same. Can you > explain a bit more about the algorithm to me according to this? > Thanks! > > Jinghua > > > > On Thu, Feb 19, 2009 at 8:30 AM, Jinghua Ge <[email protected]> > wrote: > Dear Maxim > > I have been thinking about the same things you mentioned in your > email, and test 1 is exactly what I plan to do today. I will report > back my test results. Thanks! > > > Jinghua > > On Thu, Feb 19, 2009 at 2:55 AM, Maxim Makhinya > <[email protected]> wrote: > > Hello Jinghua, > > This part of your code looks correct, I never tried it > with GL_LUMINANCE thought. How I would approach you > problem is the following: > > 1) Create same test cases for ranges [0 1] and [0 0.25]. > Which means that for one of them you HAVE TO adjust > depth scaling in your .vhf file ( dScale=..). When > you render your two cases, make sure objects occupy > exactly the SAME space on the screen, and that final > rendering is identical (make also sure you are using > the same number of intersecting slices). This is very > important since volume rendering performance directly > depends on your fill, i.e. how many pixels were > rendered, cause all the job is done by fragment shader! > > 2) analyze then 3D textures' sizes, they should be > identical (you render the same data). > > I don't see why you have this problems, because when you > have range [0 0.25] sliceClipping ( sliceClipping.cpp ) will > cut a parallelepiped out of the cube (1,1,1) and your texture > coordinates will also be in range: (0..1, 0..1, 0..0.25), > but, your texture fits perfectly in to > (0..1024, 0..1024, 0..256), and you want to use the whole > texture, not just the first quarter of it, so TD.D will be > 4, and it will rescale coordinates from sliceClipping to > (0..1, 0..1, 0..1), but on the screen it will still look as > parallelepiped! Now if you render same amount of data but > using different ranges [0 1] and [0 0.25] one will look as > a cube and another as parallelepiped (if scaling coefficients > are equal), that's why you need to readjust them for one of > your test cases; again, you need exactly the same data and > exactly the same screen space to be rendered to compare > performance, it is not enough just to simply render same > amount of data. > > > Best Regards, > > Makhinya Maxim > > > On Feb 18, 2009, at 6:28 PM, Jinghua Ge wrote: > > > Yes I see 1/4 data scaled to the same screen space. I am pretty sure > > I load the same amount of data into 3D texture, as the print out > > shows: w:1024 1024 h:1024 1024 d:1024 256 256 > > > > The texture code is: (I set comp = 1 for my ubyte volume data) > > > > if(comp == 4) > > { > > glTexImage3D( GL_TEXTURE_3D, > > 0, GL_RGBA, tW, tH, tD, > > 0, GL_RGBA, GL_UNSIGNED_BYTE, (GLvoid*) > > (&data[0]) ); > > } > > else if(comp == 1) > > { > > //glTexImage3D( GL_TEXTURE_3D, > > // 0, GL_ALPHA, tW, tH, tD, > > // 0, GL_ALPHA, GL_UNSIGNED_BYTE, (GLvoid*) > > (&data[0]) ); > > glTexImage3D( GL_TEXTURE_3D, > > 0, GL_LUMINANCE, tW, tH, tD, > > 0, GL_LUMINANCE, GL_UNSIGNED_BYTE, (GLvoid*) > > (&data[0]) ); > > } > > > > Let me double check tho. > > > > > > Jinghua > > > > > > On Wed, Feb 18, 2009 at 11:20 AM, Maxim Makhinya > > <[email protected]> wrote: > > > > > >> I set the TD.D = 1. , the rendering is fast now, but the > > >> scaling is wrong. > > > > > > Doing this you should see wrong portion of data rendered, not > > > wrong scaled! > > > > well, actually, you will see both - wrong scaled and wrong > > portion ( 4 times smaller ) of data, because smaller portion > > will occupy same screen space (if you didn't messed vertex > > positions). > > > > _______________________________________________ > > eq-dev mailing list > > [email protected] > > http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev > > http://www.equalizergraphics.com > > > > > > > > -- > > Jinghua Ge, Ph.D > > Visualization Consultant, CCT > > 331 Frey Computing Services Center > > Louisiana State University > > Phone: (225) 578-7789 > > Fax: (225) 334-2061 > > > > > > _______________________________________________ > > eq-dev mailing list > > [email protected] > > http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev > > http://www.equalizergraphics.com > > > _______________________________________________ > eq-dev mailing list > [email protected] > http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev > http://www.equalizergraphics.com > > > > -- > Jinghua Ge, Ph.D > Visualization Consultant, CCT > 331 Frey Computing Services Center > Louisiana State University > Phone: (225) 578-7789 > Fax: (225) 334-2061 > > > > > > -- > Jinghua Ge, Ph.D > Visualization Consultant, CCT > 331 Frey Computing Services Center > Louisiana State University > Phone: (225) 578-7789 > Fax: (225) 334-2061 > > > _______________________________________________ > eq-dev mailing list > [email protected] > http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev > http://www.equalizergraphics.com _______________________________________________ eq-dev mailing list [email protected] http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev http://www.equalizergraphics.com
