Project 3Dhax

[Mauganra99]

Just to boast a little: I finally made some crude z-buffering technology!

Well, the problem:

A computer draws 3D objects in whatever order it's told. For those who've seen the preview for my Legion mod (which is somewhat done now, but can't upload  ), it uses wireframes and draws those wires in the order they're specified in the weapon model file. With wireframes, this isn't much of a problem, since you won't notice the 'back' lines being drawn over the front ones.

This becomes different, however, when solid polygons are drrawn: it looks sucky when objects in the back show through the front ones. To solve this, the polygons need to be sorted in order from back to front, and then drawn.

Well, this is done now; the algorithm works like this:

First: Unpack all polygons from a model file, and convert their defining points (that is: the corners) to 2D, ready to draw. Also, calculate it's crude average z position by averaging the z positions of the 3 corners (actually, I just add them up, but same result)
Then store each polygon in a buffer, and each z value in a z buffer.

Then, create an 'order' list, which lists the polygons in their correct order (descending z value)

Then render those.

For now, I'm still needing some things:

• A 2D polygon filler algorithm. The one I'm using now doesn't fill the polygon 'evenly', which messes up transparency effects.
• A shader system. I'm able to calculate the polygon's normal vector using vector calculus, and can then use lightsources and stuff for shading. Only, I have no idea of how to do that properly
• A better 3D-2D conversion. The current one only allows rotation allong one axis, but I of course need rotation along both theta and phi  (for those comfortable with spherical coordinates). Basically, it takes x, y, z, theta and phi values, and returns x and y

Especially the first one I can't figure out. Now I'm using a system which draws lines from one corner to several points along the line on the other side (hard to explain), but this means the amount of lines/pixel is very high in one corner. This works fine for normal polygons, but transparant ones don't have an uniform transparancy.

If anyone can help me with one of the above, or make one of them for me, I'd be really glad, and you're name will be on the roll of honour and stuffs.

[Gliptic]

It's easier if you reduce it to use triangles instead of polygons, then they can rendered like this:


A) The triangle.

B) Find the horizontal middle point so that you have two triangles each with a vertical side.

C) Find the slopes of vector a and b, a_s and b_s, where v_s = v_y / v_x.
Set top and bottom to the vertical position of the red corner, progress horizontally one pixel at a time and:

• Draw vertical lines between top and bottom
• Add a_s to top, and b_s to bottom

Stop when you reach the middle point.
Do similarly for the right side.

There's some special cases to take care of, but I think you get the general point.

[TTFTCUTS]

Well, forgetting to mention me, and my poly shading

I've been working on the theory of doing the cel shading we were talking about too, but don't have it 100%, as i don't know what the code you have written is yet.

[Mauganra99]

Well, with poly I meant triangle all along: they're always 'flat', no matter what points in 3d are chosen, which simplifies things a lot.

I'll try to implement Gliptic's algorithm, which should'nt be too hard: just making sure the few 'special cases' are taken care of, and finding out some other stuff. Something like this was more or less a back-of-the-mind idea I had, but this explanation makes it a lot easier. Maybe the under-used 'hline' function can come in handy here, though it lacks wu-ness. Thanks for the help, though

As for the shading: I'm not calculating normal vectors yet, since I wanted to make the filling algorithm work before doing other things.

The procedure I had in mind for doing so:

-Find two vectors that span the plane the poly is in.
-Take their cross product.

Then the normal vector can be used to calculate shading, and maybe even eradicate 'backside' polygons (though I mind want to keep them so models can be simpler). The orientation of the polygon will be set by the order of the points in the model file, this might be a bit hard for eventual modellers but they'll have to live with it.

[Gliptic]

That method to calculate normals is the one commonly used. In the triangle (A, B, C), you simply cross the A->B and A->C vector.

For shading, it seems that using the dot-product of the normal and the normalized vector from the center of the triangle to the light-source could be used to decide the brightness (I'm not actually sure how shading is actually done). For cel-shading, you would simply quantize this value. Not sure how to make good outlines for cel-shading though.

[TTFTCUTS]

To do that you draw the outlines of backfacing polys as thick black lines.

[Mauganra99]

Wow, that sounds pretty simple for the lines!

One other method I heard of used a copy of the model, but with all normals pointing inwards, and slightly larger than the original which it 'enveloped'. This causes the engine to draw the backside/inside of the black, larger model, and then the normal model over that. It seemed horribly overcomplicated to me.

Soon I'll pick up work at this again, and I'll release some code which shows how it works so far. It's integrated into the weapon menu right now, since I ripped/replaced most of the Legion code out of lazyness. It will probably not be too hard to actually make something external out of it.