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
