From info-volumizer-owner@els.sgi.com Mon Dec 5 20:24:15 2005 Received: (from majordom@localhost) by els.sgi.com (8.12.10/8.12.2/els-2.2) id jB64Mm1r9431141; Mon, 5 Dec 2005 20:22:48 -0800 (PST) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.194]) by els.sgi.com (8.12.10/8.12.2/els-2.2) with ESMTP id jANEkNJT9195923 for ; Wed, 23 Nov 2005 06:46:24 -0800 (PST) Received: by xproxy.gmail.com with SMTP id h26so220387wxd for ; Wed, 23 Nov 2005 06:46:23 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=KOcZL4y0dslv2X5jKGfIk2Sw4LtUpmHetv3EodRllw4cUpUfJJcQq7kdTdhkKODjIiDoKypWbcsqfsXgAKIuTS4AJfKJEpqsb6v9v69qcRIePw1tVW1G7rQ9/7Xb5iPwcNcrsrB8dTgheX9GGLGIELYoJzw5vXjGhx6qC0lIt6Y= Received: by 10.65.148.6 with SMTP id a6mr6141063qbo; Wed, 23 Nov 2005 06:46:23 -0800 (PST) Received: by 10.65.155.20 with HTTP; Wed, 23 Nov 2005 06:46:22 -0800 (PST) Message-ID: Date: Wed, 23 Nov 2005 09:46:22 -0500 From: Kevin Wang To: info-volumizer@els.sgi.com Subject: Re: [info-volumizer] Re: GLSL Shader in Volumizer In-Reply-To: <017401c5ec72$15d11ce0$15000f86@asiapac.sgi.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_8478_11330127.1132757182861" References: <017401c5ec72$15d11ce0$15000f86@asiapac.sgi.com> Sender: owner-info-volumizer@els.sgi.com Precedence: bulk Reply-To: info-volumizer@els.sgi.com ------=_Part_8478_11330127.1132757182861 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Praveen, Just want to let you know that I chose the other way you recommended using vzFragmentProgram and change the interpolation mode in the callback and it works. Hopefully we can see this kind of capability in vzFragmentShader in the future volumizer release. -- Kevin On 11/18/05, Praveen Bhaniramka wrote: > > Hi Kevin, > > By outputting texture coordinates, I mean something like - > > gl_FragColor =3D integal.stp; > > You would 'see' the texture coordinates being rendered in rgb. This is > more or less a 'standard' technique for debugging fragment shaders right > now until we find a better way of doing this :( > > Volumizer actually does support slicing tetrahedra as well as directly > slicing the cuboidal geometry. However, slicing tetrahedral grids is > good for performance reasons. It also provides a good generality for > handling more complex geometry types, if say you want to do empty space > leaping using tetrahedral meshes, etc. > > Thanks. > Praveen > > -----Original Message----- > From: owner-info-volumizer@els.sgi.com > [mailto:owner-info-volumizer@els.sgi.com] On Behalf Of Kevin Wang > Sent: Thursday, November 17, 2005 12:46 PM > To: info-volumizer@els.sgi.com > Subject: Re: [info-volumizer] Re: GLSL Shader in Volumizer > > > Hi Praveen, > > Since the texture coodinates are generated in shading program, how can I > output them to screen? Also I am curious that inside Volumizer > programming guide, it says that tmrender actions uses the tetrahedron as > the basic unit for representing volumetric geometry and then do sorting > and slicing on these tetrahedron, what is the benefit of doing this > compared to just slicing on the cubic geometry. in that case you dont > need to do sorting and slicing is much easier. > > Thanks, > > -- Kevin > > > On 11/15/05, Praveen Bhaniramka wrote: > Hi Kevin, > > It is strange that the GLSL shader gives you linear interpolation even > after rounding the texture coordinates to the nearest neighbour texel's > coordinates. I guess, you might need to do some more debugging to make > sure that the texture coordinates are being computed correctly. One > simple way is to output the texture coordinates to the screen and see if > they look like they are nearest neighbour or linear interpolated. > > Yeah... I did a quick check as well and it does not look like we provide > any way to specify GL texture parameter settings when using > TMFragmentShader class. > > - Praveen > -----Original Message----- > From: owner-info-volumizer@els.sgi.com [mailto: > owner-info-volumizer@els.sgi.com] On Behalf Of Kevin Wang > > Sent: Tuesday, November 15, 2005 10:49 PM > To: info-volumizer@els.sgi.com > Subject: Re: [info-volumizer] Re: GLSL Shader in Volumizer > > > Hi Praveen, > > I tried your code, still gives me linear interpolation effect. Also you > have mentioned that using vzTMFragmentProgram I can set callbacks and > change the interpolation mode there. but you are not sure about > vzTMFragmentShader. I checked sgi documentation. It seems there is no > way to set callback for vzTMFragmentShader. Just want to let you know > that. > > Regards, > > -- Kevin > > > On 11/10/05, Praveen Bhaniramka wrote: > I wonder what could be wrong with the GLSL shader. It seems pretty > simple. Can you try using vector operations instead of scalar ones that > you are using right now? So, your shader might look like - > > "vec3 coordinates, delta, integal;\n" > "coordinates =3D vec3(volume_TexCoord) * volume_TexDims;\n" > "delta =3D floor(coordinates);\n" > "integal =3D (delta) / volume_TexDims;\n" > "color =3D texture3D(volume,integal.stp);\n" > > This should also be more efficient and hopefully less liable to shader > compilation issues in the drivers. > > No, we haven't implemented GPU-based ray casting in Volumizer yet. There > are issues with the technique which might not allow it to work in real > applications, e.g. mixing polygonal geometry with the rendering, etc. It > is definitely something that we are thinking of doing in the future, but > so far, GPU ray casting is a good research prototype IMHO. > > Cheers, > Praveen > > -----Original Message----- > From: owner-info-volumizer@els.sgi.com > [mailto: owner-info-volumizer@els.sgi.com ] On Behalf Of Kevin Wang > Sent: Thursday, November 10, 2005 8:56 PM > To: praveenb@sgi.com; info-volumizer@els.sgi.com > Subject: [info-volumizer] Re: Cg support in OpenGL multipipe > > > Hi, > > I did not get any compilation errors. I set $VOLUMIZER_DEBUG_LEVEL to 5 > to see all the debug info and I can see nothing wrong. > > Well, maybe early ray termination is not a good idea for 3D texture > mapping. Do you guys have a plan to implement GPU based ray casting in > Volumizer? > > -- Kevin > > > On 11/10/05, Praveen Bhaniramka wrote: > Not sure what is going on. Do you get any errors from Volumizer about > the shader compilation? If the shader does not compile, Volumizer will > give you an error. > > Volumizer will always use back-to-front slicing based on the transform > matrices set by the application. So, mucking with the matrices might not > really help. I will try and think about some other solution for you as > well. > > - Praveen > -----Original Message----- > From: Kevin Wang [mailto: kwang22@gmail.com] > > Sent: Thursday, November 10, 2005 1:17 AM > To: praveenb@sgi.com > Subject: Re: Cg support in OpenGL multipipe > > > Hi Praveen, > > Thanks for your ideas. > > I have tried your second recommendation regarding interpolation mode > using the following GLSL program. > > "vec3 coordinates, delta, integal;\n" > " coordinates.s =3D volume_TexCoord.s * volume_TexDims.x;\n" > "coordinates.t =3D volume_TexCoord.t * volume_TexDims.y;\n" > "coordinates.p =3D volume_TexCoord.p * volume_TexDims.z;\n" > "delta.s =3D floor( coordinates.s);\n" > "delta.t =3D floor(coordinates.t);\n" > "delta.p =3D floor(coordinates.p);\n" > "integal.s =3D (delta.s ) / volume_TexDims.x;\n" > "integal.t =3D (delta.t ) / volume_TexDims.y;\n" > "integal.p =3D (delta.p ) / volume_TexDims.z;\n" > "color =3D texture3D(volume,integal.stp);\n" > > Originally the code is > "color =3D texture3D(volume,volume_TexCoord.stp);\n" > > Now the problem is that nothing shows up in my program. Since I am new > to GLSL so I wonder if you can test this code for me. Thanks in advance. > > As regard to empty space leaping, I think your idea is good but usually > out data (maily medical imaging data) have very few empty spaces so I > would not pursue in that direction. Early ray termination uses different > rendering order and that is really a problem. Do you think if it is > possible to render the volume in the opposite direction so that the > rendering order will be changed to front to back in volumizer? this > needs to change modelviewproject matrix and manipulate the depth test. I > have not thought carefully about this. and it can be too complicated in > practice. > > -- Kevin > > > > > On 11/8/05, Praveen Bhaniramka wrote: > Kevin, > > I am not sure if you can change the interpolation filter in > TMFragmentShader or not. You should try using the callbacks and see if > they do the right thing for you. Another option would be to compute the > "integral" texture coordinates in the fragment shader and then use them > to sample the textures that you want to be NEAREST filtered. You can do > somehting like - > vec3 coordinates =3D volume_TexCoord * volume_TexDims; > vec3 delta =3D fract(coordinates); > vec3 integal =3D (coordinates - delta) / volume_TexDims; > > Yeah... I am sure that there are ways to improve the texture rendering > using early ray termination and empty space leaping with Volumizer. You > are right that 3D texture rendering is brute force in the sense that it > slices the complete volume and renders the data. One easy way to > implement empty space leaping is to compute a bounding geometry of the > volume data that you know is visible and "cut-out", using geometry, the > > data that is not visible. Then use this bounding geometry for rendering > the volume data set. That should improve the performance a bit. I am > sure that early ray termination etc is also possible,.. I just haven't > thought about that a lot. One potential issue there is that Volumizer > currently does back-to-front rendering and early ray termination is > typically useful for front-to-back rendering. Front-to-back rendering > has other issues with embedded polygonal geometry in the same scene, > etc. > > Let me know if you have other ideas or questions. > > - Praveen > > -----Original Message----- > From: Kevin Wang [mailto: kwang22@gmail.com] > > Sent: Wednesday, November 09, 2005 3:11 AM > To: praveenb@sgi.com > Subject: Re: Cg support in OpenGL multipipe > > > Hi Praveen, > > Thanks for your reply. I am using vzTMFragmentShader class, is it > possible to change interpolation mode for it? > > Also I am thinking about ways to improve either quality or speed of > volumizer. do you think it is possible to implement technique like early > ray termination for volumizer so that only a fraction of the slices need > > to be rendered ( when the opacity reaches 1 then set Z buffer and using > depth test to by pass rendering) ? As I understand, 3D texture mapping > slices the volume and renders all the slices. > > Regards, > > -- Kevin > > > On 11/5/05, Praveen Bhaniramka wrote: > Hi Kevin, > > Currently, it is not possible to change the interpolation mode in > Volumizer for the built-in shaders (LUT, Gradient, Tag, etc). The > interpolation mode is set to be GL_LINEAR for all > vzParameterVolumeTexture's and GL_NEAREST for all > vzParameterLookupTable's used in the shader. > > However, if you are using vzTMFragmentProgram shader, Volumizer provides > > you callbacks for binding your various textures. In those callbacks, > after you bind the volume texture (by using the bindVolumeTextureCB > function), you set the interpolation modes using the glTexParameteri() > commands. > > - Praveen > > -----Original Message----- > From: Kevin Wang [mailto: kwang22@gmail.com] > > Sent: Saturday, November 05, 2005 1:51 AM > To: praveenb@sgi.com > Subject: Re: Cg support in OpenGL multipipe > > > Praveen, > > Sorry I did not mean to use Cg compiler. I mean similarly it would apply > to a GLSL compiler. anyway, it is not urgent now. > > I have got a new question for you now. I know volumizer uses 3D texture > mapping technique. and when using it, usually we need to specify the > interpolation mode during the texture setup. I wonder if there is a way > i can change this mode during rendering with Volumizer? below is the > OpenGL code to set up the interpolation mode. I want to use nearest > neighbor mode in certain situations. > > glTexParameteri(GL_TEXTURE_3D_EXT, GL_TEXTURE_MIN_FILTER, GL_LINEAR); > glTexParameteri(GL_TEXTURE_3D_EXT, GL_TEXTURE_MAX_FILTER, GL_LINEAR); > > Look forward to your response. Thanks. > > -- Kevin > > > On 11/4/05, Praveen Bhaniramka wrote: > I am not sure if Cg compiler provides the option of converting GLSL to > ARB_fragment_program. > > - Praveen > -----Original Message----- > From: Kevin Wang [mailto: kwang22@gmail.com] > > Sent: Friday, November 04, 2005 8:41 PM > To: praveenb@sgi.com > Subject: Re: Cg support in OpenGL multipipe > > > Hi Praveen, > > Thanks for your response. Yes, I am using Propack 3 and we dont > anticipate a system upgrade within the next half year. since the code is > still in development stage, i guess we can wait for a while for the > upgrade. > > Interesting that Cg program can be convert into a ARB_Fragment_program. > then I would assume that so does GLSL program. I will look into that > matter. > > Regards, > > -- Kevin > > > On 11/4/05, Praveen Bhaniramka wrote: > Hi Kevin, > > I am pretty sure that OpenGL Multipipe does not support Cg. The simple > reason is that Prism does not support Cg and OpenGL Multipipe can only > run on Prism! Actually, I got the following response from Guy, who is > the tech lead on OMP. > > "OMP will support GLSL only with Propack 4 SP3. About performance > improvement with OMP, if the app is fill limited (as I assume it should > be) then OMP should scale the perfirmance." > > I would imagine that your Prism is currently running ProPack 3.x. So in > order to use GLSL, you would need to use PP4 SP3 (which will be > available in December AFAIK). For now, your best bet is to use > ARB_fragment_program in Volumizer. You can still use Cg by running the > Cg compiler and passing it your Cg program and asking it to convert the > Cg program to ARB_fragment_program. You can then pass the fragment > program to Volumizer directly. > > (Sorry for the delay in replying... I was travelling last week and > earlier this week) > > hth, > Praveen > > -----Original Message----- > From: Kevin Wang [mailto:kwang22@gmail.com] > Sent: Monday, October 24, 2005 9:57 PM > To: Saurabh Gupta; Praveen Bhaniramka > Subject: Cg support in OpenGL multipipe > Importance: Low > > > Hi Saurabh and Praveen, > > Do you guys know that if OpenGL multipipe supports Cg shading language? > We have a custom developed raycasting volume rendering software package > which uses opengl shading language. Praveen said that OMP doesnot > support OpenGL shading language so I was wondering if it supports Cg or > other high level shading language. and if possible, will the next > release support OpenGL shading language? > > Regards, > > -- Kevin > > ------=_Part_8478_11330127.1132757182861 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Praveen,

Just want to let you know that I chose the other way you recommended using vzFragmentProgram and change the interpolation mode in the callback and it works. Hopefully we can see this kind of capability in vzFragmentShader in the future volumizer release.

-- Kevin

On 11/18/05, Praveen Bhaniramka <praveenb@sgi.com> wrote:
Hi Kevin,

By outputting texture coordinates, I mean something like -=

        gl_FragColor =3D in= tegal.stp;

You would 'see' the texture coordinates being rendered in= rgb. This is
more or less a 'standard' technique for debugging fragment= shaders right
now until we find a better way of doing this :(

Volumizer actual= ly does support slicing tetrahedra as well as directly
slicing the cuboi= dal geometry. However, slicing tetrahedral grids is
good for performance= reasons. It also provides a good generality for
handling more complex geometry types, if say you want to do empty space=
leaping using tetrahedral meshes, etc.

Thanks.
Praveen
-----Original Message-----
From: owner-info-volumizer@els.sgi.com
[mailto:owner-info-volumizer@els.sgi.com] On Behalf Of= Kevin Wang
Sent: Thursday, November 17, 2005 12:46 PM
To: info-volumizer@els.sgi.com
Subject: Re: [info-volumizer] Re: GLSL Sh= ader in Volumizer


Hi Praveen,

Since the texture coodinate= s are generated in shading program, how can I
output them to screen? Als= o I am curious that inside Volumizer
programming guide, it says that tmrender actions uses the tetrahedron a= s
the basic unit for representing volumetric geometry and then do sortin= g
and slicing on these tetrahedron, what is the benefit of doing this
compared to just slicing on the cubic geometry. in that case you dontneed to do sorting and slicing is much easier.

Thanks,

-- K= evin


On 11/15/05, Praveen Bhaniramka < praveenb@sgi.com> wrote:
Hi Kevin,

It is strange that the = GLSL shader gives you linear interpolation even
after rounding the textu= re coordinates to the nearest neighbour texel's
coordinates. I guess, yo= u might need to do some more debugging to make
sure that the texture coordinates are being computed correctly. One
= simple way is to output the texture coordinates to the screen and see ifthey look like they are nearest neighbour or linear interpolated.

Yeah... I did a quick check as well and it does not look like we provideany way to specify GL texture parameter settings when using
TMFragmentS= hader class.

- Praveen
-----Original Message-----
From: owner-info-volumizer@els.sgi.com [mailto:
owner-info-volumizer@els.sgi.com] On Behalf O= f Kevin Wang

Sent: Tuesday, November 15, 2005 10:49 PM
To: info-volumizer@els.sgi.com
Subject: Re: [info-volumizer] Re: GLSL Sh= ader in Volumizer


Hi Praveen,

I tried your code, still gi= ves me linear interpolation effect. Also you
have mentioned that using v= zTMFragmentProgram I can set callbacks and
change the interpolation mode there. but you are not sure about
vzTM= FragmentShader. I checked sgi documentation. It seems there is no
way to= set callback for vzTMFragmentShader. Just want to let you know
that.

Regards,

-- Kevin


On 11/10/05, Praveen Bhaniramka= <praveenb@sgi.com> wrote:I wonder what could be wrong with the GLSL shader. It seems pretty
simp= le. Can you try using vector operations instead of scalar ones that
you are using right now? So, your shader might look like -

"= ;vec3 coordinates, delta, integal;\n"
"coordinates =3D vec3(vo= lume_TexCoord) * volume_TexDims;\n"
"delta =3D floor(coordinat= es);\n"
"integal =3D (delta) / volume_TexDims;\n"
"color =3D = texture3D(volume,integal.stp);\n"

This should also be more effi= cient and hopefully less liable to shader
compilation issues in the driv= ers.

No, we haven't implemented GPU-based ray casting in Volumizer yet. = There
are issues with the technique which might not allow it to work in = real
applications, e.g. mixing polygonal geometry with the rendering, et= c. It
is definitely something that we are thinking of doing in the future, bu= t
so far, GPU ray casting is a good research prototype IMHO.

Chee= rs,
Praveen

-----Original Message-----
From: owner-info-volumizer@els.sgi.com
[mailto: owner-info-volumizer@els.sgi.com ] On Behalf = Of Kevin Wang
Sent: Thursday, November 10, 2005 8:56 PM
To: praveenb@sgi.com; info-vo= lumizer@els.sgi.com
Subject: [info-volumizer] Re: Cg support in Open= GL multipipe


Hi,

I did not get any compilation errors. I = set $VOLUMIZER_DEBUG_LEVEL to 5
to see all the debug info and I can see nothing wrong.

Well, may= be early ray termination is not a good idea for 3D texture
mapping. Do y= ou guys have a plan to implement GPU based ray casting in
Volumizer?

-- Kevin


On 11/10/05, Praveen Bhaniramka <praveenb@sgi.com> wrote:
Not sure what i= s going on. Do you get any errors from Volumizer about
the shader compil= ation? If the shader does not compile, Volumizer will
give you an error.

Volumizer will always use back-to-front slici= ng based on the transform
matrices set by the application. So, mucking w= ith the matrices might not
really help. I will try and think about some = other solution for you as
well.

- Praveen
-----Original Message-----
From: Kevin Wan= g [mailto: kwang22@gmail.com]
<= br>Sent: Thursday, November 10, 2005 1:17 AM
To: praveenb@sgi.com
Subject: Re: Cg support in OpenGL multipipe

=
Hi Praveen,

Thanks for your ideas.

I have tried your seco= nd recommendation regarding interpolation mode
using the following GLSL = program.

"vec3 coordinates, delta, integal;\n"
" coordinat= es.s =3D volume_TexCoord.s * volume_TexDims.x;\n"
"coordinates= .t =3D volume_TexCoord.t * volume_TexDims.y;\n"
"coordinates.p =3D volume_TexCoord.p * volume_TexDims.z;\n"
"delta.s =3D flo= or( coordinates.s);\n"
"delta.t =3D floor(coordinates.t);\n&qu= ot;
"delta.p =3D floor(coordinates.p);\n"
"integal.s = =3D (delta.s ) / volume_TexDims.x;\n"
"integal.t =3D (delta.t ) / volume_T= exDims.y;\n"
"integal.p =3D (delta.p ) / volume_TexDims.z;\n&q= uot;
"color =3D texture3D(volume,integal.stp);\n"

Origi= nally the code is
"color =3D texture3D(volume,volume_TexCoord.stp);\n"

N= ow the problem is that nothing shows up in my program. Since I am new
to= GLSL so I wonder if you can test this code for me. Thanks in advance.

As regard to empty space leaping, I think your idea is good but usually=
out data (maily medical imaging data) have very few empty spaces so Iwould not pursue in that direction. Early ray termination uses different
rendering order and that is really a problem. Do you think if it is
= possible to render the volume in the opposite direction so that the
rend= ering order will be changed to front to back in volumizer? this
needs to= change modelviewproject matrix and manipulate the depth test. I
have not thought carefully about this. and it can be too complicated in=
practice.

-- Kevin




On 11/8/05, Praveen Bhanir= amka <praveenb@sgi.com> wrote= :
Kevin,

I am not sure if you can change the interpolation filter = in
TMFragmentShader or not. You should try using the callbacks and see i= f
they do the right thing for you. Another option would be to compute th= e
"integral" texture coordinates in the fragment shader and the= n use them
to sample the textures that you want to be NEAREST filtered. = You can do
somehting like -
    vec3 coordinates = =3D volume_TexCoord * volume_TexDims;
    vec3 delta =3D fract(coordinates);
 &nb= sp;  vec3 integal =3D (coordinates - delta) / volume_TexDims;
=
Yeah... I am sure that there are ways to improve the texture rendering<= br>using early ray termination and empty space leaping with Volumizer. You
are right that 3D texture rendering is brute force in the sense that it=
slices the complete volume and renders the data. One easy way to
imp= lement empty space leaping is to compute a bounding geometry of the
volume data that you know is visible and "cut-out", using geometr= y,  the

data that is not visible. Then use this bounding g= eometry for rendering
the volume data set. That should improve the perfo= rmance a bit. I am
sure that early ray termination etc is also possible,.. I just haven't<= br>thought about that a lot. One potential issue there is that Volumizercurrently does back-to-front rendering and early ray termination is
typically useful for front-to-back rendering. Front-to-back rendering
ha= s other issues with embedded polygonal geometry in the same scene,
etc.<= br>
Let me know if you have other ideas or questions.

- Praveen

-----Original Message-----
From: Kevin Wang [mailto: kwang22@gmail.com]

Sent: Wednesday, No= vember 09, 2005 3:11 AM
To: praveenb= @sgi.com
Subject: Re: Cg support in OpenGL multipipe


Hi Praveen,<= br>
Thanks for your reply. I am using vzTMFragmentShader class, is itpossible to change interpolation mode for it?

Also I am thinking ab= out ways to improve either quality or speed of
volumizer. do you think it is possible to implement technique like earl= y
ray termination for volumizer so that only a fraction of the slices ne= ed

to be rendered ( when the opacity reaches 1 then set Z buffer and= using
depth test to by pass rendering) ? As I understand, 3D texture mapping<= br>slices the volume and renders all the slices.

Regards,

-- = Kevin


On 11/5/05, Praveen Bhaniramka < praveenb@sgi.com> wrote:
Hi Kevin,

Currently, it is not po= ssible to change the interpolation mode in
Volumizer for the built-in sh= aders (LUT, Gradient, Tag, etc). The
interpolation mode is set to be GL_= LINEAR for all
vzParameterVolumeTexture's and GL_NEAREST for all
vzParameterLookupT= able's used in the shader.

However, if you are using vzTMFragmentPro= gram shader, Volumizer provides

you callbacks for binding your vario= us textures. In those callbacks,
after you bind the volume texture (by using the bindVolumeTextureCB
= function), you set the interpolation modes using the glTexParameteri()
c= ommands.

- Praveen

-----Original Message-----
From: Kevin = Wang [mailto:=20 kwang22@gmail.com]

Sent: Sa= turday, November 05, 2005 1:51 AM
To: praveenb@sgi.com
Subject: Re: Cg support in OpenGL multipipe

Praveen,

Sorry I did not mean to use Cg compiler. I mean similar= ly it would apply
to a GLSL compiler. anyway, it is not urgent now.
<= br>I have got a new question for you now. I know volumizer uses 3D texture
mapping technique. and when using it, usually we need to specify theinterpolation mode during the texture setup. I wonder if there is a wayi can change this mode during rendering with Volumizer? below is the
OpenGL code to set up the interpolation mode. I want to use nearest
neig= hbor mode in certain situations.

glTexParameteri(GL_TEXTURE_3D_EXT, = GL_TEXTURE_MIN_FILTER, GL_LINEAR);
glTexParameteri(GL_TEXTURE_3D_EXT, GL= _TEXTURE_MAX_FILTER, GL_LINEAR);

Look forward to your response. Thanks.

-- Kevin


O= n 11/4/05, Praveen Bhaniramka <prave= enb@sgi.com > wrote:
I am not sure if Cg compiler provides the op= tion of converting GLSL to
ARB_fragment_program.

- Praveen
-----Original Message-----From: Kevin Wang [mailto: kwang22@gma= il.com]

Sent: Friday, November 04, 2005 8:41 PM
To: praveenb@sgi.com
Subject: Re: Cg support in OpenGL multipipe

=
Hi Praveen,

Thanks for your response. Yes, I am using Propack 3 = and we dont
anticipate a system upgrade within the next half year. since= the code is
still in development stage, i guess we can wait for a while for the
= upgrade.

Interesting that Cg program can be convert into a ARB_Fragm= ent_program.
then I would assume that so does GLSL program. I will look = into that
matter.

Regards,

-- Kevin


On 11/4/05, Praveen = Bhaniramka <praveenb@sgi.com >= ; wrote:
Hi Kevin,

I am pretty sure that OpenGL Multipipe does no= t support Cg. The simple
reason is that Prism does not support Cg and OpenGL Multipipe can only<= br>run on Prism! Actually, I got the following response from Guy, who isthe tech lead on OMP.

"OMP will support GLSL only with Propack= 4 SP3. About performance
improvement with OMP, if the app is fill limited (as I assume it should=
be) then OMP should scale the perfirmance."

I would imagine= that your Prism is currently running ProPack 3.x. So in
order to use GL= SL, you would need to use PP4 SP3 (which will be
available in December AFAIK). For now, your best bet is to use
ARB_f= ragment_program in Volumizer. You can still use Cg by running the
Cg com= piler and passing it your Cg program and asking it to convert the
Cg pro= gram to ARB_fragment_program. You can then pass the fragment
program to Volumizer directly.

(Sorry for the delay in replying.= .. I was travelling last week and
earlier this week)

hth,
Prav= een

-----Original Message-----
From: Kevin Wang [mailto: kwang22@gmail.com]
Sent: Monday, October 24, 2005 9:57 PM
To: Sau= rabh Gupta; Praveen Bhaniramka
Subject: Cg support in OpenGL multipipeImportance: Low


Hi Saurabh and Praveen,

Do you guys kno= w that if OpenGL multipipe supports Cg shading language?
We have a custom developed raycasting volume rendering software package=
which uses opengl shading language. Praveen said that OMP doesnot
su= pport OpenGL shading language so I was wondering if it supports Cg or
other high level shading language. and if possible, will the next
releas= e support OpenGL shading language?

Regards,

-- Kevin

<= /blockquote>

------=_Part_8478_11330127.1132757182861-- From info-volumizer-owner@els.sgi.com Mon Dec 5 20:24:15 2005 Received: (from majordom@localhost) by els.sgi.com (8.12.10/8.12.2/els-2.2) id jB64Mmja9408298; Mon, 5 Dec 2005 20:22:48 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.200]) by els.sgi.com (8.12.10/8.12.2/els-2.2) with ESMTP id jB5KGpJT9422635 for ; Mon, 5 Dec 2005 12:16:52 -0800 (PST) Received: by wproxy.gmail.com with SMTP id 57so827026wri for ; Mon, 05 Dec 2005 12:16:47 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=PtzItQ3ce0tQ6k6bcfgOHN44/ggzkLwtNQTV50AezUJqVIioirfSXZpF+8GFPX5IGHV1afSUG1cwdMzLzEMMKH2BZDt58zD1hD90+6WjVw7FJTSP1YzH/XWtZMUMqoFVFV+3+yXEgbWDMUaaXYlGC8/Kir/3J56C0HDv1akzZUs= Received: by 10.65.236.11 with SMTP id n11mr1223162qbr; Mon, 05 Dec 2005 12:16:46 -0800 (PST) Received: by 10.65.155.20 with HTTP; Mon, 5 Dec 2005 12:16:46 -0800 (PST) Message-ID: Date: Mon, 5 Dec 2005 15:16:46 -0500 From: Kevin Wang To: Praveen Bhaniramka , info-volumizer@els.sgi.com Subject: [info-volumizer] How to disable outline boundary display MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_45093_7581995.1133813806718" Sender: owner-info-volumizer@els.sgi.com Precedence: bulk Reply-To: info-volumizer@els.sgi.com ------=_Part_45093_7581995.1133813806718 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi List and Praveen, I have searched the documentation and the info list and cannot find the answer. How do I disable the outline boundary of a volume from displaying? It doesnot look good in my application since we have our own outline displa= y class for that purpose. Thanks. -- Kevin ------=_Part_45093_7581995.1133813806718 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi List and Praveen,

I have searched the documentation and the info list and cannot find the answer. How do I disable the outline boundary of a volume from displaying? It doesnot look good in my application since we have our own outline display class for that purpose. Thanks.

-- Kevin
------=_Part_45093_7581995.1133813806718-- From info-volumizer-owner@els.sgi.com Mon Dec 5 20:55:05 2005 Received: (from majordom@localhost) by els.sgi.com (8.12.10/8.12.2/els-2.2) id jB64sbiC9408959; Mon, 5 Dec 2005 20:54:37 -0800 (PST) Received: from internal-mail-relay1.corp.sgi.com (internal-mail-relay1.corp.sgi.com [198.149.32.52]) by els.sgi.com (8.12.10/8.12.2/els-2.2) with ESMTP id jB64cPJT9430612 for ; Mon, 5 Dec 2005 20:38:25 -0800 (PST) Received: from mtv-atc-013e--n.corp.sgi.com (mtv-atc-013e--n.corp.sgi.com [192.26.78.50]) by internal-mail-relay1.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jB64g3AQ77889143 for ; Mon, 5 Dec 2005 20:42:03 -0800 (PST) Received: from praveenlaptop (134.14.90.82 [134.14.90.82]) by mtv-atc-013e--n.corp.sgi.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id YHSJKPKL; Mon, 5 Dec 2005 20:38:25 -0800 From: "Praveen Bhaniramka" To: Subject: RE: [info-volumizer] How to disable outline boundary display Date: Tue, 6 Dec 2005 10:08:17 +0530 Message-ID: <005f01c5fa1e$e4c0a340$525a0e86@asiapac.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Importance: Normal Sender: owner-info-volumizer@els.sgi.com Precedence: bulk Reply-To: info-volumizer@els.sgi.com Hi Kevin, Can you please be specific? Are you talking about the wireframe boundary around the volume data? That is not rendered by Volumizer and is typically done by the application itself. You should have access to the source where this is done and simply remove it! Or are you talking about something else? If you look at the VTK sample code (TMViewer.cxx under src/apps/VTK), that shows how to use VTK's vtkOutlineFilter to render the outline for the volume data. The vtkVolumeTextureMapper3D class simply renders the volume data using Volumizer. Cheers, Praveen -----Original Message----- From: owner-info-volumizer@els.sgi.com [mailto:owner-info-volumizer@els.sgi.com] On Behalf Of Kevin Wang Sent: Tuesday, December 06, 2005 1:47 AM To: Praveen Bhaniramka; info-volumizer@els.sgi.com Subject: [info-volumizer] How to disable outline boundary display Hi List and Praveen, I have searched the documentation and the info list and cannot find the answer. How do I disable the outline boundary of a volume from displaying? It doesnot look good in my application since we have our own outline display class for that purpose. Thanks. -- Kevin From info-volumizer-owner@els.sgi.com Sat Dec 10 22:10:50 2005 Received: (from majordom@localhost) by els.sgi.com (8.12.10/8.12.2/els-2.2) id jBB69Uet037092; Sat, 10 Dec 2005 22:09:30 -0800 (PST) Received: from surfboard.ka.sara.nl (surfboard.ka.sara.nl [145.100.6.3]) by els.sgi.com (8.12.10/8.12.2/els-2.2) with ESMTP id jB88cJJT9335829 for ; Thu, 8 Dec 2005 00:38:20 -0800 (PST) Received: from [145.100.25.205] ([145.100.25.205] RDNS failed) by surfboard.ka.sara.nl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Dec 2005 09:38:15 +0100 Message-ID: <4397F120.5090200@sara.nl> Date: Thu, 08 Dec 2005 09:38:56 +0100 From: Jeroen Akershoek Organization: SARA User-Agent: Debian Thunderbird 1.0.2 (X11/20050602) X-Accept-Language: en-us, en MIME-Version: 1.0 To: info-volumizer@els.sgi.com Subject: [info-volumizer] Animating multiple volumes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Dec 2005 08:38:15.0608 (UTC) FILETIME=[BB6C7B80:01C5FBD2] Sender: owner-info-volumizer@els.sgi.com Precedence: bulk Reply-To: info-volumizer@els.sgi.com Hello, In my application I'm using a fragment shader and data from two (same-sized) time-varying volumes to render a final volume. I've got all the data in local memory (2x 60 volumes, 128^3 luminance8) and every second I'm copying the next volume to shared memory. Then I do a setDataPtr to my vzShape to force it to load to texture memory. My shader basically does the following: It has 3 LUTs defined. If the value of volume1 is above 0.3 it uses LUT1, if the value of volume2 is above 0.3 it uses LUT2 and if both are above 0.3 it uses LUT3 I'm seeing some syncing problems occuring when rendering this. With LUT1 being black-to-white and LUT2 being black-to-blue for example I'm seeing my white voxels being updated and then, less than a second after, my blue voxels following. I made sure my renderaction doesn't do a draw() during memcpy() from my main application process, but it still seems like it's rendering when the volume is not (completely) updated sometimes. Is this a caching/scheduling thing of the OS or graphics driver, or am I doing something else wrong? And is using one vzShape where I update the data-ptr all the time the best way to do time-varying volumes like this? Normal operation for this application is multi-pipe CAVE, but I also see the out-of-sync in single-process mode. Machinetype is Onyx4 with FGL-X2, Volumizer 2.8 Thanks, Jeroen -- Jeroen Akershoek SARA - High Performance Computing & Visualisation dep. tel: +31 20 5923000 fax: +31 20 6683167 Draco dormiens nunquam titillandus From info-volumizer-owner@els.sgi.com Sat Dec 10 22:10:50 2005 Received: (from majordom@localhost) by els.sgi.com (8.12.10/8.12.2/els-2.2) id jBB69Vio037109; Sat, 10 Dec 2005 22:09:31 -0800 (PST) Received: from web10910.mail.bbt.yahoo.co.jp (web10910.mail.bbt.yahoo.co.jp [202.93.86.27]) by els.sgi.com (8.12.10/8.12.2/els-2.2) with SMTP id jBALDux3033721 for ; Sat, 10 Dec 2005 13:13:58 -0800 (PST) Received: (qmail 1589 invoked by uid 60001); 10 Dec 2005 21:13:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=yj20050223; d=yahoo.co.jp; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type; b=fTCbSYb6s1YFTLuxnF2wZZtu0h2lEwRzC29B8y9fsoqrMvvpigZuYZR0fIyhZ9H6nWvmfRaM8OxXk870sbBUQ3rlY/sJpfoeBrDj/RbTFrKP770ilWUXOGK1b1mDTTPc ; Message-ID: <20051210211354.1587.qmail@web10910.mail.bbt.yahoo.co.jp> Received: from [219.8.140.72] by web10910.mail.bbt.yahoo.co.jp via HTTP; Sun, 11 Dec 2005 06:13:54 JST Date: Sun, 11 Dec 2005 06:13:54 +0900 (JST) From: yoshimoto Subject: [info-volumizer] For example case "pguide" To: info-volumizer@els.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Sender: owner-info-volumizer@els.sgi.com Precedence: bulk Reply-To: info-volumizer@els.sgi.com When I run this case ,I have error like that "vzloaders.dll is not correct Windows image in japanese". Could you please give me your advice or give me your vzloaders.dll. OS:Windows2000(japanese version) Best regards, Yuji Yoshimoto From info-volumizer-owner@els.sgi.com Sat Dec 10 22:13:00 2005 Received: (from majordom@localhost) by els.sgi.com (8.12.10/8.12.2/els-2.2) id jBB6Ci3f037158; Sat, 10 Dec 2005 22:12:44 -0800 (PST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.203]) by els.sgi.com (8.12.10/8.12.2/els-2.2) with ESMTP id jB6KojJT5988876 for ; Tue, 6 Dec 2005 12:50:46 -0800 (PST) Received: by zproxy.gmail.com with SMTP id s1so200580nze for ; Tue, 06 Dec 2005 12:50:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=ebLSwyTuVoJodLViXDj6h9Dx1MYk9zD+G2oeng7ZlSYlD1O6ms1RC+CvPlw1V9SETbSW9nKom4OeG9NUiMRD7lVeH8ELm5GuO3x7+CT7fmFJKrSMZYWYIXEB5U+GNdRorAsIIROc6Xnl+IFJ2/aB2rbvXyDjzrz3MZDRx9r87Lg= Received: by 10.65.59.4 with SMTP id m4mr1001642qbk; Tue, 06 Dec 2005 12:50:42 -0800 (PST) Received: by 10.65.155.20 with HTTP; Tue, 6 Dec 2005 12:50:41 -0800 (PST) Message-ID: Date: Tue, 6 Dec 2005 15:50:41 -0500 From: Kevin Wang To: info-volumizer@els.sgi.com Subject: Re: [info-volumizer] How to disable outline boundary display In-Reply-To: <005f01c5fa1e$e4c0a340$525a0e86@asiapac.sgi.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_16532_9430872.1133902241414" References: <005f01c5fa1e$e4c0a340$525a0e86@asiapac.sgi.com> Sender: owner-info-volumizer@els.sgi.com Precedence: bulk Reply-To: info-volumizer@els.sgi.com ------=_Part_16532_9430872.1133902241414 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Praveen, Thanks for your information. I am talking about the wireframe boundary and you were right , it is a feature in our application not volumizer. -- Kevin On 12/5/05, Praveen Bhaniramka wrote: > > Hi Kevin, > > Can you please be specific? Are you talking about the wireframe boundary > around the volume data? That is not rendered by Volumizer and is > typically done by the application itself. You should have access to the > source where this is done and simply remove it! Or are you talking about > something else? If you look at the VTK sample code (TMViewer.cxx under > src/apps/VTK), that shows how to use VTK's vtkOutlineFilter to render > the outline for the volume data. The vtkVolumeTextureMapper3D class > simply renders the volume data using Volumizer. > > Cheers, > Praveen > > -----Original Message----- > From: owner-info-volumizer@els.sgi.com > [mailto:owner-info-volumizer@els.sgi.com] On Behalf Of Kevin Wang > Sent: Tuesday, December 06, 2005 1:47 AM > To: Praveen Bhaniramka; info-volumizer@els.sgi.com > Subject: [info-volumizer] How to disable outline boundary display > > > Hi List and Praveen, > > I have searched the documentation and the info list and cannot find the > answer. How do I disable the outline boundary of a volume from > displaying? It doesnot look good in my application since we have our own > outline display class for that purpose. Thanks. > > -- Kevin > > ------=_Part_16532_9430872.1133902241414 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Praveen,

Thanks for your information. I am talking about the wireframe boundary and you were right , it is a feature in our application not volumizer.

-- Kevin

On 12/5/05, Praveen Bhaniramka <praveenb@sgi.com> wrote:
Hi Kevin,

Can you please be specific? Are you talking about the wire= frame boundary
around the volume data? That is not rendered by Volumizer= and is
typically done by the application itself. You should have access= to the
source where this is done and simply remove it! Or are you talking abou= t
something else? If you look at the VTK sample code (TMViewer.cxx under=
src/apps/VTK), that shows how to use VTK's vtkOutlineFilter to render
the outline for the volume data. The vtkVolumeTextureMapper3D class
= simply renders the volume data using Volumizer.

Cheers,
Praveen
-----Original Message-----
From: owner-info-volumizer@els.sgi.com
[mailto:owner-info-volumizer@els.sgi.com] On Behalf Of= Kevin Wang
Sent: Tuesday, December 06, 2005 1:47 AM
To: Praveen Bhan= iramka;=20 info-volumizer@els.sgi.com
Subject: [info-volumizer] How to disable outline boundary display
<= br>
Hi List and Praveen,

I have searched the documentation and th= e info list and cannot find the
answer. How do I disable the outline boundary of a volume from
displ= aying? It doesnot look good in my application since we have our own
outl= ine display class for that purpose. Thanks.

-- Kevin


------=_Part_16532_9430872.1133902241414-- From info-volumizer-owner@els.sgi.com Sat Dec 10 22:40:45 2005 Received: (from majordom@localhost) by els.sgi.com (8.12.10/8.12.2/els-2.2) id jBB6eK7T037411; Sat, 10 Dec 2005 22:40:20 -0800 (PST) Received: from internal-mail-relay.corp.sgi.com (internal-mail-relay.corp.sgi.com [198.149.32.51]) by els.sgi.com (8.12.10/8.12.2/els-2.2) with ESMTP id jBB6WWx3037231 for ; Sat, 10 Dec 2005 22:32:33 -0800 (PST) Received: from mtv-amer002e--3.americas.sgi.com ([192.26.64.114]) by internal-mail-relay.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jBB6WGvD6788003 for ; Sat, 10 Dec 2005 22:32:16 -0800 (PST) Received: from praveenlaptop ([134.15.0.59]) by mtv-amer002e--3.americas.sgi.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 10 Dec 2005 22:32:31 -0800 From: "Praveen Bhaniramka" To: Subject: RE: [info-volumizer] For example case "pguide" Date: Sun, 11 Dec 2005 12:02:30 +0530 Message-ID: <007601c5fe1c$aa4a69b0$3b000f86@asiapac.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <20051210211354.1587.qmail@web10910.mail.bbt.yahoo.co.jp> Importance: Normal X-OriginalArrivalTime: 11 Dec 2005 06:32:32.0031 (UTC) FILETIME=[AA573AF0:01C5FE1C] Sender: owner-info-volumizer@els.sgi.com Precedence: bulk Reply-To: info-volumizer@els.sgi.com Hi Yuji, Can you please send us the exact error message that you are getting? I couldn't find the string you described anywhere. Which application are you trying to run when you get this error message? The vzLoaders library comes with source code which is installed under C:\Program Files\Silicon Graphics\OpenGL Volumizer\src\lib\loaders directory. You might want to try and recompile the DLL and see if you still get this message. Cheers, Praveen > -----Original Message----- > From: owner-info-volumizer@els.sgi.com > [mailto:owner-info-volumizer@els.sgi.com] On Behalf Of yoshimoto > Sent: Sunday, December 11, 2005 2:44 AM > To: info-volumizer@els.sgi.com > Subject: [info-volumizer] For example case "pguide" > > > When I run this case ,I have error like that > "vzloaders.dll is not correct Windows image in japanese". > Could you please give me your advice or give me your > vzloaders.dll. > > OS:Windows2000(japanese version) > > Best regards, > Yuji Yoshimoto > > From info-volumizer-owner@els.sgi.com Sun Dec 11 07:09:36 2005 Received: (from majordom@localhost) by els.sgi.com (8.12.10/8.12.2/els-2.2) id jBBF8bbM041047; Sun, 11 Dec 2005 07:08:37 -0800 (PST) Received: from internal-mail-relay.corp.sgi.com (internal-mail-relay.corp.sgi.com [198.149.32.51]) by els.sgi.com (8.12.10/8.12.2/els-2.2) with ESMTP id jBBF6wx3041180 for ; Sun, 11 Dec 2005 07:06:58 -0800 (PST) Received: from mtv-amer002e--3.americas.sgi.com ([192.26.64.114]) by internal-mail-relay.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jBBF6gvD6945144 for ; Sun, 11 Dec 2005 07:06:42 -0800 (PST) Received: from praveenlaptop ([134.15.0.24]) by mtv-amer002e--3.americas.sgi.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 11 Dec 2005 07:06:57 -0800 From: "Praveen Bhaniramka" To: Subject: RE: [info-volumizer] Animating multiple volumes Date: Sun, 11 Dec 2005 20:36:55 +0530 Message-ID: <00bd01c5fe64$877ba820$3b000f86@asiapac.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <4397F120.5090200@sara.nl> Importance: Normal X-OriginalArrivalTime: 11 Dec 2005 15:06:57.0412 (UTC) FILETIME=[878A9C40:01C5FE64] Sender: owner-info-volumizer@els.sgi.com Precedence: bulk Reply-To: info-volumizer@els.sgi.com Hi Jeroen, The scheme for updating texture data using the setDataPtr() method is the best and the recommended technique with Volumizer. The same would be true if you were updating the LUT as well. Also, your approach of using 1 shape with multiple volume textures seems fine. It is not completely clear what your code is doing and the behaviour you are seeing, but I would try to outline here the set of steps that should be followed to do this properly in a multi-pipe multi-threaded environment. // Main app AppMainLoop() { while(!exit) { // Update the volume data vzParameterVolumeTexture *texture = GetMyVolumeTextureForShape(); void *dataPtr = GetNextTimeStepData(); texture->setDataPtr(dataPtr); // Tell the rendering threads to render now RenderNextFrame(); } } // Draw routine called from different rendering threads Draw() { renderAction->beginDraw(); renderAction->draw(shape); renderAction->endDraw(); } Note in the above : - The setDataPtr() method should be called _once_ from the application thread and NOT from the different rendering threads. - The data is updated by each render action for each pipe only _in_ the beginDraw() method. The similar technique is used by the time-varying sample application module in volview (libvolviewTV.so). You might want to give that a try. Cheers, Praveen > -----Original Message----- > From: owner-info-volumizer@els.sgi.com > [mailto:owner-info-volumizer@els.sgi.com] On Behalf Of Jeroen > Akershoek > Sent: Thursday, December 08, 2005 2:09 PM > To: info-volumizer@els.sgi.com > Subject: [info-volumizer] Animating multiple volumes > > > Hello, > > In my application I'm using a fragment shader and data from two > (same-sized) time-varying volumes to render a final volume. > I've got all the data in local memory (2x 60 volumes, 128^3 > luminance8) > and every second I'm copying the next volume > to shared memory. Then I do a setDataPtr to my vzShape to force it to > load to texture memory. > > My shader basically does the following: > It has 3 LUTs defined. If the value of volume1 is above 0.3 it uses > LUT1, if the value of volume2 is above 0.3 it uses LUT2 and > if both are > above 0.3 it uses LUT3 > > I'm seeing some syncing problems occuring when rendering > this. With LUT1 > being black-to-white and LUT2 being black-to-blue for example > I'm seeing > my white voxels being updated and then, less than a second after, my > blue voxels following. I made sure my renderaction doesn't do a draw() > during memcpy() from my main application process, but it still seems > like it's rendering when the volume is not (completely) > updated sometimes. > > Is this a caching/scheduling thing of the OS or graphics > driver, or am I > doing something else wrong? > And is using one vzShape where I update the data-ptr all the time the > best way to do time-varying volumes like this? > > Normal operation for this application is multi-pipe CAVE, but > I also see > the out-of-sync in single-process mode. > Machinetype is Onyx4 with FGL-X2, Volumizer 2.8 > > Thanks, > Jeroen > > -- > Jeroen Akershoek > SARA - High Performance Computing & Visualisation dep. > tel: +31 20 5923000 fax: +31 20 6683167 > > Draco dormiens nunquam titillandus > From info-volumizer-owner@els.sgi.com Wed Dec 14 21:01:47 2005 Received: (from majordom@localhost) by els.sgi.com (8.12.10/8.12.2/els-2.2) id jBF50bxC122862; Wed, 14 Dec 2005 21:00:37 -0800 (PST) Received: from surfboard.ka.sara.nl (surfboard.ka.sara.nl [145.100.6.3]) by els.sgi.com (8.12.10/8.12.2/els-2.2) with ESMTP id jBEFehx3113006 for ; Wed, 14 Dec 2005 07:40:45 -0800 (PST) Received: from [145.100.25.205] ([145.100.25.205] RDNS failed) by surfboard.ka.sara.nl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Dec 2005 16:40:40 +0100 Message-ID: <43A03CF8.1060009@sara.nl> Date: Wed, 14 Dec 2005 16:40:40 +0100 From: Jeroen Akershoek Organization: SARA User-Agent: Debian Thunderbird 1.0.2 (X11/20050602) X-Accept-Language: en-us, en MIME-Version: 1.0 To: info-volumizer@els.sgi.com Subject: Re: [info-volumizer] Animating multiple volumes References: <00bd01c5fe64$877ba820$3b000f86@asiapac.sgi.com> In-Reply-To: <00bd01c5fe64$877ba820$3b000f86@asiapac.sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Dec 2005 15:40:40.0184 (UTC) FILETIME=[BC725F80:01C600C4] Sender: owner-info-volumizer@els.sgi.com Precedence: bulk Reply-To: info-volumizer@els.sgi.com Praveen Bhaniramka wrote: >// Draw routine called from different rendering threads >Draw() >{ > renderAction->beginDraw(); > renderAction->draw(shape); > renderAction->endDraw(); >} > >Note in the above : >- The setDataPtr() method should be called _once_ from the application >thread and NOT from the different rendering threads. >- The data is updated by each render action for each pipe only _in_ the >beginDraw() method. > > Thanks >The similar technique is used by the time-varying sample application >module in volview (libvolviewTV.so). You might want to give that a try. > > Yes, I ripped some code from that one now. The syncing problem was fixed when I did a manage/unmanage in the renderer (beginning and end of your Draw() so to say). Another problem I ran into was that my volume didn't update after 30 frames (which is, probably not by coincidence, about 64MB of textures). Everything kept running, but it just didn't update. When the renderer had reached the end of the loop (180 in my case) and it started rendering at frame 0 again it updated fine. This problem is fixed now when I do it like in the volview sample, with a vzShape for every timestep, so that's good. The updating with setDataPtr is also not necessary then (which is good cause it segfaulted after 13 frames if I did :) So, everything seems to be going ok and my 1.1GB of volume-data actually renders nicely :) Thanks, Jeroen -- Jeroen Akershoek SARA - High Performance Computing & Visualisation dep. tel: +31 20 5923000 fax: +31 20 6683167 Draco dormiens nunquam titillandus From info-volumizer-owner@els.sgi.com Wed Dec 14 21:01:47 2005 Received: (from majordom@localhost) by els.sgi.com (8.12.10/8.12.2/els-2.2) id jBF50bi7122978; Wed, 14 Dec 2005 21:00:37 -0800 (PST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.204]) by els.sgi.com (8.12.10/8.12.2/els-2.2) with ESMTP id jBEHRkx3114955 for ; Wed, 14 Dec 2005 09:27:46 -0800 (PST) Received: by zproxy.gmail.com with SMTP id 40so138603nzk for ; Wed, 14 Dec 2005 09:27:45 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=GU13aMag5lrJzbu5Z56E3tJMtsLYFZQ14wkFOvi06eUa9SCv27wtEvcQqexEmzlugeqyhvGnK1hQz3A3viHUmpxWrfTPrHnVZolyRVL70HkDIQTUjkGyR4DMPso4sGIv/gsvdX4opqciP7DS9rwi+V6kL7v8IpQCi7a8d9xLW5E= Received: by 10.64.91.18 with SMTP id o18mr597053qbb; Wed, 14 Dec 2005 09:27:44 -0800 (PST) Received: by 10.65.151.13 with HTTP; Wed, 14 Dec 2005 09:27:43 -0800 (PST) Message-ID: Date: Wed, 14 Dec 2005 12:27:44 -0500 From: Kevin Wang To: info-volumizer@els.sgi.com Subject: [info-volumizer] 3D Clip Texture MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_17555_21918127.1134581264083" Sender: owner-info-volumizer@els.sgi.com Precedence: bulk Reply-To: info-volumizer@els.sgi.com ------=_Part_17555_21918127.1134581264083 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi list and Praveen, I am interested in using volumizer's 3D clip texture in VTK. I have already had a modified version of vtkOpenGLVolumeTextureMapper3D for use in VTK. No= w the problem is that I want to use VTK's image reader to read in the 3D clip texture instead of Volumizer's IFL file loader. anyone has done this so far or what is the neccessary steps to do that? Thanks, -- Kevin ------=_Part_17555_21918127.1134581264083 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi list and Praveen,

I am interested in using volumizer's 3D clip te= xture in VTK. I have already had a modified version of vtkOpenGLVolumeTextu= reMapper3D for use in VTK. Now the problem is that I want to use VTK's imag= e reader to read in the 3D clip texture instead of Volumizer's IFL file loa= der. anyone has done this so far or what is the neccessary steps to do that= ?

Thanks,

-- Kevin
------=_Part_17555_21918127.1134581264083-- From info-volumizer-owner@els.sgi.com Thu Dec 15 22:49:02 2005 Received: (from majordom@localhost) by els.sgi.com (8.12.10/8.12.2/els-2.2) id jBG6lR2x119450; Thu, 15 Dec 2005 22:47:27 -0800 (PST) Received: from internal-mail-relay1.corp.sgi.com (internal-mail-relay1.corp.sgi.com [198.149.32.52]) by els.sgi.com (8.12.10/8.12.2/els-2.2) with ESMTP id jBG6hkx3148414 for ; Thu, 15 Dec 2005 22:43:46 -0800 (PST) Received: from mtv-amer002e--3.americas.sgi.com ([192.26.64.114]) by internal-mail-relay1.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jBG6lNAQ81648333 for ; Thu, 15 Dec 2005 22:47:23 -0800 (PST) Received: from praveenlaptop ([134.14.90.82]) by mtv-amer002e--3.americas.sgi.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 15 Dec 2005 22:43:45 -0800 From: "Praveen Bhaniramka" To: Subject: RE: [info-volumizer] 3D Clip Texture Date: Fri, 16 Dec 2005 12:13:41 +0530 Message-ID: <001001c6020c$0e8491b0$525a0e86@asiapac.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: X-OriginalArrivalTime: 16 Dec 2005 06:43:45.0951 (UTC) FILETIME=[101802F0:01C6020C] Sender: owner-info-volumizer@els.sgi.com Precedence: bulk Reply-To: info-volumizer@els.sgi.com Hi Kevin, I have never tried doing this myself. However, in order to accomplish what you need to do, you would probably need to modify VTK's image reader code. The only dependency on the loader that 3D clip-textures impose is that the vzParameterClipTexture class requires you to set a data loader callback which is invoked by the clip-texture's data manager to load a sub-brick in the volume data at a given level of resolution. The data loader callback is of type (as in ParameterClipTexture.h file) - typedef bool (*vzDataLoaderCB)(const int offset[3], const int level, const int dim[3], void *data, void *userData); The callback is passed the offset, level and dimensions of the brick to be loaded and the callback is required to load this region of data into the void *data pointer supplied to the callback. Take a look at the ClipLoader class installed under src\lib\loaders directory. It shows how to setup the clip-texture loader callback and use it to load data into the clip-texture. hth, Praveen -----Original Message----- From: owner-info-volumizer@els.sgi.com [mailto:owner-info-volumizer@els.sgi.com] On Behalf Of Kevin Wang Sent: Wednesday, December 14, 2005 10:58 PM To: info-volumizer@els.sgi.com Subject: [info-volumizer] 3D Clip Texture Hi list and Praveen, I am interested in using volumizer's 3D clip texture in VTK. I have already had a modified version of vtkOpenGLVolumeTextureMapper3D for use in VTK. Now the problem is that I want to use VTK's image reader to read in the 3D clip texture instead of Volumizer's IFL file loader. anyone has done this so far or what is the neccessary steps to do that? Thanks, -- Kevin From info-volumizer-owner@els.sgi.com Mon Dec 19 22:38:30 2005 Received: (from majordom@localhost) by els.sgi.com (8.12.10/8.12.2/els-2.2) id jBK6b0sA224402; Mon, 19 Dec 2005 22:37:00 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.198]) by els.sgi.com (8.12.10/8.12.2/els-2.2) with ESMTP id jBJLonx3208840 for ; Mon, 19 Dec 2005 13:50:51 -0800 (PST) Received: by wproxy.gmail.com with SMTP id i27so1111534wra for ; Mon, 19 Dec 2005 13:50:49 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=skOvbwe+3/JQTZTjhkKI9GIB2BZuayLN8n+ERwUElVLJZ5Dm/L/oPo46LdYBN8tjT6vlK0x6Jatuj8qUHARH516w+Ji0d0HS+nfeNqDWzkteS4oB2Q0fZmYU0hCErBwZzcPmU53h+I+vToks2Wt7n/5wO5Ha4FHVkuovAF9zt+k= Received: by 10.65.157.12 with SMTP id j12mr3557098qbo; Mon, 19 Dec 2005 13:50:47 -0800 (PST) Received: by 10.65.151.13 with HTTP; Mon, 19 Dec 2005 13:50:47 -0800 (PST) Message-ID: Date: Mon, 19 Dec 2005 16:50:47 -0500 From: Kevin Wang To: info-volumizer@els.sgi.com Subject: Re: [info-volumizer] 3D Clip Texture In-Reply-To: <001001c6020c$0e8491b0$525a0e86@asiapac.sgi.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_6596_28149651.1135029047840" References: <001001c6020c$0e8491b0$525a0e86@asiapac.sgi.com> Sender: owner-info-volumizer@els.sgi.com Precedence: bulk Reply-To: info-volumizer@els.sgi.com ------=_Part_6596_28149651.1135029047840 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Praveen, Thanks for your information. I have got another question for you. I tried t= o load a 598x570x621 dataset into volumizer and to my suprise, volumizer does bricking automatically. it divides the data into 9 bricks. the following is the output of volumizer: Volumizer (3): Original volume sizes: (598, 570, 621) Volumizer (3): Number of bricks =3D (3, 3, 3) Volumizer (3): Brick Dimensions: Volumizer (3): X axis =3D 512 64 24 Volumizer (3): Y axis =3D 256 256 60 Volumizer (3): Z axis =3D 512 64 47 so the largest brick is 512x256x512 which is about 64M. the data is in unsigned char type and only one component. but we have an altix3700 with graphics system installed. Volumizer (4): Vendor string =3D ATI Technologies Inc. Volumizer (4): Renderer string =3D Fire GL X2 (FireGL) (GNU_ICD) and I think the texture memory come with 256M with this type of graphics card so i wonder why volumizer compose the bricks in the above way instead of using the whole texture memory. as regard to the previous question, I am trying vtk's lod class first. although it isnot as intelligent as volumizer's 3D clip texture. Using that class, I create 3 lod and each one uses one volumeTextureMapper. so I have = 3 TMRenderActions and 3 shapes in my app. Each manages different level of dataset. I wonder what kind of texture memory managing scheme volumizer use= s in this kind of situation? Since the first and second level fit into the texture memory so will they be swapped out if the third level is larger tha= n the texture memory? If so, how can I make them stay in? Thanks again, -- Kevin On 12/16/05, Praveen Bhaniramka wrote: > > Hi Kevin, > > I have never tried doing this myself. However, in order to accomplish > what you need to do, you would probably need to modify VTK's image > reader code. The only dependency on the loader that 3D clip-textures > impose is that the vzParameterClipTexture class requires you to set a > data loader callback which is invoked by the clip-texture's data manager > to load a sub-brick in the volume data at a given level of resolution. > The data loader callback is of type (as in ParameterClipTexture.h file) > - > > typedef bool (*vzDataLoaderCB)(const int offset[3], const int level, > const int dim[3], void *data, void > *userData); > > The callback is passed the offset, level and dimensions of the brick to > be loaded and the callback is required to load this region of data into > the void *data pointer supplied to the callback. Take a look at the > ClipLoader class installed under src\lib\loaders directory. It shows how > to setup the clip-texture loader callback and use it to load data into > the clip-texture. > > hth, > Praveen > > -----Original Message----- > From: owner-info-volumizer@els.sgi.com > [mailto:owner-info-volumizer@els.sgi.com] On Behalf Of Kevin Wang > Sent: Wednesday, December 14, 2005 10:58 PM > To: info-volumizer@els.sgi.com > Subject: [info-volumizer] 3D Clip Texture > > > Hi list and Praveen, > > I am interested in using volumizer's 3D clip texture in VTK. I have > already had a modified version of vtkOpenGLVolumeTextureMapper3D for use > in VTK. Now the problem is that I want to use VTK's image reader to read > in the 3D clip texture instead of Volumizer's IFL file loader. anyone > has done this so far or what is the neccessary steps to do that? > > Thanks, > > -- Kevin > > ------=_Part_6596_28149651.1135029047840 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Praveen,

Thanks for your information. I have got another question for you. I tried to load a 598x570x621 dataset into volumizer and to my suprise, volumizer does bricking automatically. it divides the data into 9 bricks. the following is the output of volumizer:

Volumizer (3): Original volume sizes: (598, 570, 621)
Volumizer (3): Number of bricks =3D (3, 3, 3)
Volumizer (3): Brick Dimensions:
Volumizer (3): X axis =3D 512 64 24
Volumizer (3): Y axis =3D 256 256 60
Volumizer (3): Z axis =3D 512 64 47

so the largest brick is 512x256x512 which is about 64M. the data is in unsigned char type and only one component. but we have an altix3700 with graphics system installed.

Volumizer (4): Vendor string =3D ATI Technologies Inc.
Volumizer (4): Renderer string =3D Fire GL X2 (FireGL) (GNU_ICD)

and I think the texture memory come with 256M with this type of graphics card so i wonder why volumizer compose the bricks in the above way instead of using the whole texture memory.

as regard to the previous question, I am trying vtk's lod class first. although it isnot as intelligent as volumizer's 3D clip texture. Using that class, I create 3 lod and each one uses one volumeTextureMapper. so I have 3 TMRenderActions and 3 shapes in my app. Each manages different level of dataset. I wonder what kind of texture memory managing scheme volumizer uses in this kind of situation? Since the first and second level fit into the texture memory so will they be swapped out if the third level is larger than the texture memory? If so, how can I make them stay in?

Thanks again,

-- Kevin


On 12/16/05, Praveen Bhaniramka <pra= veenb@sgi.com> wrote:
Hi Kevin,

I have never tried doing this myself. However, in order to= accomplish
what you need to do, you would probably need to modify VTK's= image
reader code. The only dependency on the loader that 3D clip-textu= res
impose is that the vzParameterClipTexture class requires you to set adata loader callback which is invoked by the clip-texture's data manager<= br>to load a sub-brick in the volume data at a given level of resolution.
The data loader callback is of type (as in ParameterClipTexture.h file)=
-

typedef bool (*vzDataLoaderCB)(const int offset[3], const int = level,
           = ;            &n= bsp;       const int dim[3], void *data, void
*userData);

The callback is pa= ssed the offset, level and dimensions of the brick to
be loaded and the = callback is required to load this region of data into
the void *data poi= nter supplied to the callback. Take a look at the
ClipLoader class installed under src\lib\loaders directory. It shows ho= w
to setup the clip-texture loader callback and use it to load data into=
the clip-texture.

hth,
Praveen

-----Original Message--= ---
From: owner-info-vo= lumizer@els.sgi.com
[mailto:owner-info-volumizer@els.sgi.com] On Behalf Of Kevin Wang Sent: Wednesday, December 14, 2005 10:58 PM
To: info-volumizer@els.sgi.com
Subject: [info-volu= mizer] 3D Clip Texture


Hi list and Praveen,

I am interest= ed in using volumizer's 3D clip texture in VTK. I have
already had a modified version of vtkOpenGLVolumeTextureMapper3D for us= e
in VTK. Now the problem is that I want to use VTK's image reader to re= ad
in the 3D clip texture instead of Volumizer's IFL file loader. anyone
has done this so far or what is the neccessary steps to do that?
Thanks,

-- Kevin


------=_Part_6596_28149651.1135029047840-- From info-volumizer-owner@els.sgi.com Mon Dec 19 23:48:41 2005 Received: (from majordom@localhost) by els.sgi.com (8.12.10/8.12.2/els-2.2) id jBK7lwW7220187; Mon, 19 Dec 2005 23:47:58 -0800 (PST) Received: from internal-mail-relay1.corp.sgi.com (internal-mail-relay1.corp.sgi.com [198.149.32.52]) by els.sgi.com (8.12.10/8.12.2/els-2.2) with ESMTP id jBK7kAx3219141 for ; Mon, 19 Dec 2005 23:46:11 -0800 (PST) Received: from mtv-amer002e--3.americas.sgi.com ([192.26.64.114]) by internal-mail-relay1.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jBK7nlAU83297839 for ; Mon, 19 Dec 2005 23:49:47 -0800 (PST) Received: from praveenlaptop ([134.14.90.82]) by mtv-amer002e--3.americas.sgi.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 19 Dec 2005 23:42:14 -0800 From: "Praveen Bhaniramka" To: Subject: RE: [info-volumizer] 3D Clip Texture Date: Tue, 20 Dec 2005 13:12:10 +0530 Message-ID: <006901c60538$e3fffdf0$525a0e86@asiapac.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: X-OriginalArrivalTime: 20 Dec 2005 07:42:14.0636 (UTC) FILETIME=[E515DAC0:01C60538] Sender: owner-info-volumizer@els.sgi.com Precedence: bulk Reply-To: info-volumizer@els.sgi.com Hi Kevin, Volumizer performs different optimizations internally to ensure optimal texture memory utilization. It also handles the limitations imposed by different GPUs on valid texture dimensions, etc. In this particular case, - bricking the data helps reduce texture memory overhead - provides correct behaviour on ATI Fire GLX2 GPUs, where the maximum texture size is 64MB for a 3D texture. Your basic idea of using multiple LODs sounds fine to me. However, to get best performance and optimal texture memory usage, you should create ONLY ONE vzTMRenderAction and share them across the 3 vtkVolumeTextureMapper classes. Depending on which LOD you want to render, you can simply manage the shape corresponding to that LOD and render it using the render action. The TMRenderAction will internally try to handle the texture swapping stuff in the most efficient way possible. I am not sure what you mean by "how can I make them stay in". If you are rendering LOD 3 which is larger than texture memory, then LOD 1 and 2 _should_ be swapped out so that you can get good rendering performance. If for some reason, you want to force LOD 1 and LOD 2 to stay in the texture memory every frame, make sure that the corresponding shapes are managed (even though sometimes the driver might still swap them out if it finds a reason to do so). Cheers, Praveen -----Original Message----- From: owner-info-volumizer@els.sgi.com [mailto:owner-info-volumizer@els.sgi.com] On Behalf Of Kevin Wang Sent: Tuesday, December 20, 2005 3:21 AM To: info-volumizer@els.sgi.com Subject: Re: [info-volumizer] 3D Clip Texture Hi Praveen, Thanks for your information. I have got another question for you. I tried to load a 598x570x621 dataset into volumizer and to my suprise, volumizer does bricking automatically. it divides the data into 9 bricks. the following is the output of volumizer: Volumizer (3): Original volume sizes: (598, 570, 621) Volumizer (3): Number of bricks = (3, 3, 3) Volumizer (3): Brick Dimensions: Volumizer (3): X axis = 512 64 24 Volumizer (3): Y axis = 256 256 60 Volumizer (3): Z axis = 512 64 47 so the largest brick is 512x256x512 which is about 64M. the data is in unsigned char type and only one component. but we have an altix3700 with graphics system installed. Volumizer (4): Vendor string = ATI Technologies Inc. Volumizer (4): Renderer string = Fire GL X2 (FireGL) (GNU_ICD) and I think the texture memory come with 256M with this type of graphics card so i wonder why volumizer compose the bricks in the above way instead of using the whole texture memory. as regard to the previous question, I am trying vtk's lod class first. although it isnot as intelligent as volumizer's 3D clip texture. Using that class, I create 3 lod and each one uses one volumeTextureMapper. so I have 3 TMRenderActions and 3 shapes in my app. Each manages different level of dataset. I wonder what kind of texture memory managing scheme volumizer uses in this kind of situation? Since the first and second level fit into the texture memory so will they be swapped out if the third level is larger than the texture memory? If so, how can I make them stay in? Thanks again, -- Kevin On 12/16/05, Praveen Bhaniramka wrote: Hi Kevin, I have never tried doing this myself. However, in order to accomplish what you need to do, you would probably need to modify VTK's image reader code. The only dependency on the loader that 3D clip-textures impose is that the vzParameterClipTexture class requires you to set a data loader callback which is invoked by the clip-texture's data manager to load a sub-brick in the volume data at a given level of resolution. The data loader callback is of type (as in ParameterClipTexture.h file) - typedef bool (*vzDataLoaderCB)(const int offset[3], const int level, const int dim[3], void *data, void *userData); The callback is passed the offset, level and dimensions of the brick to be loaded and the callback is required to load this region of data into the void *data pointer supplied to the callback. Take a look at the ClipLoader class installed under src\lib\loaders directory. It shows how to setup the clip-texture loader callback and use it to load data into the clip-texture. hth, Praveen -----Original Message----- From: owner-info-volumizer@els.sgi.com [mailto:owner-info-volumizer@els.sgi.com] On Behalf Of Kevin Wang Sent: Wednesday, December 14, 2005 10:58 PM To: info-volumizer@els.sgi.com Subject: [info-volumizer] 3D Clip Texture Hi list and Praveen, I am interested in using volumizer's 3D clip texture in VTK. I have already had a modified version of vtkOpenGLVolumeTextureMapper3D for use in VTK. Now the problem is that I want to use VTK's image reader to read in the 3D clip texture instead of Volumizer's IFL file loader. anyone has done this so far or what is the neccessary steps to do that? Thanks, -- Kevin From info-volumizer-owner@els.sgi.com Wed Dec 21 04:07:47 2005 Received: (from majordom@localhost) by els.sgi.com (8.12.10/8.12.2/els-2.2) id jBLC68gZ235502; Wed, 21 Dec 2005 04:06:08 -0800 (PST) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by els.sgi.com (8.12.10/8.12.2/els-2.2) with ESMTP id jBKM7kx3236020 for ; Tue, 20 Dec 2005 14:07:47 -0800 (PST) Received: from vail.cam.nist.gov (vail.cam.nist.gov [129.6.80.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id jBKM7i0l027260; Tue, 20 Dec 2005 17:07:44 -0500 Received: from vail.cam.nist.gov (localhost [127.0.0.1]) by vail.cam.nist.gov (SGI-8.12.5/8.12.5) with ESMTP id jBKM7gT4050560; Tue, 20 Dec 2005 17:07:42 -0500 (EST) Received: from localhost (steve@localhost) by vail.cam.nist.gov (SGI-8.12.5/8.12.5/Submit) with ESMTP id jBKM7fuT050803; Tue, 20 Dec 2005 17:07:41 -0500 (EST) X-Authentication-Warning: vail.cam.nist.gov: steve owned process doing -bs Date: Tue, 20 Dec 2005 17:07:41 -0500 From: Steve Satterfield X-X-Sender: steve@vail.cam.nist.gov To: Volumizer Mailing List cc: Steve Satterfield Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: steve@nist.gov Subject: [info-volumizer] Volumizer on a Dual Core Dell with SuSe Sender: owner-info-volumizer@els.sgi.com Precedence: bulk Reply-To: info-volumizer@els.sgi.com Hi, I sent the folloiwng message to the performer Email list, but I have the same quesiton with regard to Volumizer. Are dual core 32 bit Linux systems a good or bad idea for the 32 bit Volumizer distribution? Thanks, Steve ---------- Forwarded message ---------- Date: Tue, 20 Dec 2005 17:01:51 -0500 From: Steve Satterfield To: Performer Mailing List Subject: Performer on a Dual Core Dell with SuSe Can anyone provide me with any advice on using 32 Bit Performer for Linux on a dual core system? We are looking at buying a few 32 Bit Linux machines, probably Dell and running SuSe and Performer. Does having 2 CPUs give you any advantage with regard to Performer. Can the 32 Bit Linux distribution do any multi-processing? If there are no advantages, are than any disadvantages? Thanks for any advice, I need to make a buying decision very soon. -Steve From info-volumizer-owner@els.sgi.com Wed Dec 21 05:22:49 2005 Received: (from majordom@localhost) by els.sgi.com (8.12.10/8.12.2/els-2.2) id jBLDLtHS262417; Wed, 21 Dec 2005 05:21:55 -0800 (PST) Received: from hastur.corp.sgi.com (hastur.corp.sgi.com [198.149.32.33]) by els.sgi.com (8.12.10/8.12.2/els-2.2) with ESMTP id jBLCu3x3245314 for ; Wed, 21 Dec 2005 04:56:03 -0800 (PST) Received: from mtv-amer002e--3.americas.sgi.com ([192.26.64.114]) by hastur.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jBLCtYf6230238193 for ; Wed, 21 Dec 2005 04:55:38 -0800 (PST) Received: from praveenlaptop ([134.14.90.82]) by mtv-amer002e--3.americas.sgi.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 21 Dec 2005 04:25:42 -0800 From: "Praveen Bhaniramka" To: Subject: RE: [info-volumizer] Volumizer on a Dual Core Dell with SuSe Date: Wed, 21 Dec 2005 17:55:39 +0530 Message-ID: <002a01c60629$a8592c80$525a0e86@asiapac.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Importance: Normal X-OriginalArrivalTime: 21 Dec 2005 12:25:43.0093 (UTC) FILETIME=[A9542E50:01C60629] Sender: owner-info-volumizer@els.sgi.com Precedence: bulk Reply-To: info-volumizer@els.sgi.com Hi Steve, Can more processing power ever be bad for us engineers? :-) Your choice of systems depends on your applications needs. Since you are using Performer, which uses a multi-processing model of execution, you should see some speed-up in your application with multiple CPUs. However, the actual speed-up would really depend on the multi-processing scheme that your application uses (APP, CULL, DRAW) and how much time is spend in executing each process. Typically, volume rendering ends up being a heavily pixel-fill limited operation. Hence, if you are running something like volview, the CPU is sitting idle most of the time, waiting for the GPUs to get done with the rendering. However, if your application is doing more sophisticated processing like UI processing or data manipulation, the CPU load is probably higher. Hth, Praveen > -----Original Message----- > From: owner-info-volumizer@els.sgi.com > [mailto:owner-info-volumizer@els.sgi.com] On Behalf Of Steve > Satterfield > Sent: Wednesday, December 21, 2005 3:38 AM > To: Volumizer Mailing List > Cc: Steve Satterfield > Subject: [info-volumizer] Volumizer on a Dual Core Dell with SuSe > > > > Hi, > > I sent the folloiwng message to the performer Email list, but > I have the > same quesiton with regard to Volumizer. Are dual core 32 bit > Linux systems > a good or bad idea for the 32 bit Volumizer distribution? > > Thanks, > Steve > > ---------- Forwarded message ---------- > Date: Tue, 20 Dec 2005 17:01:51 -0500 > From: Steve Satterfield > To: Performer Mailing List > Subject: Performer on a Dual Core Dell with SuSe > > Can anyone provide me with any advice on using 32 Bit > Performer for Linux on > a dual core system? We are looking at buying a few 32 Bit > Linux machines, > probably Dell and running SuSe and Performer. > > Does having 2 CPUs give you any advantage with regard to > Performer. Can the > 32 Bit Linux distribution do any multi-processing? > > If there are no advantages, are than any disadvantages? > > Thanks for any advice, I need to make a buying decision very soon. > > -Steve > From info-volumizer-owner@els.sgi.com Wed Dec 21 06:37:44 2005 Received: (from majordom@localhost) by els.sgi.com (8.12.10/8.12.2/els-2.2) id jBLEasRe261882; Wed, 21 Dec 2005 06:36:54 -0800 (PST) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by els.sgi.com (8.12.10/8.12.2/els-2.2) with ESMTP id jBLE1bx3255912 for ; Wed, 21 Dec 2005 06:01:38 -0800 (PST) Received: from vail.cam.nist.gov (vail.cam.nist.gov [129.6.80.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id jBLE1STv021195; Wed, 21 Dec 2005 09:01:28 -0500 Received: from vail.cam.nist.gov (localhost [127.0.0.1]) by vail.cam.nist.gov (SGI-8.12.5/8.12.5) with ESMTP id jBLE1QT4058006; Wed, 21 Dec 2005 09:01:26 -0500 (EST) Received: from localhost (steve@localhost) by vail.cam.nist.gov (SGI-8.12.5/8.12.5/Submit) with ESMTP id jBLE1Qmf058007; Wed, 21 Dec 2005 09:01:26 -0500 (EST) X-Authentication-Warning: vail.cam.nist.gov: steve owned process doing -bs Date: Wed, 21 Dec 2005 09:01:26 -0500 From: Steve Satterfield X-X-Sender: steve@vail.cam.nist.gov To: Volumizer Mailing List cc: Performer Mailing List , Steve Satterfield Subject: RE: [info-volumizer] Volumizer on a Dual Core Dell with SuSe In-Reply-To: <002a01c60629$a8592c80$525a0e86@asiapac.sgi.com> Message-ID: References: <002a01c60629$a8592c80$525a0e86@asiapac.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: steve@nist.gov Sender: owner-info-volumizer@els.sgi.com Precedence: bulk Reply-To: info-volumizer@els.sgi.com Hi Praveen, Thanks for the reply. I hope to hear some thoughts from the Performer people. In general, more processing power is good. But I am concerned exactly what Performer does. Based on experience with single CPU 32 bit Linux machines as compared to our Onyx, we seem to always be able to display larger models on a 1CPU/1GB 32 bit Dell than the 24CPU/24GB Onyx using n32 addressing. Of the 32bit address space, single threaded Linux Performer seems to be able to use most of it for the Performer shared memory. When Performer is used in multi-processing mode on the Onyx, the various Performer stages make copies of the model, thus dividing up the 32bit address space, to effectively halve the model size. Model size is important to us. My question is whether a dual core Linux system would use multi-processing Performer and make copies of the model within the 32 bit addressing space. Thanks, Steve On Wed, 21 Dec 2005, Praveen Bhaniramka wrote: > Hi Steve, > > Can more processing power ever be bad for us engineers? :-) > > Your choice of systems depends on your applications needs. Since you are > using Performer, which uses a multi-processing model of execution, you > should see some speed-up in your application with multiple CPUs. > However, the actual speed-up would really depend on the multi-processing > scheme that your application uses (APP, CULL, DRAW) and how much time is > spend in executing each process. > > Typically, volume rendering ends up being a heavily pixel-fill limited > operation. Hence, if you are running something like volview, the CPU is > sitting idle most of the time, waiting for the GPUs to get done with the > rendering. However, if your application is doing more sophisticated > processing like UI processing or data manipulation, the CPU load is > probably higher. > > Hth, > Praveen > > > -----Original Message----- > > From: owner-info-volumizer@els.sgi.com > > [mailto:owner-info-volumizer@els.sgi.com] On Behalf Of Steve > > Satterfield > > Sent: Wednesday, December 21, 2005 3:38 AM > > To: Volumizer Mailing List > > Cc: Steve Satterfield > > Subject: [info-volumizer] Volumizer on a Dual Core Dell with SuSe > > > > > > > > Hi, > > > > I sent the folloiwng message to the performer Email list, but > > I have the > > same quesiton with regard to Volumizer. Are dual core 32 bit > > Linux systems > > a good or bad idea for the 32 bit Volumizer distribution? > > > > Thanks, > > Steve > > > > ---------- Forwarded message ---------- > > Date: Tue, 20 Dec 2005 17:01:51 -0500 > > From: Steve Satterfield > > To: Performer Mailing List > > Subject: Performer on a Dual Core Dell with SuSe > > > > Can anyone provide me with any advice on using 32 Bit > > Performer for Linux on > > a dual core system? We are looking at buying a few 32 Bit > > Linux machines, > > probably Dell and running SuSe and Performer. > > > > Does having 2 CPUs give you any advantage with regard to > > Performer. Can the > > 32 Bit Linux distribution do any multi-processing? > > > > If there are no advantages, are than any disadvantages? > > > > Thanks for any advice, I need to make a buying decision very soon. > > > > -Steve > > > > > From info-volumizer-owner@els.sgi.com Wed Dec 21 08:33:34 2005 Received: (from majordom@localhost) by els.sgi.com (8.12.10/8.12.2/els-2.2) id jBLGWsQA264786; Wed, 21 Dec 2005 08:32:54 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.197]) by els.sgi.com (8.12.10/8.12.2/els-2.2) with ESMTP id jBLGJAx3259297 for ; Wed, 21 Dec 2005 08:19:11 -0800 (PST) Received: by wproxy.gmail.com with SMTP id i14so172488wra for ; Wed, 21 Dec 2005 08:19:10 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=P7FP0mvTGuO6VFukGXUeF/GvK+b5IrAT0fzGnFHHfKv5lAOXxQPP+twm9EzqMZ5pfTXn8luAeje4azP61ZoegTMfQFlltlSGN16VzJ3bXZhYpOVoGp4aTtLloZ+koFP7+XkAVQSGn0/RRXWYUIDPDAm0+GzOIiDp89JBXBEE09w= Received: by 10.65.121.8 with SMTP id y8mr613979qbm; Wed, 21 Dec 2005 08:19:09 -0800 (PST) Received: by 10.65.151.13 with HTTP; Wed, 21 Dec 2005 08:19:09 -0800 (PST) Message-ID: Date: Wed, 21 Dec 2005 11:19:09 -0500 From: Kevin Wang To: info-volumizer@els.sgi.com Subject: Re: [info-volumizer] 3D Clip Texture In-Reply-To: <006901c60538$e3fffdf0$525a0e86@asiapac.sgi.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_8951_2455816.1135181949265" References: <006901c60538$e3fffdf0$525a0e86@asiapac.sgi.com> Sender: owner-info-volumizer@els.sgi.com Precedence: bulk Reply-To: info-volumizer@els.sgi.com ------=_Part_8951_2455816.1135181949265 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Praveen, So the ATI FIRE GLX2 only has 64M memory. I thought it is 256M. Could you explain why only one vzTMRenderAction can be created? I create 3 and it seems it works fine. Another thing I want to point out is that on our 64bit altix system and 32 bit pc linux system, if the data type is set to VZ_SHORT, then nothing got rendered. but after I change it to VZ_UNSIGNED_SHORT, everything is fine. I searched the list and found that you suggested to use unsigned short over short, but I figured I should let you guys know this. -- Kevin On 12/20/05, Praveen Bhaniramka wrote: > > Hi Kevin, > > Volumizer performs different optimizations internally to ensure optimal > texture memory utilization. It also handles the limitations imposed by > different GPUs on valid texture dimensions, etc. In this particular > case, > - bricking the data helps reduce texture memory overhead > - provides correct behaviour on ATI Fire GLX2 GPUs, where the > maximum texture size is 64MB for a 3D texture. > > Your basic idea of using multiple LODs sounds fine to me. However, to > get best performance and optimal texture memory usage, you should create > ONLY ONE vzTMRenderAction and share them across the 3 > vtkVolumeTextureMapper classes. Depending on which LOD you want to > render, you can simply manage the shape corresponding to that LOD and > render it using the render action. The TMRenderAction will internally > try to handle the texture swapping stuff in the most efficient way > possible. > > I am not sure what you mean by "how can I make them stay in". If you are > rendering LOD 3 which is larger than texture memory, then LOD 1 and 2 > _should_ be swapped out so that you can get good rendering performance. > If for some reason, you want to force LOD 1 and LOD 2 to stay in the > texture memory every frame, make sure that the corresponding shapes are > managed (even though sometimes the driver might still swap them out if > it finds a reason to do so). > > Cheers, > Praveen > > -----Original Message----- > From: owner-info-volumizer@els.sgi.com > [mailto:owner-info-volumizer@els.sgi.com] On Behalf Of Kevin Wang > Sent: Tuesday, December 20, 2005 3:21 AM > To: info-volumizer@els.sgi.com > Subject: Re: [info-volumizer] 3D Clip Texture > > > Hi Praveen, > > Thanks for your information. I have got another question for you. I > tried to load a 598x570x621 dataset into volumizer and to my suprise, > volumizer does bricking automatically. it divides the data into 9 > bricks. the following is the output of volumizer: > > Volumizer (3): Original volume sizes: (598, 570, 621) > Volumizer (3): Number of bricks =3D (3, 3, 3) > Volumizer (3): Brick Dimensions: > Volumizer (3): X axis =3D 512 64 24 > Volumizer (3): Y axis =3D 256 256 60 > Volumizer (3): Z axis =3D 512 64 47 > > so the largest brick is 512x256x512 which is about 64M. the data is in > unsigned char type and only one component. but we have an altix3700 with > graphics system installed. > > Volumizer (4): Vendor string =3D ATI Technologies Inc. > Volumizer (4): Renderer string =3D Fire GL X2 (FireGL) (GNU_ICD) > > and I think the texture memory come with 256M with this type of graphics > card so i wonder why volumizer compose the bricks in the above way > instead of using the whole texture memory. > > as regard to the previous question, I am trying vtk's lod class first. > although it isnot as intelligent as volumizer's 3D clip texture. Using > that class, I create 3 lod and each one uses one volumeTextureMapper. so > I have 3 TMRenderActions and 3 shapes in my app. Each manages different > level of dataset. I wonder what kind of texture memory managing scheme > volumizer uses in this kind of situation? Since the first and second > level fit into the texture memory so will they be swapped out if the > third level is larger than the texture memory? If so, how can I make > them stay in? > > Thanks again, > > -- Kevin > > > > On 12/16/05, Praveen Bhaniramka wrote: > Hi Kevin, > > I have never tried doing this myself. However, in order to accomplish > what you need to do, you would probably need to modify VTK's image > reader code. The only dependency on the loader that 3D clip-textures > impose is that the vzParameterClipTexture class requires you to set a > data loader callback which is invoked by the clip-texture's data manager > to load a sub-brick in the volume data at a given level of resolution. > The data loader callback is of type (as in ParameterClipTexture.h file) > - > > typedef bool (*vzDataLoaderCB)(const int offset[3], const int level, > const int dim[3], void *data, void > *userData); > > The callback is passed the offset, level and dimensions of the brick to > be loaded and the callback is required to load this region of data into > the void *data pointer supplied to the callback. Take a look at the > ClipLoader class installed under src\lib\loaders directory. It shows how > to setup the clip-texture loader callback and use it to load data into > the clip-texture. > > hth, > Praveen > > -----Original Message----- > From: owner-info-volumizer@els.sgi.com > [mailto:owner-info-volumizer@els.sgi.com] On Behalf Of Kevin Wang > Sent: Wednesday, December 14, 2005 10:58 PM > To: info-volumizer@els.sgi.com > Subject: [info-volumizer] 3D Clip Texture > > > Hi list and Praveen, > > I am interested in using volumizer's 3D clip texture in VTK. I have > already had a modified version of vtkOpenGLVolumeTextureMapper3D for use > in VTK. Now the problem is that I want to use VTK's image reader to read > in the 3D clip texture instead of Volumizer's IFL file loader. anyone > has done this so far or what is the neccessary steps to do that? > > Thanks, > > -- Kevin > > ------=_Part_8951_2455816.1135181949265 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Praveen,

So the ATI FIRE GLX2 only has 64M memory. I thought it i= s 256M.

Could you explain why only one vzTMRenderAction can be crea= ted? I create 3 and it seems it works fine.

Another thing I want to= point out is that on our 64bit altix system and 32 bit pc linux system, if= the data type is set to VZ_SHORT, then nothing got rendered. but after I c= hange it to VZ_UNSIGNED_SHORT, everything is fine. I searched the list and = found that you suggested to use unsigned short over short, but I figured I = should let you guys know this.=20

-- Kevin

On 12/20/05, Praveen Bhaniramka <praveenb@sgi.com> wrote:
Hi Kevin,

Volumizer performs different optimizations internally to e= nsure optimal
texture memory utilization. It also handles the limitation= s imposed by
different GPUs on valid texture dimensions, etc. In this pa= rticular
case,
        - bricking the= data helps reduce texture memory overhead
     = ;   - provides correct behaviour on ATI Fire GLX2 GPUs, wher= e the
maximum texture size is 64MB for a 3D texture.

Your basic i= dea of using multiple LODs sounds fine to me. However, to
get best performance and optimal texture memory usage, you should creat= e
ONLY ONE vzTMRenderAction and share them across the 3
vtkVolumeText= ureMapper classes. Depending on which LOD you want to
render, you can si= mply manage the shape corresponding to that LOD and
render it using the render action. The TMRenderAction will internallytry to handle the texture swapping stuff in the most efficient way
pos= sible.

I am not sure what you mean by "how can I make them stay= in". If you are
rendering LOD 3 which is larger than texture memory, then LOD 1 and 2_should_ be swapped out so that you can get good rendering performance.If for some reason, you want to force LOD 1 and LOD 2 to stay in the
texture memory every frame, make sure that the corresponding shapes are
= managed (even though sometimes the driver might still swap them out if
i= t finds a reason to do so).

Cheers,
Praveen

-----Original = Message-----
From: owner-info-vo= lumizer@els.sgi.com
[mailto:owner-info-volumizer@els.sgi.com] On Behalf Of Kevin Wang Sent: Tuesday, December 20, 2005 3:21 AM
To: info-volumizer@els.sgi.com
Subject: Re: [info-vol= umizer] 3D Clip Texture


Hi Praveen,

Thanks for your infor= mation. I have got another question for you. I
tried to load a 598x570x621 dataset into volumizer and to my suprise,volumizer does bricking automatically. it divides the data into 9
bric= ks. the following is the output of volumizer:

Volumizer (3): Origina= l volume sizes: (598, 570, 621)
Volumizer (3): Number of bricks =3D (3, 3, 3)
Volumizer (3): Brick D= imensions:
Volumizer (3): X axis =3D 512 64 24
Volumizer (3): Y axis = =3D 256 256 60
Volumizer (3): Z axis =3D 512 64 47

so the largest= brick is 512x256x512 which is about 64M. the data is in
unsigned char type and only one component. but we have an altix3700 wit= h
graphics system installed.

Volumizer (4): Vendor string =3D ATI= Technologies Inc.
Volumizer (4): Renderer string =3D Fire GL X2 (FireGL= ) (GNU_ICD)

and I think the texture memory come with 256M with this type of gra= phics
card so i wonder why volumizer compose the bricks in the above way=
instead of using the whole texture memory.

as regard to the prev= ious question, I am trying vtk's lod class first.
although it isnot as intelligent as volumizer's 3D clip texture. Using<= br>that class, I create 3 lod and each one uses one volumeTextureMapper. so=
I have 3 TMRenderActions and 3 shapes in my app. Each manages different
level of dataset. I wonder what kind of texture memory managing scheme<= br>volumizer uses in this kind of situation? Since the first and second
= level fit into the texture memory so will they be swapped out if the
third level is larger than the texture memory? If so, how can I make
the= m stay in?

Thanks again,

-- Kevin



On 12/16/05,= Praveen Bhaniramka <praveenb@sgi.co= m > wrote:
Hi Kevin,

I have never tried doing this myself. H= owever, in order to accomplish
what you need to do, you would probably n= eed to modify VTK's image
reader code. The only dependency on the loader= that 3D clip-textures
impose is that the vzParameterClipTexture class requires you to set adata loader callback which is invoked by the clip-texture's data manager<= br>to load a sub-brick in the volume data at a given level of resolution.
The data loader callback is of type (as in ParameterClipTexture.h file)=
-

typedef bool (*vzDataLoaderCB)(const int offset[3], const int = level,
           = ;            &n= bsp;       const int dim[3], void *data, void
*userData);

The callback is passed the offset, level and dimensi= ons of the brick to
be loaded and the callback is required to load this = region of data into
the void *data pointer supplied to the callback. Tak= e a look at the
ClipLoader class installed under src\lib\loaders directory. It shows ho= w
to setup the clip-texture loader callback and use it to load data into=
the clip-texture.

hth,
Praveen

-----Original Message--= ---
From: owner-info-vo= lumizer@els.sgi.com
[mailto:owner-info-volumizer@els.sgi.com] On Behalf Of Kevin Wang Sent: Wednesday, December 14, 2005 10:58 PM
To: info-volumizer@els.sgi.com
Subject: [info-volu= mizer] 3D Clip Texture


Hi list and Praveen,

I am interest= ed in using volumizer's 3D clip texture in VTK. I have
already had a modified version of vtkOpenGLVolumeTextureMapper3D for us= e
in VTK. Now the problem is that I want to use VTK's image reader to re= ad
in the 3D clip texture instead of Volumizer's IFL file loader. anyone
has done this so far or what is the neccessary steps to do that?
Thanks,

-- Kevin


------=_Part_8951_2455816.1135181949265-- From info-volumizer-owner@els.sgi.com Wed Dec 21 08:33:34 2005 Received: (from majordom@localhost) by els.sgi.com (8.12.10/8.12.2/els-2.2) id jBLGWsq6264892; Wed, 21 Dec 2005 08:32:54 -0800 (PST) Received: from jefferson.patriot.net (jefferson.patriot.net [209.249.176.3]) by els.sgi.com (8.12.10/8.12.2/els-2.2) with ESMTP id jBLFgGx3259760 for ; Wed, 21 Dec 2005 07:42:16 -0800 (PST) Received: from [127.0.0.1] (adams.patriot.net [209.249.176.2]) by jefferson.patriot.net (8.13.4/8.13.4/Debian-3) with ESMTP id jBLFgC51014433; Wed, 21 Dec 2005 10:42:15 -0500 Subject: Re: [info-performer] RE: [info-volumizer] Volumizer on a Dual Core Dell with SuSe From: Donald Tidrow To: Steve Satterfield Cc: Volumizer Mailing List , Performer Mailing List In-Reply-To: References: <002a01c60629$a8592c80$525a0e86@asiapac.sgi.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-004fOmjuiE9tW05G/gVS" Organization: GNU Linux Message-Id: <1135179731.6794.61.camel@redline> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6-1mdk Date: Wed, 21 Dec 2005 10:42:12 -0500 Sender: owner-info-volumizer@els.sgi.com Precedence: bulk Reply-To: info-volumizer@els.sgi.com --=-004fOmjuiE9tW05G/gVS Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2005-12-21 at 09:01, Steve Satterfield wrote: > Hi Praveen, >=20 > Thanks for the reply. I hope to hear some thoughts from the Performer > people. >=20 > In general, more processing power is good. But I am concerned exactly > what Performer does. Based on experience with single CPU 32 bit Linux > machines as compared to our Onyx, we seem to always be able to display > larger models on a 1CPU/1GB 32 bit Dell than the 24CPU/24GB Onyx using n3= 2 > addressing. Of the 32bit address space, single threaded Linux Performer > seems to be able to use most of it for the Performer shared memory. When > Performer is used in multi-processing mode on the Onyx, the various > Performer stages make copies of the model, thus dividing up the 32bit > address space, to effectively halve the model size. Model size is > important to us. >=20 > My question is whether a dual core Linux system would use multi-processin= g > Performer and make copies of the model within the 32 bit addressing space= . >=20 > Thanks, > Steve >=20 It's not too surprising that you are able to load larger models on a Linux x86 system than on your Onyx using the n32 process model - the usable address space on an IRIX n32 process is 2GB, while on Linux it's 3GB. In addition, Performer allocates most(all?) of its memory out of a shared memory region that needs to be contiguous, and (at least back when I regularly worked with Performer) some of the Performer shared libs got mapped into the address space that prevented large (>768MB) shared arenas from being created. You could remap the libs to another location in the address space and get shared arenas up to 1.5GB, though that sometimes caused other problems - more shared arena memory meant less C/C++ heap memory. In short, if you need to load large models, use the 64-bit libs - you could then use all of that 24GB of memory for the shared arena. Don --=-004fOmjuiE9tW05G/gVS Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBDqXfTQDkEBZuoxIERAnuoAJ4lcM7zPCTA1a3siPZz2v7AuaJbmQCfcGdh MO73zXQ/jtV3LeSVJwFsSOk= =E44g -----END PGP SIGNATURE----- --=-004fOmjuiE9tW05G/gVS-- From info-volumizer-owner@els.sgi.com Wed Dec 21 08:53:58 2005 Received: (from majordom@localhost) by els.sgi.com (8.12.10/8.12.2/els-2.2) id jBLGrcDk265090; Wed, 21 Dec 2005 08:53:38 -0800 (PST) Received: from internal-mail-relay.corp.sgi.com (internal-mail-relay.corp.sgi.com [198.149.32.51]) by els.sgi.com (8.12.10/8.12.2/els-2.2) with ESMTP id jBLGrKx3265534 for ; Wed, 21 Dec 2005 08:53:20 -0800 (PST) Received: from mtv-amer002e--3.americas.sgi.com ([192.26.64.114]) by internal-mail-relay.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jBLGqsvR11420612 for ; Wed, 21 Dec 2005 08:52:56 -0800 (PST) Received: from praveenlaptop ([134.15.0.150]) by mtv-amer002e--3.americas.sgi.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 21 Dec 2005 08:51:33 -0800 From: "Praveen Bhaniramka" To: Subject: RE: [info-volumizer] 3D Clip Texture Date: Wed, 21 Dec 2005 22:21:30 +0530 Message-ID: <008801c6064e$cc24fe30$96000f86@asiapac.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Importance: Normal X-OriginalArrivalTime: 21 Dec 2005 16:51:34.0220 (UTC) FILETIME=[CCF100C0:01C6064E] Sender: owner-info-volumizer@els.sgi.com Precedence: bulk Reply-To: info-volumizer@els.sgi.com Hi Kevin, No... Your assumption is correct that the Fire GLX2 has 256 MB graphics memory. However, a single 3D texture is limited to 64MB in size. So, in practice you can have 4 64 MB textures and they would still fit in the graphics memory (not really since some space would be used by the frame buffer, display lists, etc). That is why Volumizer bricks anything that is greater than 64 MB in size. Yes, you can create multiple TMRenderActions and things would still work. But the texture memory utilization would not be very efficient. E.g. each TMRenderAction creates and manages it's own pool of textures and assumes that it owns ALL of the texture memory on the GPU. With multiple TMRenderAction's for the same GPU, each of them would create and manage their own pool. But they would not be able to share these textures among each other since they don't know about each other. This can lead to unnecessary texture memory fragmentation and texture swapping. Hence, the best scheme is to always create 1 TMRenderAction per GPU and then use the shape manage/unmanage interface to tell the TMRenderAction which textures you want to be in the GPU memory which ones you don't. For your case, where you are oversubscribing the available texture memory on the GPU, this should significantly improve the rendering performance. Hope this makes sense. There is some information about this in the programming guide in the TMRenderAction chapter's later half. Regarding use of VZ_SHORT, you are right. OpenGL simply truncates the negative values for signed data types and hence using signed types is not a good idea. VZ_UNSIGNED_SHORT on the other hand should give you the expected results. - Praveen -----Original Message----- From: owner-info-volumizer@els.sgi.com [mailto:owner-info-volumizer@els.sgi.com] On Behalf Of Kevin Wang Sent: Wednesday, December 21, 2005 9:49 PM To: info-volumizer@els.sgi.com Subject: Re: [info-volumizer] 3D Clip Texture Hi Praveen, So the ATI FIRE GLX2 only has 64M memory. I thought it is 256M. Could you explain why only one vzTMRenderAction can be created? I create 3 and it seems it works fine. Another thing I want to point out is that on our 64bit altix system and 32 bit pc linux system, if the data type is set to VZ_SHORT, then nothing got rendered. but after I change it to VZ_UNSIGNED_SHORT, everything is fine. I searched the list and found that you suggested to use unsigned short over short, but I figured I should let you guys know this. -- Kevin On 12/20/05, Praveen Bhaniramka wrote: Hi Kevin, Volumizer performs different optimizations internally to ensure optimal texture memory utilization. It also handles the limitations imposed by different GPUs on valid texture dimensions, etc. In this particular case, - bricking the data helps reduce texture memory overhead - provides correct behaviour on ATI Fire GLX2 GPUs, where the maximum texture size is 64MB for a 3D texture. Your basic idea of using multiple LODs sounds fine to me. However, to get best performance and optimal texture memory usage, you should create ONLY ONE vzTMRenderAction and share them across the 3 vtkVolumeTextureMapper classes. Depending on which LOD you want to render, you can simply manage the shape corresponding to that LOD and render it using the render action. The TMRenderAction will internally try to handle the texture swapping stuff in the most efficient way possible. I am not sure what you mean by "how can I make them stay in". If you are rendering LOD 3 which is larger than texture memory, then LOD 1 and 2 _should_ be swapped out so that you can get good rendering performance. If for some reason, you want to force LOD 1 and LOD 2 to stay in the texture memory every frame, make sure that the corresponding shapes are managed (even though sometimes the driver might still swap them out if it finds a reason to do so). Cheers, Praveen -----Original Message----- From: owner-info-volumizer@els.sgi.com [mailto:owner-info-volumizer@els.sgi.com] On Behalf Of Kevin Wang Sent: Tuesday, December 20, 2005 3:21 AM To: info-volumizer@els.sgi.com Subject: Re: [info-volumizer] 3D Clip Texture Hi Praveen, Thanks for your information. I have got another question for you. I tried to load a 598x570x621 dataset into volumizer and to my suprise, volumizer does bricking automatically. it divides the data into 9 bricks. the following is the output of volumizer: Volumizer (3): Original volume sizes: (598, 570, 621) Volumizer (3): Number of bricks = (3, 3, 3) Volumizer (3): Brick Dimensions: Volumizer (3): X axis = 512 64 24 Volumizer (3): Y axis = 256 256 60 Volumizer (3): Z axis = 512 64 47 so the largest brick is 512x256x512 which is about 64M. the data is in unsigned char type and only one component. but we have an altix3700 with graphics system installed. Volumizer (4): Vendor string = ATI Technologies Inc. Volumizer (4): Renderer string = Fire GL X2 (FireGL) (GNU_ICD) and I think the texture memory come with 256M with this type of graphics card so i wonder why volumizer compose the bricks in the above way instead of using the whole texture memory. as regard to the previous question, I am trying vtk's lod class first. although it isnot as intelligent as volumizer's 3D clip texture. Using that class, I create 3 lod and each one uses one volumeTextureMapper. so I have 3 TMRenderActions and 3 shapes in my app. Each manages different level of dataset. I wonder what kind of texture memory managing scheme volumizer uses in this kind of situation? Since the first and second level fit into the texture memory so will they be swapped out if the third level is larger than the texture memory? If so, how can I make them stay in? Thanks again, -- Kevin On 12/16/05, Praveen Bhaniramka wrote: Hi Kevin, I have never tried doing this myself. However, in order to accomplish what you need to do, you would probably need to modify VTK's image reader code. The only dependency on the loader that 3D clip-textures impose is that the vzParameterClipTexture class requires you to set a data loader callback which is invoked by the clip-texture's data manager to load a sub-brick in the volume data at a given level of resolution. The data loader callback is of type (as in ParameterClipTexture.h file) - typedef bool (*vzDataLoaderCB)(const int offset[3], const int level, const int dim[3], void *data, void *userData); The callback is passed the offset, level and dimensions of the brick to be loaded and the callback is required to load this region of data into the void *data pointer supplied to the callback. Take a look at the ClipLoader class installed under src\lib\loaders directory. It shows how to setup the clip-texture loader callback and use it to load data into the clip-texture. hth, Praveen -----Original Message----- From: owner-info-volumizer@els.sgi.com [mailto:owner-info-volumizer@els.sgi.com] On Behalf Of Kevin Wang Sent: Wednesday, December 14, 2005 10:58 PM To: info-volumizer@els.sgi.com Subject: [info-volumizer] 3D Clip Texture Hi list and Praveen, I am interested in using volumizer's 3D clip texture in VTK. I have already had a modified version of vtkOpenGLVolumeTextureMapper3D for use in VTK. Now the problem is that I want to use VTK's image reader to read in the 3D clip texture instead of Volumizer's IFL file loader. anyone has done this so far or what is the neccessary steps to do that? Thanks, -- Kevin From info-volumizer-owner@els.sgi.com Wed Dec 21 19:50:23 2005 Received: (from majordom@localhost) by els.sgi.com (8.12.10/8.12.2/els-2.2) id jBM3nPdw256164; Wed, 21 Dec 2005 19:49:25 -0800 (PST) Received: from pixie.artic.edu (pixie.artic.edu [198.40.30.132]) by els.sgi.com (8.12.10/8.12.2/els-2.2) with ESMTP id jBM1iex3271512 for ; Wed, 21 Dec 2005 17:44:41 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by pixie.artic.edu (Postfix) with ESMTP id B3AE239849D; Wed, 21 Dec 2005 19:44:39 -0600 (CST) Received: from [10.0.0.3] (adsl-68-252-238-141.dsl.chcgil.ameritech.net [68.252.238.141]) by pixie.artic.edu (Postfix) with ESMTP id 1AABD39848D; Wed, 21 Dec 2005 19:44:29 -0600 (CST) Message-ID: <43AA0495.6010205@artic.edu> Date: Wed, 21 Dec 2005 19:42:45 -0600 From: ben chang User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: info-volumizer@els.sgi.com Cc: Performer Mailing List , Steve Satterfield Subject: Re: [info-volumizer] Volumizer on a Dual Core Dell with SuSe References: <002a01c60629$a8592c80$525a0e86@asiapac.sgi.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-info-volumizer@els.sgi.com Precedence: bulk Reply-To: info-volumizer@els.sgi.com Hi Steve, Yes, Performer would run in multiprocessing mode on a dual-core cpu; I don't know much about the details of its memory allocation, but if it does turn out to be a problem you can always disable performer's multiprocessing at the beginning of your app. If you're developing more than one app, some might gain more from multiprocessing than others, and you'd have the capability if you need it. We just bought some athlon 64 dual-core machines, also running suse. performance is terrific, better than the dual-xeon we were using before; and cheaper too! Although, i should mention that they are not actually running in smp. turns out the motherboards are one slight revision off from being able to support dual-core. on the plus side, they're enjoyably fast even if half-crippled. --Ben Chang Steve Satterfield wrote: > Hi Praveen, > > Thanks for the reply. I hope to hear some thoughts from the Performer > people. > > In general, more processing power is good. But I am concerned exactly > what Performer does. Based on experience with single CPU 32 bit Linux > machines as compared to our Onyx, we seem to always be able to display > larger models on a 1CPU/1GB 32 bit Dell than the 24CPU/24GB Onyx using n32 > addressing. Of the 32bit address space, single threaded Linux Performer > seems to be able to use most of it for the Performer shared memory. When > Performer is used in multi-processing mode on the Onyx, the various > Performer stages make copies of the model, thus dividing up the 32bit > address space, to effectively halve the model size. Model size is > important to us. > > My question is whether a dual core Linux system would use multi-processing > Performer and make copies of the model within the 32 bit addressing space. > > Thanks, > Steve > > > On Wed, 21 Dec 2005, Praveen Bhaniramka wrote: > > >>Hi Steve, >> >>Can more processing power ever be bad for us engineers? :-) >> >>Your choice of systems depends on your applications needs. Since you are >>using Performer, which uses a multi-processing model of execution, you >>should see some speed-up in your application with multiple CPUs. >>However, the actual speed-up would really depend on the multi-processing >>scheme that your application uses (APP, CULL, DRAW) and how much time is >>spend in executing each process. >> >>Typically, volume rendering ends up being a heavily pixel-fill limited >>operation. Hence, if you are running something like volview, the CPU is >>sitting idle most of the time, waiting for the GPUs to get done with the >>rendering. However, if your application is doing more sophisticated >>processing like UI processing or data manipulation, the CPU load is >>probably higher. >> >>Hth, >>Praveen >> >> >>>-----Original Message----- >>>From: owner-info-volumizer@els.sgi.com >>>[mailto:owner-info-volumizer@els.sgi.com] On Behalf Of Steve >>>Satterfield >>>Sent: Wednesday, December 21, 2005 3:38 AM >>>To: Volumizer Mailing List >>>Cc: Steve Satterfield >>>Subject: [info-volumizer] Volumizer on a Dual Core Dell with SuSe >>> >>> >>> >>>Hi, >>> >>>I sent the folloiwng message to the performer Email list, but >>>I have the >>>same quesiton with regard to Volumizer. Are dual core 32 bit >>>Linux systems >>>a good or bad idea for the 32 bit Volumizer distribution? >>> >>>Thanks, >>>Steve >>> >>> ---------- Forwarded message ---------- >>> Date: Tue, 20 Dec 2005 17:01:51 -0500 >>> From: Steve Satterfield >>> To: Performer Mailing List >>> Subject: Performer on a Dual Core Dell with SuSe >>> >>> Can anyone provide me with any advice on using 32 Bit >>>Performer for Linux on >>> a dual core system? We are looking at buying a few 32 Bit >>>Linux machines, >>> probably Dell and running SuSe and Performer. >>> >>> Does having 2 CPUs give you any advantage with regard to >>>Performer. Can the >>> 32 Bit Linux distribution do any multi-processing? >>> >>> If there are no advantages, are than any disadvantages? >>> >>> Thanks for any advice, I need to make a buying decision very soon. >>> >>> -Steve >>> >> >> >> > > > From info-volumizer-owner@els.sgi.com Mon Dec 26 19:56:29 2005 Received: (from majordom@localhost) by els.sgi.com (8.12.10/8.12.2/els-2.2) id jBR3swT1349517; Mon, 26 Dec 2005 19:54:58 -0800 (PST) Received: from exchange.keenmedia.net (placeholder55.lanset.com [208.187.162.55] (may be forged)) by els.sgi.com (8.12.10/8.12.2/els-2.2) with ESMTP id jBQHnsx3353177 for ; Mon, 26 Dec 2005 09:49:56 -0800 (PST) Subject: [info-volumizer] Visual Studio 2005 && Volumizer MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C60A44.C4EC9732" Date: Mon, 26 Dec 2005 09:49:25 -0800 Content-class: urn:content-classes:message Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Visual Studio 2005 && Volumizer Thread-Index: AcYKRLWvbbzJuS5uTRSZWVq2iQv50A== From: "Tommy" To: Sender: owner-info-volumizer@els.sgi.com Precedence: bulk Reply-To: info-volumizer@els.sgi.com This is a multi-part message in MIME format. ------_=_NextPart_001_01C60A44.C4EC9732 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 I was wondering if anyone has ported the volumizer project to Visual = Studio 2005 yet and if they would be willing to provide it as a = download? It seems like the project needs a bit of cleanup anyways so = if anyone is interested in this or has done it already, let me know. Thanks, Thomas Goddard thomasgoddard.com ------_=_NextPart_001_01C60A44.C4EC9732 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
=0A=
 
=0A=
I was wondering if anyone has ported = the volumizer =0A= project to Visual Studio 2005 yet and if they would be willing to = provide it as =0A= a download?  It seems like the project needs a bit of cleanup = anyways so if =0A= anyone is interested in this or has done it already, let me =0A= know.

Thanks,
Thomas Goddard
=0A=
thomasgoddard.com
------_=_NextPart_001_01C60A44.C4EC9732--