As I mentioned above, if you have a sin/cos table, you don't need to do 9 multiplications (see the link I posted above)

The problem is that it uses full 3D transform so can't apply it.

There’s a shit ton of possible optimisations possible in the 3D math. Things like pre-transforming static objects with their local transform, half a dozen kinds of culling, culling in world space rather than camera space, avoiding unnecessary multiplications, and I forgot many more (I wrote about several in an earlier thread, and I should have some notes at home as well).

Problem is, as I encountered in my little 3D project last year, it just takes a lot of time to do all of those optimisations, because there are so many. And the 3D math wasn’t the biggest bottleneck, so I hadn’t even started to do any of it. But games like Quake ran on the hardware of those days because it did pretty much all of them.

I still want to pick up that project again sometime because it was fun, I moved on to other things when I had to rewrite the polygon drawing to use painter’s algorithm, but I’m focusing on other things now .

I need full 3D

I am digging around here

http://www.opengl-tutorial.org/assets/faq_quaternions/index....

This is a good place to start your study

http://www.realtimerendering.com/resources/GraphicsGems/gems...

Two links from my older thread:

*Grauw*wrote:

To throw a link out here, in addition to Michael Abrash’s Graphics Programming Black Book which I think I mentioned earlier, the Hugi programming articles on 3D graphics are also interesting.

A lot of interesting low-level optimisation techniques from back in the day described at those links. Efficient culling is an important optimisation I think, cull as much as soon as you can.

Indeed we have that the fastest drawing is no drawing.

But culling can be a heavy process, specially for non-convex figures. Imagine the ship wings with the ship partially rotated, at which point the back wing is covered by the body?

A solution to this is work only with convex figures, like seems they done in Battle of the Planets:

https://youtu.be/ghm2qomMEIs

Then, for each triangle, you see it or not, but not partially. Draw only full length edges from vertex to vertex.

Another good optimization, preprocess figures to triangle sripts:

https://en.wikipedia.org/wiki/Triangle_strip

We can notice that using triangles the edges can be drawn multiple times, with strips each edge is only drawn once. For drawing the process is simple:

- Draw the 1st triangle.

- For the others of the strip list, you draw the 2 edges from the last 2 vertices to the new one.

I.e. for this:

Diagram of four triangles, 1, 2, 3, and 4, with vertices A, B, C, D, E, and F.

For example, the four triangles in the diagram, without using triangle strips, would have to be stored and interpreted as four separate triangles: ABC, CBD, CDE, and EDF. However, using a triangle strip, they can be stored simply as a sequence of vertices ABCDEF. This sequence would be decoded as a set of triangles ABC, BCD, CDE and DEF then every even-numbered (with counting starting from one) triangle would be reversed resulting in the original triangles.

You draw:

- Triangle ABC.

- Edge BD, edge CD.

- Edge CE, edge DE.

- Edge DF, edge EF.

And so on. For culling, if the triangle is not visible, you don't draw the new edges and continue.

This with the only convex figures mentioned above, can be handy.

Not just drawing less, every vertex that's culled means 16 multiplications and one perspective divide fewer, too. There’s many types of culling too, back face culling, object culling, frustrum culling, occlusion culling, etc...

Depending on the game type, it could be simplified in many manners, so the design is also important.

I.e., for a Starfox like game, the static object culling can be simplified to preprocess obj lists dividing the scenario (linear) in "cubes", and adding to the list the objects inside each one, then you only compute objects in the "sub-area" list the camera is into, and maybe the next one up to a certain distance. For the frustum culling, probably is enough with checking only by the AABB and not the OOBB. For distance culling, we can also preprocess the distance of each static obj to the front "cube" face (the one that the camera passes 1st), and store it in the list. Then the distance computation is simple using the camera Z position, the "sub-area cube" front face, and the object computed distance, if greater than the distance required, ignore it.

Then the game type determines many things for 3D optimizations.

right, the link I provided only shows optimizations for rotation. I just put it to show an example. I haven't looked at it for a long time, but I remember from the DOS days that it was possible to do full 3D transforms with only 8 multiplications instead of 9 with some manipulation of the equations (and perhaps some simplifications, can't remember now ). But in any case, great set of optimizations that you have been listing here!