I’ve been pulling my hair out since saturday (part time) on this matter and I just found out how to make it work, but I don’t understand why it does work and I’m quite certain it’s very far from optimal. Anybody can explain/help with this?
Create a TerrainQuad
Create a HeightfieldCollisionShape and apply it to the TerrainQuad
Move the TerrainQuad node some units away e.g.: +100 on X axis using: tq.getControl(RigidBodyControl.class).setPhysicsLocation()
Try to collide the player capsule or any physic object; it goes through the terrain like if there were no RigidBodyControl set at all.
WTF 1) If I getLocalTranslation() on the TerrainQuad, it returns the good values and I see it just fine at the correct location.
WTF 2) If I getControl(RigidBodyControl.class) on the TerrainQuad, it returns a non-null control.
WTF 3) If I getPhysicsLocation() it returns the good values.
WTF 4) If I setPhysicsLocation() on it, it takes the vec3 and saves it but it doesn’t affect anything.
I tried countless approaches and println()'s to debug this and I swear all the values are good and the 3D render looks perfect, but the RigidBodyControl is just not working at all, just like if there were none but there is one and it’s not null.
THE ONLY THING I could come up with after 4 days of head banging on the keyboard is:
At step #3 above, to move the TerrainQuad, I have to do this:
Why do I have to do this? Is that even the optimal way of moving a TerrainQuad’s RigidBodyControl? Maybe it has anything to do with how the HeightfieldCollisionShape mechanics work in JME… Can a HeightfieldCollisionShape be moved using setPhysicsLocation() without messing up anything? And should I call something after moving the control to make it work? etc… thx for enlightening me. At least I found a solution, but I find it very dirty and I fear it will cause lag when doing this for 9 TerrainQuad’s every now and then.
try use GImpactCollisionShape for terrain at cost of gameplay speed slows down to 0.1 fps and then you can also abandon collision listeners because they dont work on this shape (they dont code it because it is too expensive)
terrain-specific collision shape uses some rules to speed things up, so terrain can be fast and precise shape, but only works when you dont move with it.
lets think about little example:
you have a car with mesh-accurate collision shape, you cant even imagine, how its collisions detection rules works
then you have a cube with cube shape, you can use some rules that are only applied to cubes and you can create collision rules by yourself right now from your head, but it cannot be applied on precise shapes for cars
then imagine terrain as “2d cube” (so square but it doesnt sounds cool), it uses bunch of rules, that is only true when you dont move with it
and even if it would be possible to move with terrain, imagine character on it. when you move terrain, character is now in air (better) or underground (not good) and falls through
you could probably think i didnt answered why you should not move with terrain, while it looks like you probably normally should… i dont know
PAUL! Thanks for backing my motives You followed my learning curve from 6 months ago so you know what I’m after.
Ascaria, I understand that JME is using a special way to detect collisions on TerrainQuads, that’s why it’s a HeightfieldCollisionShape and not a BoxCollisionShape. But the problem is: just like any other RigidBodyControl, we should be able to move it. Right now, as soon as the TerrainQuad’s control is moved, it does not work anymore, just like if it did not exist anymore. I think it’s either a bug or a missing feature. Altough my PRIMARY question would be: as it sits right now, is removing the control, displacing its location and re-adding the control to the physics space the most optimal way of dealing with moving a TerrainQuad? (because it works, but I fear it’s not optimal)
BTW, yesterday evening I could finally see the end of the world. It looks like this! No more trees, very very squarish mountains (the noise function probably has a lot of a rough time to be precise with such billion magnitude numbers) haha…
That’s a first. I was shocked at how far one could go now in my open world!
Re-adding your physics collision shapes is probably the best way because afaik bullet recalculates some collision data for mesh collision shapes when you add them. Moving mesh shapes isn’t supported per se. But really you don’t need to move the terrain shape when it doesn’t change, just adapt the relative offset of physics and visuals, then the physics space can stay as it is.
@normen said:
Re-adding your physics collision shapes is probably the best way because afaik bullet recalculates some collision data for mesh collision shapes when you add them. Moving mesh shapes isn't supported per se. But really you don't need to move the terrain shape when it doesn't change, just adapt the relative offset of physics and visuals, then the physics space can stay as it is.
That’s interesting. Are you implying that a surrounding node will encapsulate all the TerrainQuads and that I move that node? Because if I remember well, it wasn’t working when I tried.
What I have been doing in the past week (part time lol) is to convert my actual environment to become one where all the TerrainQuads move and the player stays near the origin {0,0,0} because the projection matrix F**** up when it’s far away. On chunk change detection, I would reposition everything depending on where the player moved. I succeeded in everything yet, but my question was if removing and re-adding the TerrainQuads in the PhysicsSpace was the way to go or if there was something more efficient. I tested it yesterday and I can barely see any difference, but I have an 8-core CPU so I barely notice ANYTHING anytime anyways.
@.Ben. said:
That's interesting. Are you implying that a surrounding node will encapsulate all the TerrainQuads and that I move that node? Because if I remember well, it wasn't working when I tried.
What I have been doing in the past week (part time lol) is to convert my actual environment to become one where all the TerrainQuads move and the player stays near the origin {0,0,0} because the projection matrix F**** up when it’s far away. On chunk change detection, I would reposition everything depending on where the player moved. I succeeded in everything yet, but my question was if removing and re-adding the TerrainQuads in the PhysicsSpace was the way to go or if there was something more efficient. I tested it yesterday and I can barely see any difference, but I have an 8-core CPU so I barely notice ANYTHING anytime anyways.
And your question is what I gave an answer to. Physics has nothing to do with nodes.
It has nothing to do with nodes, but what are you implying exactly when saying this: “you don’t need to move the terrain shape when it doesn’t change, just adapt the relative offset of physics and visuals, then the physics space can stay as it is.”
What does that mean, can you elaborate a little on this please? I’m not sure what you mean.
If I move the TerrainQuads, then the physics need to be moved too, not just the geometry…
@.Ben. said:
It has nothing to do with nodes, but what are you implying exactly when saying this: "you don’t need to move the terrain shape when it doesn’t change, just adapt the relative offset of physics and visuals, then the physics space can stay as it is."
What does that mean, can you elaborate a little on this please? I’m not sure what you mean.
If I move the TerrainQuads, then the physics need to be moved too, not just the geometry…
Why? You move the terrain to simulate an endless world. In your world the coords of the hill in the terrain stay at the same in-world coordinates so you can keep the physics located according to your in-world coordinates as well.
The TerrainQuad is moved from {0,0,0} to {-512,0,0} when the player goes to the chunk {1,0} then the TerrainQuad is moved to {-1024,0,0} when the player crosses again onward to chunk {2,0} until it is far enough that it’s not visible anymore and then the pool checker detached that TerrainQuad. Does that change your answer? Because I still don’t understand what you’re trying to explain to me. At any given moment, there are AT LEAST 27 TerrainQuads visible. The player or anything physics can NEVER be outside of this range at any given moment: {-1536 to 1536, whatever, -1536 to 1536}. That’s the beauty of this system is that the matrices are VERY VERY precise because of such small magnitude numbers.
@.Ben. said:
The TerrainQuad is moved from {0,0,0} to {-512,0,0} when the player goes to the chunk {1,0} then the TerrainQuad is moved to {-1024,0,0} when the player crosses again onward to chunk {2,0} until it is far enough that it's not visible anymore and then the pool checker detached that TerrainQuad. Does that change your answer? Because I still don't understand what you're trying to explain to me. At any given moment, there are AT LEAST 27 TerrainQuads visible. The player or anything physics can NEVER be outside of this range at any given moment: {-1536 to 1536, whatever, -1536 to 1536}. That's the beauty of this system is that the matrices are VERY VERY precise because of such small magnitude numbers.
Nope, doesn’t change it. You still want to link visuals and physics positions 1:1 which isn’t needed.
There’s a portion of my brain that tries very hard to IMAGINE what you’re talking about, but it fails so much and the other half of my brain is laughing at me for sucking so much at this. Can you give a concrete example of just what the F*** you’re talking about? LOL
Your physics character is moving across the physics terrain from 0/0/0 to 0/0/512. At 0/0/256 you reset the visual terrain to 0/0/0. When the character arrives at 0/0/512 its visually at 0/0/256 and in the in-game coords it might also be at 0/0/512. Now it crosses the 512 barrier and you need to load a new physics terrain piece anyway. So you do that at 0/0/0 (physics) and reset the physics character to 0/0/0. Because the visual grid size is 256 you reset the visuals too to 0/0/0. The character goes on in that direction and the in-game coords are now say 0/0/780, the physics coords would be 0/0/268 and the visual coords would be 0/0/12. The initial point was that you don’t need to move the physics just because you move the visuals.
Well, but in case it was missed from earlier, he is moving the visuals because floating point becomes inaccurate. This will affect float-based physics also. (In fact, much sooner than it affected the visuals.)
@pspeed said:
Well, but in case it was missed from earlier, he is moving the visuals because floating point becomes inaccurate. This will affect float-based physics also. (In fact, much sooner than it affected the visuals.)
Doesn’t change the fact that you don’t need to move physics when you move visuals. And the solution for the initial problem was given too in case not moving the physics mesh is too complicated.
@normen said:
Doesn't change the fact that you don't need to move physics when you move visuals.
Then I must be confused by your other answer.
If the effective world location is 1000000x1000000 which has been locally translated into 0x0… wouldn’t you also want physics to be 0x0 based so that it doesn’t move things in giant inaccurate chunks? And if so, then it seems reasonable that once the effective location has moved far enough then you’d want to readjust everything to be 0x0 based, including physics.
Your answer may have been covering this case but I wasn’t able to follow it, if so.
But whatever… I guess the “issue” is that terrain collision meshes are generated in world space… so moving the terrain requires recalculating the collision mesh. Since this is unlikely to be changed, OP must go with his solution of regenerating the collision meshes when the origin basis has moved.
@Momoko_Fan said:
I would be surprised if bullet did not actually support this rather common use case.
Isn’t there a way to move static mesh shapes without recomputing them from scratch?
I agree… but don’t have any clue. I’m guessing, but I think the issue here might be specific to terrain. I’ve never looked at any of it but I know in other cases terrain takes a “this is more optimal for heightmaps” path.
You followed my learning curve from 6 months ago so you know what I’m after.
