Addressing is misbehaving for volume textures [DX9]

[51mon]

[SOLVED] Addressing is misbehaving for volume textures [DX9]

Just in case anybody experience the same problem as me and stumble on this thread, I put out the solution.

The solution was rather simple and it was related to addressing in a kind of way. The problem was that D3DXCreateVolumeTextureFromFile filtered the source data in an incorrect way (at least from my point of view). So I just changed to D3DXCreateVolumeTextureFromFileEx and specified the D3DX_FILTER_POINT method explicitly. In photoshop the texture looked alright, which fooled me to suspect the hardware addressing.

When I loaded the texture with D3DXCreateTextureFromFile the filters worked as I expected (no overlapping on the perimeter). I don't know, maybe the D3DXCreateVolumeTextureFromFile function works as it should, or maybe it's a bug?


Hi
I'm storing skydome data in a volume texture. The data got accessed with float3(zenith angle, azimuth angle, time of day).

The problem I'm facing is that no matter what addressing and filter mode I use the texture is always bleeding into the opposite side on the perimeter (back, front, right, left). See the image below.

In order to make the example more clear I have used point sampling but the artefact is present in linear sampling as well. As you can see the stripe in the middle got colour values blended between right and left edge of the texture, peculiar in my opinion especially since point sampling is used and no blending should occur. This is the setup of the sampler:

sampler sampSkydomeLookup =
sampler_state
{
Texture = <texSkydomeLookup>;
MinFilter = POINT;
MagFilter = POINT;
MipFilter = NONE;
AddressU = MIRROR;
AddressV = CLAMP;
AddressW = CLAMP;
};​

I have tried different variants but no luck. When I change the texture to regular 2D the problem goes away. I can't see any problems with the coordinates eighter. I have tried the code on both nVidia and ATI machines and both displayed the error.

Have anybody experienced this before? Does anybody know where this problem come from?


Thanks

 

[Nick]

What's the output of the reference rasterizer? If that produces the same result the problem is in your code or something is specified to work differently than you expected.

By the way, storing skydome data in a volume texture sounds weird. Exactly what are you storing and how is it being used?

 

[51mon]

What's the output of the reference rasterizer? If that produces the same result the problem is in your code or something is specified to work differently than you expected.

By the way, storing skydome data in a volume texture sounds weird. Exactly what are you storing and how is it being used?

I got the same result with ref, but thanks for pointing that out

I'm still prototyping but the idea is based on the assumption that the shade of the atmosphere is symmetric around the "zenith axe" (excluding clouds). So at a certain time of the day, shading data can be stored in texture and looked-up with spherical coordinates (2D). I generate the data in even intervals and store them in a volume texture. Therefore the coordinates are float3(azimuth angle, zenith angle, time of day).

In my implementation the "data" is stored as RGB intensity values, but if a more dynamic system is required, intermediate data in the light transportation equation could be used instead. Since the data is continuous in all dimensions, linear interpolation do a good job. This is only valid when the camera is positioned near the ground.

 

[Voxilla]

You have to take care where you sample in the Z direction.
You have to sample in the middle of voxels.
With DX9 this is like for the z coord: ( z +0.5) / ZnrVoxels

 

[51mon]

You have to take care where you sample in the Z direction.
You have to sample in the middle of voxels.
With DX9 this is like for the z coord: ( z +0.5) / ZnrVoxels

Sorry, but I can't see how that would be relevant here. In fact I want to sample in between texels to make nice transitions as time goes by (the boxy picture in the top-post was just made to emphasize the error)

 

[Voxilla]

Sorry, but I can't see how that would be relevant here. In fact I want to sample in between samples to make nice transistions as time goes by (the boxy picture in the top-post was just made to emphasize the error)

Mabye post your shader code then, we are just guessing.

 

[51mon]

Mabye post your shader code then, we are just guessing.

There is not so much to the code:

float4 DrawSkydomePS( VS_SKYDOME_OUT Input) : COLOR0
{	
	float3 coordLookup;
	
	// Obtain the lookup coord
	float3 eyeToSphereNorm = normalize( Input.eyeToSphere);
	coordLookup.x = atan( eyeToSphereNorm.z / abs( eyeToSphereNorm.x) + 0.000001f);
	coordLookup.y = acos( eyeToSphereNorm.y);	
	coordLookup.z = g_sunDir.y;
	coordLookup.xyz *= float3( 0.63661977f * 0.5f, 0.63661977f, 0.5f);
	coordLookup.xz += 0.5f;
	
	return tex3D( sampSkydomeLookup, coordLookup);
}

Based on the appearance of the artefact and the fact that it works fine when I change to 2d texture; it feels like some addressing issue?


Thanks

 

[Humus]

coordLookup.x = atan( eyeToSphereNorm.z / abs( eyeToSphereNorm.x + 0.000001f));

Do you need that epsilon? And if so, shouldn't it be:

coordLookup.x = atan( eyeToSphereNorm.z / (abs(eyeToSphereNorm.x) + 0.000001f));

 

[51mon]

Do you need that epsilon? And if so, shouldn't it be:

coordLookup.x = atan( eyeToSphereNorm.z / (abs(eyeToSphereNorm.x) + 0.000001f));

Yeah, that's right and I don't think I need it to be honest. Just something I put there for safety until I figure the error out.