Hello there
I searched around a bit for this, but couldnt find an Answer yet - I’m extending the AbstractHeightMap class with my own. Generating my own HeightMap works whitout problems. But, I need a Solution for a single Issue: Holes on the ground.
For example: I need to convert every 0 height point, into ‘nothing’ - for the texturemapping and the collision calculation. Is that even possible? If so, how could I solve that?
Thanks already for the help!
Regards, Ruby
There is no way yet to do that with TerrainQuad. At least the holes for collision. To have it not render there, just make sure the alpha maps have nothing painted there for any of the texture layers and it will be see-through.
@Sploreg said:
There is no way yet to do that with TerrainQuad. At least the holes for collision. To have it not render there, just make sure the alpha maps have nothing painted there for any of the texture layers and it will be see-through.
Thanks for the Info! Yeah, you're right - the TerrainQuad cant do that yet. But now I'm in the process of rewriting the Terrain classes, for this - takes a bit of time tough, since I have to go over about a dozen classes and Interfaces. But if I should be able to do it, I'll post the results here again.
Sure if you end up with something that works quite well we would love the contribution.
The main area of difficulty, and why terrain doesn’t support holes yet, is level of detail. The LOD routines modify the index buffer of the terrain so it can change LODs quickly without swapping out the whole geometry. The algorithms to recalculate the LOD but handle holes would have to change entirely, and across tile it could get quite difficult. It also uses triangle strips to save a little on memory, but that makes it difficult to have holes. One change that would make it easier would be to use triangles instead of strips as the underlying geometry.
@Sploreg said:
Sure if you end up with something that works quite well we would love the contribution.
The main area of difficulty, and why terrain doesn't support holes yet, is level of detail. The LOD routines modify the index buffer of the terrain so it can change LODs quickly without swapping out the whole geometry. The algorithms to recalculate the LOD but handle holes would have to change entirely, and across tile it could get quite difficult. It also uses triangle strips to save a little on memory, but that makes it difficult to have holes. One change that would make it easier would be to use triangles instead of strips as the underlying geometry.
Yeah, that's actually one thing I cant really do, since I'm not all too versed with all those algorithms. What I'm trying to do right now (with some success) is manipulating the buffers used as the GeoMap class creates the final Mesh. I already managed to create 'holes' in the Mesh, by ignoring y=0 values (took me a bit, since every manipulation of the buffers caused mostly strange and unexpected results). But I fear, that performance wise, it wont be any better than the full Mesh (but not worse either).
About the whole LOD thing, and such, I'll have to look into that and try to find a way around it then. My current result, is that the Landscape works with holes now, on every distance. But I'm not sure if I've activated the LOD anyway. Interestingly enough, the class I'm manipulating tough, is the Geomap used by LODGeomap - so maybe I already fixed that part.
The problem is, I'm still having difficutles to understand every part of it - I started to use JME about one or two weeks ago, and before that I never worked on such complex algorythms / Meshes at all. So I'm maybe a bit too unexperienced to find a good solution.
Edit: my next step, is to implement something physic-based, to test if it really works with those holes (or if they maybe cause some problems). Since I didnt implement anything physics based after the tutorials, I'll need a bit I think ;)
Well, little update. Basically, now it works. I can build heightmaps with holes in them, whitout having any problems. But I’m sadly not sure, if the LOD still works (I basically had to overwrite that whole part).
And it’s rather ugly, and result-oriented sadly. So I guess, the solution I found probably only really works as a temporary fix until something better comes out.
Glad you got it working. Yea I have been down this road too, it is not an easy one. Another difficulty is physics. Jme uses a heightfield for the terrain collision which is significantly faster than regular mesh collision. But with holes Bullet cannot use a heightfield, so you have to revert to using the much slower mesh collision.
@Sploreg said:
Glad you got it working. Yea I have been down this road too, it is not an easy one. Another difficulty is physics. Jme uses a heightfield for the terrain collision which is significantly faster than regular mesh collision. But with holes Bullet cannot use a heightfield, so you have to revert to using the much slower mesh collision.
That's one of the problems I'm strangely having now - even if the mesh seems 'correct', the physics dont seem to work correctly. I have this strange behaviours:
When I have a small hole, it seems that a couple of points 'under' the hole, there is an invisible wall - but the sides seem open. So nothing can fall straight trough.
I tried to let 1000 'balls' drop on such a form, and half of it, falls trough the middle of the heightmap (where no hole is) - the other half, stays on the heightmap. Is that a known Issue? Am I maybe doing something wrong? ( did it like here: https://wiki.jmonkeyengine.org/legacy/doku.php/jme3:beginner:hello_physics )
I mean, the heightmap at the end is just another Mesh anyway, right? So it should just act as one. And I should be able to 'see' this invisible walls, if there are any, but I dont see anything (from every perspective) so how can they be there?
EDIT: tested it with standard heightmap, whitout my code - balls still fall trough - so this is a common bug, then?
The height map terrain collision shape will always be that, a height map. No matter what you do to make the terrain look like its got holes, you will have to specify these points for the collision shape in a way that you get the desired behavior. You could resort to using mesh collision shapes but height maps perform much better.
@normen said:
The height map terrain collision shape will always be that, a height map. No matter what you do to make the terrain look like its got holes, you will have to specify these points for the collision shape in a way that you get the desired behavior. You could resort to using mesh collision shapes but height maps perform much better.
Yes, sorry - I explained myself wrongly. What I mean, is the Mesh resulting out of the heightmap - so, the finall result in form of a Mesh, seems to have bugs when many objects (like balls I use to test it) falls 'on' it - half of it, falls trough - is this a common problem? Is there a solution?
Yeah, thats common, theres ccd for that. If the balls move so fast that they completely move past the obstacle in one frame (60fps) it will just go through the wall. Look at the javadoc of setCcdThreshold()
The collision heightfield does not support holes, so it will collide with physics objects all across its surface. I wouldn’t doubt that the generated heightfield is broken with your data since it expects a square, fully filled-in, array of height values. If there are missing values, then the resulting heightfield collision shape could be undesirable or a bit unpredictable.
You will have to take your terrain mesh and generate the physics shape from that, not using the existing terrain collision shape generation (which expects a valid heightfield)
@normen said:
The height map terrain collision shape will always be that, a height map. No matter what you do to make the terrain look like its got holes, you will have to specify these points for the collision shape in a way that you get the desired behavior. You could resort to using mesh collision shapes but height maps perform much better.
Is it not possible to make exceptions in the collision shape? Like "If player is between (x1,y1) and (x2,y2), then ignore collisions".
Also, congratulations on 1000 imaginary internet points :D
@WASD said:
Is it not possible to make exceptions in the collision shape? Like "If player is between (x1,y1) and (x2,y2), then ignore collisions".
Also, congratulations on 1000 imaginary internet points :D
Sure that would definitely be an option.
@Sploreg said:
The collision heightfield does not support holes, so it will collide with physics objects all across its surface. I wouldn't doubt that the generated heightfield is broken with your data since it expects a square, fully filled-in, array of height values. If there are missing values, then the resulting heightfield collision shape could be undesirable or a bit unpredictable.
You will have to take your terrain mesh and generate the physics shape from that, not using the existing terrain collision shape generation (which expects a valid heightfield)
Well, if that's the case, the next step should be easy now then. I tought my Mesh was corrupted because of the balls falling trough, but it seems to be common. So now, I just will take out the mesh instead of the heightmap itself. But even for the heightmap itself, there is a workaround (in my case, it'll work: lowering the 'invisible' ground.
If you do that in a normal heightmap, (y = -100 for example) there still is a wall at every 'side' of that hole. But I apparently dont have this walls now, so it has the same effect and works like an actual hole. I'm playing around with it a bit more, maybe I find a better solution. But it works now, with physics included.