@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