Sign in to follow this  
RKT

Colliding with MANY objects and some other questions

Recommended Posts

Hi all. I am writing a medium OpenGL application, actually I didn't yet came to the practical subject of my question, but I always before writing something do think about how it will (or won't) work and possible problems.

So, the world will (or rather consist of , similar to Infiniminer/Minecraft, but not exactly) have in it few thousands (or tens,or more) of objects, and obviously I will have to check player's collision with them(only this, no other physical checks or interpretations). Obviously, it is not good idea to bruteforce them all. I have been thinking about this and came with idea of dividing all the objects into groups (for example 10 cubes placed on each other is one group, the other ten standing near them is another) and check the distance between groups and player and if group is near enough - check each group's object for collision and stuff (same comes for rendering).

I guess it is not good idea at all (or is it? Anyways, it still a lot of calculations).

How can I check so many collisionable objects with player?

How should I check their renderability?

Should I store each object as entity (in array of structs/classes), can it affect memory drastically?

Share this post


Link to post
Share on other sites
Hierarchical partitioning (groups) is a commonly-used technique for game actors (player, enemies, npc), but world data is usually partitioned by using a fixed node structure (binary tree, quadtree, octree) since the data is (usually) mostly static.

There is a balance point in which the cost of spatial partitioning becomes equal or greater to the cost of a brute force method. If this is the case, it is not worth implementing the partitioning at all. The balance point can be determined by profiling several options, and seeing which works best in your case (each engine and environment is different).

In rendering, calculating the potentially visible set can take the spatial partitioning into account too. In addition:[list][*]If your objects are very complex, use depth-based occlusion culling (if your
target supports implementing this) to effectively discard non-visible objects
before rasterization. If the objects and shaders are simple to begin with, this
may not be worth the trouble because drawing simple objects is fast anyway.[*]Since the camera usually limits the view
volume of the player to a truncated pyramid, you can check whether the partition
groups intersect this pyramid in order to determine whether the player can see
them at all.[/list]

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this