Falagard
08-05-2007 14:30:19
I'm going to do a quick comparison here because I've been looking at the AdVantage Terrain Library lately.
http://www.advantageterrain.com
What I like about AdVantage terrain:
It's focused on doing one thing - loading and displaying terrain data quickly using the least amount of memory. It background loads the terrain data in a separate thread, and only takes up as much memory as it needs to display the terrain around the user - so for distant pages it only load lower detail data.
The API is simple and easy to understand. It creates an instance of TerrainQuad (or your derived version of it) when it needs to, then gives you vertex buffer and index buffer data that has been background streamed. Since this particular library has been designed to work with any rendering API, it's up to the caller to copy that data into the appropriate vertex and index buffers specific to the API (so for Ogre, it's Ogre's HardwareVertexBuffer and HardwareIndexBuffer.
It has tools that work with large sized heightmaps and textures without needing to load the entire thing into memory.
It has a nice API for requesting collision data asynchronously, so it won't even have collision data loaded until you need it.
It's free for commercial and non commercial use.
What I don't like about AdVantage terrain library:
It's closed source unless you purchase a license.
It doesn't give you direct access to the internal file format used to store data - you need to take your heightmap files and texture files and convert them to a special file format that is used by AdVantage.
What I like about the PLM2
It is open source so I can make changes to it if I desire.
It has editing features built into the library.
What I don't like about PLM2
It loads all data into memory, even for distant pages.
It's not as focused in what it wants to be. PLM2 attempted to be everything to everyone instead of just providing some simple hooks into the terrain system so users can do what they want. The PLM2 attempts to have many different splatting techniques, shadowing techniques, etc. all bulked into the main project. These should be split out into separate layers so they are completely optional.
The editing features are not robust enough to be used for actual terrain editing, or the code is too confusing to figure out how to do simple things like terrain smoothing and flattening in addition to raise and lower. The editing features should also be separated into a separate library.
The PLM2 loads data on the main thread, which causes hiccups in framerate.
There are tools (map splitter) for splitting large maps into pieces, but they need to load the entire map into memory.
There are tools (map splitter) for working on large maps only, but this doesn't help me if I already have textures that are split into pieces.
The setOption functionality is nasty as an API. There's no reason why the developer can't call on the SceneManager directly or why everything should be done through an anonymous API function like that. The developer should be able to communicate directly with the PagingLandscapeSceneManager instead of just with SceneManager, so instead of everything through setOption we should have actual functions exposed on the scene manager.
The code doesn't follow a single convention - but instead uses different naming conventions for variables and functions all over the place (a result of different developers working on the PLM2 I assume).
Collision data is loaded into memory at all times, instead of only needing to be loaded when needed.
Does PLM3 solve these issues?
PLM3 should be able to load only the data that is necessary at any particular time (I believe this is on its planned feature list).
What could be done to PLM3 to make it better?
Have the different texturing/rendering techniques as plugins instead of building them directly into the project. This way the library doesn't get bulky when we only need 1 of the 12 available texturing techniques (or whatever).
Background load data instead of loading it on the main thread. This includes both heightmap and texture data.
Add support for full terrain editing features and a sample application showing these features in use. Put the editing features in a different library possibly so they don't make PLM3 even more bulky.
Make sure the tools for splitting terrains can handle large sized maps without loading the entire thing into memory. Make sure the tools can support previously split heightmap and textures.
Fix the API so everything doesn't go through setOption.
Fix the code so it follows a single convention - naming standards for variables, etc.
Collision data should be only loaded when requested so that it doesn't need to keep all heightmap data in system memory for collision purposes.
I'm willing to help out on these tasks.
Clay
http://www.advantageterrain.com
What I like about AdVantage terrain:
It's focused on doing one thing - loading and displaying terrain data quickly using the least amount of memory. It background loads the terrain data in a separate thread, and only takes up as much memory as it needs to display the terrain around the user - so for distant pages it only load lower detail data.
The API is simple and easy to understand. It creates an instance of TerrainQuad (or your derived version of it) when it needs to, then gives you vertex buffer and index buffer data that has been background streamed. Since this particular library has been designed to work with any rendering API, it's up to the caller to copy that data into the appropriate vertex and index buffers specific to the API (so for Ogre, it's Ogre's HardwareVertexBuffer and HardwareIndexBuffer.
It has tools that work with large sized heightmaps and textures without needing to load the entire thing into memory.
It has a nice API for requesting collision data asynchronously, so it won't even have collision data loaded until you need it.
It's free for commercial and non commercial use.
What I don't like about AdVantage terrain library:
It's closed source unless you purchase a license.
It doesn't give you direct access to the internal file format used to store data - you need to take your heightmap files and texture files and convert them to a special file format that is used by AdVantage.
What I like about the PLM2
It is open source so I can make changes to it if I desire.
It has editing features built into the library.
What I don't like about PLM2
It loads all data into memory, even for distant pages.
It's not as focused in what it wants to be. PLM2 attempted to be everything to everyone instead of just providing some simple hooks into the terrain system so users can do what they want. The PLM2 attempts to have many different splatting techniques, shadowing techniques, etc. all bulked into the main project. These should be split out into separate layers so they are completely optional.
The editing features are not robust enough to be used for actual terrain editing, or the code is too confusing to figure out how to do simple things like terrain smoothing and flattening in addition to raise and lower. The editing features should also be separated into a separate library.
The PLM2 loads data on the main thread, which causes hiccups in framerate.
There are tools (map splitter) for splitting large maps into pieces, but they need to load the entire map into memory.
There are tools (map splitter) for working on large maps only, but this doesn't help me if I already have textures that are split into pieces.
The setOption functionality is nasty as an API. There's no reason why the developer can't call on the SceneManager directly or why everything should be done through an anonymous API function like that. The developer should be able to communicate directly with the PagingLandscapeSceneManager instead of just with SceneManager, so instead of everything through setOption we should have actual functions exposed on the scene manager.
The code doesn't follow a single convention - but instead uses different naming conventions for variables and functions all over the place (a result of different developers working on the PLM2 I assume).
Collision data is loaded into memory at all times, instead of only needing to be loaded when needed.
Does PLM3 solve these issues?
PLM3 should be able to load only the data that is necessary at any particular time (I believe this is on its planned feature list).
What could be done to PLM3 to make it better?
Have the different texturing/rendering techniques as plugins instead of building them directly into the project. This way the library doesn't get bulky when we only need 1 of the 12 available texturing techniques (or whatever).
Background load data instead of loading it on the main thread. This includes both heightmap and texture data.
Add support for full terrain editing features and a sample application showing these features in use. Put the editing features in a different library possibly so they don't make PLM3 even more bulky.
Make sure the tools for splitting terrains can handle large sized maps without loading the entire thing into memory. Make sure the tools can support previously split heightmap and textures.
Fix the API so everything doesn't go through setOption.
Fix the code so it follows a single convention - naming standards for variables, etc.
Collision data should be only loaded when requested so that it doesn't need to keep all heightmap data in system memory for collision purposes.
I'm willing to help out on these tasks.
Clay