Saving into file to do deterministic procedural generating

Just throwing an idea.

I'm thinking about implementing a feature which allows extra large levels, but to do so, I can't store geometry, so I'm planning to use ogre-procedural as some sort of compression method.

Compression is not a good term, but I guess the result would save a lot of disk memory and maybe allow to stream levels across an internet connection as the player walk through it.

Ogre-Procedural works like this: first you create a 2D shape with an inside and an outside, then you extrude it along a path, would it be a line, a catmullrom spline, or with a lathe, or any other thing the lib allows to do.

I guess the file format would look like this:

1. Sub-object: a sub-object is just a multishape with a path, it also contains many enums and booleans to configure it.[/*:m]
   
2. Object: an Object is just a finished mesh resulting of adding several subobject.[/*:m]
   
3. Aggregate: an aggregate is a collection of objects stuck with each other. For example, I could create a town of 50 buildings with 5 different type of buildings, and still greatly reduce the amount of batches drawn. [/*:m][/list:u]
   
   I guess An aggregate would be a single Trianglebuffer, if not instancing could be used to spawn single objects.
   
   I guess all this is easy, what could be greatly useful but harder to make is an editor that would save those into small .procedural.bin files or something similar.
   
   What is the best way to reduce the amount of batches ? Using a single addToTriangleBuffer will make the mesh bigger, and I don't really know how instancing really works...

Hi,
A file format to define procedurally generated stuff is definitely in the plans.
And an editor, too
In fact, I've been thinking about it since the very beginning of OgreProcedural...
I'm working on it these days, and currently stuck on a point of detail, but I hope to release it some day

And about instancing, there are a lot of resources about it in the Ogre forums, surely it should be used wherever it's relevant...

I'm working on it these days, and currently stuck on a point of detail, but I hope to release it some day :)


Which point of detail ?

Also making a 3D editor interface is not really a cake walk.

I started a very small embryo of an editor.

Which point of detail ?
Mostly a problem about genericity : I'm trying to create a generic 'operator' interface for each mesh/texture generator.
In that sense, mesh linear transforms (translation, rotation..) should not be in every mesh generator, but into its own operator.
But doing that makes the programmatic interface less elegant, and breaks some existing code...
Also making a 3D editor interface is not really a cake walk.
I was thinking a first version would simply be a text editor with live script reload, a bit like what I did with ScriptInterpreter.

But doing that makes the programmatic interface less elegant, and breaks some existing code...

Well you can't always make everything elegant. Do it when you can, but don't get stuck when you can't :)