Using separate objects for each terrain quad?

[AW999]

Is there any disadvantage to using separate Object3D objects for each quad in the terrain rather than using a single object with a large number of quads?  I.e., would it use a significantly greater amount of memory or take longer to generate the terrain, or some other disadvantage?

[.jayderyu]

Well I've done a lot of reading about terrain. Your better off using extra objects, but it also depends on the detail of the terrain.

In the Terrain demo. It's a single mesh model with limited depth. However there are samples out there that produce the same type of terrain as the demo, but then adds additional layers of height and density as you get closer. In these cases your better off splitting them up and swapping the hiegher details models for lesser ones in the distance. In the case where i'm working on a 512x512 height map with no further details. Well I suggest using the various in api methods to split into octree(if not already done) and go with that.

For example
http://www.youtube.com/watch?v=F-4OeWL1sCw&feature=related
is from Inifinity: The Quest for Earth

Terrain demo is nice, but there is no way a single mesh design without breaking it into zones could handle a the demo in the video.

So determine what you need and go with it. Small terrains don't need it, BIG ones will.

[AW999]

I guess I should have explained my question more clearly. If I need X number of quads in the terrain mesh, what is the difference (in terms of memory usage, speed, etc) between a) having a single object with X quads, versus b) X number of objects, each consisting of one quad?

A related question: I'm hoping to produce smooth variation from one quad to the next by either: a) giving each quad a single color which varies only slightly from neighboring quads (e.g., a smooth progression from green to tan), or b) better yet, tinted textures which use a combination of a texture with an overlaid color, where the color would vary slightly from one quad to the next as in option A.
From what I can gather from the manual, option B can only be done by using setAdditionalColor to 'tint' an entire object (in which case each quad would have to be a separate object), and option A could be done by generating a 1x1 texture from a color using AddTexture(width,height,color). Correct?

[EgonOlsen]

With quad, you mean a real quad consisting of two polygons? If yes, then this will be the absolute killer for performance...don't do this. Try to create chunks of geometry as large as possible to try to minimize state changes, i.e. use one set of textures on as many polygons as possible. If you want to use different colored textures for each quad for whatever reason, merge them into one larger texture instead.

[AW999]

With quad, you mean a real quad consisting of two polygons? If yes, then this will be the absolute killer for performance...don't do this. Try to create chunks of geometry as large as possible to try to minimize state changes, i.e. use one set of textures on as many polygons as possible. If you want to use different colored textures for each quad for whatever reason, merge them into one larger texture instead.

  Yes, I meant a quad consisting of two triangles.  I need to generate terrain which has both a realistic degree of variety and also smooth transitions. I've been adapting my procedural terrain algorithm (which I had previously been using for a voxel-based program), in which you just have a plain grid with an elevation and a unique color for each voxel, hence smooth transitions from one voxel to the next. I thought I could just treat each grid point as a quad (or a vertex on a quad) and then add 3D plants, trees, etc, as needed.  But this requires varying the color slightly from one quad to the next. 
So you're saying it's actually better for performance to use Terrain Demo's method of having two meshes and blending them, thereby duplicating each quad?   If so, how do I blend more than three textures, or tint them to produce smooth transitions?
 

[EgonOlsen]

If varying the colors is the only issue, just create a texture containing all 256 levels from black to white as small 2x2 quad and assign them to your polygons using a second texture layer with color modulation and u/v coordinates located in the middle of each 2x2 quad. That should allow you to use different shades per quad while still using one texture. I think it will still look tiled though...
Using the approach in the terrain demo, you can blend as many textures as you like as long as you blend them with the ground texture only. The fact that the demo uses this effect for different height levels only is no limitation of the principle but is caused by the fact that i'm creating the mapping programmatically in a pretty simple way.
Another option mentioned in the terrain demo thread is the use of shaders, but i haven't tried this yet.

[AW999]

If varying the colors is the only issue, just create a texture containing all 256 levels from black to white as small 2x2 quad and assign them to your polygons using a second texture layer with color modulation and u/v coordinates located in the middle of each 2x2 quad. That should allow you to use different shades per quad while still using one texture. I think it will still look tiled though

  I assume, then, that there won't be a performance drop so long as all the quads use (a portion of) a single texture graphic, even if they each use different parts of that texture by setting the UV coordinates to a different part of the texture?  Hence each quad could effectively have a different texture, so long as all the texture 'tiles' are in the same big graphic?  Or am I misunderstanding?  In your previous note you had said that performance drops with 'state changes' from one poly to the next, but I'm not sure what you meant by 'state changes'.

[EgonOlsen]

Yes, you got that right. A state change is for example a change of the texture or the blending mode,...if you compile() an object in jPCT, the object compiler reorganizes the object internally to minimize state changes, but it can't avoid it unless the object is pretty simple. So it's your task to provide objects that don't require much state changes...like storing your colored textures in one big one. State changes are very expensive, it's mandatory to minimize them to get good performance.