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..
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...