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
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)
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
That’s exactly what I had in mind, but traversing licenses is more the
senior members of Jogamp specialty than mine, so when I get some time I’ll look
into it and see what building an exporter might take.
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.
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
If you reply to this email, your message will be
added to the discussion below:
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:
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.
I used to use a lot of the j3d gear particular as examples and start
I’ve never notice the stl format reader, but then again I’ve never notice
the stl format particularly, the obj is pretty good as a common base
In checking through my projects I see none of them are dependent on
j3d-org-java3d-all.jar anymore, there was a time when I always included it with
To be honest I’ve got a lot more on my plate trying to make the java3d
android version public, and generally getting the shader pipeline working
better, so the stl library inclusion is way down the list.