3d drawing order

[Cyberman]

ficedula you are having entirely too much fun with your DS LOL

It's too bad the GBA simply doesn't have enough internal memory even fake running FF7

Cyb

[Darkness]

Another (more or less unrelated) question:

I'm working on camera angle now, and im using the equation:

screen_x = distance_from_screen * tan(arccos(a dot b))

where a is the direction of the camera vector and b is the vector from the camera through the vertex.

This always gives a positive angle (at least in the viewable area)

How can I make this give me a negative value when the vertex lies below this camera vector / Is the a more effective way to do this?

Does this make any sense?

[mirex]

I don't get it, what do you want to get as a result ?

[Darkness]

I need to find the distance between the long black line and the red line along the short black line. In this case it needs to be negative because the red line falls below the black one.

[mirex]

Still not enough input. What should be usage of that angle ? Why should it be negative ?

Also, there are tons of math algorithms on the net, try to google for them (aproximate name should be sufficient for google).

[dziugo]

The point? Displaying this on screen. You can add 400 (if the output is in range <-400 ; 400>) to the result and you'll get X coordinate in 800x600 resolution. Now... since that algorithm always gives positive numbers, after displaying, everything will be on the right side of the screen leaving the left side blank.

I think, that using arccos there is no easy way to get negative results. You'll need to check if the point is actually on the left "side" of that black line and correct the result if necessary.

dziugo

[L. Spiro]

If you are referring to rasterization, you may find it easier to use these:

Code: [Select]

INT iHalfScreenX = g_piResolution.x >> 1;
INT iHalfScreenY = g_piResolution.y >> 1;
pntReturn.x = (LONG)((FLOAT)iHalfScreenX + (FLOAT)iHalfScreenX * (d3vTarg.fX / d3vTarg.fZ));
pntReturn.y = (LONG)((FLOAT)iHalfScreenY - (FLOAT)iHalfScreenX * (d3vTarg.fY / d3vTarg.fZ));
Do not perform this equation if d3vTarg.fZ is 0.

This small section does not account for the rotation of the camera.
This is the whole code written for my Doom® 3 perfect-lock auto-aim.

Code: [Select]

// Transform a 3-D point into screen coordinates.  Returns TRUE if the coordinate is actually on the screen.
BOOL Rasterize( PDoom3Vector pd3vPlayerPos, PDoom3Direction pd3dPlayerDirection, PDoom3Vector pd3vTargetPos, POINT &pntReturn ) {
Doom3Vector d3vTarg;
// Copy the target vector so we don’t change it.
memcpy( &d3vTarg, pd3vTargetPos, sizeof( d3vTarg ) );

// Translate the vector to the center of the world, which would literally mean
// our player.
d3vTarg.fX -= pd3vPlayerPos->fX;
d3vTarg.fY -= pd3vPlayerPos->fY;
d3vTarg.fZ -= pd3vPlayerPos->fZ;

// The pitch and yaw are in radians.
FLOAT fPitch = 0.0f - D3DXToRadian( pd3dPlayerDirection->fPitch );
FLOAT fYaw = D3DXToRadian( pd3dPlayerDirection->fYaw - 90.0f );

// Rotate accordingly.  This must be done in this order!
if ( fYaw != 0.0f ) {
FLOAT fTemp = d3vTarg.fZ * (FLOAT)cos( fYaw ) - d3vTarg.fX * (FLOAT)sin( fYaw );
d3vTarg.fX = d3vTarg.fX * (FLOAT)cos( fYaw ) + d3vTarg.fZ * (FLOAT)sin( fYaw );
d3vTarg.fZ = fTemp;
}
if ( fPitch != 0.0f ) {
FLOAT fTemp = d3vTarg.fY * (FLOAT)cos( fPitch ) - d3vTarg.fZ * (FLOAT)sin( fPitch );
d3vTarg.fZ = d3vTarg.fZ * (FLOAT)cos( fPitch ) + d3vTarg.fY * (FLOAT)sin( fPitch );
d3vTarg.fY = fTemp;
}

// The result will be where the enemy is in relation to our player.

// From this 3-D point, we can directly determine the 2-D screen point where the 3-D point would be drawn.
// This is useful for drawing targets over objects or determining if an object is on the screen.
if ( d3vTarg.fZ == 0.0f ) {
pntReturn.x = (LONG)(d3vTarg.fX * (FLOAT)(g_pntResolution.x >> 1) + (FLOAT)(g_pntResolution.x >> 1));
pntReturn.y = (LONG)(d3vTarg.fY * (FLOAT)(g_pntResolution.y >> 1) + (FLOAT)(g_pntResolution.x >> 1));
}
else {
pntReturn.x = (LONG)((FLOAT)(g_pntResolution.x >> 1) + (FLOAT)(g_pntResolution.x >> 1) * (d3vTarg.fX / d3vTarg.fZ));
pntReturn.y = (LONG)((FLOAT)(g_pntResolution.y >> 1) - (FLOAT)(g_pntResolution.x >> 1) * (d3vTarg.fY / d3vTarg.fZ));
}

if ( d3vTarg.fZ < 0.0f ) { return FALSE; }
if ( pntReturn.x < 0 || pntReturn.x >= g_pntResolution.x ) { return FALSE; }
if ( pntReturn.y < 0 || pntReturn.y >= g_pntResolution.y ) { return FALSE; }


return TRUE;
}


For my auto-aim, I manually transform according to the rotation of my player’s head (camera [math shown]) but in your engine you are going to have more control over how your rotations work and you should use an optimized rotation routine.
This routine is also not optimized for handling a massive number of points.
You would want to handle your rotations separately from your rasterization, using the first code I posted as your primary rasterization method.
Pass it the final X, Y, and Z points of each vertex (or whatever) after you have rotated the whole scene according to the camera.

You can modify the formula to handle view ports also, and note that I used iHalfScreenX in both sides of the formula.  This is to keep a 1-to-1 aspect ratio.  Aspect ratios can be added to the equation as well.

I have not benchmarked it for speed.


L. Spiro