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
