- Tech Support Hotline
-
- Posts: 815
- Joined: 03-April 10
- Gender:Male
- Location:Mar Del Plata
- Project:SonicGLvl
Heyo, I've been putting some research towards cracking the terrain stuff so I can try some custom geometry imports. While I have one more format left to crack and a few quirks left to figure out, I have a question about how you, the end users, would like to be able to export their own terrain into my editor, and into the game itself.
First some technical background on the situation:
So reading the above, you should know "Terrain Groups" say which meshes are supposed to be loaded in a certain range. There's enough evidence to support this on the files I've researched, since a good bunch of them are mostly definitions of bounding spheres that match exactly to the mesh, so the game knows whether to load it when in range or not. For example, in Arid Sands...
While meshes might have their spheres on their own, terrain groups are bigger than that. They cover big chunks of the terrain, and have a list of the sub-meshes that are in its range. For example, a terrain group could have the floor, a pillar, a tree, a rock in its content. When Sonic gets near the chunk, the whole terrain group gets loaded at once.
The good thing about terrain groups is that they don't have any range limits. They can be as big as you want to cover the entire stage, if you'd like to have a chunk of terrain constantly loaded and viewable. What I come to ask though is, how would you people like to manage these terrain groups?
Since I said the model format is going to be the Ogre meshes, that leaves out of the question any 3d editor specific features like groups and stuff that can't be exported. (That won't prevent you from writing your own scripts to fit the naming conventions I will explain in a bit). My plan is for the editor to be able to auto-generate these terrain groups on its own by using a configurable grid on the Y plane, but still allowing the user to force the terrain group the mesh belongs to by appending a tag to it.
Let's say I have this stage in my 3D editor. Instead of bothering to do all that terrain group fancy stuff in my own, I would let the editor do it on its own when importing the Ogre Scene. It would look like this:
As you can see, the amount of Terrain groups would be reduced to the bare-bones it needs. Any terrain geometry in the range of each block would get lumped into the nearest group, and the names would be auto-generated. The plan is, if the user wanted an specific mesh to be part of Terrain Group #5(for example, for unloading far away geometry when Sonic reaches the place), it would have to append to the name INSIDE the 3D editor before exporting, something like @tg-0005. Or probably something similar to that. Keep in mind the terrain groups wouldn't be restricted to the grid at all. The grid is just a guidance for my editor to auto-generate the groups.
Do you think this method would be fine for all of you? Most of the stuff would be done in the background automatically. Unless someone has a better suggestion I'll probably go with it.
First some technical background on the situation:
- The format that I will likely end up reading is the Ogre mesh and material format. The reasons are simple. Ogre supports human-readable and edittable material scripts, and the plugins for exporting a mesh(and even entire scenes) is already available for several popular 3D editors(you can check it on the wiki page)
- Since there is support for scenes, you won't have to do any specific tasks to support instancing of geometry(e.g., rocks, flowers, etc.) the same way the game does.
- Generations handles terrain loading in the so-called "Terrain Groups". The terrain groups define which instances of geometry to load as groups. The game uses the internal IDs of this groups to specify whether to load it or unload it when Sonic goes past certain points(or the so called, triggers). It's not necessary to bother with this since the game can stream geometry around it on its own, but it's better for geometry-heavy stages if you want good performance.
So reading the above, you should know "Terrain Groups" say which meshes are supposed to be loaded in a certain range. There's enough evidence to support this on the files I've researched, since a good bunch of them are mostly definitions of bounding spheres that match exactly to the mesh, so the game knows whether to load it when in range or not. For example, in Arid Sands...
While meshes might have their spheres on their own, terrain groups are bigger than that. They cover big chunks of the terrain, and have a list of the sub-meshes that are in its range. For example, a terrain group could have the floor, a pillar, a tree, a rock in its content. When Sonic gets near the chunk, the whole terrain group gets loaded at once.
The good thing about terrain groups is that they don't have any range limits. They can be as big as you want to cover the entire stage, if you'd like to have a chunk of terrain constantly loaded and viewable. What I come to ask though is, how would you people like to manage these terrain groups?
Since I said the model format is going to be the Ogre meshes, that leaves out of the question any 3d editor specific features like groups and stuff that can't be exported. (That won't prevent you from writing your own scripts to fit the naming conventions I will explain in a bit). My plan is for the editor to be able to auto-generate these terrain groups on its own by using a configurable grid on the Y plane, but still allowing the user to force the terrain group the mesh belongs to by appending a tag to it.
Let's say I have this stage in my 3D editor. Instead of bothering to do all that terrain group fancy stuff in my own, I would let the editor do it on its own when importing the Ogre Scene. It would look like this:
As you can see, the amount of Terrain groups would be reduced to the bare-bones it needs. Any terrain geometry in the range of each block would get lumped into the nearest group, and the names would be auto-generated. The plan is, if the user wanted an specific mesh to be part of Terrain Group #5(for example, for unloading far away geometry when Sonic reaches the place), it would have to append to the name INSIDE the 3D editor before exporting, something like @tg-0005. Or probably something similar to that. Keep in mind the terrain groups wouldn't be restricted to the grid at all. The grid is just a guidance for my editor to auto-generate the groups.
Do you think this method would be fine for all of you? Most of the stuff would be done in the background automatically. Unless someone has a better suggestion I'll probably go with it.
But yeah, let's not think too much about ports... importing custom geometry means only the sky is the limit from there.
