Cooperative Modeling
-
@plot-paris said:
if the changes were viewed live (or almost live), that would be huge fun! one person could simply navigate through the model and look around, while three others are building it.
Something like what Onuma does at his BIMStorms perhaps?
-
I just remembered, we had a similar discussion about seven months ago.
and Gaieus, in this thread you mentioned...
@unknownuser said:
You don't even know how close you are to REALITY
you still haven't told us, what you meant by this...
(you see, be careful of what to write on this forum, for it will never be forgotten
) -
Okay, check this application out for instance. My ID there is gaieus {at} sketchucation{dot} com and this is my webshare ID (PIN: 162622).
Of course I'm not at share mode at the moment but find out the app and once we "meet" online here, we can test it.
-
that software is really cool Gaieus. and it will become even more powerful with internet bandwidth rising dramatically these times. that definitely goes into the direction of what we want, I think.
although it only give one person the control over SketchUp (or lets say it gives two people control over one mouse
).
it is definitely heading in the right direction, though.but what we need now (well, not really need. but what we would love as a toy), is an option, that takes this Idea and incorporates it into SketchUp:
- two people (or more) working on the same model, but in two different windows, with independent camera views (so that each person can move around independently) and some sort of representation of the other users online in this model.
actually, I think this could be done really quickly. for there is no video information that has to be transferred. the only information that has to be exchanged is the changes made to the model (which are only a couple of lines unless you insert a big component or do copying processes of lots of geometry...
-
This could be solved in a following or similar way:
- an user logs in into a 'server' and opens a 'workgroup' current model
- an user would have access to one group for editing so others won't have access to it
- the groups will be updated every .. 5s so every user will have fellow workers groups refreshed every 5 sec. I imagine it as a group(component) saved in the same folder as a master drawings and reloaded by co-workers
- when one will leave the group - will have to look for another 'job' or create new group..
For the time being it will work for relatively small models and probably in LAN only.
I have no clue how complicated it would be in terms of coding. The problem is, what we would do with components inside various groups?
Just an idea.
For a start we could just share transformations of same 'brick' between peers and the brick would be an only allowed building component.
So if users moves a brick script should let know others that a brick 'ID...' has changed its transformation. It would work even through internet
Wouldn't it?Chris, your Namesets could help? Isn't it? As an external database - accessible for all users?
Tomasz
-
great, Tomasz.
you already put quite a bit of thought into how all this could work. as a start it is really a good idea to 'lock' a group or component for others, when one participant is editing it. and I imagine updating groups throughout the internet/network should definitely possible.to your question, what happens, if anyone is editing a component that is a copy of a component, that lies within a group/component, that is currently edited by someone else - well, this component is 'locked' for everyone.
(this sentence was probably too long and too confusing to be comprehensible. sorry)the big question is: is it possible to update only the changes, but not the whole group/component. because if you have nested groups, they can quickly become huge. and if you have to send all this data every 5 seconds - thats going to crash you broadband connection...
do you think it is time to make a ruby request?
-
Plot, what I have outlined here is much more complex 'behind the scenes'. I am not sure it can be done with pure Ruby. I think it is should be rather a software request for a real developer. ... We've got few here!
Tomasz
-
I believe this is technically possible to write such a plugin right now - at least to a limited degree. I don't know about real-time synchronization with mouse cursor, but perhaps near-real-time updates of some events could be broadcast to remote SketchUp's from a session leader.
-
@l.frisken said:
@chrisglasier said:
The development of namesets is intended precisely for that - visit NS website and let me know whether this matches what you have in mind.
Cheers
Chris
Kind of but What I was thinking about was something much more simple so that it would be easy to set up and use(like the synchronise button)
Let me say this. You are in danger of thinking up dozens of what appear simple solutions that will soon become very complicated to control and use. If you really want to get to grips with this, start with thinking about an operating system and an infrastructure. Think about how DOS and subdirectories underpinned the PC, and apply the principles to data structures. It is the data structures that will do the synchronising and, with devices, model generation.
Now data belongs to objects and objects have names, hence I came to the conclusion that names are the lowest common denominators, i.e. they can be manipulated into sets to represent both simple and complex ideas (a teapot, building, town ...). You may not agree. However I am willing to share what I have done over the years provided it is used in a sincere effort to improve everyday work.
Chris
-
Sorry Chris,
You see I'm not that old, and I struggle to understand your Nameset's Idea, that's why I wrote it, I'll take the comment back If you think it will help with this thing. I'm just glad there are people out there smarter than me who can make or at least understand this kind idea! I am trying to learn though and maybe one day I might be able to write a plugin to help people myself, in the meantime all i can do is try and suggest ideas that i think there is a need for!
l.frisken
-
@l.frisken said:
Sorry Chris
No need for sorry. But you could help me by telling me what part of namesets you find difficult. Ask as many questions as you like. My problem is that I'm so deep into it all seems obvious - that is very bad!
Chris
-
@chrisglasier said:
Now data belongs to objects and objects have names, hence I came to the conclusion that names are the lowest common denominators, i.e. they can be manipulated into sets to represent both simple and complex ideas (a teapot, building, town ...). You may not agree. However I am willing to share what I have done over the years provided it is used in a sincere effort to improve everyday work.
Chris. Let's assume, for a sake of simplicity, that we have a Nameset containing transformations of a single component called 'Brick', SU would serve as a display for the Nameset and as a modifier. Would it be hard to make it work in a network?
You are right. You are so deep into Namesets, that you skip some basic stuff we need to understand. I know that the whole idea is to share just single interlinked data records, instead of sharing webpages. The brick example above would be good for basic SU user to understand the principles.
@jim said:
I believe this is technically possible to write such a plugin right now - at least to a limited degree. I don't know about real-time synchronization with mouse cursor, but perhaps near-real-time updates of some events could be broadcast to remote SketchUp's from a session leader.
I thought that seeing someone drawing a line during dragging it won't be possible. This would be so nice!
Jim if you would help Chris, we could have something very interesting here. -
Let me try and analyse this bit by bit.
@unknownuser said:
Let's assume, for a sake of simplicity, that we have a Nameset containing transformations of a single component called 'Brick'
.Better to omit transformations I think - "Let's assume, for a sake of simplicity, that we have a Nameset containing a single component called 'Brick'".
@unknownuser said:
SU would serve as a display for the Nameset
Precisely.
@unknownuser said:
... and as a modifier.
I think this is confusing. The brick would have a record which includes index no, name, fileName, x, y, z. It is the record that gets modified before the instruction to display.
@unknownuser said:
Would it be hard to make it work in a network?
The record is a comma separated value. As far as I can see, you can do anything with it, whether on a standalone machine, LAN or Internet.
Let me leave it there for now and see if you think I am progressing.
Chris
-
@chrisglasier said:
@unknownuser said:
... and as a modifier.
I think this is confusing. The brick would have a record which includes index no, name, fileName, x, y, z. It is the record that gets modified before the instruction to display.
Yep. I meant - the modifier of Namesets records. So if I would move a component Brick (Index number 10) it would cause an update in the record first and then as a result - refresh position on the screen for other users. Mine brick would be in correct position already. Does it sound reasonable?
If an user would select a brick, plugin would block its record for editing by others and wouldn't let them move that particular brick.
The problem is that for a big model the amount of records would be enormous. Will Namesets handle 100,000 components relatively fast?
Tomasz
-
@unknownuser said:
The problem is that for a big model the amount of records would be enormous. Will Namesets handle 100,000 components relatively fast?
you should rather ask: "Does SketchUp itself handle 100.000 components relatively fast?"
this nameset thing sounds quite good. although that means, that if I edit a component that is lets say 10.000 polygons heavy, all this information will have to be uploaded and not only the changes, right?
it also means, that updates are only shown, once the person exits the component and therefore finishes the modeling process (no live modelling), right?how do namesets behave with nested components?
-
I would guess that handling large amounts of components would be fine, unless someone was trying to move all of them at one time on the x, y, and z axes. Then the namesets would be trying to update 3 properties (x,y,z) on 100,000 entities. I don't know how many bytes of info that turns into, but I'd guess it would be pretty big? So the transfer of that info over the network would be slow, THEN you'd have to worry about how slow your SU would get once it recieves the updated coordinates and attempts to move those same components to match the updated nameset coordinates.
Does that make sense? I think so.
We need someone who has developed multiplayer games so they can write the server and client programs and get them to send namesets data back and forth smoothly.
Chris
-
@unknownuser said:
Yep. I meant - the modifier of Namesets records. So if I would move a component Brick (Index number 10) it would cause an update in the record first and then as a result - refresh position on the screen for other users. Mine brick would be in correct position already. Does it sound reasonable?
Yes, but I would like to discuss the business of refreshing.
First namesets allows you to have the whole model displayed or only a part. The full set of records (a js array) is always updated but only the required components and groups will be called to display.
Say a designer was responsible for a "typical" floor in a hotel guestroom tower. She has assistants working on the guestrooms, bathrooms, circulation areas, walls and service ducts and so on. Generally each assistant has just the entities he is responsible for displayed, simply because it would be very distracting to see other entities moving around out of his control. On the other hand the walls and service duct guy needs to see the spaces, but he has the option either to filter them out alternately or to temporarily switch off updating completely. The team leader, of course, sits back and watches the design process like a film - her screen showing the whole floor being refreshed after any change. She also has the option to use SU tools to have a good look round.
@unknownuser said:
If an user would select a brick, plugin would block its record for editing by others and wouldn't let them move that particular brick.
Yes, hence the importance of updating the record first and updating the display from it. (One record entry identifies the team member.)
@unknownuser said:
The problem is that for a big model the amount of records would be enormous. Will Namesets handle 100,000 components relatively fast?
The records are plain text when stored (ave 91 bytes per 24 entry record) and a simple three level js array when in memory. Actually the main reason I animated the NS UI was it was so fast you did not see it change. The restraint is the display ...
@plot-paris said:
you should rather ask: "Does SketchUp itself handle 100.000 components relatively fast?"
this nameset thing sounds quite good. although that means, that if I edit a component that is lets say 10.000 polygons heavy, all this information will have to be uploaded and not only the changes, right?
it also means, that updates are only shown, once the person exits the component and therefore finishes the modeling process (no live modelling), right?how do namesets behave with nested components?
I will try and discuss this altogether as the items raised are interrelated.
NS tries to get as close as possible to real objects and processes. Components are not grouped with SU tools but by the hierarchy of the Nameset. Each set, which normally includes other namesets, represents (and exposes) human ideas. Nesting is an intellectual device not a physical one. This allows crosslinking so that, for example, the same component can be put in a container, lifted in a hoist and positioned in a space, and, if it is a table, booked for dinner.
Up to now I haven't really looked very deeply at using namesets from a strictly Sketchup modeler's point of view. I have only considered components and groups, meaning your 10000 polygons would need to be in a file. NS would have to be told to reload a revised file. The main thing is the record; I would be very happy to see multi-lateral means to create and maintain it.
Changes can be made on the fly (only affected objects are moved) or completely regenerated.
On the question of live modeling I think I can say no more than what I wrote above.
@chris fullmer said:
I would guess that handling large amounts of components would be fine, unless someone was trying to move all of them at one time on the x, y, and z axes. Then the namesets would be trying to update 3 properties (x,y,z) on 100,000 entities. I don't know how many bytes of info that turns into, but I'd guess it would be pretty big? So the transfer of that info over the network would be slow, THEN you'd have to worry about how slow your SU would get once it recieves the updated coordinates and attempts to move those same components to match the updated nameset coordinates.
I am really not worried about updating the record and transmitting it. But I am concerned about the display. I have noted some options that can help and I am working on other filters and so forth so that only what is needed is generated.
@chris fullmer said:
We need someone who has developed multiplayer games so they can write the server and client programs and get them to send namesets data back and forth smoothly.
Yes!! Any multiplayer games developer please step up to the plate! Also I think it is good to think of namesets as a game combined with filesharing and a machine-like UI. I don't know if it is clear that namesets exist to cope with the diversity of human endeavours; this needs to be taken into account; the structure and nature of the data is as important as the coding that automates it.
Please visit the website; it may help clarify my meanderings.
Thanks
Chris
-
I will try to understand more about namesets works! It sounds very interesting! In the meantime, I really hope that someone out there like a game programmer can volunteer some of their time or ideas.
Advertisement