Thanks for all of your help Maxim. I have much more understanding of how to use eVolve now. Jinghua
On Fri, Feb 20, 2009 at 2:53 AM, Maxim Makhinya <[email protected]> wrote: > > 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 > -- 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
