Jump to content
  • Advertisement
  • entries
  • comments
  • views

Good news

Sign in to follow this  


Real life news first - got a decent job starting tomorrow. Working for a supplier to the oil and gas industry as an expiditor, which basically just involves chasing through orders from supplier to end user and making sure everything gets delivered on time. Nice friendly team and money is a bit better than the last one, so hopefully I'll be able to stay there a bit longer than the last few jobs [smile].

Dev news:

Decided to seperate renderable triangles from collision polygons and added the facility to define them seperatley to the map editor.

As a result, the nice rounded shape in the middle of the screenshot above is constructed of about twenty triangles in terms of rendering, but exists as a single convex polygon in terms of collision detection.

Still obviously takes longer to collide test against a polygon with lots of edges, but better than testing against than many triangles.

I tried this zone bucket thing for reducing the collision checks, but it actually ended up slower than the current method. I think that the current system is okay - AABB checking everything against everything else. I can have about 150 individual objects all bouncing against each other and the map before the frame rate slows, and only then if they are densely packed, so more than fast enough for the sorts of levels I envisage.

If it does present a performance issue later, I always have other avenues to explore to cull collision checks, but until it presents an actual problem, I'm going to leave it as it is.
Sign in to follow this  


Recommended Comments

Hey, sorry I didn't get back to you yesterday I got distracted by silly things like work ;) BTW, good to hear that things might be settling down on the job front for you.

The pairwise problem. Given the simplicity of the geometry that you're dealing with, and the numbers involved, I think leaving it as-is is a reasonable option. You'll probably want to do something more efficient only if you start using more polygonal collision shapes.

Someone suggested using grids and this is probably the best way to go because it is one of the simplest. The basic idea of all strategies to get around the pairwise problem is divide and conquer; If you can easily put objects into bounding regions that don't overlap, there is no need to perform a collision test. The difficulty of using this strategy is just that it involves more book-keeping work.

Share this comment

Link to comment
For my project I'm (also) opting for a simple spatial partitioning grid (or, "regular grid"), which -- although simple -- will certainly be able to handle the job even for hundreds of collidable objects. In the large scale, the savings over the pairwise O(n^2) approach are quite satisfactory.

I also finally had a chance to try out your demo: nice work. I'm glad you've been having more luck (and likely less frustration) with implementing physics than I have. [grin]

Share this comment

Link to comment
Cheers all.

There was probably something wrong with my implementation of the grid system before. I can see in theory it should massively reduce the collision checks and should certainly be far less costly than even doing AABB check against every pair.

To be honest, I'm almost looking forward to finding a bottleneck with my current naive system, since as I said last journal, it is actually really nice to have a bottleneck I can actually do something about rather than hitting the limit that my graphics card can render.

Can't really work out why my previous grid system caused a slow down. I had a class containing a std::vector of std::list<Object*>s. When an Object moved, it first called erase(this) on its current cell, moved, then called push_back(this) on its new cell.

AABB checks were then only performed against other objects in the same cell or in any of the adjoining cells.

I appreciate there must be ways to cull even further (e.g. by culling pair checks that have already been performed etc) but I still think the above should have been faster than the current system of AABB compare everything to everything else.

Perhaps have another try tonight. Maybe was doing something stupid.

Thanks for the comments.

Share this comment

Link to comment

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
  • Advertisement

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!