I wanted to post this idea for discussion to get some feedback. The context is a MMOG using 3D graphics. I want some opinions on how well a client/server setup could handle objects created from a common cubic building block. The idea here is that the client would have information on what a cube is and a large library of textures and slight morphing effects that can be applied to a cube. Objects are made up of these cubes. Each object would have one marker cube that the server uses to keep track of the object's location. The other cubes that make up the object then only need to know their own location relative to the cube(s) next to them. In this way, the server doesn't need to keep track of each cube individually. No actual object data is stored on the client, and if it works the way I'm imagining, very little object data needs to be transmitted. The server would only transmit textual information on a cube's existence, what texture file the client should load, and whether or not a given side of the cube should be displayed as curved, or whatever. The server itself only deals with the cubes. Cube sides that connect to another cube would not be rendered, limiting the rendering to the parts of the object that are actually visible. The collision detection could probably just remain completely cubular and ignore the morphing visuals. The goal is to allow new objects to be added in real time without having to transmit new graphical data to the client and without using up too much valuable bandwidth. I hope this makes sense. I'd be happy to answer questions if anyone wants me to clarify something. Added 8/25/03: This would be used for custom-designed combat units. The landscape, fixed objects, player characters, etc. are things that aren't designed by the player, and can be stored on the player's hard drive. Since the combat units are to be designed by the players, it's possible that every player will have dozens or more independent designs. The game cannot be transmitting complete unit data to every client for every design in these circumstances, so I came up with the idea to make these units out of a common primitive shape, in this case a cube. The players would actually design their units using these cubes as a framework. Then, when players do battle, instead of the server having to distribute designs to all of the clients prior to the commencement of battle, it can simply assemble units using pre-existing cube data on the clients. In other words, the game never deals with a "unit design" at all. It only needs to know the cube configuration, which I'm hoping can be done in real-time with thousands of unit designs. I have thought about using other shapes in addition to the cube and I think it's a good idea, but for purposes of discussion I'm just talking about cubes. quote: Original post by jdi "In most cases, bandwidth would be lower than sending a group of cubes over, especially if you're storing extended information about the cubes - storing information for curving each face could be somewhat expensive, depending on how you do it." Well how about something like this: Cube 99 Hit Points: 50 Side 1: Attaches to Cube 98, no rendering Side 2: Load texture "Metal 1" Side 3: Load texture "Metal 1", Morph: 45% "Bulge" Side 4: Attaches to Cube 87, no rendering Side 6: Load texture "Red Paint", Morph: 10% "Curve" This isn't in code, it's just for an example. The server doesn't send any extensive information on the cube or any information on how to morph, it only tells the client which morphing function to run, just like a texture. In this case, the client is to run the "Bulge" morph on side 3 of the cube, bulging 45% of maximum, with the maximum determined by the "Bulge" function. Same story with the "Curve". The client would have all of these morphing functions stored along with the textures. I'm thinking that a new object need not be identified as an object at all. Each object might simply have one cube that's used as a locator, and include a line identifying it's location in the game world. The other cubes that make up that object would be attached to that locator cube, so they don't need any location information other than what cube they're attached to. [edited by - Trifler on August 25, 2003 2:06:48 PM]

Efficiently representing massive scenes and characters does have a space in MMORPG systems, at least in the way you describe it. I don''t think cubes are the answer, though, as they don''t lend themselves to complex representations (at the limit you end up with polygonal systems like we have today).

SGDL (http://www.sgdl-sys.com) is a company developping such efficient representations. Maybe you could get a demo license from them for your project?

-cb

I added more information to my original post from another thread of the same name.

You''re aiming for a parametric representation. That is a system in which set of functions manipulate a set of primitives ( be they spheres, cubes, etc.) to arrive at the final object form. High end 3D programs support objects called constructive soild geometric objects which are described by a set of equations. Using a series of bollean operations and linear transformations, one can construct a variety of forms from these CSGs.

I believe this is how the MMORPG game Second Life handles their objects as well.

If the goal is to reduce the amount of data sent, using CSGs would do it, however they have their limitations. Also the amount of 3D model data vs the amount of texture data sent is disportinately tilted toward the texture side.

Investing the time on making a powerful prodecural texture scheme will yeild more bang for your buck. There are some 5k demos which use this technique to store over a megabyte of texture procedurally, so there is alot of potential in the scheme.

Good Luck.

-ddn