java3d, jogamp and an stl viewer

hi jogamp maintainers for the java3d 'continuation' and the jogamp jogl stack, it is really well created :)

i've always wanted a STL (https://en.wikipedia.org/wiki/STL_(file_format) viewer for java.
i didn't find it on github and finally created one :)

https://github.com/ag88/stl-viewer

i've only really tested it in linux on my own pc, your mileage may vary
but the java 3d 'continuation' and opengl implementation rocks ! thanks ! :)

in case the maintainers or any one is trying / testing out the stl viewer app
i noted that some models/objects 'freezes' while others seemed ok, initially i suspected it may be related to file size, however it turns out that this is not necessary true

i tried loading this 'Curro Expo 92 cookie cutter' model by lolo_aguirre from thingverse
http://www.thingiverse.com/thing:2171286/#files

the file CURRO_INTERIOR.STL which is about 1mb renders just fine and one can pan / rotate around the model to view it


while a smaller file CURRO_EXTERIOR.STL which is about 500k freezes
(in the same link above)

the scene graph in java3d is setup as follows

SimpleUniverse > Locale > Branch group (this is the root) > Transform group (scale) > Branch group > Shape3D (this is the model - all triangles from the STL file is loaded in this node)

there are various bounding spheres and lights (with spherical bounds), i'm not too sure if that is after all the cause of the freezes, do drop a tip / comment

the source can be checked out from github https://github.com/ag88/stl-viewer if one wants to examine the codes. codes that deal with java3d are mainly in org.stlviewer.PCanvas3D and org.stlviewer.PModel (PModel is the BranchGroup > Shape representing the STL model/object it also loads the triangles when the file is loaded)

thanks in advance

pretty much fixed, it likely has something to do with those bounding spheres
translating the objects close to origin fixes most of the freezes and ease rotating the model/object

CURRO_EXTERIOR.STL by lolo_aguirre mentioned in the prior post

ag123,
Excellent stuff, thanks for building this and letting everyone know.

It looks nice and straight forward.

I wasn't aware of the stl format until I read your post but I see it's firmly part of the 3d printing world.

I guess the next step might be to write a writer for it so people can build 3d models then export and email it off to their local printer.


Phil.

i'm thinking that STL format could possibly be included as a 'loader' in the java3d 'continuation' stack, the STL import code i use is not actually mine but attributed to cyanobacterium https://github.com/cyanobacterium/STL-Parser-for-Java who released it under MIT license. i simply included and release all source and retained the original license for its parts in the same spirit.

i'm finding that it is one of the more stable and 'tightly written' stack. However, it loads the file into a structure of triangles in memory, it'd take up quite a bit of memory for large files. however, i choose to go with stability even if it does consume more memory during the loading stage. any way those same structures would be converted into java3d structures and the temporary structures garbage collected

currently, you may like to just play with my app, the STL codes currently still hit a blank for many STL files that one may download from thingverse. i.e. it doesn't parse just about every STL file yet

JogAmp's Ardor3D Continuation has (in my humble opinion) the best STL and PLY importers I have ever seen in Java, I spent several weeks in implementing and testing them, the first one was based on Graham's contribution, the first one is inspired of tons of other loaders but the end result is a lot more reliable. Actually, they are designed to be extendible and writing exporters for those formats in this engine isn't very hard. Our (Graham + I) STL importer is a lot more complete than the rudimentary loader you quote. Feel free to use our source code. Seriously, the source code you quote is poorly commented, just look at ours:
https://github.com/gouessej/Ardor3D/blob/master/ardor3d-extras/src/main/java/com/ardor3d/extension/model/stl/StlImporter.java

thanks Gouesse, i'm intending to transit to Ardor3D Continuation even for its graphics engine, i'm leaving things the way it is currently for a while

did a round of fixes it probably open many more binary stl files
the catch is that some binary stl files starts with "solid" in the header text, this confuses the stl parser to treat that as an ascii stl file. added some logic in the parser to correctly tell apart ascii stl files and binary stl files with "solid" in the header, many more files it seemed are viewable now

The header of the binary STL file doesn't contain any useful standard information, you can safely skip it. STL4J uses a fast but unreliable method to determine whether a file is an ASCII file or a binary file. Moreover,it supports neither the attributes nor the normals.

Have you ever tested this STL file reader for Java3D?
http://code.j3d.org/javadoc/org/j3d/loaders/stl/STLFileReader.html

Maybe reinventing the wheel isn't necessary.

I totally understand your position and anyway, some contributors can port our loaders from JogAmp's Ardor3D Continuation to Java3D if necessary.

The WaveFront OBJ format is more complete and more capable in my humble opinion.