GitHub announces 3D File Diffs

https://github.com/blog/1633-3d-file-diffs

by adefa • 13 years ago

438 113 13 years ago

Not sure why but from just reading the title I was expecting a new way to view diffs of normal files in some funky 3D mode

bollockitis• 13 years ago

I thought the same thing. I thought the title was implying that they were offering "3D diffs for files," not "diffs for 3D files."

antsar• 13 years ago

Same here, perhaps "GitHub announces Diffs for 3D Files" would be clearer. This is a really awesome feature though, I'd be curious to see what other types of files they do this for (if any).

benjamta2• 13 years ago

me too. so whoes up for implementing a funky 3D tool for normal file diffs ;-)

rfnslyr• 13 years ago

How do you see that working?

jack-r-abbit• 13 years ago

Me too. But as I was clicking and lagging on getting to the page, I was trying to visualize what a 3D view of a file diff would look like. I can't even imagine it.

ianstallings• 13 years ago

I thought the same. No 3D GUI for text? Guess I'm gonna have to write my own.

Cue swordfish music.

ceph_• 13 years ago

Dramatic interpretation: http://youtu.be/volV54jPkqI

mck-• 13 years ago

Me 8

hosh4• 13 years ago

Me too, but this is way better.

mcintyre1994• 13 years ago

Same, I was expecting something like Mozilla's crazy 3d view for webpages

ape4• 13 years ago

File one on the X axis, File two on the Y axis, differences on the Z axis.

castis• 13 years ago

my head already hurts

Serow225• 13 years ago

This needs to be done.

alecsmart12• 13 years ago

Reminds me of a scene from Jurassic Park.

manlycode• 13 years ago

This is a Unix system. I know this!

theoh• 13 years ago

It really was! http://en.wikipedia.org/wiki/Fsn

tsahyt• 13 years ago

I was thinking the same thing and was wondering how exactly that would look like as the page loaded. In a way I was disappointed. It's still a pretty cool feature though.

SCdF• 13 years ago

Me too, and was initially disappointed.

Now I think about it, it's super cool that GitHub are putting so much effort into being a useful platform for file formats traditionally not associated (much) with software development.

There is so much cool stuff you could investigate over and above text files: understanding photoshop files and describing layer changes; diffing audio and identifying mixes and how they were mixed.

furyofantares• 13 years ago

As much as I don't like meta comments I'm going to have to make one finally, because I think about it every day and just need to get it out there to at least relieve the pressure in my head.

Why is the top voted comment so often about the title of the story? I guess it's because it's the first thing we interact with and it frames our expectations, but man alive, the title is probably the least interesting thing about any article posted to HN but consistently I see top rated comments talking about the title. Maybe it's just lowest-common-denominator.

And it's not that I think the comments themselves are bad, it's just weird to me that I consistently see them at the top of the page.

Apologies for the meta rant, it won't happen again, at least from me. (In fact the reason we have a lot of meta comments might be the same as the reason we have a lot of title-comments making me a bit hypocritical, but I digress.)

hardwaresofton2• 13 years ago

I think it's because people upvote most often when they share a particular opinion -- and your first opinion is mostly about the title of the article.

For example. I saw the title, clicked through (also opened comments), gave the page a once-over (didn't even read) -- came back here, and saw that first post. I also agree with the guy said, I thought they came up with some amazing new way to view regular diffs in 3D. So, I would have upvoted. Maybe it's just me, but I'm guessing far more people do that

kbenson2• 13 years ago

In this case, possibly because it may provide some value to anyone reading the comments before the article. I too through it was going to be a diff for text files using a different visualization, not a diff of a specific file type. In that respect, it's a clarification of whatever summary you might infer from the title.

In short, I found the comment useful, it not necessarily inspiring of conversation (although a discussion of different visualizations of changes may be worthwhile).

jotux5• 13 years ago

I've thought about this before and attributed it simply to bikeshedding. When something interesting pops up people really want to be part of the conversation but don't have the background to talk about the main topic so they comment about the meta information.

danabramov• 13 years ago

I thought the same, and I freaked out a little bit because this was something I was thinking about just an hour ago (some sort of parallax).

asselinpaul• 13 years ago

Wow, I love how Github is transforming into the a great tool maker for the digital world.

chriskelley• 13 years ago

I wonder if they have any plans to add support for other 3D filetypes (.ma, fbx, obj, etc)? It would be great to use this with more organic VFX-type models where some of the intricate detail updates are hard to discern at first glance.

Blue sky thinking, it would even be awesome to have something like this as a plugin in Maya where we could load in a previous version of the model and onion-skin between them with a slider like in the demo.

Going to check out the links in the article. Very cool!

kmfrk• 13 years ago

I would unironically love a GitHub developer's conference where they get to do a keynote presenting all the awesome features they churn out at record pace.

I feel more people who aren't unrepentant nerds should get to see what these guys (and gals) are doing.

---

EDIT: They could just do something simple at a local, informal event (say a bar) with a few dozens of people. it doesn't have to be something huge.

It'd also be a great way for everyone at GitHub to get some training in making and delivering presentations, and it's great to have on your resumé.

I'd definitely want to try something like that out as a CEO, and I imagine it'd make it even more fun to work at a playful place like GitHub.

steveklabnik2• 13 years ago

They did a conference a long time ago: CodeConf. It was a blast.

Goopplesoft• 13 years ago

I wonder what percent of Github users store 3D files, to make this worth the effort. I imagine less than 0.5% if that?

robertely• 13 years ago

Probably that many previously, but this has been a long requested feature of the hobby 3d community.

If you build it they will come sort of thing.

maxk42• 13 years ago

Well now that Github actually supports 3D files, I'm sure that will change.

fletchowns• 13 years ago

With 3D printers becoming more common, I think they are positioning themselves for the future, rather than fulfilling a strong demand that exists today.

scoofy2• 13 years ago

A friend and I built http://www.bld3r.com as a vastly more open 3d file sharing platform than thingiverse. We welcome this move, as we prefer files to be hosted on open platforms like github. I thought I'd plug the site for anyone who wants an alternative. We are still in beta, but are finishing that soon.

kanzure5• 13 years ago

I wouldn't call github an open platform. Maybe you meant gitorious or cgit or gitweb?

scoofy2• 13 years ago

I mean open in the sense that they have clear terms such that they don't effectively own your content. In building a 3d printing social network, not having to trust us was important to our design.

thrillgore• 13 years ago

This certainly makes Github a viable option compared to Thingiverse. Hopefully we'll see OpenSCAD file support in the future!

willvarfar• 13 years ago

This is great! Historically, studios has shunned dvcs; github moving in his direction - even if motivated by personal 3d printing projects - may open some eyes and change some minds.

hosh4• 13 years ago

That would be great ... but I think the bigger thing is, just as open-source software has taken over much of the Internet, this is a critical step in helping open-source hardware take over ... well, everything else.

kanzure5• 13 years ago

Cool, that's one wishlist feature down.

https://news.ycombinator.com/item?id=5519676

(hehe "Wow. That's a stupidly large amount of work, barfed out with seeming ignorance to the cost of implementation." Yes, well.... libffi helps out a lot.)

angersock2• 13 years ago

Sometimes, open source actually helps mitigate the work issue.

rafeed2• 13 years ago

This is so great! I'm always working with STL's and always asking myself, "what's different in these models?" I'd love to see meta data and other 3D file types like VRMLs or SolidWorks parts included in the future as well.

kanzure5• 13 years ago

SolidWorks seems really difficult to implement unless you're licensing a Windows server + SolidWorks software licenses or running wine and hacking up their dlls.. I would be curious to hear ideas on how to do it.

rafeed2• 13 years ago

This is true. I think it would require working directly with SolidWorks to make it happen since everything of theirs is so proprietary.

jotux5• 13 years ago

A neat feature but I wish they had support for 3d source file types instead of exported "binary", for lack of a better term, file types. If you wanted to truly open source your mechanical project you'd need to add an extra step to delete the previously exported STL and export a new one every time you commit. You also lose color/texture data when you export to STL.

steveklabnik2• 13 years ago

STL files are the source file for most 3D printers, which is probably the vast majority of 3D files on GitHub, I'd imagine.

kanzure5• 13 years ago

STL files aren't sources. They are near the very end of the toolchain. At the front of the toolchain tends to be scripting languages like AutoLISP, OpenSCAD, MGED (BRL-CAD), etc.

jotux5• 13 years ago

Yes, it's the output from a CAD tool and used for 3d printing but STL is a binary file type and not easy to edit. Committing STL files to a repo is analagous to commiting EXE files instead of source code or PDF files instead of TEX.

DanielRibeiro• 13 years ago

Actually there are 10x more OBJ formatted files than STL files. I created a Chrome extension to visualize these on GitHub as well: https://github.com/danielribeiro/three-hub

Collada format is also very popular, particular with WebGL guys. The problem with diffing these is that you start diffing animations as well. Which literally adds a new dimension to the problem. If you take textures and materials into account, then the problem soon becomes really hard to visualize

dnautics4• 13 years ago

it's pretty trivial to include your SCAD file (for openSCADders like me) alongside your STLs. That's what I did on my github project (linked to indirectly via my info, and elswhere in this section).

srimech• 13 years ago

I have my SCAD files on github. It seems wrong to me to have a build result (the .STL file) under version control though.

dnautics4• 13 years ago

this is great, comes just in time as I'm desiging a custom 3d scientific part. https://github.com/ityonemo/imsocultured/blob/master/device....

kanzure5• 13 years ago

Would you like any help building/designing/softwaring that? I have a soft spot for rolling my own lab equipment.

Only asking here because github is down, otherwise would be looking..

dnautics4• 13 years ago

well the design is complete, we printed some first round tests, and adjusted the tolerances, and the final device is being printed as we speak.

pbhjpbhj• 13 years ago

What's it do - presumably it's a connector, glass rod to rubber hose (ie tubing)?

Edit: ah, found this https://github.com/ityonemo/imsocultured/commit/08b57107b757... - "oral microbiome community culturing apparatus" - so the complete apparatus is for culturing whatever bacteria and such you find in your mouth in a mini biome?

dnautics4• 13 years ago

the oral microbiome model system is an anaerobic community; this apparatus allows you to connect a pH probe using the screw side for continuous pH monitoring (we already have a device that does this; but it's suboptimal for other reasons too) plus a second port that will be fitted with a septum to draw gas, draw samples, or add to the medium.

schrijver• 13 years ago

They had diffs for typefaces at some point: http://i.liketightpants.net/and/how-it-has-come-about-that-c...

I originally suggested it to them, and was kind of sad that they did away with this feature—that being said, it makes sense they want to streamline their platform.

Then, I’ve found it hard to create these kind of things myself, selfhostable FOSS solutions like Gitorious don’t offer enough possibilites to build upon (no real API)

thefreeman• 13 years ago

And.... they're down.

edit: back up yay!

angersock2• 13 years ago

This is why we can't have nice things.

GantMan• 13 years ago

have you ever seen Cube 2, hypercube? They must have tried to go 4D

jackflintermann• 13 years ago

Hmm, github.com is throwing a 500 error at the moment. I wonder if this is somehow related?

markdunphy• 13 years ago

In other (possibly related) news, the entire website is now throwing an error.

jared314• 13 years ago

I wonder if this feature is targeting the growing consumer 3D printing market. Being the goto place for collaborating, and versioning, 3D designs would be a good play for them.

leoh• 13 years ago

It could be great to have something like this for SVG!

hardware_nick• 13 years ago

This is nice, but, it feels like a splashy visual tool that took a lot of dev resources and will only be used significantly by a small user base. I personally feel that they would make a lot more users happy by spending a little on improving their existing code diff interface. Some ideas:

- make the context button "..." for the code diff actually do something

- side-by-side diffs

- syntax highlighting

pyrocat• 13 years ago

They're doing it before a significant user base grows that precipitates a github-for-3D startup. Building this feature also fosters growth of open source 3D modeling and printing, which is a net positive thing.

bradtgmurray• 13 years ago

It is a net positive, I just wish they would focus more on their core users. Their basic code diff tool could use a lot of love to make it on par with the diffs generated from other tools.

tesseract• 13 years ago

I wonder if it really will though. As mentioned elsewhere in this thread, STL is an output format (think PostScript) that I would be a little bit surprised to see checked in to a repository. Maybe diffs for 3D source formats will come in the future?

pintglass• 13 years ago

I agree. I think whoever is ok'ing things like the UI changes made in the past months and whoever approved this diff really is not doing what the majority of users are looking for. I think GH provides a great service, but something is wrong.

hosh4• 13 years ago

This is aweomse. It's a small, but critical step in making the design for things versionable and forkable.

snowwindwaves• 13 years ago

Does anybody know of a 2D diff for diagrams? a lot like http://www.diffplug.com/

plg• 13 years ago

Sometimes more is less

adamwong246• 13 years ago

Oh Github, you're wonderful

malkia• 13 years ago

In a similar vein: http://3drepo.org/

sam2• 13 years ago

This is a small step into a big open field. Collaboration in the hardware design space is moving slowly. It's not even at the SVN/CVS level now.

Has an architect ever forked an open source building? Has an biomedical engineer ever forked a open source prosthetic hip implant? Has a civil engineer forked an open source bridge? They will.

jotux5• 13 years ago

Solidworks has had a svn-like system built into it for the last few years: http://www.solidworks.com/sw/products/product-data-managemen...

sam2• 13 years ago

Yeah, but it's probably expensive. The pricing isn't even public: http://www.solidworks.com/sw/purchase/quote.htm

bronxbomber92• 13 years ago

But are these things "open" in the first place to be forkable?

hosh4• 13 years ago

Sure.

    http://opensourceecology.org/
    http://www.cd3wd.com/cd3wd_40/cd3wd/index.htm
    http://theurbanfarmingguys.com/our-story
    http://urbanrootsamerica.com/urbanrootsamerica.com/Home.html
    http://arkfab.org/

hardwaresofton2• 13 years ago

You might even say this field is ripe for... "disruption"?

iamwil• 13 years ago

Cubehero(https://cubehero.com) had visual diffs a while back in a post (https://news.ycombinator.com/item?id=4393704). However, I've found that people outside of software think about version control a bit differently, and diffs are of a secondary concern. That said, I think it's important step, and the next one is to figure out how to do merges.

samwillis2• 13 years ago

I think we will only see a github for mechanical design once there is a good OS alternative to solidworks and it's brethren, freecad (http://www.freecadweb.org/) is in the right area but you can't underestimate how huge these packages are. I think it will be another 10 years to see something like freecad reach the level of the commercial software.

Part of the issue is that there is not open standard for an editable parametric cad file. All the open file formats are 'flat', its like flattening a photo shop psd into a bmp.

Anyone collaborating on an open platform will at the moment still need the same expensive software to edit the files. That is the barrier to entry, not the availability of a github for CAD.

triggercut2• 13 years ago

Has an architect ever forked an open source building? Has an biomedical engineer ever forked a open source prosthetic hip implant? Has a civil engineer forked an open source bridge?

------

TLDR: Yes and no. They driver is 'why'. What were you intending to achieve by forking a building/bridge? It's not always useful for geometry but is for the information that drives that geometry, which we are getting better at doing thank's to some international standards.

------

Walloftext: As someone who consults to Engineers and Architects on their use of technology in collaborative design, as well as previously working in both types of design environments as a CAD Manager I'll attempt to answer, but not really answer your (maybe hypothetical) question.

Firstly, effective collaboration in the Architecture Engineering Construction (AEC) industry is a big problem, widely regarded as the core reason why the industry's productivity rate globally has remained so low and stagnate for years when compared to other industries.

One of the big problems has been effective digital interoperability. Currently there are two global standards in development, ISO15926 (for plant) and IFC ISO16739 (for architecture). Both are domain specific ways of transmitting information about a design at all stages of a projects lifecycle to other people involved. Think of it as an object orientated way of representing buildings, rather than by arbitrary geometry.

What you'll notice about both of these standards is that geometry (whilst important) only forms a portion of the overall dataset. There's information on procurement, construction, cost, scheduling, materials etc. and in my experience that is the information, and the reasons why such information was decided upon, that would benefit most from a version control system. (I've had success with using semantic wiki for collaborating on contracts, scopes of work and specifications for instance). At the moment the design processes behind designing a bridge or building are like a manual CVS. Every part of the design is modularised, you have folders that have sheets of paper showing drawings at particular revisions and associated documents like calculations. This way those who need to sign off documents have the full design history available to them. However this is extremely cumbersome and has limitations. Merely replicating this process digitally (with files and folders) ends up being a duplication of the manual process anyway.

Digitally there are ways to centrally share and 'fork', 'merge', 'pull', 'push' etc, many around the standards I mentioned, however the industry tends to be mostly linear in it's design methods and is only slowly moving towards a central model of digital collaboration (for pages and pages of reasons that I won't mention; cultural, historical, legal...). Short answer however, there a huge number of nuanced variables and complicated dependencies that make things difficult.

Would you fork a building? Yes and no, it's pretty much done all the time (in 2D mostly) by builders and property developers where you see a show home and then slightly modify it to your block. However, Architecture is always uniquely tied to it's environment; Even ignoring the art of designing for place, you have regulations that will dictate setbacks, overshadowing, where windows can be placed in relation to your neighbours, etc. Currently if you have a whole load of dumb 2D and 3D geometry this is a manual process and simply modifying may take you longer than just starting a model again from scratch. IFC is making this easier, much research has been done in Singapore on this particular example (automated code compliance) but is still quite a way off from mainstream adoption.

Would you fork a bridge? Probably not. I've been heavily involved in engineering (mining) for the last 6 years and have been fascinated watching the "copy and paste" design scenario play out again, and again. Standard design has it's place but is mostly a myth or relegated to smaller parts with fixed parameters and requirements (like a truss or a joint), not entire projects. You'll be very lucky if you have say, the ground conditions match up exactly to the size of your previous bridge. Say physically it's the same, maybe the soil conditions or the way water drains off that bank is different, requiring you to redesign the foundations. Things get jigged a bit and have a compound knock on effect somewhere else in the design. The wind-loads are different here and you need to reconsider the bracing and profile. Then suddenly the client has different needs, requiring you to redesign for them. Before you know it, you have a completely different bridge, with different specifications, dimensions and a different contract. But it was quicker to start from the initial one, right? Well, that's debatable. This is a very simple scenario but in my experience, probably not.

I worked for a company recently that had some IP in mineral processing, a very modular system, a lot of repetition, hundreds of kilometres of piping and thousands of tonnes of steel. Despite it being a "standard" design, it is still re-engineered every single time it was used, partly because of the regulatory requirements for documentation, partly because of local conditions (they can't procure unit A so get unit B, they don't have capacity to construct in a particular method, so everything is changed to suit another method of construction).

Copy and paste in large scale engineering in the built environment is a fools paradise. Geometry is just the tip of the iceberg. On one project I produced visual diffs on detail drawings for a while, but the feedback was that they weren't really required, most teams are so intimately linked to their design visually that they don't need them. What they do like, however are diffs on what drives that geometry (notes on calculations, specifications, product data-sheets).

I'm going to stop now before this gets more out of hand and less helpful.

fra• 13 years ago

Meanwhile, still no side by side diffs :(

dandyhighwayman• 13 years ago

GitHub: Doing the Work That Matters(tm)

voodootikigod• 13 years ago

Mike Skalnik (post author) will be at RobotsConf http://robotsconf.com and available to talk about this and other similar initiatives going on (make-me, etc). Still a few tickets left. Saw a couple comments about conferences and such, figured it would be worth mentioning.

jamesmiller5• 13 years ago

I haven't seen anyone mention binary space partitioning since using quake3's bsp toolchain a few years ago.

http://www.mralligator.com/q3/

3rd33• 13 years ago

I'm wondering why they ended up using BSP as a data structure for boolean mesh operations. Is there an advantage over Octrees I'm not aware of in this case?

3rd33• 13 years ago

Aparently, yes: http://onlinelibrary.wiley.com/doi/10.1111/j.1467-8659.2009....

sshirokov• 13 years ago

For the use case of boolean mesh ops the majority of the work is polygon splitting and clipping, something BSP trees excel at.

perone• 13 years ago

And they still didn't implemented a visualization for SVG ?

tibbe• 13 years ago

Can we have side-by-side diffs of code first, please?

swang• 13 years ago

Yes. With maybe support for viewing full files instead of just the diffs. None of the Chrome/Browser Extensions really do this.

itsbits• 13 years ago

awesome addition..althgh am little confused looking for changes..but revision wise looks quite descriptive....

marcosscriven• 13 years ago

This is very cool. Rather obviates my own site. (http://fabfabbers.com) Ho hum ;)

talles• 13 years ago

Now I'm feeling in the future

GitHub announces 3D File Diffs

Related Stories