Jvo Could you tell me more about your custom dae to cgr importer? My problem is if i use a bigger patch (32x32) then dae vertexs position would need some extra calculation itself. For a 2 triangle its simple. But once it gets big i get lost.Also some faces must be remove and tessellation should change in different areas (performance reason). So the logic system for putting all of those faces as a single uniform mesh could be very complex. My issue is mainly with this section which i think is doing the welding for triangles. Perhaps it's just an index id of the shared vertex's.

Code:

source="#Quad-UV0"/><p> 0 0 1 1 2 2 2 2 1 1 3 3</p></triangles>

Well, they are indeed indices. But it's part of a bigger whole. I just exported a simple box with normals and mapping coordinates. First you get three float_array elements with the positions, normals and mapping coordinates grouped in sets of 3, 3 and 2. Here is part of the position array:

Code:

<float_array id="geom-Box001-positions-array" count="24">-9.624062 -10.42627 0 9.624062 -10.42627 0 -9.624062 10.42627 0 9.624062...

The first xyz position with index 0 is -9.624062, -10.42627, 0.

Then you get the triangle indices. Each triangle of course consists of the three vertices. Each vertex has three indices. One into the position array, one into the normal array and one into the mapping coordinate array. Here is part of the triangle indices:

Code:

<triangles material="ColorMaterial" count="12">
          <input semantic="VERTEX" source="#geom-Box001-vertices" offset="0"/>
          <input semantic="NORMAL" source="#geom-Box001-normals" offset="1"/>
          <input semantic="TEXCOORD" source="#geom-Box001-map1" offset="2" set="0"/>
          <p>0 0 9 2 1 11 3 2 10 3 2 10 1 3 8 0 0 9...
        </triangles>

The first triangle is indexed as 0 0 9 2 1 11 3 2 10. The first vertex of the first triangle is indexed as 0 0 9.

It has position index 0, normal index 0 and mapping coordinate index 9.

This is an actual example of course. Since you are the one to generate the file, you can be a bit more logical than 0, 0, 9.

Thanks. That was my issue about those indices which you solved  . Since i don't need normal and uv for now i guess i only need to take care of  indices #3 (position). So my next question, is there any relation between position indices or i just must put a unique number for each one of them? If there is no relation then it would be easy.

Well, the relation is pretty strict. Each index tells which position should be assigned to each vertex. So lets say I have a simple quad consisting of two triangles:

Code:

0,1  1,1
-----
|  /|
| / |
|/  |
-----
0,0  1,0

The x and y coordinates are noted in the diagram and lets say the value of Z is 3 in all cases.

Then I have 4 positions:

Code:

<float_array id="geom-Box001-positions-array" count="12">0 0 3 0 1 3 1 0 3 1 1 3</float_array>

My first triangle consists of vertex 0, 1 and 3 and my second triangle consists of vertex 0, 3 and 2. So:

Code:

<triangles material="ColorMaterial" count="2">
          <input semantic="VERTEX" source="#geom-Box001-vertices" offset="0"/>
          <p>0 1 3 0 3 2</p>
</triangles>

I see. So there is a relation and that make things very difficult. I need a multires tessellation, discard, Detach, but as i can see it's not easy. A full complex logic system is needed for that. Do you have any suggestion?

True, that would require some fairly complex logic. Maybe it would help to just work with fixed size patches. By combining a fixed number of patch layouts, you might be able to generate any grid you want.

Yes. I guess that's the only way for now. It should be fun to build such a system, but my time is limit. Again thanks a lot for all the info. 

Interesting solution!  You could also consider using the height map channel ( http://quest3d.com/forum/index.php?topic=64398.0 ), just needs recompiling for 5.0 I guess.  We use it to generate terrain collision in one of our apps, although on a smaller scale.  The custom geometry channel could also be useful?

Yes i saw those before. But despite the fact that they are not compiled for 5.0, i need a very custom collision mesh (For optimization reason) So that displacement channels could not help that much, but custom geometry channel could help alot, if someone could compile it for 5. with custom geometry channel the whole dae, xml conversion will dissmiss, which is the main performance killer. I am working on a combination of 16x16 with 1x1 unit. It should do the job.

This time with 32x32 patch and generation speed is much more faster.

Terrain test with World Machine. Very powerful app.

Terrain color.
Btw, Terrain in Battle field 3. http://dice.se/wp-content/uploads/GDC12_Terrain_in_Battlefield3.pdf

Refraction leaking mask.

Looks great 

BTW just used XML in a project we are working on for the settings file - wish I knew about it a long time ago!  Thanks for the tip!

Thanks. yes xml is very helpful and its only one of the ways to save stuff, but for the GUI it's perfect.