3D Display Engine

[zero-impact]

You can change the filename in 3d.t to open any of the .raw files. Also if you want to try your ownl models just export as a .raw and make sure to convert it to tris first.
There are 3 different resolutions for the monkey head: monkSmall, monk, and monkHiRes. monkSmall should run smoothly on most computers but if you have a newer computer you can try out the other ones.

Rotate by clicking and dragging.
Zoom with 'z' and 'x'.

Any tips for optimization or anything I could improve are appreciated

[saltpro15]

won't work for me

[zero-impact]

Fixed

[saltpro15]

cool, you have way too much free time to make all these + 5 bits

[Zren]

I like how it continues to rotate after you let go of the mouse.

-Lighting's next prob. Not much you could improve on a wireframe. You could put in a total polys and FPS counter I guess though. Maybe make the zoom speed faster...

[saltpro15]

you definitely have to rub this in paul's face

[zero-impact]

OK update.

Thanks Zren, lighting is what I will be working on next but for this I have added solid faces. also I did increase the zoom speed

[andrew.]

That is truly amazing. Well done zero-impact. I could never program something 3D like that in Turing.

[DemonWasp]

Very nicely done. I'm still looking at the code, but the first thing that jumps out at me as an easy fix is this:

You're loading your data so that you have some N triangles with 3N points. That's great, and it works, but it's an awful lot of storage, since you tend to have multiple triangles sharing points. That means you're doing additional work, and storing more information!

Instead, try this:

For each model (or for the whole program, since you seem to be loading exactly one), have an array of Point objects. Load each point independent of the triangles. Then, have an array of Triangles - all these need are three integers, each an index into the Points() array.

This allows you to re-use points in your geometry and simplifies your rotate methods (which now only need to rotate points). You will probably find that you need around 1/3rd as many points.

This means:
1/3 as many point-rotate operations
1/3 as many point-draw operations
1/3 as much space required for point storage

This would require that you either update your input files (save a backup first!) or re-interpret on-the-fly after loading.

If you're not going past wireframe, it's also possible to just have an array of indices for each point indicating all the other points its connected to.

Edit 1: Fixed some grammar.

Edit 2: As a point of interest, it's generally poor style to have drawX() methods modify data. I realise it's just the x2 and y2 fields of Point, but either comment that behaviour, or comment in the Point object that x2 and y2 are just for graphics. Even so, it's probably best to move the "point.x2 := round (ZOOM * point.x) + XOFFSET" bit into drawObject(). This may happen as a result of the optimisation noted above.

Edit 3: In your revised version (note: using version numbers helps us all keep them straight; the first one can be 0.01, this is then 0.02 or whatever), you're quicksorting. This appears to be in an attempt to make sure that your model is drawn in the "correct" order, so that polygons on the back don't appear over polygons on the front. Unfortunately, the only true solution to this is a depth buffer for every pixel on the screen (impractical, methinks); your solution is alright but not fantastic (look carefully at monkey's ears).

[CodeMonkey2000]

You should also try back face culling (compare the normal vector to the view vector). You will be drawing roughly half as many polygons.

[zero-impact]

Thanks DemonWasp I have thought of a few ways of optimizing it but I just wanted to get it working :p unfortunately I have to completely redesign most of it to optimize it. Also for the quicksort, I have noticed the glitches in the monkey and especially the gun. It seems to happen with very elongated polygons.. which makes sense considering how it calculates it.

Thanks for the tip CodeMonkey I will look into that.

[SNIPERDUDE]

... Makes me want to dust off my old 3D engine and start working on that again. I never did post the thing because I kept wanting to refine it better. Anywho pretty good job Zero-impact.

[saltpro15]

I just had an idea for this thing, being able to zoom in on a specific area on the models would be interesting. For example, zooming in to only look at the trigger of the gun

[DemonWasp]

Update: I did a quick-and-dirty modification of your program to eliminate duplicate points as I'd suggested. I ran it on the monk.raw model; I had it give output:

code:

Of 2904 points, 2399 were duplicates (82.61%) and 505 (17.39%) were unique

What this means is that you could potentially use around 20% of the space and computation time as your current method uses. This modification didn't take very long, maybe about 30-60 minutes. I can post code if you want, but it'll need a cleanup first.

[zero-impact]

That would be very much appreciated DemonWasp. I have been racking my brain for hours on how to eliminate duplicates.. easily.. that is. I would love to see the code for it regardless

Codemonkey: I think I have the back face culling working pretty well as well as simple Lambertian reflectance.

Here is the updated code