Jump to content
  • Advertisement
Sign in to follow this  
dietepiet

RTS Scene management

This topic is 3664 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi I have a bit of a scene management problem. Imagine a complex RTS game engine. All kinds of interactions between objects need to be handled: - collisions between objects (Object collision volumes play a roll here) - 'collisions' between visible objects and visible light sources - 'collisions' between dynamic decals and decaltargets (unit selection decal on platform objects) - view frustum culling. (Or so you will, collision between frustum and objects) - shadow frustum culling. - reflection culling. - LOS checks - etc. - etc. Al these problems have a lot in common, and similar solutions could be used for all of them (For example a loose octree). However, using only one such datastructure has the disadvantage that when selecting potential interactions, a lot of useless interactions are found and discarded, such as light-light, shadow-light, shadow-decal and object-decal collision for non decal-target objects. On the other hand, handling all kinds of objects in different data structures has the disadvantage of having to manage many different data structures which all need a lot of memory. My question: Is it, in game engines, more common and useful to separate all these management problems in different data structures, or are these problems usually solved once and for all with one single datastructure. Thnx, Dietger

Share this post


Link to post
Share on other sites
Advertisement
Typically you separate collision spatial partitions from rendering ones.

Also, in an RTS there's not really any need for collision detection between units (only between projectiles and units). You can use steering behaviors to keep the units apart and if they do collide just allow them to interpenetrate. With the high camera that generally goes unnoticed and if noticed no one cares.

-me

Share this post


Link to post
Share on other sites
thanks for the replay!

About the collision between objects, when using steering to avoid collision, you still have to select all objects within the proximity of any moving object. So 'collision' might be better interpreted as 'interact'. Also, in current RTS games, like Faces Of War, static structures have complex shapes (nothing near square) defined with collections of collision volumes, so I assumed these structures were objects as well.

Besides that, having a rendering and spatial collision structure solves most problems. But for unit AI, units have to search within there local area for shelter, weapons, enemies etc. Does one still use the same spatial structure for all these problems as used for collision detection? I have a hart time thinking of a general structure capable of handling so many different queries with reasonable performance.

Share this post


Link to post
Share on other sites
Quote:
Original post by dietepiet
Also, in current RTS games, like Faces Of War, static structures have complex shapes (nothing near square) defined with collections of collision volumes, so I assumed these structures were objects as well.


Sure but they don't actually need collision again except for bullets. You just cut out the tiles/nodes over which they're built from the A* mesh and then units will auto-magically avoid them. I probably confused the issue by including a runtime optimization within a discussion of data structure design.

Quote:
Original post by dietepiet
Besides that, having a rendering and spatial collision structure solves most problems. But for unit AI, units have to search within there local area for shelter, weapons, enemies etc. Does one still use the same spatial structure for all these problems as used for collision detection? I have a hart time thinking of a general structure capable of handling so many different queries with reasonable performance.


Yes you're right about the object search. You'd need the units in that spatial structure anyway for bullet collision checks. In the RTS game I worked on we used the same spatial structure for collision and "get objects near me" type queries. That, however, was separate from the render structure.

That query is exactly the same query you do for collision detection: often called "nearest neighbors search". So they easily fall within the same data structure design.

Otherwise you should pick up the book "Real-Time Collision Detection".

-me

Share this post


Link to post
Share on other sites
I see why 'nearest neighbors search' is quite general. I assume you just don't care that, when selecting all enemies in a certain radius, you also get all other objects within this radius and have to filter them out afterwards.

On the A* meshes. When buildings are open structures, only consisting of thin walls with a roof, in which units can walk freely, and when these buildings can be partially destroyed when a tank drives through one, some collision detection has to take place. Therefore I assumed this was handled in a more general way using spatial structures. But as I understand you, you handle this kind of interactions with a separate (2D) mesh structure (also used for path-finding), only enabling default collision when an object moves into cut-out part of your mesh (is this anything like what you meant?). This gives a few complications when an object tries to move through a gate that is to low, but this is probably doable.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!