3D Display Engine

[zero-impact]

DemonWasp: I looked at your code and redid the quicksort to draw the faces semi correctly (havn't done the back face culling yet) and it seems that the quick sort really is the biggest bottle neck. On monkHiRes it only gives an improvement of about 3-5 fps.. Does anyone know of any other practical ways of determining the order of the polygons? back face culling by itself is not enough as there is still some glitches with overlapping polys.

[DemonWasp]

I've done some more code updates:
- Returned the quickSort, but refactored to improve its efficiency slightly. Draw order is now determined by an array of indices to faces, with back-culled faces removed beforehand. There's probably something that can be done to improve this, but I'm not seeing it offhand. Maybe when I've had some sleep.
- Added a display for the number of points, faces, duplicated points and FPS
- Added a logger stream (WARNING: logging severely reduces performance and generates a lot of data (if you uncomment the logger-writing lines) )
- Added the Vector3f class in Vector3f.t ; the API is largely the same as the jME Vector3f class. This class can replace Point soon.

You will need to put Vector3f.t in the same folder as the main turing file and all the raw objects.

Comments / recommendations / suggestions are all welcome.

[CodeMonkey2000]

Too bad turing doesn't support operator overloading.

[DemonWasp]

Yeah, operator overloading could have made this a little easier. It'd also have helped if they hadn't grabbed "length" and "set" as reserved keywords.

Most of what jME has are sorta useless though; their code for some of the multiply methods calls another multiply method. This works out fine in the JVM, which can short-circuit that, but Turing won't, so I cut it out: methods do what they're supposed to and return the result immediately.

[zero-impact]

Here is a small update with the lighting (still using my original procedural version) using Lambertian Reflectance.

[DemonWasp]

Updates:
- Integrated zero-impact's Lambertian Reflectance.
- Removed the Point type entirely. Use the Vector3f class instead. For projected pixel coordinates (formerly x2, y2), use pointProjectX, pointProjectY.
- Added pervasive keyword so that certain classes / methods / variables do not need to be imported into classes.

Performance:
On this 2.4Ghz P4, I get about 5-9 FPS with monk.raw, depending on model angle. This represents a slight improvement over the version posted by zero-impact, which ran at about 4FPS on the same machine with the same file, regardless of model orientation.

[zero-impact]

Interesting.. I ran monkHiRes.raw on your newest update and walked away for about 5 minutes. When I got back Turing had crashed due to a "fatal error". Any ideas?

[DemonWasp]

Sorry, no ideas. I can't reproduce the issue on my home PC. It spends about 10 seconds loading, then draws at about 3-4 fps.

I should mention: the machine in question is incredibly powerful (q9450, 6GB ram, high-end hard disks). Is your machine perhaps short on RAM or CPU? If so, try a smaller model; monk or monkSmall or gun or whatever really, so long as it's not the high-res model.

Load time is still an issue; I'm considering implementing some of the Java Collections framework so I can use a hashtable or similar to cut down loading from O ( numPoints^2 ) to O ( numPoints )

[zylum]

Try using transformation/rotation matrices.. They should speed up your program a bit. My old engine used them but I'm not sure I posted a version with matrices.. Also look into the .ply file format -- it's a bit more efficient than .raw as it doesn't store multiple instances of the same point. Also, if you are aiming for speed, you'll want to minimize function calls and the number of classes you have. This is really bad practice but it helps a lot.

[DemonWasp]

@zylum: I inlined the swap() method used by qSort() and that resulted in a 0.5 FPS average increase (averages about 5.25FPS on this machine now). Inlining rotatePoint() wasn't quite as effective, but did provide a slight boost. Inlining drawFace improved by another 0.25 FPS or so.

At this point I think we're rapidly approaching Turing's limits on speed. No matter how much we destroy real design for speed, it's never going to exceed 7-8 FPS on this machine. Turing is just too slow. For reference, the only testing I've ever done seems to indicate that Turing is about 1% the speed of compiled C / C++ or Java.

[zylum]

Hmm... I remember my engine being quite a bit faster and I remember having ideas on how to improve the speed. Your implementation looks very similar to mine though... Do you cull the faces before sorting?? Check out my engine for more ideas..

[DemonWasp]

Faces are "culled" before sorting, in that the indices of drawable faces are input into an array which is then sorted. Perhaps some speed can be gained by allocating that array differently...nope. Even allocating the array so that it's not new'd at each frame-draw doesn't produce any meaningful performance boost.

Remember, speed varies substantially from one version of Turing to another, and from one machine to another. I'm on a dreadfully slow and overburdened machine (Firefox + WinAmp + a server + Lotus Notes + remote-desktop software, with only 2.4Ghz CPU and 2GB RAM).

[zylum]

I just tested my old engine and it can run two monkey models at 10-16 fps depending on the rotation. And like I said, there's tons of room for improvement... You must have some sort of bottle neck somewhere. Try timing each major section of code to see where the biggest slow down is. Check the rotation function, sorting and drawing..

Here's my engine btw http://compsci.ca/v3/viewtopic.php?t=9639&highlight=zylum+engine

[zero-impact]

DemonWasp: no power issues here. I'm running a q660 with 2Gb of RAM. I get about 12 - 20 fps on monk.raw

Zylum: That is amazing