Paraboloid mapping in view space

Started by
18 comments, last by Viik 13 years, 11 months ago
I can't get paraboloid mapping to start working in view space. It works as it should if both paraboloid TranslationRotation matrix and vertices positions in World space but not when I convert both into View space. Code is basically similar to Jason's greate article. Thank you Jason! Basically vertex shader looks like this, it works just fine if all in world space:
float4	toWorld = mul(float4(input.pos.xyz, 1), object_to_world);
float4	clip_pos = mul( toWorld, mWVP ); //mWVP is a paraboloids InverseTraslationRotation matrix

clip_pos = clip_pos / clip_pos.w;
clip_pos.z = clip_pos.z * direction;
	
float L = length( clip_pos.xyz );
clip_pos = clip_pos / L;
	
output.z_value = clip_pos.z; //used for culling	
	
clip_pos.z = clip_pos.z + 1;
clip_pos.xy = clip_pos.xy / clip_pos.z;

clip_pos.z = L / 500;
clip_pos.w = 1;	

output.clip_pos = clip_pos;

return output;

Now I want to do it in view space so it goes like this at the beginning:

float4	toWorld = mul(float4(input.pos.xyz, 1), object_to_world);
float4	toView = mul(toWorld, viewM); //viewM is a projects view matrix
float4	clip_pos = mul( toView, mWVPv); //mWVPv is a paraboloids InverseTraslationRotationMatrix multiplyed by View matrix


It does rasterized as a paraboloid but content of rasterization changes as I move camera, I don't uderstand why, as both vertex and parabloid should be in view space right now. Does anybode has an idea why and how it can be solved? Maybe I need to first move paraboloid position and direction into view space, then make a matrix from it and use it as a basis, not sure that it will work and basically it will be kind a similar to what I have right now, if I'm not missing something here.
Advertisement
What are you trying to do in view space? I'm not entirely clear what the actual symptoms of the issue are - can you further describe what isn't working?

About the article: I'm happy you were able to use it! Did you use thestand alone article, or the section from the d3d10 book?
Quote:What are you trying to do in view space?

Shadow mapping in a light pre-pass. I'm restoring view space position of vetices later in the process, right now I'm just checking will it work in view space at all.

Quote:I'm not entirely clear what the actual symptoms of the issue are - can you further describe what isn't working?

Rasterized image of scene moves as I move camera, while it should remain static as nor vertices nor paraboloid basis is moving.

Quote:Did you use thestand alone article, or the section from the d3d10 book?

I think that was a standalone article here on gamedev.net, as I've implemented shadow mapping for omni lights using it, that was about a year ago.


I'm think that I really need to separately take position and rotation of paraboloid, move them into view space, then construct a matrix from them and use it as basis. Not just multiply paraboloids matrix with view matrix as I'm trying to do it now.
Tryed to move both position and direction of paraboloid into view space and make kind of LookAt matrix from them. It behaives differently but image is still moving as camera moves.

I have suspicion that in view space vertex translation into paraboloid's space dosn't work as it should. By the idea of algorithm, translation turns paraboloid's position into new origin of the scene and vertices are positioned realtive to it, but it view space axis's are different and translation dosn't move vertex properly in relation to paraboloids position.
I haven't done much with deferred rendering/light pre-pass rendering, so unfortunately I can't comment too much about it. However, from what I remember, the paraboloid basis matrix basically generates a view space from the location of the paraboloid and looking out from the orientation of that paraboloid. So the geometry that gets rendered into the paraboloid map is already in its own 'paraboloid view space'.

Is this the view space that you are talking about? If not, perhaps you could post a screen shot or two to illustrate the problem.
By View space I mean View space of project's camera, so it's view matrix of current camera. It stored separately. In gbuffer normals are stored in view space and fragment position reconstuction from depth is done into view space as well.

Basically when I render shadow map using parabaloid projection I can use world space position of vetices, but during sampling of shadow map I have only view space position. I can restore fragment position in world space but that would lead to some small overhead here and there that I'm trying to avoid.

Paraboloid in view space issue

1) is a what I get when vertices and paraboloid's position and rotation are in world space

2) vertices and paraboloid matrix multiplied by camera's view matrix

3) the same as 2, but camera orientation was changed
Ahhh - now I understand. I think what you want to do is to transform your view space position (from the G-buffer) back to world space, and then to paraboloid space. So you would want to multiply be the inverse of the view matrix (back to world space) and then multiply by the paraboloid matrix used to generate the paraboloid map.

Have you tried this yet?
That for sure will work, I just didn't wanted to do it, simply to avoid inverse view matrix multiplication and save some performance. Just found a small trick where I would need to do this only ones for a fragment, not for every fragment that every light can effect.
If you are doing a paraboloid map lookup, you must calculate the fragment's location relative to the paraboloid itself. Without this, you wouldn't know which part of the map to look in - so you are already doing at least one matrix multiplication per paraboloid shadow/environment map.

Concatenating that matrix with the inverse of the camera's view matrix should not be a performance issue - it is small potatos compared to the rendering that is going on. How many lights are you targetting for this operation?
In matrix multiplication A * B != B * A, however, for an affine matrix, A * B == B^(-1) * A.

You can save yourself a matrix inversion by switching your multiplication order, provided you know the input data is going to be kosher (which it should be, for a view matrix).

This topic is closed to new replies.

Advertisement