Rick

But that's what we are trying to do with getting the terrain height at a given point on the terrain. I think the issue is a given point on the terrain is retrieved from an interpolation calculation by the near vertices, which won't make it always exact, which is what I thin whisper is seeing. So whisper, I wouldn't say it's a bug by any means, I'd say there doesn't seem to be a way to get the exact point height for any possible point on the terrain using those terrain functions. This is why I still think a raycast would produce more accurate results than this method. The raycast should give the exact x, Y, & z point of collision on the terrain. Or at least a constant value could be used to add or substract the y value to get the exact point on the terrain, instead of having the terrain method interpolate a point.

Really? I assumed the plane would have to be raised from the terrain somewhat. If it was the exact position wouldn't you get z fighting (or whatever it's called) since 2 things are on the same plane?

Ah, you load a model in instead of creating it in code. I think my issue I'm having is the creation of the plane. I understand the issue you are seeing. I was just curious if adding 0.02 or 0.03 instead of 0.01 would solve the issue for those troubled spots and if it does, would it make a difference for the spots that worked already. 0.02 or 0.03 is such a small difference that if it worked for the troubled spots and yet still looked ok for the spots that didn't have troubles then the problem would be solved. For some of those troubled spots there might be rounding errors or something going on, so maybe try a value higher than 0.01 to see what seems to make it work for the troubled spots.

Do you know how far off it is? You could just start adding 0.01 until you see it show up on top of the terrain. I wonder because maybe if you add 0.02 or 0.03 if it would work and if it does then I assume you could just use that value to add. If the value is small enough I doubt it would be noticeable and would still look like it's morphing to the terrain. BTW wh1sp3r, how did you do yours? I assume you used C++ so mind sharing your code? If you did it the same way klepto did it might help me see what I went wrong with my C++ version.

So I'm getting an access violation on UpdateMesh(). The mesh is a valid pointer so now sure what I'm missing. I've went over what klepto posted and it looks like I converted it correctly from what I can tell. The only difference I see is he has mesh.AddSurface() where I have CreateSurface(mesh,...) because I couldn't find the AddSurface() method. #include "TerrainPlane.h" TerrainPlane::TerrainPlane(TTerrain terrain, TEntity parent, float scale) { _terrain = terrain; _plane = CreatePatch(32, 32, parent); ScaleMesh(_plane, Vec3(scale, 1.0, scale)); MoveEntity(_plane, Vec3(scale / 2.0, 0.0, -scale / 2.0)); } TerrainPlane::~TerrainPlane(void) { } TMesh TerrainPlane::CreatePatch(int xsegs, int zsegs, TEntity parent) { TMesh mesh; int x, z, count; TSurface surf; mesh = CreateMesh(parent); surf = CreateSurface(mesh); for(z = 0; z < zsegs; z++) { for(x = 0; x < xsegs; x++) { count = AddVertex(surf, Vec3((float)x / (float)xsegs, 0.0, (float)z / (float)zsegs), Vec3(0.0,1.0,0.0), Vec2((float)x / (float)xsegs, 1.0 - (float)z / (float)zsegs)); if(x > 0 && z > 0) { AddTriangle(surf, count - 1, count, count - xsegs - 1); AddTriangle(surf, count - 1, count - xsegs - 1, count - xsegs - 2); } } } UpdateMesh(mesh); // THIS IS GIVING ME ACCESS VIOLATION! return mesh; } void TerrainPlane::Update() { int Si, Vi; for(Si = 1; Si < CountSurfaces(_plane); Si++) { TSurface surf = GetSurface(_plane, Si); for(Vi = 0; Vi < CountVertices(surf) - 1; Vi++) { TVec3 vertex = TFormPoint(GetVertexPosition(surf, Vi), _plane, 0); TVec3 newpos = Vec3(vertex.X, TerrainElevation(_terrain, vertex.X, vertex.Z) + 0.01, vertex.Z); SetVertexPosition(surf, Vi, TFormPoint(newpos, 0, _plane)); } } }

Nevermind, I got it. Forgot the = in my <= in my for loop.

Bah, just noticed I forgot the = in my <= for loop. Got it. Thanks!

I tried classname also and that didn't work for me.

Have you tried this? Because I don't get a "Terrain".

Did you upload it to the download section? It sounds like what I would need for this also. I'm going to give klepto's solution a try quick here first if I can every figure out how to get the terrain from LoadScene

According to this http://forum.leadwerks.com/viewtopic.php?f=37&t=3677&hilit=LoadScene+terrain (for 2.24 anyway) I could look at the class key and it would say Terrain. This doesn't seem to be the case. All that is returned are "Model" values. No terrain. So is this still a bug even though Josh said it was fixed in that thread for 2.24?

klepto2, just one question on the code. You have surf=mesh.AddSurface() but I can't seem to find that in the wiki. I see a CreateSurface() and I assume that's the same thing? Is the wiki not right for Bmax on that? A search for AddSurface() didn't bring up anything, not even for BMax.

How do we get the TTerrain object after calling LoadScene()

I think it's a cool idea for people who maybe want a job at an existing game company (which doesn't even sound like much fun from all the stories you hear these days), but for the person who wants to create their own business making games probably not so much. You would want to own and control all aspects and not have to give up certain rights to the game you make for this.

Did you have this code somewhere? I guess I didn't see a link on the old forums that pointed to where this is.

Why would that be? I've had transparent textures in the same world before. I wouldn't think would be any different? Also, what does your mat file look like for the above screenshot you have?

klepto2, that is perfect! That's exactly what I want. I assume I can paint a material to the plane then that has some transparency. This is really nice of you to do this. I'll convert it over to C++ and you should public this code on the download section because I think it could be useful for others.

I'll try the TerrainElevation tonight. I should be able to figure that out. Is there some function already setup to allow me to create a terrain that will have x number of vertices to it, or do I have to create a surface and ad vertices manually and all of that? I hate doing that, it's so tedious. It would be nice to have a create plane function and tell it how many triangles I want. So I'm confused about one thing about your code. At the end after you find this information is when you say create the plane. I was thinking create the plane first and then manipulate it's vertices to match the terrain height. Since this plane would be moving along the terrain with the mouse I would think it's cheaper to create the plane once and just manipulate it's vertices than to create a plane each cycle with it's vertices at the location on the terrain height around my mouse.

I'm not really interested in getting into shader programmer at the moment. I want to focus more on the game and not learning how shader programming works right now. The terrain height way seems to be the way to do this. Since I know the point of each vertex in the plane, I can use the vertex x & z values as the terrain point and that could give me the height. My only 3 questions would be about the function. http://www.leadwerks.com/wiki/index.php?title=Terrain#TerrainHeight 1. The parameter names are x & y. I assume y is really the z value? 2. Also it returns a value between 0 and 1. How is that the height of the terrain at that location? That doesn't make sense to me because the terrain value in the world could be any size. 3. Because this interpolates points does that mean my plane could end up a different size? Does the raycast also interpolate the collision on the terrain to get the point of collision which would give the same effect of the plane being different sizes once it's placed over the terrain? That's a good point. That would make it

I'm not following what you are saying here. Why would I need 2 raycasts with short range or 1 with max range? Let's use the mouse pointer for now as an example. If I set the Y value of the plane a set distance from the Y value of the mouse position on the terrain that would basically make the plane following the mouse but be higher. Then loop through each vertex on the plane (the number of vertices the plane has would determine how precise it morphs and this could be variable), and do a raycast from that point down past the Y distance I went up and maybe add a few more units for good measure (or if there is a way to get the min terrain height value would only need to go slightly past that). Then once the collision is found with the terrain I use that Y value for that vertex in the plane. That would mean 1 raycast per vertex in the plane. These planes wouldn't be very large so I'm thinking maybe 20 some vertices would be enough to make it look good. So for each plane (there would be 11 at max) loop through 20 vertices each, which would end up being 220 raycasts each cycle. I guess I could even break that down and say if a character isn't moving then there is no need to redo that plane. Because the game is turn based only 1 unit would be moving at a time which would mean only 1 plane would need to do this each cycle, so maybe 20 raycasts when the character is moving. I've not messed to much with raycasts so I'm not sure how expensive they are, but I would assume 20 each cycle would be doable. I might be missing something, so that's why I step through how I'm thinking. If you can see where I'm missing something let me know. I also don't have to worry about huge peaks or valleys in my game.

I have an idea of how I would solve this issue and would be interested in what people think about this solution. Remember that I would require this plane to move with either characters or the mouse. It won't be static on a surface. 1. I would create a plane with x number of vertices. 2. Each cycle I would position the plane's x & z position with the values of either the mouse on the terrain or the character on the terrain. The plane would still be flat at this point. 3. I would set the plane's y vlaue to some large number making it well above the terrain. 4. Then cycle through each vertice in the plane and do a raycast down to the terrain. 5. Get the collision point of that raycast with the terrain, and use that y value to set that planes vertice y value + .01 so no fighting happens. It seems like this solution would work, but I have to wonder if the speed would be bad? This would happen with at most 11 planes at a time.

What's the general high level idea behind trying to make a plane "hug" or "blanket" the terrain? I want to make a plane that will follow my mouse around the terrain but would love for the plane to morph itself to hug the terrain under it. I guess I would assume you could take every vertex in the plane and set it's height .1 unit up from the terrain directly below it? The only issue seems to be that the CreatePlane() doesn't seem to let you decide how many vertices to have so it looks like you just have enough to make 2 triangles, which wouldn't be enough to morph around bumpy terrain.

I think the TTexture (and all the other T*) are just char*. They are sort of just like id's for the engine.

I'm guessing it means To Much F*&%ing Information

I used 2D images and DrawImage(). I don't require any sort of rotation. If you get the rotation working I would be interested in how you got it working.