Quick theoretical question
-
Hi again,
I am just writing up the conclusion for my thesis and was asked by my prof to speculate about better integration with web 2.0 services. Without really needing any detail per say could anyone speculate into the possibilities of sharing sketchup information between computers live through web-dialogs or something. I was thinking maybe something with PHP/MYSQL could share variables information....but it would probably be pretty limited..every entity would have to be broken down to coordinates or something? Any way, wild speculation is welcome, like i said its just for a consideration in my conclusion.
Cheers
Korbin -
Theoretically, sure. I can imagine a world where multiple people can collaborate on a single model across the internet. I'm playing with that very idea right now. I'm not using php, mysql, or any webdialogs (yet). I use a simple UDP socket server setup similarly to how it would be for a multi-player video game like quake or call of duty. The sketchup sessions shares information back and forth through a server to stay in sync. The following link is a very early proof of concept that shows the view location being shared between two Sketchup sessions.
http://www.youtube.com/watch?v=BNHQT-o3RKk
The view is one thing but sharing entities does requires a lot more work. Not impossible, in my opinion, just more work.
good luck with the thesis.
-Mike
-
I would think the common model file would need to be on the server, and each client would be running a client plugin that implements observers.
When one client makes changes to the model, his client saves the file locally, then updates the server file. A signal is sent to all clients that are "watching" the model (via UDP, whatever,) and each client redownloads the file from the server, and opens the local edited version.
The only other way I can think of is a XML collada (DAE) format that can do transaction updates. Again the DAE file would be on the server. I this case a client that makes changes only sends a transaction file of the changes to be done (not the whole file.)
This would also allow non-modelers to watch the changes only, by using the O3D plugin (or similar,) with a webbrowser.Imagine a "Live" modeling contest where teams of modelers compete, and spectators can watch the contest in realtime via an O3D plugin.
-
I think you've got the idea. pretty exciting to think about what could be possible if you got 10's if not 100's of people in on model environment creating something together in real-time. I think it could be really amazing.
I am trying very hard to stay away from the first method you suggest. Revit uses a similar method of "saving to central" and I find it not very collaborative at all. The key here is "real-time." so your second methods it closer to the method I am exploring. I was going to use the XML collada approach but from what I can tell there is sketchup info that is not created in the collada file i.e. layers, attributes, pages, styles, etc. (layers being the big deal breaker). If I'm wrong about that, let me know.
The other approach I considered was plugging into an IFC file as my goals are for architecture. However, studying the IFC documentation gave me a headache so I gave up. Right now, I'm creating my own simple model database that uses mostly hashes to recreate and record changes to the model. all clients have this mega hash, when observers fire, the client tells the server, the server updates the hash and sends the changes to all other clients to update their local hash and the local model.
-
Wow that sounds really cool, and totally outside my skill level
I just said MySQL/PHP since i did GeoWeb stuff before, its probably not too practical in this situation.I hope you don't mind if summarize what you said into a few sentences and slide it right into my thesis
I'll be sure to give you (and everyone else from this site who without my thesis work would of failed) a shout out in my acknowledgments.
Out of curiosity, is the work your doing (mtalbott) going to be released publicly one day? or is it personal use? I'm always looking at new ways get citizens designing collaboratively with different visualization methods, and what you described has sooooo much potential.
Cheers,
Korbin -
@unknownuser said:
spectators can watch the contest in realtime via an O3D plugin.
That is also something that I want it to do. I've been trying to familiarize myself with WebGL after is saw the Google Body Browser project.
http://bodybrowser.googlelabs.com/body.html#
(you need chrome, or some of the nightly betas for the other major browsers, for it to work. no IE). -
@unknownuser said:
I hope you don't mind if I summarize what you said into a few sentences and slide it right into my thesis
no prob.
as for release... I'd love to eventually share it with the world. Maybe for a small price, maybe not. That depends on what is going to be necessary on the server side. I'm a lowly full-time architect with no formal code training and no real free-time outside of work so dedicating serious time to it is difficult. That said, improving the process by which we design has sort of become my passion. Providing the best tools is imperative to creating the best design process. In the building industry with so many disciplines involved in the design process, I believe the tools must be as collaborative as possible. I think that is where software is going and that is what I'd like to create.
-
@mtalbott said:
However, studying the IFC documentation gave me a headache so I gave up.
Which IFC file format, STEP or XML ? (The STEP files look like a nightmare!)
-
it was STEP, I believe. is the xml simplier?
-
@mtalbott said:
it was STEP, I believe. is the xml simplier?
The XML is simplier and free.
Get the XSD Schemas here:
http://www.iai-tech.org/ifcXML/The ISO spec (10303-21) for STEP is 180 euros.
-
@mtalbott said:
I was going to use the XML collada approach but from what I can tell there is sketchup info that is not created in the collada file i.e. layers, attributes, pages, styles, etc. (layers being the big deal breaker). If I'm wrong about that, let me know.
I have a copy of the COLLADA specs v1.4 and v1.5, and as I scan thru it:
Pagesare called Scenes in COLLADA (and also in the Sketchup UI, although in the API, the class is still the old name Page. You can alias a class in Ruby, BTW.)
Layers: COLLADA uses a SceneGraph Tree structure with [simplfied] <scene> subelements, with <node> subelements, with <render> subelements, that have <layer> subelements.
It's a bit strange.. I would expect there to be a <layers> element under which all the layers would be declared, perhaps near the top of the doc, but nope. Layer names appear in XML attribute values of other element tags, and within a <layer> element, within a <render> element.Styles: If Sytles cannot be directly translated into COLLADA effects, they can at least be stored in the file within a <extra> element. They are custom extensible elements for holding application specific data.
Attributes & AttributeDictionaries: They might be stored within <source> elements, but it looks cumbersome to me. Likely better to create custom <extra> elements for SKP attribute data.
So.. for Layers I would likely do the same, create a <extra> element that described SKP layer data that COLLADA does not use, and being sure to list all layers, even those unused (that might not end up being specified by any COLLADA element.)
-
Super helpful, as always. Thanks.
Advertisement