dependent texturing - NVIDIA

Graphics and GPU Programming Programming

Started by np39223 October 09, 2006 03:06 PM

4 comments, last by Eric Lengyel 17 years, 6 months ago

118

Author

October 09, 2006 03:06 PM

I have following problem with dependent texturing. I'm using ARB_multitexture, and NV_texture_shader. tex0 is B&W data and tex1 is color map texture. So I configure texture shader like this ..


	/// stage 0 - hold 2D displ. tex
	glEnable(GL_TEXTURE_SHADER_NV);
	glActiveTextureARB(GL_TEXTURE0_ARB);
	glTexEnvi(GL_TEXTURE_SHADER_NV, GL_SHADER_OPERATION_NV, GL_TEXTURE_2D);
	glTexEnvi(GL_TEXTURE_ENV, GL_SHADER_OPERATION_NV, GL_TEXTURE_2D);
	glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE);

	/// stage 1 - depTex TF
	glEnable(GL_TEXTURE_SHADER_NV);
	glActiveTextureARB(GL_TEXTURE1_ARB);
	glTexEnvi(GL_TEXTURE_SHADER_NV, GL_SHADER_OPERATION_NV, GL_DEPENDENT_GB_TEXTURE_2D_NV);
	glTexEnvi(GL_TEXTURE_SHADER_NV, GL_PREVIOUS_TEXTURE_INPUT_NV, GL_TEXTURE0_ARB);

Then i load textures like this


		///////////////////////////////////////////////
		// this is B&W data
		//////////////////////////////////////////////
		glActiveTextureARB(GL_TEXTURE0_ARB);
		glEnable(GL_TEXTURE_2D);
		glBindTexture(GL_TEXTURE_2D, texture[0]);


		glTexImage2D(GL_TEXTURE_2D, 0, 1, 256, 256, 0, GL_LUMINANCE, GL_UNSIGNED_BYTE, voxels);
		glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MIN_FILTER,GL_LINEAR);
		glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MAG_FILTER,GL_LINEAR);

		

		////////////////////////////////////////
		///  color TF
		///////////////////////////////////////////////////
		glActiveTextureARB(GL_TEXTURE1_ARB);
		glEnable(GL_TEXTURE_2D);
		glBindTexture(GL_TEXTURE_2D, texture[1]);
		
		glTexImage2D(GL_TEXTURE_2D, 0, 4 , 256, 256, 0, GL_RGBA, GL_UNSIGNED_BYTE, voxelsRGBA);
		glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MIN_FILTER,GL_LINEAR);
		glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MAG_FILTER,GL_LINEAR);

The problem is I want to use texture1 and it's RGBA components but dependent texturing affects only RGB components and alpha is allways the same in final image although I change volxelsRGBA[..] array where alpha is written. In other words I don't now how to use alpha, only RGB changes

Yann L

1,806

October 09, 2006 04:38 PM

Quote:Original post by np39223
The problem is I want to use texture1 and it's RGBA components but dependent
texturing affects only RGB components

Ughh, texture shaders. Damn, how I hated those. Glad they're gone...

Anyway, the colour format of the texture unit accessed by a dependent read is unaffected by the texture shader operation. It's only the format of the previous unit that is important for the operation (in your case, the green and blue components). The result from the dependent read on unit 1 should be a full RGBA value. Of course, you still need to configure the texture environment combiners to actually use that RGBA value in a sensible way.

That said, you should really stop using texture shaders. As said above, they're dead and gone nowadays. If the extension is buggy (which wouldn't surprise me in newer drivers), it will never be fixed.

You should look into programmable shaders instead, ie. GLSL, Cg, or ASM level fragment programs (which still have their place besides high level shaders, unlike texture shaders).

Anonymous

October 09, 2006 06:34 PM

Thanks Yann L,
why I am using texture shaders is because I'm working on hardware
accelerated volume rendering and I would like widest support possible. So
I guess NV_texture_shader is supported from GForce2 till now, so majority of
NVIDIA cards support it whereas GLSL, cg and other stuff aren't supported
on older cards.

So I need basicly tex.shaders to interactivly change transfer
functions in volume rendering and in the same time require support of minimum number of extensions as possible . . I'm limited with time but maby I even add
lighning effects to VR, such ass diffuse, specular, etc. So I'm not really sure how to do it - texture_shaders+register_combiners?
I'm not expert in per pixel lightning stuff, so I don't know is there an alternative to my outdated approach, I'm not even sure how long mentioned
extensions will be supported in new nvidia chipset.

So if there is better aproach then mine (to achieve max. compatibility +
interactive TF editing and lightning) I will be glad to find out. thx...

Yann L

1,806

October 09, 2006 07:10 PM

Quote:Original post by Anonymous Poster
Thanks Yann L,
why I am using texture shaders is because I'm working on hardware
accelerated volume rendering and I would like widest support possible. So
I guess NV_texture_shader is supported from GForce2 till now, so majority of
NVIDIA cards support it whereas GLSL, cg and other stuff aren't supported
on older cards.

Basic texture shaders were supported on GeForce3 on upwards, but they were extremely slow on that card. The more 'powerful' ones from GeForce4 on, but not really fast either. But as I mentioned, those extensions are really outdated, and for all practical purposes, they're dead. They won't ever be updated anymore, nor maintained. It's very well possible that future GPUs and driver revisions will entirely drop support for them, or introduce bugs that will break your code.

And as you noted, they're only supported by Nvidia, and won't work on ATI.

Quote:Original post by Anonymous Poster
So I need basicly tex.shaders to interactivly change transfer
functions in volume rendering and in the same time require support of minimum number of extensions as possible . . I'm limited with time but maby I even add
lighning effects to VR, such ass diffuse, specular, etc. So I'm not really sure how to do it - texture_shaders+register_combiners?

The best possible solution is to go with time, and use a modern form of shader programming through GLSL or Cg. Cg might be an even better option for you, since it can compile to old texture_shader and register_combiner profiles. Although this support might also be dropped in a not too distant future.

Seriously, texture shaders and register combiners are a dead end road. Save yourself the hassle, and use GLSL or fragment programs instead. They will be faster, they're vendor independent, and they're allow for much quicker development. But note that the ASM variant (ie. fragment programs) are not updated anymore, although they will still stick around for some time to come (support won't be removed from future drivers). But GLSL is definitely the way of the future.

np39223

118

Author

October 10, 2006 02:52 PM

Thanx for advice Yann L. I'm already learning GLSL, I started today and i already have some result. I was too thinking that GLSL could be better but I neded something to be sure. I couldn't make decision by my self. Problem is that all matherials about hardvare Volume Rendering were refering to NV_reg_comb and ATI_frag_shaders.. That was my main mental barrier. Now I'm sure.. thanx a lot!!

Eric Lengyel

3,463

October 10, 2006 11:49 PM

Quote:Original post by Yann L
But note that the ASM variant (ie. fragment programs) are not updated anymore

I just wanted to point out that Nvidia *is* still updating these. They have added quite a bit to the ARB VP and FP languages (and now geometry programs, too) for the next generation of GPUs.

I work on this stuff: Slug Library | C4 Engine | The 31st | Foundations of Game Engine Development | OpenGEX

dependent texturing - NVIDIA

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

dependent texturing - NVIDIA

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines