Serializable, pluggable mesh generators. How?

[bitplane]

Currently there's no way to serialize custom geometry, for example hill planes, cubes, arrow meshes and anything else made by the geometry creators don't work with loadScene, saveScene or getMesh

Does anyone have any design suggestions about this? I was thinking that the most simple solution would be to abuse the file name, for example names that start with "geom:" are picked up by a geometry loader, the rest of the file name is an encoded IAttributes set which gets passed to the geometry creator.

Anyone have any ideas?

[pc0de]

I think you're asking for a way to generically serialize all current and future custom geometries without having to create scene node types for every geometry type. Thinking out loud...

Volume Lights currently use the geometry creator to generate its mesh and with recent changes it is now able to be serialized. But, it is currently able to do this because it has it's own scene node type (ESNT_VOLUME_LIGHT) and ISceneNode derivative.

If a new generic IGeometrySceneNode type is introduced, it may be programmatically generated via:

Code: Select all

IAttributes* attr;
attr->setAttribute("Type", "volumelight");
attr->setAttribute("SubDivideU", 100);
attr->setAttribute("SubDivideV", 100);
//... other volumelight/geometry attributes

IGeometrySceneNode* n = smgr->addGeometrySceneNode(parent, attr);

addGeometrySceneNode() could call into a CGeometryCreator method that contains the necessary code to parse the type and appropriate type based parameters required for generating the correct mesh. If that was acceptable, then I think everything else would be in place for de/serialization.

Adding new geometry would mean updating the CGeometryCreator mesh generating method called by both ISceneManager::addGeometrySceneNode() and IGeometrySceneNode::deserialize().

[bitplane]

That's a good idea, I like it. Less hacky than encoding the attributes directly into the file name, we'd still need another interface for geometry creators if they were to be pluggable, but it seems clean.

One thing it wouldn't work with is if we create a mesh, then a copy, convert it to tangents, add it as a mesh node and then save the scene. The filename approach would retain the full stack of manipulations which could be unwound when deserialized (getMesh -> mesh manipulator -> getMesh -> mesh manipulator -> getMesh -> geometry creator). This may or may not be desirable though, depending on your point of view.

[3DModelerMan]

What if the geometry scene node contained that data in it's attributes?

[pc0de]

One thing it wouldn't work with...

Indeed it wouldn't.

I guess simple manipulations that weren't order dependent could be handled with additional attributes like 3DModelerlMan suggests. But, I'm not sure if unwinding a result mesh back to geometry would be desirable because I can't get my head around on why I would want to do that.

[fmx]

Why would you want to keep a history of mesh manipulations?
Mostly the operations would be applied and the programmer would never dream of undoing it.
IMO it seems like it would be redundant memory usage in most cases

[bitplane]

Yes, you're right. I think pc0de's idea is the way forward.

I was thinking you'd want a history of manipulations, if, for example you loaded a mesh, made it a tangent mesh, loaded a texture, converted it to a normal map, added it as a node and then saved the scene. Upon loading the scene you'd get an S3DVertex mesh with a heightmap as the second texture layer.

But yeah, editors should take care of this sort of thing.