The following short video shows what takes to setup and share a project from scratch:
We are still working on this system, but hopefully you get the idea. Our focus is to make the setup as simple as possible so people can start collaborating without significant effort.
This is also intended for more than collaboration and source control. This same layer of distributed persistence can be used by any application to store and sync the changes their users make.
This is a very active area of development for us. I will be posting more about this in the future, meanwhile as always I look forward to the questions you may have about this system.
nice
ReplyDeleteCool, I wish you guys good luck, as I know that network programming can be a bit annoying, but you guys have done great things already, so I'm sure you won't have too many problems =).
ReplyDeleteIs there a reason why you show the user's own avatar in their camera view? Wouldn't it make more sense to hide it for themselves and only show other avatars, since the avatar is essentially in the camera position?
ReplyDeleteThis is awesome though, I can imagine one user constructing a huge building and other users going through adding fine details as it's built. Or people working on different parts of the same structure. So many opportunities!
No particular reason for the third person view. For us it was useful to display the avatar at some point, it shows where the server (and others) see you and it reminds you that you are editing in the cloud and not locally.
DeleteHey, the ability to easily load up shared spaces to create in is more interesting than loading up a space where you can remove someone else's edits. You'd get more bang for your buck to have UIs support easily navigating scenes, streaming scenes to others within an organization, and a public demo registry that others could simply view.
ReplyDeleteFor anyone working in a collaborative model intended to produce output in the long term (company or otherwise) isn't the ability to turn off Todd's edits is a bit of a parlour trick - pretty cool, but not so valuable as a must-have feature?
If you're looking to solve the problem of "how to show who owns what in a collaborative space," I think a market of architectural grammars is likely to be an interesting area.
Not a parlor trick, this is the cornerstone of the system.
DeleteThis is not about displaying ownership, this is about source control. When you are working with a larger team, you must be able to control who get's their contributions approved and committed. This is essential to any source control system.
Think about a similar system like GitHub. According to your rationale, GitHub should be concerned about allowing different people to easily browse repositories and download the source code. While a source control system will allow you to do that, it is really about controlling the production of content by a group of collaborators across a period of time.
While source control systems are a well known thing for text content (like code), they are virtually nonexistent for volumetric content. The use of voxel data open up this posibility because they can be merged automatically. This is what the video is showing at that point.
This may be a new concept to you, like code source control was at some point for many. Today, however, you will not find any team working on their code without source control. They would have to be out of their minds. In the future, it will be the same with large sets of 3D content. You would have to be crazy to develop a city for your MMO without source control.
The other advantage of this system is in crowdsourcing. When you open world creation to thousands of people, you really need the ability to selectively turn on/off contributor streams. For instance if someone is griefing it is trivial for the community to ignore that person's stream of content. This is an asymmetric system like Twitter of Facebook. Yes, there are a lot of assholes in Twitter, but if you do not "follow" them it is like they do not exist at all.
So in this example, would Bob be able to remove a chunk from the blocks that Alice put down? Going by the git analogy I would assume not because they would both have separate working copies made from the same branch but their changes are only merged in the display. If that is that case I would assume that for Bob to edit Alice's changes Alice would need to commit the changes, and Bob would need to be working off the updated branch?
ReplyDeleteBob would be able to remove chunks from blocks that Alice put down. There is not need to commit or think about branches. When you decide to see both Bob and Alice's contributions, they are applied in order. If bob removed after Alice added, the results will reflect that.
ReplyDeleteOk, so each person's work is stored as a set of actions with a timecode (or some other value that specifies order) so that two sets can be merged in the right order to allow editing of each other's work?
ReplyDeleteYes you got it! :)
Delete