3d engine performance

[WesGilster]

Fat Guy loading performance (48mb file)
Autodesk Meshmixer on 4 core 2.5Gz Laptop:
From load to view: 43 seconds

Three.js via http://dimensionalley.com/new-stl-viewer/
From load to view in 28 seconds

JMonkey(without OpenGL accel) on 4 core 2.5Gz Laptop:
loading: 3.513 sec
buildMesh: .772 sec
creatingCollisionData: 3.732 sec

JMonkey(without OpenGL accel) On Raspberry Pi II:
loading: 11.212 sec
buildMesh: 3.084 sec
creatingCollisionData: 28.579 sec

In Slacer.js:
Chrome runs out of memory after several minutes.

Apache Geo package on 4 core 2.5Gz Laptop
Will not finish due to a couple of O(N*N) loops. I talked to Apache and they are interested in finding a maintainer for their 3d geo utils.

I'm not loving the performance on the Raspberry Pi II, but once the BIHTree is built JMonkey has a mechanism that can export it's internal data structures and loading will go direct from disk to data structure. I'd love to hear everyone's thoughts.

[kloknibor]

Hi,

I'm quite impressed by the differance of speed and the speed in JMonkey. I also had several files crashing in SLAcer.js (way smaller) so I was already a bit concerned about that since we want to use it quite much. I think JMonkey is a nice alternative but would we be back at zero?

[WesGilster]

We must have a 3d viewer for the web. So, it doesn't really change much other than reinforce my opinion that Slacer.js data structures(and perhaps it's algorithms) need to be fixed, or we need to move towards raw Three.js.

This doesn't change the past. I'm asking more towards where we should perform support generation. I'm not ready to invest time and double down on Slacer.js. It's strength is in managing printer settings and manipulating a 3d figure, but not much outside of that. Three.js is really doing the work of slicing with some helper methods built into mesh.js(from Slacer). If I were interested in putting my effort into supporting another open source product, I'd rather be the maintainer for Apache's geo utils. However, I'm not really interested in doing that when JMonkey seems to have what I need. I say "seems", because I'm not 100% sure the jbullet collision engine is going to return the geometry that I need for the supports.

@kloknibor keep in mind that those times are not an equal comparison with the rendering apps. I'm not performing any rendering in JMonkey, so it has a slight advantage that I didn't count in the rendering numbers above. I say "slight" because JMonkey is a rendering engine, and it better render rather quickly. Also keep in mind that I created the STL loader for JMonkey as my daughter was sitting on my head, so it might be completely wrong. LOL. :)

[DanielJoyce]

48mb file is gonna have problems. You don't need all of those polys anyways. You should decimate first.