| |
LHS
Registered: Dec 2002
Posts: 66 |
Vector visibility - Z axis solution
Hi all,
I am coding a classical demo part - filled vector. I have a routine for vertex transformation (rotation) and a routine for EOR surface filling.
If I have f.e. a simple opaque cube (all angles are 90dgrs), what is the best technique to check which surface I may show and which I mustn't? I have f.e. 4 vertexes of a side (X, Y and Z coordinates in signed variable), how can I calculate, if is this surface (of the cube) visible or invisible? I think the same technique can be used for a glanz cube which surface is inner or outer.
Thanks,
LHS |
|
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
It's all quite easy. Simply check which side of the plane you're on.
A plane is defined by the following equation:
Ax+By+Cz+D=0 where A,B,C is the normal of the plane.
Conviniently the normals for a cube's surfaces are the unit vectors definied by your rotation matrix.
If you further assume that the cube is rotated around origo and doesn't move, then the x and y component of the equation is 0, only z is defined (distance from eye to rotation origo). This reduces the plane equation to:
Cz+D=0
If Cz+D>0 then z lies outside the plane (visible).
Now, C is derived (taken from) directly from the rotation matrix.
z is the eye relative to the cube, i.e. the distance to the cube (constant).
D is the distance from rotation origo to the plane's center expressed in units of normal-length (1).
Hence:
C*z+D>0 => C>D/z => C>constant (visible).
So, it's a simple compare on the Z-value of one of the unit axises in the rotation matrix depending on which of the 6 surfaces you want to check visibility on.
Now, I know Graham have an alternative explanation to this, but it boils down to the exact same equations (and code). I find his explanations less understandable, however you might not. Graham, please post your explanation.
Note: This method assumes:
1) Convex objects
2) If same constant is used for all surfaces then all surfaces must lie from the same distance from rotation origo, else you need one constant per surface.
3) No x,y,z movement of the object, i.e. fixed rotation origo.
4) If you're using the values of the rotation matrix directly to derive surface normals, all you can do is cubes. For other surfaces you need to rotate the normals first and use their rotated Z-values in the compare.
Good luck!
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
(p1x-p2x*p1y-p3y)-(p1y-p2y*p1x-p3x)
- all 3 points must lie in a plane of the face you're checking
- the rotational order of these points will decide about default visibility. (ie when defining an object faces visible by default must have the opposite rotational order compared to faces invisible)
- you have to calculate this AFTER projections were done
- you only need the sign of the result to decide visibility (trial and error, depends on how you set up rotational orders)
- dont ask me about the math background I've forgot it through the years :/ derived from cross product, and gives Z coordinate iirc, but my google findings were against that. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
read the different perspective series. issue 8-9-10
http://www.ffd2.com/fridge/chacking/
also you might find some help here:
http://codebase64.com/
btw, you can simply compare the Z coordinates of a normal for each side for a cube (which one is smaller), and you can get "inside" pointing normals from the default 8 cube coordinates (this is roughly what jackasser talks about but in human language:), but with perspective projection you will get incorrect results. as projected faces visibility differs from unprojected ones. |
| |
LHS
Registered: Dec 2002
Posts: 66 |
Thanks,
I have read this technique in a book about universal 3D gfx, but I have disbelieved in usability at C64 :-)
The simple Z compare doesn't give me sufficient solution (I mean this technique is sufficient, but maybe I have a bug in my routine, maybe I must check signed overflow etc...).
Oswald, do you mean
((p1x-p2x)*(p1y-p3y))-((p1y-p2y)*(p1x-p3x))
or
(p1x-(p2x*p1y)-p3y)-(p1y-(p2y*p1x)-p3x)
(I mean the firts is right)???
If I have f.e. a hexagonal polygon with right rotation order, check first 3 vertexes (p1, p2, p3 - with your comparasion) is enough?
p.s. sorry, I don't like read english books, as you can see in my english diction... |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
((p1x-p2x)*(p1y-p3y))-((p1y-p2y)*(p1x-p3x)) is the right one.
you can check any vertexes they only should be on the plane of the face in the right order, tho with low precision c64 routines it is better to check ones which are as far as possible. :) sorry for no math background but I'm using this formula since ~10 years, and forgot :/. (copied this one straight from desert dream's raster cube so it should work ;) |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Thanks,
I have read this technique in a book about universal 3D gfx, but I have disbelieved in usability at C64 :-)
The simple Z compare doesn't give me sufficient solution (I mean this technique is sufficient, but maybe I have a bug in my routine, maybe I must check signed overflow etc...).
Oswald, do you mean
((p1x-p2x)*(p1y-p3y))-((p1y-p2y)*(p1x-p3x))
or
(p1x-(p2x*p1y)-p3y)-(p1y-(p2y*p1x)-p3x)
(I mean the firts is right)???
If I have f.e. a hexagonal polygon with right rotation order, check first 3 vertexes (p1, p2, p3 - with your comparasion) is enough?
p.s. sorry, I don't like read english books, as you can see in my english diction...
Z-compare is sufficient. I've implemented in my own vectors and Graham uses the technique in Natural Wonder. ;D
Also, Oswalds method using the cross-product is correct, however a lot slower on a c64 but also much more general.
Use what ever method you like, it can always be changed later. ;D
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
Z compare on projected faces is sufficient? iirc, projected faces gets hidden "sooner" than non projected ones -> will bug.
"you need to rotate the normals first and use their rotated Z-values in the compare."
how is a rotation faster than 2 mul in the cross method? |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Z compare on projected faces is sufficient? iirc, projected faces gets hidden "sooner" than non projected ones -> will bug.
"you need to rotate the normals first and use their rotated Z-values in the compare."
how is a rotation faster than 2 mul in the cross method?
Given the constraints I gave a simple Z-compare of the normal is sufficient, please read the math I posted and you will understand (I mean, it's based on which side the eye is of a plane, projected or not).
The problem you think of is to simply check the SIGN of the Z-component. That would yield the problem you say. In my example I calculate a CONSTANT to compare against and this constant depends on object<->eye distance AND object size.
So, yes and no. :D I hope I make myself clear.
However, for general back face culling I'd also go for the re-creation of the Z-component of the normal by using the cross product of the projected vectors of course.
|
| |
LHS
Registered: Dec 2002
Posts: 66 |
Huh, there is a misunderstanding from my side. I am sorry, I forgot a lot of school geometry...
How can I calculate the normal?
I have 4 points (p1-p4) of a plane (with X, Y and Z coordinates). How can I use these coordinates for the "Z-normal compare"?
The universal definition is Ax+By+Cz+D=0, but what is the implementation (algorithm, no 6502 code)?
|
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Huh, there is a misunderstanding from my side. I am sorry, I forgot a lot of school geometry...
How can I calculate the normal?
I have 4 points (p1-p4) of a plane (with X, Y and Z coordinates). How can I use these coordinates for the "Z-normal compare"?
The universal definition is Ax+By+Cz+D=0, but what is the implementation (algorithm, no 6502 code)?
Assuming a cube that is world axis aligned the normals for the faces are the world axises defined by your rotation matrix, neat huh? =D
Otherwise to recalculate a face normal you simply take the cross product for two vectors in the plane of the desired face, then normalize it. This you NEVER want to do on the c64. |
... 19 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 | 3 - Next |
