LÖVE

Ref wrote:Have made further changes to substitute541's Love3D so have decided to rename my mutilated version to RefD3 so that no one else will fall into the trap of confusing the various versions of Love3D and will be able to find the latest & best version of the real Love3D. (Well delete previous demos to avoid confusion.)
Substitute541 original license is still present. (Not too sure what all this licensing is about when you take functions from someone elses book and not give credit to the author in the code – sort of like copy-writing a translation of a book under a new name without the author’s permission or credit. The basic functions can be found in Jasoco's work. As long as I'm not precluded from using the code, I don't mind. I guess it has to do with ego or something?). Have to say the the biggest advantage of substitute541's code is that he used very descriptive function names (Yes kikito, someone actually does!) as compared to Jasoco's uncommented code.
What I've done is stripped out all the stuff I don't need and replaced x,y,z indexing with [1],[2],[3] and ipairs with for loops. Got ~10% increase in speed.
Have add ability to read geometry from a data file (using Jasoco's format). Geometry can now be read in form CAD files (like the free openscad) without reversing the handedness (right-hand rule now followed).
Limitations:
1. custom file format (points & poly) though geometry can be inserted directly or a simple STL translation used.
2. images are highly faceted because facet normals are used – not point normals (but since we don't currently have point blending – that's what were stuck with.)
3. Squares created from multiple triangles are not uniformly colored because lighting uses surface normals and z value. When image rotates, triangles have different z's and even though their normals have the same orientations, they are rendered differently. Weird effect.
4. Until the God's of Love enable more access to openGL, texturing is a problem. Of course, more openGL == more complexity. Remember, in Love, complexity ~= fun – KISS!
5. Status:
Suitable for adding simple 3D geometry to scripts.
Really need ability to transfer tables from a thread so points can be rotate in the background while the image is being displayed.

Demo attached. Wasd active and mouse moves light source.
Probably should stay out of substiture541's hair and let him run with this.

Ref wrote:Just another shot at 3D.
...
CAUTION: Without using time delays in main-thread transfers, CPU usage can (will) approach 100%!

substitute541 wrote:

Ref wrote:Just another shot at 3D.
...
CAUTION: Without using time delays in main-thread transfers, CPU usage can (will) approach 100%!

My 3rd and 4th cores (in my CPU) did approach 78%, I got 50 - 60 FPS without the debug profiler, 25 - 28 with debug profiler.

Ref wrote:No help with threads?
Another limiting area is the redrawing of the image even when no change has occurred (waiting fo the thread's new data).
So I tried using a custom love.run which I could control when the buffers were swapped and only redraw the image when there has been a change.
Some improvement but not enough to compensate for the poor data transfer between main & thread.
Don't know how much of an improvement since fps indication is for when drawing is not being done (>1000 fps).
Best guess (unless you are really good) is not the approach to improve fps for large 3D objects until we get the ability to transfer tables from threads (like lanes).