dependent 3D-textures

Hi NG!

Does anyone here have some experience with dependent 3D-textures on the Nvidia GeForce 3?I wonder if it is possible to have one texture map to map into itself?

What I’m thinking about is that I upload only texture to - let’s say tex unit 0. And do a dependent texture fetch on unit one as well. Is that possible or can I only do that using two texture units?

Is it furthermore possible to have 2 textures use the same dependent texture? Say I upload one texture to unit 0 and do a dependent fetch on unit 2 and upload another texture to unit 1 and to a dependent fetch on texture unit 2 as well.

  • Jens

you can have per texture unit one fetch on the there bound texture. you can use results of previous fetches to set up the texture-coordinates for the particular fetch, but you fetch on the current texture…

if you want two times the same texture, simply bind it for two texture-units…

this answers the last question i guess,too

If ARB_texture_env_crossbar is supported on your hardware (I don’t know whether it is or not), that might be a way around that limitation.

>if you want two times the same texture, >simply bind it for two texture-units…

That answers the second question but my first question is if I can use only one texture-UNIT to do both. The first fetch and and the dependent fetch? The problem is that in my app i only have one “free” texture unit. Is it possible to use unit one for both fetches?

  • Jens

What does “ARB_texture_env_crossbar” do?
-Jens

Jens,

It actually answers both questions. You can only do one fetch per texture unit. If you had one unit do a fetch, and then a dependent fetch, then that would be two fetches in one unit, which is not supported.

texture_env_crossbar supports routing the output of any texture fetch unit to any application unit; the original texture_env_combine functionality only supports accessing the output of the previous texture unit and the texture fetched from the current unit. nVIDIA does not support texture_env_crossbar; you’d have to use register combiners there instead.

[This message has been edited by jwatte (edited 03-09-2002).]

What does “ARB_texture_env_crossbar” do?

It enables the texture samples (not the combiner output) from any texture unit to be mapped to an input of another texture environment. I seriously do not know whether that can help you as I have exactly zero knowledge of shaders - and these are AFAIK required to do dependant reads.

Anyway, I merely suggested having a look at the spec. It can do wonders while in TEXTURE_ENV_COMBINE mode. It is archived here .

[This message has been edited by zeckensack (edited 03-08-2002).]

If you want to use a 3D texture lookup, to perform a new lookup in a 3D texture ( and on a GeForce3 ), then you’ll need to use 4 texture units. The first stage fetches RGBA given (s,t,r), the next three stages perform dotproducts and uses that to fetch a new texel. NV_texture_shaders2 extension is required.

You can do a dependent 3D lookup using the NV_texture_shader3 extension on GF4Ti:
http://www.nvidia.com/dev_content/nvopenglspecs/GL_NV_texture_shader3.txt

> 33. DEPENDENT_RGB_TEXTURE_3D_NV - Converts the red, green, and
> blue components of a previous shader RGBA result into an (s,t,r)
> texture coordinate set to access a 3D non-projective texture.

As for ARB_texture_env_crossbar, if you search, you will see in this forum that I have previously explained why we support the functionality, but through a different interface, namely, NV_texture_env_combine4, and why we cannot ever support crossbar (in short, the ARB screwed up and ignored our advice).

  • Matt

Just a question:

what does “dependent texture fetch” mean. Dependent on what exactly?

V-man

Dependent on another texture. You fetch a texel from a texture, then use the texel value to address into another texture, either by some fixed lookup function or through some arbitrary math in a fragment shader.

Originally posted by Humus:
Dependent on another texture. You fetch a texel from a texture, then use the texel value to address into another texture, either by some fixed lookup function or through some arbitrary math in a fragment shader.

Well, Im more awake now, so ic

Is there a good demonstration of this? and also wont coordinates be limited from 0 to 255 (unsigned char).

V-man

Well, we are dealing with [0,1] as usual, but nothing prevents you from scaling you texel values to wider ranges (at least in a fragment shader).

The best example of dependent texture reads is EMBM, where you fetch a texel from the bumpmap and use that as an offset on the texture coords on an environment map.

Originally posted by PH:
If you want to use a 3D texture lookup, to perform a new lookup in a 3D texture ( and on a GeForce3 ), then you’ll need to use 4 texture units. The first stage fetches RGBA given (s,t,r), the next three stages perform dotproducts and uses that to fetch a new texel. NV_texture_shaders2 extension is required.

PH why do I need 4 texture units or do you think of for combiner stages? I both cases why can’t I simply use the RGB values as STR directly?

  • Jens

Using RGB directly as (s,t,r) is not an operation that’s supported on the GeForce3. Dependent texture lookups are supported on the GeForce3 via texture shaders. There are other operations that do not require 4 texture stages such as using AR or GB of a previous stage to access a 2D texture.

Jens,

I didn’t explain that very well, have you seen this presentation,
http://developer.nvidia.com/view.asp?IO=texture_shaders

It talks about texture shaders on the GeForce3. The stages that I mentioned are the shader stages as shown in the presentation.