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.)
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).
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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).
(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.)
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
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)
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!
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.
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.
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.
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.
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.
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?
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.
[+] [-] suhailpatel|12 years ago|reply
[+] [-] furyofantares|12 years ago|reply
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.)
[+] [-] antsar|12 years ago|reply
[+] [-] ianstallings|12 years ago|reply
Cue swordfish music.
[+] [-] SCdF|12 years ago|reply
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.
[+] [-] manlycode|12 years ago|reply
[+] [-] ape4|12 years ago|reply
[+] [-] bollockitis|12 years ago|reply
[+] [-] danabramov|12 years ago|reply
[+] [-] tsahyt|12 years ago|reply
[+] [-] jack-r-abbit|12 years ago|reply
[+] [-] mcintyre1994|12 years ago|reply
[+] [-] hosh|12 years ago|reply
[+] [-] benjamta|12 years ago|reply
[+] [-] mck-|12 years ago|reply
[+] [-] drivebyacct2|12 years ago|reply
[deleted]
[+] [-] benjamta|12 years ago|reply
[deleted]
[+] [-] sam|12 years ago|reply
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.
[+] [-] triggercut|12 years ago|reply
------
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.
[+] [-] samwillis|12 years ago|reply
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.
[+] [-] jotux|12 years ago|reply
[+] [-] iamwil|12 years ago|reply
[+] [-] hardwaresofton|12 years ago|reply
[+] [-] kmfrk|12 years ago|reply
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.
[+] [-] steveklabnik|12 years ago|reply
[+] [-] jotux|12 years ago|reply
[+] [-] steveklabnik|12 years ago|reply
[+] [-] dnautics|12 years ago|reply
[+] [-] kanzure|12 years ago|reply
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.)
[+] [-] hardware_nick|12 years ago|reply
- make the context button "..." for the code diff actually do something
- side-by-side diffs
- syntax highlighting
[+] [-] schrijver|12 years ago|reply
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)
[+] [-] chriskelley|12 years ago|reply
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!
[+] [-] rafeed|12 years ago|reply
[+] [-] kanzure|12 years ago|reply
[+] [-] asselinpaul|12 years ago|reply
[+] [-] thrillgore|12 years ago|reply
[+] [-] fra|12 years ago|reply
[+] [-] dandyhighwayman|12 years ago|reply
[+] [-] thefreeman|12 years ago|reply
edit: back up yay!
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] angersock|12 years ago|reply
[+] [-] GantMan|12 years ago|reply
[+] [-] willvarfar|12 years ago|reply
[+] [-] malkia|12 years ago|reply
[+] [-] scoofy|12 years ago|reply
[+] [-] voodootikigod|12 years ago|reply
[+] [-] Goopplesoft|12 years ago|reply
[+] [-] jamesmiller5|12 years ago|reply
http://www.mralligator.com/q3/
[+] [-] 3rd3|12 years ago|reply
[+] [-] jared314|12 years ago|reply