Yes. I think eventually, I'll have it generate a photo first, and not use webGL as a default. I did it mostly as a shortcut, because it would have been more work to figure out how to make the server generate and cache a picture of the 3D model.
In addition, someone else mentioned that I can probably just send the diffs, rather than the whole model.
Someone did a viewer and just pre-rendered a view of the object at every 20 degrees, which turns out to not require lots of bandwidth. Alternatively, the shapesmith guy sometimes does reduced tessellation on STL models instead of pumping out the whole model.
Side question: what I'm seeing appears to be a wire frame model with flat shading of a model with very few vertices. I know nothing of the STL format. The only time I've dealt with it in the past was having an ME send me models of parts when doing circuit board design work. To get to the point, why on earth is it so large? 10MB is a lot of data for what I would assume would be some polygon vertex coordinates and some texture instructions(which should be minimal given this is flat shaded).
It's because it's the ASCII version of the STL format. (horror!) A binary STL would be about quarter to half the size. And there are other open formats that would be smaller and perform better than STL.
The reason why I didn't futz around with it too much is that I'm still working out whether HNers and 3D modelers would find it useful to version control 3d printable models.
I could spend a long time optimizing transfer times of models, but it'd be a pity if no one wanted to use it in the first place.
i suspect it renders the model twice, in different colours, and what you end up with is the "diff" (one reason i think this is that there seem to be artifacts due to rounding error where the two meet).
this has the advantage of requiring little processing on the server and, on the client, you can use a generic renderer. i imagine calculating actual 3d diffs is quite complex (and so cpu expensive).
the diffs that are being suggested to reduce file size are, i think, just textual diffs on the source. they won't have valid syntax as graphical deltas in their own right.
someone please correct if wrong, just guessing here...
I wrote it, and while it's a good guess, the diff is actually done on the server and cached, since any one commit is immutable.
I had started off doing the diff on the client, and then I realized that in order to support the various different types of file formats, I'd have to implement parsers for every one in javascript. So I moved things to the server, and just send the results to the client to render.
These are definitely not "semantic" diffs on the original source code (in this case, OpenSCAD barf language). When people say that visual diff is hard, they are usually referring to the semantic aspects, not so much the problem of coloring missing or added triangles..
The semantic aspects would need to be captured with each diff. Currently, if you don't label a change with "Added super sonic ears", there's no way a computer would know those were ears.
Or were you thinking of something else wrt to semantic diffs?
Yes, super sonic ears. Don't get me wrong, there's nothing like automatic summarization for code commits either, so I was not claiming that people ask for that. When a feature branch is merged into a mainline branch, usually an engineer is looking for commit messages and commit visualizations about "a new way for managing excess heat" rather than "here are some messy triangles that you probably don't care about".
The message conveyed by the second is not entirely the same as the message conveyed by the first. The second might complement the first, but if it's really about complementing then the committer would ideally craft the second's message to communicate meaning just as he crafts the message in the first..
In addition, someone else mentioned that I can probably just send the diffs, rather than the whole model.