Big world size to accomodate huge terrain chunks?

Big world size to accomodate huge terrain chunks?

Imagen de Brendan A.

Hi Havok!

I'm making a space game using the free version of Havok Physics. So far everything is going great but I'm encountering an issue with how I'm designing my gameplay and setting up my world broadphase and landscape meshes.

In the game, you can fly around Earth-sized procedurally-generated planet surfaces (and space) in a ship at very high speeds. In order to load landscape physics efficiently I generate very large, low-def meshes (they can be huge- like 8000m x 8000m). This is only as a safeguard in case the player crashes into a mountain or whatever. Once the ship slows down, the game generates smaller, high-def terrain chunks (more like 100m x 100m) for landing and walking around. All these chunks are added to the physics world, and the world is "silently shifted" a-la SlidingWorldDemo in order to keep everything in the right place as the player flies around. This is all working great- everything is nice and fast and it's lots of fun.

The problem is my broadphase size. I was hoping that I could add fixed objects outside the broadphase and they would "shift in" when I moved the world, but their AABBs do not seem to update when this happens. After reading the docs it would seem that if I forced the objects to update, it would involve recalculating collisions and is not a good idea. Am I right about that?

So, in order for the broadphase to accomodate this stuff it needs to be huge, like 25000m wide or more. Is this crazy? It would be one thing if I ONLY had huge objects, as I could scale everything, but the fact that I also deal with character-sized objects complicates matters.

I'm leaning towards having 2 physics worlds- one for the macro and one for the micro, and somehow syncronizing the two, but it seems like a lot of extra work and I'd like to avoid it if you guys think it's possible to have huge worlds, or think there might be another solution.

Thanks very much! My game is very small but it's a commercial project and if it ever makes any money I will definitely be buying a license! Havok is great! :D

publicaciones de 4 / 0 nuevos
Último envío
Para obtener más información sobre las optimizaciones del compilador, consulte el aviso sobre la optimización.
Imagen de Havok_Amy

Hi Brendan,

I just want to make sure I understand your use case and exactly where your having a problem with your broadphase.

1) Are you having a problem shifting the broadphase when the ship is at high speeds or is this only done when the ship slows down?
2) Would the broadphase you are suggesting of 25,000m contain the entire world or only a single planet surface (so the 8,000m planets expand to 25,000m)?
3) Yes, forcing the objects to update their position in the broadphase can be very expensive if this is done to alot of objects often, however the performace hit may not be a problem if you aren't adding/removing alot of objects very often.
4) There is a known issue with how the broadphase gets shifted in the SlidingWorldDemo but unfortunately I can't offer a quick fix for this as the problem was in our source code (so you will be able to get a fix for this after the next Havok release, but it may be a few months before it is available for free users). Hopefully once I have a better idea of what your use case is we might be able to find another way around this problem.

Amy Developer Support Engineer Havok www.havok.com
Imagen de Brendan A.

Hi Amy, thanks so much for getting back to me. Here are some answers to your questions. I hope they are clear :)

1) It doesn't really matter how fast the ship is moving, but the problem only occurs with very large terrain chunks, which are large enough to be generated outside of the broadphase and usually come as the ship is flying around. Whichever part of that object's AABB is past the broadphase seems to remain on the broadphase border even when the broadphase shifts so that it completely encompasses the object. If the chunk is generated/added entirely outside the broadphase, then it's AABB will be on the broadphase border forever and my ship will not collide with it.

Increasing the world size up to 25000 meters ensures that there will always be room for new terrain chunk to fit entirely within the broadphase.

2) This size wouldn't even contain a whole planet surface- the 8000x8000 chunks represent only a small portion of a single planet, which have radii of up to 10 million meters. This is why I generate chunks of terrain to follow the player around. (let me know if I'm not understanding your question properly, I'm not 100% sure I addressed your point about "8,000m planets expand[ing] to 25,000m")

The world size of 25000 meteres would contain these large terrain chunks, but once the player lands and starts walking around their ship, it will also contain smaller objects like rooms, ammo boxes, and the player. These smaller objects are only added to the world once the player has landed. In addition, once the player has landed the large terrain chunks (which necessitated the huge world in the first place) are no longer really needed, as I generate smaller, high detail terrain in this mode. This is the reason why I am supposing that it may make sense to make use of two different physics worlds- one for the macro level and one for the micro level. I'm only worried about the labor and unanswered questions involved with trying that out and syncronizing everything. If I can get away with having this huge 25000m world for everything, I won't bother with 2 worlds.

3) Hm, thank you for the info. I probaby should just test this. This might be done once every couple seconds, to 4-6 large terrains which together would encompass most of the scene. My game does not have many dynamic objects in it- just terrain and spaceships flying above it for now, so perhaps this would be fine!

4) Thanks! I hope that I've described the use case sufficiently :)

Imagen de Havok_Amy

Hi Brendan,

1) That behaviour sounds similar to the bug I mentioned in the last post. Could you send a snapshot or visual debugger movie of this behaviour so I can make sure we're on the same page?

2) Although it should be possible to have a broad-phase of 25,000m, because of the way Havok's broad-phase gets quantized internally, more collisions will be detected at the broad-phase (creating extra work for the later stages), particularly when the player lands and smaller objects are added to the world.
From what I understand so far, a broad-phase of 25,000m should be fine when you are only loading the large low-res terrain chunks, but when your player lands and smaller objects are added to the world the large broad-phase would create unnecessary work for the mid & narrow phases. Two separate worlds should solve this problem but would of course require extra work from yourself to get setup. If you have any more "unanswered questions" about this feel free to ask :)

Amy Developer Support Engineer Havok www.havok.com

Inicie sesión para dejar un comentario.