Cooperative Modeling
-
@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