Not logged in, Join Here! or Log In Below:  
 
News Articles Search    
 

 Home / 3D Theory & Graphics / x, y, z, w - need clarification on the w please. Account Manager
 
Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.
 
Steven Hansen

March 15, 2005, 05:45 PM

Hi.

I'm working on a shader. I want to manipulate the geometry in world space, perform the projection using the concatenated view/perspective matrices, and then perform a small tweak in viewspace coordinates.

I think my problem is that the final coordinates before the last tweak have a w of non-zero, so adding my viewspace tweak won't work without a bit more understanding.

Let's say the vector has w not equal 1. What does this mean for additional transforms. I know the position has been transformed to viewspace (that box that's 2 wide, 2 high, and 1 deep). What do I need to do next to add say half the view width (1.0f)? I wanted to try: position + float4(0.5f, 0, 0, 0). But this doesn't work.

Can anyone enlighten me on that w beast? Thanks.

 
Reedbeta

March 15, 2005, 09:48 PM

The point hasn't truly been transformed to screen-space until you have divided the other coordinates by W. If you have multiplied by the model-view-projection matrix and not divided yet, the point is in a wierd sort of space called 'clip space', which is shaped like a pyramid.

I'm not sure why you would want to manipulate vectors in this space, but if you do, you can probably do it by multiplying your desired vector by the W of the vector you're adding it to. So (X, Y, Z, W) would become (X + 1.0W, Y, Z, W). Note that when you later divide by W, to map it into screen space, this will become (X/W + 1.0, Y/W, Z/W, 1) which is just the same as adding your desired vector directly in screen space.

 
Steven Hansen

March 16, 2005, 12:55 PM

So you are saying I should multiply my offset vector by the w in the transformed position vector? I tried this previously but I now realize that I forgot to change the array index for my offsets (stupid me. Only vertex[0] had a valid offset).

Now it seems to function for everything in front of the camera. For some odd reason however, anything that is partially in front and partially behind the camera (an arrow through the viewers eye) behaves very strangely. I can't place my finger on what is wrong, but the width seems to increase and then decrease as the object travels through the camera, and the tex coordinates seem wrong somehow (even though I've applied no changes to them).

Any ideas?

BTW - I'm using this approach to simulate lines with quads, but I want lines to have the same thickness regardless of their viewing angle/distance from camera/etc. The offsets mentioned are viewer aligned vectors orthogonal to the line direction. I just need them to have the same width on screen - not in world space.

Thanks.

 
Rui Martins

March 16, 2005, 01:14 PM

BTW - I'm using this approach to simulate lines with quads, but I want lines to have the same thickness regardless of their viewing angle/distance from camera/etc. The offsets mentioned are viewer aligned vectors orthogonal to the line direction. I just need them to have the same width on screen - not in world space.


Shouldn't you be using an orthogonal transformation instead of a perspective one ?
Or this a special case just for lines ?

If it is, why don't you bring all the lines, temporarily (every frame), to a fixed distance from the camera ?

But I find this very odd, because Perspective Transforms implicitly include foreshortnening, which in plain words means "reduce the size with distance from eye (camera)".

 
Steven Hansen

March 16, 2005, 01:39 PM

I appreciate the thoughts into the problem.

Essentially, I want 3D lines. But I don't want the problems inherent in DirectX lines (no texture, no multi-sampling, no etc etc). This particular case is very specific, and embedded in the vertex stream is information on how to extend the line positions for width so the quad will be aligned correctly.

No - I don't want an orthogonal transform - the length of the line should be perspective correct based on its depth.

So, I have things setup the way I need them, I just need to have all the lines the same width regardless of distance from eye. Like I already mentioned, everything in front of the camera looks correct. The objects piercing the camera don't. Any ideas?

 
Steven Hansen

March 16, 2005, 02:55 PM

Ok - update.

I tried manually dividing through by w before adding my offset. This works perfect! Except...

Now my coordinates are in rhw, so clipping thinks it has already been done, and objects behind the camera are projected to z=0 (or something similar). Ick.

I really can't quite wrap my mind around what is going on. If I divide through by w and then add my offset, everything looks like I expect except the objects behind the camera aren't clipped. If I multiply my offset by w, then clipping occurs, but now objects look strange when they get close to the camera.

In both cases, I'm pretty sure that the math is the same, so I'm baffled at the difference. (x/w) + a = (x + a*w) / w. And that sums up the two approaches. Somehow though, simply multiplying my offset by w isn't perfectly correct.

 
Rui Martins

March 17, 2005, 06:52 AM

You mentioned "objects piercing the camera", that shouldn't happen, i.e. you can't have a correct display, if the camera can go through objects like a ghost. The objects will always look "funny".

If you really need this, you have to disable BackFace Culling, so that when you are inside an object, it's "Walls" won't magically disappear. But it will still look odd.

Essentially, I want 3D lines. But I don't want the problems inherent in DirectX lines (no texture, no multi-sampling, no etc etc)


In OpenGL lines can be textured without problems (usually 1D textures, but can also be 2D).
Is this a specific limitation of DirectX ?
If it is I didn't know about it.

 
tokjunior

March 17, 2005, 07:21 AM

Using D3DX for lines allow you texturing, width, anti-aliasing and all that stuff.

 
Steven Hansen

March 17, 2005, 12:25 PM

D3DXLine only works in screen space (2D). My lines must exist in world space (3D).

I was incorrect about the divide by w giving correct results - an early incorrect appraisal on my part. For whatever reason, as soon as the near points were behind the near clipping plane, the entire line would disappear, so I wasn't seeing the anomaly, but neither was I seeing the hind end of the lines that should have been visible. Interestingly enough, as soon as the line was far enough behind the camera, it would be projected back into the visible area (imagine the college physics class candle and mirrors presentation - where the candle is rightside up on one mirror, and upside down on the other). I just need it to clip correctly.

I'm imagining that I'm doing something slightly wrong. Simply adding (offset.x * transformedVector.w) to the transformedVector.x value isn't quite correct is my guess.

Does anyone see the missing link? Thanks.

 
Steven Hansen

March 17, 2005, 12:59 PM

Interestingly, the reason why objects behind the near plane were showing up after the divide by w was that I had culling off (no idea why). Turning culling on removed that problem.

I think I'm happy enough with this solution. If I need to manually clip to get perfect results, I can do that - but this application isn't critical enough to worry too much about absent lines... it just can't have bad looking lines. (The lines represent streaks of light... ala laser fighting or similar, not construction lines for walls and such).

This foray has taught me a few things about that w component. I still have some things to figure out, but that can wait until the next time I butt heads with that thing.

Thanks to everyone for the help!

 
theAntiELVIS

March 17, 2005, 03:36 PM

Don't use ID3DXLine - use a point list and the line primitive. You get true 3D lines, with texturing, anti-aliasing, whatever you want. About all you can't have is thickness greater than 1 pixel.

 
Steven Hansen

March 17, 2005, 05:51 PM

Actually they don't support anti-aliasing (multi-sampling). That was the consideration for using quads instead. Previously I had employed line-lists, and it worked fine. Then we wanted to do anti-aliasing (multi-sampling). After the changes were in place, the lines were still aliased. The documentation specifies that it only anti-aliases triangles (somewhere).

Additionally, I want width >1 pixel.

But - thanks for the info!

 
This thread contains 12 messages.
 
 
Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.