Show HN: Visual diff for 3D printable models | Hacker News Reader

Show HN: Visual diff for 3D printable models

cubehero.com

127 pointsiamwil39 comments

These are STL files, which are used commonly in 3D printing. The models were generated by OpenSCAD (programming language for 3d modeling). As I've worked more on 3D models for 3D printing, I've been wishing for visual diffs in order to make it easier to collaborate with others.

Right now, it's a pre-populated demo of a robokitty (because the internet needs more cats). But soon, you'll be able to push to your own repos using git.

Let me know if you have some feedback. Thanks!

Pretty useful. Although it would be better if you could just send the diff over the wire when trying to look a previous version -- it takes way too much time to download the whole model.

Being able to continue inspecting the model in the same position it was before loading another version would be nice as well.

Ahh, yes, that makes a lot of sense. And then if someone jumps around, send the whole model, but if it's sequential, just the diff will work.

Is this not what git does?

My understanding of his question was how I rendered the diff of the models.

While git does calculate textual diffs, it does not calculate visual diffs of 3D models, which is what I've managed to do here.

I'm not talking directly about your method versus the git method. What I was alluding to: if you're planning to use git to distribute your models eventually, perhaps you should have an eye toward optimizing the models and their diffs for use with git. Then, git transmits only the diffs as needed, when needed.

Nice work, really impressive! A few comments:

- You actually have at least four diff states you need to visualize, it's like a matrix. One axis is boolean operations (add, sub etc) the other axis is difference between revisions. For example it's hard to see form the diff if material was added or removed between revisions. You can naturally just highlight where things changed but it's a trade off you need to consider carefully and probably sketch out the most common use cases.

- I thought for a long while that transparency is an easy way to solve problems like showing diffs. My more graphics savvy co-founder managed to convince me that transparency is usually not a good solution. When you have a transparent surface on top of another surface it feels like you can suddenly get more information on the screen. However, this is obviously not true, you still have 24 bits of color information on the screen however you slice it. What is happening is that you have divided your bits between the front surface and anything behind it. Our experience is that users have a very hard to grasping even basic 3D shapes on a 2D monitor, making it harder using transparency is usually not beneficial.

- If you want to do transparency right you need to do something about the render order, I noticed you are rendering the transparent surfaces in a fixed order.

If you haven't checked it out already take a look at our project Tinkercad at http://tinkercad.com. Even if the UI uses a direct manipulation paradigm the underlying operations tree is isomorphic with OpenSCAD.

I did something similar using Thingiview.js as a base: http://n0r.org/thingiview.js/examples/client_side_diff.html

Source: https://github.com/nrpatel/thingiview.js

Cool. I did happen upon you solution a couple months ago when I was researching the topic. :)

I checked out your snow globe and the augmented reality stuff you're doing in open hardware. Pretty neat!

Feature suggestion: be able to drag your mouse left and right to create a "swipe diff" line that reveals or hides the old version on the left vs the new version on the right.

Maybe that's in there, but I didn't spot it.

Ahh, like a cross-fade slider? It's not in there, but I've heard this a couple times now. Thanks for the feedback!

This is perfect. We've been using GitHub + OpenSCAD and have been looking for a less hacky way of doing 3D diffs.

Signed up!

Awesome! I'll have the accounts up soon, so you can get started on pushing to your own repo.

Awesome. What are you guys using GitHub+OpenSCAD for?

This is very good. Some suggestions - you should make the the camera point to the center of the model. Also fixing the light to the eye (not transforming it with the model) will make the rendering look good from all angles. Zoom and pan would be nice. Also maybe an orthographic projection will make better sense as the 3D printed models are likely to be quite small.

Interesting demo. I don't know anything about this space but it seems to download a ton of data every time I look at a different diff (like 8-10 MB). Is there any way to reduce this? As an outsider I don't even understand how that much information could be needed to render this thing.

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.

Since you seem to understand already the changes in the file, perhaps it would be possible to download (and merge) only the changes?

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

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

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.

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.

Thanks for the response.

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.

Neat!

Looking forward to seeing OpenSCAD and STL diffs together on the same page - that'd be a powerful OpenSCAD learning tool as well as a good change-management / collaboration tool.

Definitely cool to see where this goes - I've been wanting "GitHub + Thingiverse" for a while.

Do you mean OpenSCAD and STL diffs side by side, and live edited, so when you change the code, you see the model change?

That'd be most powerful as a learning tool (and a sweet "oh wow!" demo).

However, just a GitHub-style +/- diff view on the OpenSCAD files next to the STL diff view would be awesome (basically like the GitHub commit-range/pull-request "files" view, but with STL support).

Yes, I agree. I'll have to find space to fit it, but it makes sense to do so.

> Do you mean OpenSCAD and STL diffs side by side, and live edited, so when you change the code, you see the model change?

Well, there's always openjscad. I don't think it was a direct port, though.

Yup, OpenJsCad has the ability to do live editing, but it tends to render a bit slow when the models are somewhat more complex. It sends work back and forth to a background worker to generate the polygons, but it still has to send it all back to the main thread.

Unfortunately, OpenJsCad doesn't seem to have a high rate of adoption among 3D printing modelers...at least not yet.

You might want to look at http://3drepo.org for a robust integrated solution including diffing and tailored 3D version control.

Hope your bandwidth is cheap - how compressible are these files?

Also there's a few suggestions to just send the diffs after the initial model which is a really good idea.

It's just using regular gzip. I'm sure I could do more work to further compress the files, but for the time being, I just wanted to get something out to show people, rather than optimize prematurely. :)

This is really cool. Especially with the potential for ordering parts/BOM management. How are BOM vendors to be chosen?

For now, that's a ways off, but I was picturing the BOM vendors be crowdsourced based on what people have been using to build the project.

Cool deal - good luck with it, I'll keep an eye as you move forward. Could be useful to us!

that's cool.

Reply on news.ycombinator.com