
Show HN: Visual diff for 3D printable models - iamwil
http://cubehero.com/physibles/iamwil/robokitty/files/0cecb53528a7be6eb6236e01f36b7e37dbb260c8/robokitty.stl
======
iamwil
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!

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

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

~~~
delinka
Is this not what git does?

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

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

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

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

~~~
iamwil
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!

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

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

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

Signed up!

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

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

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

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

~~~
mbell
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).

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

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

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

~~~
bri3d
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).

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

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

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

~~~
iamwil
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. :)

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

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

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

------
vj44
that's cool.

