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.)
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
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).
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.
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.
A always assumed it was fake until a few years later a friend brought an SGI workstation into work to play with, and showed me the file manager.
Now I generally try to keep an open mind when I see things in movies as elements, while they may not be entirely correct, are sometimes based on reality. It just happens to be a portion of reality you are unfamiliar with.
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.
We have just got SolidWorks PDM at work and I am in the process of setting it up. I know a little about it.
There is two different solidworks PDM products, workgroup and enterprise. We went with workgroup which is cheaper and probably better for smaller teams. Workgroup is about £1000 + £200pa per seat and no cost for the server. Enterprise from memory was about 50% more per seat and you have to a few grand for the server, plus pay someone to 'configure' it for you.
PDM workgroup is actually pretty similar to SVN, you check files out, work on them and check them back in again. Except it understands relationships between files and their meta data so you can check out an assembly in its 'as built' state and it will checkout the correct old version of the parts.
Enterprise goes much further and creates work flows for you company. Documents go through different stage gates with different people being able to make changes and approve them. It is very much design for large teams with rigourous QA. It also appears as a network drive with some nice shell extensions on Windows.
Suprisingly neither of them have a Diff built in, although solidworks does itself have that sort of tool.
As a market it is definitely ripe for disrupting, although to succeed there would need to be tight integration with the software packages (solidworks, creo, inventor etc)
I anyone on here is looking to do something in this area I would love to hear from you.
But as we all know it's been a ripe area for disruption since the 1970's. :)
At the moment it's less to do with software as it is to do with the way we share the resultant information, of which there are emerging international standards. MCAD is not my speciality but I don't think I've seen a standard for handling parametrics. Unfortunately closed standards are hard enough to get governments and industry to adopt let along open ones.
If you want a solid object modeller with parametrics that's open source and you can compile yourself, check out BRL-CAD.
You can bet it's thousands of US dollars, if not tens of thousands. Just a single seat of Solidworks is $4000 without any extras. Believe it or not, that was actually crazy cheap for parametric CAD back when Solidworks started becoming popular ~15 years ago.
As much as people give Solidworks flak, it actually is really, really good software for what it does, and it does a lot of different things. There are other pieces of software that can match or exceed it in single matters, but very few can do all the things it does. While it's not cheap by an means, it fills a role at which little else comes close.
In other words, it may be $4000, but it does what would take four or five $1000 (plus training) pieces of software to do.
As a near-daily Solidworks user, I totally agree. The problem in my mind is just that the barrier to entry is so high due to cost that it prevents the kind of open collaboration on mechanical design that's been possible for years in software and electronic hardware. Just like 3D printers, prices will come down to better serve hobbyists and individuals -- it's just a matter of time.
Solidworks is a great 3d modeller software. It's a pleasure to do most things in, and gets out of the way when you want it to.
The only modeller I like more for certain operations is OpenSCAD, but that's because I can understand the math operations in printed pieces in complex curves.
The one program I want to see die a firey death in source-code hell is ProEngineer, now called Creo(sote). It is patently user-unfriendly, and requires so much PITA setup to even do things like regular polygons. "Oh, you want to fillet? You better do it in the right order, or the last fillet _WILL_ fail!"
That's exactly what open source can change about a field. Opening a field to contribution from people with less money but just as many ideas can only be a good thing.
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.
> 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 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.
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.
What I mean is ease of editing in a typical CAD tool: Solidworks, AutoCad, Sketchup, etc. STL is imported as a solid blob and you lose all the individual features from the source model.
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
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.
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
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.
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.
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?
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.
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.
I am neither authorized nor inclined to speak for GitHub, but if you were to suggest devoting more resources to convincing the people running botnets to go fold proteins, that would be nice.
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.
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.
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.
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.
If github would make import/export a lot easier than it is today it would qualify as an open platform. Right now only the 'git' part of it is open (and git was open all along).
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.
With 3D printers becoming more common, I think they are positioning themselves for the future, rather than fulfilling a strong demand that exists today.
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.
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.
