re: Geometry factory

[bitplane]

We have lots of cool algorithms which create IMesh instances. In the engine we have cubes, spheres, skyboxes, skydomes, hillplanes, terrains, cylinders, cones, arrows and volume lights.

Currently there's no extensible way to add new creators, so they aren't serializable and there's no standard way to cache them.

As hybrid said earlier, it would be cool to support geometry factories. We could rename CGeometryCreator to CStandardGeometryFactory and have it inherit IGeometryFactory as well as IGeometryCreator, then add some new methods to the scene manager:

Code: Select all

IMesh* createGeometry(const stringc &type, IAttributes *params);
u32 registerGeometryFactory(const IGeometryFactory* factory);
IGeometryFactory* getGeometryFactory(u32 index) const;
void unregisterGeometryFactory(u32 index);

Okay, here's the bit which people may not like: we abuse mesh loaders and file archives to make them both serializable and actual files, using only the file name and mesh writers.

When the scene manager creates a piece of geometry using one of the factories, it also sets its name to something like: "geom:meshType/parameters.irrMesh"

Firstly, this acts as the name of and path to the file, which allows geometry creator meshes to exist in the mesh cache. The first part of the file name "geom:" is used to invoke the geometry file archive, which uses the geometry creators and the ".irrMesh" writer to create real file for reading!

We also add a "geom:" mesh loader, which is processed before all others and creates the meshes using the geometry creator.

The solution means that we have cacheable, serializable meshes which exist as virtual files in any format supported by the mesh writers!

[Dorth]

Great idea, especially using the ':' character in the path, it avoids conflicts

[DtD]

Sounds good to me! It might also be a good idea to make a irr::scene::ISceneManager::addGeometrySceneNode like there is with addCubeSceneNode.

[d3jake]

This sounds great, but what purposes can you use this factory for? I've seen the "Factory" classes in Irrlicht's API, but I'm not sure what exactly they do.

[hybrid]

They provide means for proper deserialization of e.g. scene files. That way, you can also serialize and deserialize custom scene nodes, e.g. for use in irrEdit.

[bitplane]

Hybrid, does my filesystem hack idea make sense and do you support it? Seems like a relatively simple thing to ease me back into Irrlicht development gently, something I could do over the next few evenings.

The idea is that the archive plugin would claim a geom: file exists, but the mesh loader would not try to open the file. Also, maybe we could call it "generate:" instead so that it could work for textures and materials in future.

[hybrid]

The idea sounds nice, but I'm not sure about other implications with file handling, etc. But it's probably easiest to check with the real implementation once you're done I'll think about it in the next days, let's see who comes further