Hi, I am relatively new to opengl. I am trying to use 2D texture and
3D texture for volume rendering. that is, I have a volumetric image,
for example, 500 slices, each slice has 400 by 320 pixels. I want to
do the direct 3D volume rendering using opengl 2D texture or/and 3D
texture. can some one show me some sample codes how to do it?
are there any other ways for rendering the volume?
thanks,
Zhengrong Ying
|
|
0
|
|
|
|
Reply
|
zhengrongying
|
6/18/2004 6:44:06 PM |
|
Dale wrote:
> Hi, I am relatively new to opengl. I am trying to use 2D
> texture and 3D texture for volume rendering. that is, I have a
> volumetric image, for example, 500 slices, each slice has 400
> by 320 pixels. I want to do the direct 3D volume rendering
> using opengl 2D texture or/and 3D texture. can some one show me
> some sample codes how to do it?
This is the right attempt, however your image/volume dimensions
must be a power of 2. Instead of GL_TEXTURE_2D and you've to use
GL_TEXTURE_3D_ARB as the texture target.
But one problem will be the size of the final texture: Given your
dimensions with RGBA voxels will result in 244.2MiB needed
texture space. Using texture compression you can probably shrink
this about 1/3.
Wolfgang
|
|
0
|
|
|
|
Reply
|
Wolfgang
|
6/18/2004 11:13:36 PM
|
|
Wolfgang Draxinger <wdraxinger@darkstargames.de> wrote in message news:<cavsuj$es8$1@svr7.m-online.net>...
> Dale wrote:
>
> > Hi, I am relatively new to opengl. I am trying to use 2D
> > texture and 3D texture for volume rendering. that is, I have a
> > volumetric image, for example, 500 slices, each slice has 400
> > by 320 pixels. I want to do the direct 3D volume rendering
> > using opengl 2D texture or/and 3D texture. can some one show me
> > some sample codes how to do it?
>
> This is the right attempt, however your image/volume dimensions
> must be a power of 2. Instead of GL_TEXTURE_2D and you've to use
> GL_TEXTURE_3D_ARB as the texture target.
>
> But one problem will be the size of the final texture: Given your
> dimensions with RGBA voxels will result in 244.2MiB needed
> texture space. Using texture compression you can probably shrink
> this about 1/3.
>
> Wolfgang
thanks for the reply. can I load the whole images (244.2MB) into the
video card? for the 2D rendering, it requires three stacks of images.
this means it needs over 700 MB. But the Nvidia card (e.g. 5950) only
has 256MB memory. how do I do it?
thanks,
ZY
|
|
0
|
|
|
|
Reply
|
zhengrongying
|
6/19/2004 5:14:36 PM
|
|
Dale wrote:
> thanks for the reply. can I load the whole images (244.2MB)
> into the video card? for the 2D rendering, it requires three
> stacks of images. this means it needs over 700 MB. But the
> Nvidia card (e.g. 5950) only has 256MB memory. how do I do it?
Well, you could reduce the bits per pixel resolution. I'm not
sure, if texture compression is avaliable for 3D textures.
But one question: Why not write a small raycaster for this? If it
has not to be realtime this probably the more robust solution.
There are also some techniques to convert a volumetric dataset
into a a set of isosurfaces. I've a PDF about this here, I could
send it per Mail.
Wolfgang
|
|
0
|
|
|
|
Reply
|
Wolfgang
|
6/19/2004 8:04:38 PM
|
|
Wolfgang Draxinger <wdraxinger@darkstargames.de> wrote in message news:<cb2689$3di$1@svr7.m-online.net>...
> Dale wrote:
>
> > thanks for the reply. can I load the whole images (244.2MB)
> > into the video card? for the 2D rendering, it requires three
> > stacks of images. this means it needs over 700 MB. But the
> > Nvidia card (e.g. 5950) only has 256MB memory. how do I do it?
>
> Well, you could reduce the bits per pixel resolution. I'm not
> sure, if texture compression is avaliable for 3D textures.
>
> But one question: Why not write a small raycaster for this? If it
> has not to be realtime this probably the more robust solution.
>
> There are also some techniques to convert a volumetric dataset
> into a a set of isosurfaces. I've a PDF about this here, I could
> send it per Mail.
>
> Wolfgang
thanks for the reply again. The major problem is that the application
has to be in real time. Another issue which is worse is that the
original raw data can have different color schemes resulting in more
than one RGBA data sets for volume rendering. The isosurface is not
good for the application.
|
|
0
|
|
|
|
Reply
|
zhengrongying
|
6/20/2004 2:31:44 AM
|
|
Dale wrote:
> thanks for the reply again. The major problem is that the application
> has to be in real time. Another issue which is worse is that the
> original raw data can have different color schemes resulting in more
> than one RGBA data sets for volume rendering. The isosurface is not
> good for the application.
You may need to do a lot of memory management for this -- load a portion
of the volume, render it, load another portion, render it, etc. Multiple
threads should help overlap the operations.
You will probably need to have multiple resolutions of your volume, and
choose which resolution level to use based on distance from the eye and
how much long you can take to render the frame. You might want to keep
high frame rates at the expense of resolution while the user is
manipulating the volume, and have one more pass at high resolution
afterwards.
Good luck!
--
Andy V
|
|
0
|
|
|
|
Reply
|
Andy
|
6/20/2004 3:38:48 AM
|
|
Dale wrote:
>
> thanks for the reply again. The major problem is that the application
> has to be in real time. Another issue which is worse is that the
> original raw data can have different color schemes resulting in more
> than one RGBA data sets for volume rendering. The isosurface is not
> good for the application.
>
Well, isn't the original data 8 bit unsigned ? That's usually the case.
If so, you can load it as an 8 bit indexed 3D texture
(GL_COLOR_INDEX8_EXT) which fits into the video card memory (320*200*500
is ~64Mb), and then apply the RGBA transfer function using glColorTableEXT.
Also, there are different techniques for volume rendering. Mostly, you
have two techniques if you want hardware acceleration :
- draw the data using three sets of parallel slices
- draw the data using screen-parallel slices that intersect a 3d texture
As for source code, see for example this project :
http://openqvis.sourceforge.net/
Stephane
|
|
0
|
|
|
|
Reply
|
Stephane
|
6/20/2004 11:16:29 AM
|
|
Stephane Marchesin wrote:
> Well, isn't the original data 8 bit unsigned ? That's usually
> the case. If so, you can load it as an 8 bit indexed 3D texture
> (GL_COLOR_INDEX8_EXT) which fits into the video card memory
> (320*200*500 is ~64Mb), and then apply the RGBA transfer
> function using glColorTableEXT.
Also most cards having 3D texture support (expect GeForce3) have
cpability for executing pixelshaders, which can be used to
implement a flexible color table lookup:
Intensity of a voxel is the range coordinate for a 1D RGBA
texture, that gives the final color.
Wolfgang
|
|
0
|
|
|
|
Reply
|
Wolfgang
|
6/20/2004 11:24:42 AM
|
|
Andy V <nobody@nowhere.net> wrote in message news:<cF7Bc.200$Zx3.6863@petpeeve.ziplink.net>...
> Dale wrote:
>
> > thanks for the reply again. The major problem is that the application
> > has to be in real time. Another issue which is worse is that the
> > original raw data can have different color schemes resulting in more
> > than one RGBA data sets for volume rendering. The isosurface is not
> > good for the application.
>
> You may need to do a lot of memory management for this -- load a portion
> of the volume, render it, load another portion, render it, etc. Multiple
> threads should help overlap the operations.
>
> You will probably need to have multiple resolutions of your volume, and
> choose which resolution level to use based on distance from the eye and
> how much long you can take to render the frame. You might want to keep
> high frame rates at the expense of resolution while the user is
> manipulating the volume, and have one more pass at high resolution
> afterwards.
can someone show me or point me to some sample codes using opengl 2d
texture and 3d texture for volume rendering?
thanks,
zy
>
> Good luck!
|
|
0
|
|
|
|
Reply
|
zhengrongying
|
6/20/2004 5:11:23 PM
|
|
http://www.gris.uni-tuebingen.de/areas/scivis/volren/
"Dale" <zhengrongying@gmail.com> wrote in message
news:5d1bd0a0.0406200911.47a95e7@posting.google.com...
> Andy V <nobody@nowhere.net> wrote in message
news:<cF7Bc.200$Zx3.6863@petpeeve.ziplink.net>...
> > Dale wrote:
> >
> > > thanks for the reply again. The major problem is that the application
> > > has to be in real time. Another issue which is worse is that the
> > > original raw data can have different color schemes resulting in more
> > > than one RGBA data sets for volume rendering. The isosurface is not
> > > good for the application.
> >
> > You may need to do a lot of memory management for this -- load a portion
> > of the volume, render it, load another portion, render it, etc. Multiple
> > threads should help overlap the operations.
> >
> > You will probably need to have multiple resolutions of your volume, and
> > choose which resolution level to use based on distance from the eye and
> > how much long you can take to render the frame. You might want to keep
> > high frame rates at the expense of resolution while the user is
> > manipulating the volume, and have one more pass at high resolution
> > afterwards.
>
> can someone show me or point me to some sample codes using opengl 2d
> texture and 3d texture for volume rendering?
>
> thanks,
> zy
> >
> > Good luck!
|
|
0
|
|
|
|
Reply
|
JB
|
6/20/2004 7:26:44 PM
|
|
Wolfgang Draxinger <wdraxinger@darkstargames.de> wrote in message news:<cb3s5b$gm9$1@svr7.m-online.net>...
> Stephane Marchesin wrote:
>
> > Well, isn't the original data 8 bit unsigned ? That's usually
> > the case. If so, you can load it as an 8 bit indexed 3D texture
> > (GL_COLOR_INDEX8_EXT) which fits into the video card memory
> > (320*200*500 is ~64Mb), and then apply the RGBA transfer
> > function using glColorTableEXT.
>
> Also most cards having 3D texture support (expect GeForce3) have
> cpability for executing pixelshaders, which can be used to
> implement a flexible color table lookup:
>
> Intensity of a voxel is the range coordinate for a 1D RGBA
> texture, that gives the final color.
>
> Wolfgang
thanks all for the replies. In the 2D texture rendering, which opengl
commands shall I use to load 500 textures into the video card? after I
load the texture into the video memory, how do I do the blending? or I
should load one texture into video card memory at a time and do the
blending?
thanks,
ZY
|
|
0
|
|
|
|
Reply
|
zhengrongying
|
6/21/2004 2:10:21 PM
|
|
Wolfgang Draxinger <wdraxinger@darkstargames.de> wrote in message news:<cb3s5b$gm9$1@svr7.m-online.net>...
> Stephane Marchesin wrote:
>
> > Well, isn't the original data 8 bit unsigned ? That's usually
> > the case. If so, you can load it as an 8 bit indexed 3D texture
> > (GL_COLOR_INDEX8_EXT) which fits into the video card memory
> > (320*200*500 is ~64Mb), and then apply the RGBA transfer
> > function using glColorTableEXT.
>
> Also most cards having 3D texture support (expect GeForce3) have
> cpability for executing pixelshaders, which can be used to
> implement a flexible color table lookup:
>
> Intensity of a voxel is the range coordinate for a 1D RGBA
> texture, that gives the final color.
>
> Wolfgang
Also, what are the typical values assigned to alpha channel for each slice?
|
|
0
|
|
|
|
Reply
|
zhengrongying
|
6/21/2004 5:08:19 PM
|
|
Dale wrote:
> thanks all for the replies. In the 2D texture rendering, which
> opengl commands shall I use to load 500 textures into the video
> card? after I load the texture into the video memory, how do I
> do the blending? or I should load one texture into video card
> memory at a time and do the blending?
At a best you should use a 3D texture. Loading only one slice at
a time will result in a fairly bad performance.
Blending is easy: Just render the slices back to front and use
glBlendFunc(GL_SRC_COLOR, GL_ONE_MINUS_SRC_COLOR);
as the blend mode. The "brighter" the texture at the given
location is, the more it opaque the slice will be there.
Wolfgang
|
|
0
|
|
|
|
Reply
|
Wolfgang
|
6/21/2004 7:17:13 PM
|
|
start with (1/# of slices, or 1/255., whichever is larger).
I sugest that you run and look at the code for, one of the many volume
rendering open source
tools out there. It's a very complicated topic, especially managing more
texture memory
than will fit on the card, and you will be very hard pressed to do better
than what volren
does. (http://www.volren.org )
"Dale" <zhengrongying@gmail.com> wrote in message
news:5d1bd0a0.0406210908.7ff1c92a@posting.google.com...
> Wolfgang Draxinger <wdraxinger@darkstargames.de> wrote in message
news:<cb3s5b$gm9$1@svr7.m-online.net>...
> > Stephane Marchesin wrote:
> >
> > > Well, isn't the original data 8 bit unsigned ? That's usually
> > > the case. If so, you can load it as an 8 bit indexed 3D texture
> > > (GL_COLOR_INDEX8_EXT) which fits into the video card memory
> > > (320*200*500 is ~64Mb), and then apply the RGBA transfer
> > > function using glColorTableEXT.
> >
> > Also most cards having 3D texture support (expect GeForce3) have
> > cpability for executing pixelshaders, which can be used to
> > implement a flexible color table lookup:
> >
> > Intensity of a voxel is the range coordinate for a 1D RGBA
> > texture, that gives the final color.
> >
> > Wolfgang
>
> Also, what are the typical values assigned to alpha channel for each
slice?
|
|
0
|
|
|
|
Reply
|
JB
|
6/22/2004 3:47:23 AM
|
|
"JB West" <jbwest@NOSPAM_acm.org> wrote in message news:<Wf-dnVZPvrA0NkrdRVn-hQ@comcast.com>...
> start with (1/# of slices, or 1/255., whichever is larger).
>
> I sugest that you run and look at the code for, one of the many volume
> rendering open source
> tools out there. It's a very complicated topic, especially managing more
> texture memory
> than will fit on the card, and you will be very hard pressed to do better
> than what volren
> does. (http://www.volren.org )
>
>
> "Dale" <zhengrongying@gmail.com> wrote in message
> news:5d1bd0a0.0406210908.7ff1c92a@posting.google.com...
> > Wolfgang Draxinger <wdraxinger@darkstargames.de> wrote in message
> news:<cb3s5b$gm9$1@svr7.m-online.net>...
> > > Stephane Marchesin wrote:
> > >
> > > > Well, isn't the original data 8 bit unsigned ? That's usually
> > > > the case. If so, you can load it as an 8 bit indexed 3D texture
> > > > (GL_COLOR_INDEX8_EXT) which fits into the video card memory
> > > > (320*200*500 is ~64Mb), and then apply the RGBA transfer
> > > > function using glColorTableEXT.
> > >
> > > Also most cards having 3D texture support (expect GeForce3) have
> > > cpability for executing pixelshaders, which can be used to
> > > implement a flexible color table lookup:
> > >
> > > Intensity of a voxel is the range coordinate for a 1D RGBA
> > > texture, that gives the final color.
> > >
> > > Wolfgang
> >
> > Also, what are the typical values assigned to alpha channel for each
> slice?
Another question, in my 500 slices of images, most of them are
backgrounds, so I assign RGB zero values to the background, and after
I blend, I got very dark images. or even without blending, each image
is very dark too. Is there a way for doing an inverse video operation
in glut?
thanks,
ZY
|
|
0
|
|
|
|
Reply
|
zhengrongying
|
6/23/2004 9:31:46 PM
|
|
Dale wrote:
> Another question, in my 500 slices of images, most of them are
> backgrounds, so I assign RGB zero values to the background, and after
> I blend, I got very dark images. or even without blending, each image
> is very dark too. Is there a way for doing an inverse video operation
> in glut?
You are using OpenGL to render, not GLUT. GLUT is just an aid to
creating windows and contexts.
If you have dark images, this suggests to me you have low color values
but moderate alpha values. Consider scaling the alpha value by half to
see if that works correctly.
Are your colors pre-weighted by their opacity? (In other words, do your
color values range from 0.0 to alpha?) If so, you should use a blend of
(GL_ONE, GL_ONE_MINUS_SRC_ALPHA). If your colors are not pre-weighted
(color values range from 0.0 to 1.0), the usual blend (GL_SRC_ALPHA,
GL_ONE_MINUS_SRC_ALPHA) is appropriate.
Your "background" values I think are meant to be "transparent". Make
sure their alpha components are 0.0.
What do you want for "inverse video" anyway -- just a white background?
Set the clear color to (1,1,1,0) for one effect, or (1,1,1,1) for another.
--
Andy V
|
|
0
|
|
|
|
Reply
|
Andy
|
6/24/2004 1:09:05 AM
|
|
Andy V <nobody@nowhere.net> wrote in message news:<RQpCc.227$Zx3.7603@petpeeve.ziplink.net>...
> Dale wrote:
>
> > Another question, in my 500 slices of images, most of them are
> > backgrounds, so I assign RGB zero values to the background, and after
> > I blend, I got very dark images. or even without blending, each image
> > is very dark too. Is there a way for doing an inverse video operation
> > in glut?
>
> You are using OpenGL to render, not GLUT. GLUT is just an aid to
> creating windows and contexts.
>
> If you have dark images, this suggests to me you have low color values
> but moderate alpha values. Consider scaling the alpha value by half to
> see if that works correctly.
>
> Are your colors pre-weighted by their opacity? (In other words, do your
> color values range from 0.0 to alpha?) If so, you should use a blend of
> (GL_ONE, GL_ONE_MINUS_SRC_ALPHA). If your colors are not pre-weighted
> (color values range from 0.0 to 1.0), the usual blend (GL_SRC_ALPHA,
> GL_ONE_MINUS_SRC_ALPHA) is appropriate.
>
> Your "background" values I think are meant to be "transparent". Make
> sure their alpha components are 0.0.
>
> What do you want for "inverse video" anyway -- just a white background?
> Set the clear color to (1,1,1,0) for one effect, or (1,1,1,1) for another.
thanks for the suggestions. I found that I did not set the backgrounds
to complete transparent, that is why my image is so dark.
also I have used blend(GL_ONE_MINUS_DST_COLOR,GL_ZERO) with an all-one
image to make the reverse the video successfully.
I have another question, I can only load size of power of two images
as 2D textures into the video memory. Is this the limitation of a
video card? or it is the limitation of the opengl?
thanks,
ZY
|
|
0
|
|
|
|
Reply
|
zhengrongying
|
6/25/2004 9:03:30 PM
|
|
Dale wrote:
>
> I have another question, I can only load size of power of two images
> as 2D textures into the video memory. Is this the limitation of a
> video card? or it is the limitation of the opengl?
>
Both.
Limiting textures to a power of two makes
the hardware easier to make so OpenGL made
it the law.
--
<\___/> "To err is human, to moo bovine."
/ O O \
\_____/ FTB. For email, remove my socks.
|
|
0
|
|
|
|
Reply
|
fungus
|
6/25/2004 11:17:41 PM
|
|
There's non-power-of-2 extensions available for 2D textures.
"Dale" <zhengrongying@gmail.com> wrote in message
news:5d1bd0a0.0406251303.3ef78c49@posting.google.com...
> Andy V <nobody@nowhere.net> wrote in message
news:<RQpCc.227$Zx3.7603@petpeeve.ziplink.net>...
> > Dale wrote:
> >
> > > Another question, in my 500 slices of images, most of them are
> > > backgrounds, so I assign RGB zero values to the background, and after
> > > I blend, I got very dark images. or even without blending, each image
> > > is very dark too. Is there a way for doing an inverse video operation
> > > in glut?
> >
> > You are using OpenGL to render, not GLUT. GLUT is just an aid to
> > creating windows and contexts.
> >
> > If you have dark images, this suggests to me you have low color values
> > but moderate alpha values. Consider scaling the alpha value by half to
> > see if that works correctly.
> >
> > Are your colors pre-weighted by their opacity? (In other words, do your
> > color values range from 0.0 to alpha?) If so, you should use a blend of
> > (GL_ONE, GL_ONE_MINUS_SRC_ALPHA). If your colors are not pre-weighted
> > (color values range from 0.0 to 1.0), the usual blend (GL_SRC_ALPHA,
> > GL_ONE_MINUS_SRC_ALPHA) is appropriate.
> >
> > Your "background" values I think are meant to be "transparent". Make
> > sure their alpha components are 0.0.
> >
> > What do you want for "inverse video" anyway -- just a white background?
> > Set the clear color to (1,1,1,0) for one effect, or (1,1,1,1) for
another.
>
> thanks for the suggestions. I found that I did not set the backgrounds
> to complete transparent, that is why my image is so dark.
> also I have used blend(GL_ONE_MINUS_DST_COLOR,GL_ZERO) with an all-one
> image to make the reverse the video successfully.
>
> I have another question, I can only load size of power of two images
> as 2D textures into the video memory. Is this the limitation of a
> video card? or it is the limitation of the opengl?
>
> thanks,
> ZY
|
|
0
|
|
|
|
Reply
|
JB
|
6/26/2004 2:38:23 AM
|
|
JB West wrote:
> There's non-power-of-2 extensions available for 2D textures.
>
Um, yes, but it doesn't work like normal
textures. There's no repeat and the coordinates
are funny.
A: Top posters
Q: Whats the most annoying thing on Usenet?
> "Dale" <zhengrongying@gmail.com> wrote in message
> news:5d1bd0a0.0406251303.3ef78c49@posting.google.com...
>
>>Andy V <nobody@nowhere.net> wrote in message
>
> news:<RQpCc.227$Zx3.7603@petpeeve.ziplink.net>...
>
>>>Dale wrote:
>>>
>>>
>>>>Another question, in my 500 slices of images, most of them are
>>>>backgrounds, so I assign RGB zero values to the background, and after
>>>>I blend, I got very dark images. or even without blending, each image
>>>>is very dark too. Is there a way for doing an inverse video operation
>>>>in glut?
>>>
>>>You are using OpenGL to render, not GLUT. GLUT is just an aid to
>>>creating windows and contexts.
>>>
>>>If you have dark images, this suggests to me you have low color values
>>>but moderate alpha values. Consider scaling the alpha value by half to
>>>see if that works correctly.
>>>
>>>Are your colors pre-weighted by their opacity? (In other words, do your
>>>color values range from 0.0 to alpha?) If so, you should use a blend of
>>>(GL_ONE, GL_ONE_MINUS_SRC_ALPHA). If your colors are not pre-weighted
>>>(color values range from 0.0 to 1.0), the usual blend (GL_SRC_ALPHA,
>>>GL_ONE_MINUS_SRC_ALPHA) is appropriate.
>>>
>>>Your "background" values I think are meant to be "transparent". Make
>>>sure their alpha components are 0.0.
>>>
>>>What do you want for "inverse video" anyway -- just a white background?
>>>Set the clear color to (1,1,1,0) for one effect, or (1,1,1,1) for
>
> another.
>
>>thanks for the suggestions. I found that I did not set the backgrounds
>>to complete transparent, that is why my image is so dark.
>>also I have used blend(GL_ONE_MINUS_DST_COLOR,GL_ZERO) with an all-one
>>image to make the reverse the video successfully.
>>
>>I have another question, I can only load size of power of two images
>>as 2D textures into the video memory. Is this the limitation of a
>>video card? or it is the limitation of the opengl?
>>
>>thanks,
>>ZY
>
>
>
--
<\___/> "To err is human, to moo bovine."
/ O O \
\_____/ FTB. For email, remove my socks.
|
|
0
|
|
|
|
Reply
|
fungus
|
6/26/2004 9:44:23 AM
|
|
fungus wrote:
> Um, yes, but it doesn't work like normal
> textures. There's no repeat and the coordinates
> are funny.
Not to forget the lack of mipmapping...
Wolfgang
|
|
0
|
|
|
|
Reply
|
Wolfgang
|
6/26/2004 9:45:54 AM
|
|
I found that "NV_texture_rectangle" allows the arbitrary dimension of
the 2d texture, however, I heard that it only allows to load one 2D
texture into the video memory (versus 500 2D textures). Is this true?
thanks
ZY
Wolfgang Draxinger <wdraxinger@darkstargames.de> wrote in message news:<cbjgjm$p0n$1@svr7.m-online.net>...
> fungus wrote:
>
> > Um, yes, but it doesn't work like normal
> > textures. There's no repeat and the coordinates
> > are funny.
>
> Not to forget the lack of mipmapping...
>
> Wolfgang
|
|
0
|
|
|
|
Reply
|
zhengrongying
|
7/2/2004 5:48:30 PM
|
|
Dale wrote:
> I found that "NV_texture_rectangle" allows the arbitrary dimension of
> the 2d texture, however, I heard that it only allows to load one 2D
> texture into the video memory (versus 500 2D textures). Is this true?
>
No.
Remember, NV_texture_rectangle places a lot of
limitations on the texture. No mipmapping, no
repeat, coordinates not in range (0,1), etc.
Basically the only thing NV_t_r does is save video
memory - without it you have to use the bottom-left
rectangle of a larger texture when you're using
textures as bitmaps. All the unused "border" area
is wasted memory.
--
<\___/> "To err is human, to moo bovine."
/ O O \
\_____/ FTB. For email, remove my socks.
|
|
0
|
|
|
|
Reply
|
fungus
|
7/2/2004 6:10:59 PM
|
|
Using 3D texture for volume rendering, do I have to re-slice by myself
or there is a function I can call to do it?
also in 2D texture rendering, at what angle should I change one stack
of 2D texture to another one? I am now switching at 45 degrees, and
have seen the significant jumping effect.
thanks,
ZY
fungus <openglMY@SOCKSartlum.com> wrote in message news:<TyhFc.1306958$A6.5287379@telenews.teleline.es>...
> Dale wrote:
>
> > I found that "NV_texture_rectangle" allows the arbitrary dimension of
> > the 2d texture, however, I heard that it only allows to load one 2D
> > texture into the video memory (versus 500 2D textures). Is this true?
> >
>
> No.
>
> Remember, NV_texture_rectangle places a lot of
> limitations on the texture. No mipmapping, no
> repeat, coordinates not in range (0,1), etc.
>
> Basically the only thing NV_t_r does is save video
> memory - without it you have to use the bottom-left
> rectangle of a larger texture when you're using
> textures as bitmaps. All the unused "border" area
> is wasted memory.
|
|
0
|
|
|
|
Reply
|
zhengrongying
|
7/19/2004 3:06:58 PM
|
|
Dale wrote:
> Using 3D texture for volume rendering, do I have to re-slice by myself
> or there is a function I can call to do it?
>
> also in 2D texture rendering, at what angle should I change one stack
> of 2D texture to another one? I am now switching at 45 degrees, and
> have seen the significant jumping effect.
I guess you can't avoid those artifacts without resampling
the volume.
Check out good old Vis5D's volume rendering capability
from Bill Hibbard (and his papers).
http://www.ssec.wisc.edu/~billh/vis5d.html
volume rendering screeny:
http://www.ssec.wisc.edu/~billh/vis5d2.gif
The technique used in Vis5D has exactly the same problem you
described above.
Cheers,
Toni
--
for mail, mirror: ed.lausivksa@elielb
|
|
0
|
|
|
|
Reply
|
Antonio
|
7/19/2004 4:16:16 PM
|
|
Dale wrote:
> Using 3D texture for volume rendering, do I have to re-slice by myself
> or there is a function I can call to do it?
Do you mean generating the proxy geometry (sampling planes)? OpenGL does
not have any operations to do this.
Do you mean generating stacks with a different orientation? That is only
needed for 2D texture mapping.
> also in 2D texture rendering, at what angle should I change one stack
> of 2D texture to another one? I am now switching at 45 degrees, and
> have seen the significant jumping effect.
For isotropic data, 45 degrees is appropriate.
You could render two or three stacks and blend between them to smooth
this out (say, between 40 and 50 degrees), but that would be slow.
--
Andy V
|
|
0
|
|
|
|
Reply
|
Andy
|
7/19/2004 10:58:55 PM
|
|
I am trying to use GL_COLOR_INDEX8_EXT and glColorTableEXT for the 2D
texture rendering. I am using Nvidia 5950 card, and have installed the
driver on the linux system. I included "glext.h" in my program, but I
am not able to link to "glColorTableEXT" function. Which library am I
supposed to link?
or a more general question: how do I use opengl extension functions?
does any one have a sample c/c++ program?
thanks,
ZY
Andy V <nobody@nowhere.net> wrote in message news:<PmYKc.312$Zx3.11081@petpeeve.ziplink.net>...
> Dale wrote:
> > Using 3D texture for volume rendering, do I have to re-slice by myself
> > or there is a function I can call to do it?
>
> Do you mean generating the proxy geometry (sampling planes)? OpenGL does
> not have any operations to do this.
>
> Do you mean generating stacks with a different orientation? That is only
> needed for 2D texture mapping.
>
> > also in 2D texture rendering, at what angle should I change one stack
> > of 2D texture to another one? I am now switching at 45 degrees, and
> > have seen the significant jumping effect.
>
> For isotropic data, 45 degrees is appropriate.
>
> You could render two or three stacks and blend between them to smooth
> this out (say, between 40 and 50 degrees), but that would be slow.
|
|
0
|
|
|
|
Reply
|
zhengrongying
|
7/21/2004 6:17:32 PM
|
|
|
26 Replies
476 Views
(page loaded in 0.221 seconds)
|