Love3D

[Ref]

The more you draw, the slower it gets.
Multiple copies of the same object avoids recalculating the points for each one (but even so, high facet counts kill you).
Limited geometries work.
Edit: Sorry for miss-packaged demo. Think the replaced one works.

[Nixola]

It doesn't find the module "Ref3D", and I don't have time to find and correct it now, sorry ^^'

[substitute541]

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.

I guess I can probably use some of your code . And yes, I do use descriptive function names, kinda helps me update things and stuff like that.

[substitute541]

Oh and, about the license, it uses the MIT License now.

[Ref]

Just another shot at 3D.
Was successful at predicting failure.
Assumed 4 sources of time consumption in Love3D:
1. rotating points
2. ordering facets based on point orientations
3. calculating lighting
4. drawing facets
Attempted to do point rotation in a thread and predicting failure because of inability to efficiently transfer a table out of a thread.
Approach taken:
1. transferred desired rotation angle change from main to thread.
2. rotated points in thread
3. changed point table into a string using concatenation (ugg!)
4. transferred string to main
5. split string back into a point table (ugg! ugg!)
Used the 3D library to complete calculations & drawing.
Right, result was actually better than expected (usable) but poorer that just doing the rotation in main.
LoveJIT gave 50% better performance but if you're going to use it, why bother with threads.
Conclusion: Need better way to get data out of a thread for this approach to have a chance at working.
If you're interested in using threads, you might want to look at the Communicate.lua file. Definitely needs some expert help but does work.
CAUTION: Without using time delays in main-thread transfers, CPU usage can (will) approach 100%!

[substitute541]

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]

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.

Yah!
I really don’t know what I’m doing.
Just pounding a bunch of keys.
Obviously my implementation of threads not right.
Observation:
Without adding love.timer.sleep(0.005) to the thread, the CPU usage goes way up and the fps goes down. With the sleep in the thread, CPU usage goes down, fps goes up and drawing performance improves. Hard to optimize how much sleep is really needed.
Hypotheses:
The love.update – love.draw loop independent of the main - thread loop. If no constraints placed on the thread loop, the CPU will loop continuously (at high speed) between main and thread at the expense of the update-draw loop.
Is this anywhere near correct?
Tried using wait and demand with thread but wasn’t successful – just stalled the thread.
Any good examples out there on how to exchange info between main & thread?
Help! Help! (like help – please)
Please find attached my feeble attempt at a communication library.

[Ref]

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).

[substitute541]

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).

>2500 fps for me.

[Nixola]

I get nearly 30'000 FPS with this last example (Yes, thirty thousand), but this PC is quite powerful