area515 / Photonic3D

Control software for resin 3D printers
http://photonic3d.com
GNU General Public License v3.0
131 stars 115 forks source link

3d engine performance #283

Open WesGilster opened 7 years ago

WesGilster commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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