Sorry your browser is not supported!

OK I just tried this but I get an error when I try to create the mesh from my terrain object. This is where we see the limitations of DGSDK. I think most can agree the limitation right now is in the docs and samples area. We have a terrain and now in order to get a model to function on the terrain there has to be some way of doing collision. Well I was going to use a 3rd party physics engine, so I needed the mesh data of the terrain. I tried to get it using dbMakeMeshFromObject after I build the terrain and it throws an error. How is this supposed to work? Is there built in collision code we are supposed to use with the terrain engine, if so how? If not, how do we get the mesh information in order to use a 3rd party physics engine? Bascially if the SDK already has its on collision library for the terrain (like putting a vehicle on it) that would be great, to bad I can't find it in the docs.

As usual looking for any help on this one. TIA. I have attached the code so everyone can see. The call stack traces it back to CreateSingleMeshFromObject() and its a memcpy command. This is where error codes would help (I know I've said it before) no need in doing this command if its not able to generate the required mesh or what not. Actually I don't know what the problem is because lack of error codes and/or exceptions.

I posted this in another thread as well. DBP has this bug so I assume Dark Game SDK does as well.

If the terrain is over 21844 polys you will want to use something like this as DBP's make mesh from object command is bugged and DBP will crash over this number of polys:
`do this for every limb of the terrain
make object from limb
convert object fvf to 2 `this will get rid of all unneeded data but the vertex positions
make mesh from object
delete object made from limb
make memblock from mesh
delete mesh
`now you can access the vertex data needed for collision/physics
`The first dword is it's format. The second DWORD is it's number of verts, the third DWORD is the size of each vertex in bytes, and the from position 12 until the last position of the memblock will follow this pattern:
memblock float #,12 = vert x pos
memblock float #,16 = vert y pos
memblock float #,20 = vert z pos
memblock float #,24 = vert x pos
memblock float #,28 = vert y pos
memblock float #,32 = vert z pos
over and over until the last position in the memblock.

Lost in thought I got that one, but I was hoping someone can clarify the terrain collision or explain terrain more in detail, as there is hardly any coverage on it in the SDK instructions. You're post is what got me far, but there should be more explanation about terrains, collision with respect to terrain, and/or extracting vertex information.

I mean what good is terrain code if it only just puts a "pretty" picture on our screen? And if the advanced terrain code is that limited I would just as rather create a mesh and just load it myself. If the terrain is not using ROAM or some other "wow" feature why use it in the first place if its so limited? Does it support Octree or PVS? If not, I'm just going to create a giant mesh for the terrain and use that.