Precise collision

#1 What do you mean by precise collision? You can edit an object's collision polygon to make the collisions more similar to the shape of the object, just select the object and click on the "Edit this object's collision polygon" button. tdn.garagegames.com/wiki/Collision_polys

Let me know if this helps.

#2 Shape of object has some concave parts.

What do you think about this link
http://tdn.garagegames.com/wiki/TGB/MiniPlatformerTutorial. In this example, I think that we should use the concav(pixel) collision for the ninja sprite. I used to collision polygon for it but I think that, it doesn't support full collision according to shape.

In the gamemaker, There is a subject about collision. It is below. This tool's price is 20$ approximately and It support pixel collision. The TGB that I bought price is 500 $. It supports only polygon collision. When will it support the pixel collision?

precise collision :
"First of all there are options related to collision checking. Whenever two instances meet a collision event is generated. Collisions are checked in the following way. Each sprite has a bounding box. This box is such that it contains the non-transparent part of all the sub-images. When the bounding boxes do overlap, it is checked whether two pixels in the current sub-images of the two sprites overlap."

#3 So you assume, that the slower and feature cut version of collision, ie pixel collision, is the "professional way"? (thats at least what I assume from the posting that missing precise = unprofessional)

the one that wouldn't allow you usefull and performant full tile layer collision and similar things?
Something that would not allow fast moving objects as swept collision needs polygons?

Thats what you see as the better collision ...

#4 For images with concavity, breaking images into their convex parts and then mounting the images together may be a solution.

#5 If having it fast is the professionality then use image boxes and rectangles which would be ugly visually but very fast. There are times when it is visually necessary to have some precise collision check. Imagine you have a top view airplane image and collision polygon leaves an empty space in the area between the tip of the wing and the cockpit. Now when a missile hits that empty part, airplane will explode because of polygon collision check. The ninja sprite in TGB platform example collects the coins with an invisible body (the polygon) between his arm and leg because of the polygon collision check. Also, the polygon cannot adjust to the changing images in an animated sprite. So for a running man sprite, the man stops before he reachs the wall. All because of polygon collision check and there are lots of other examples.

I know that there is a trade off between visual quality and performance, however it would have been better if TGB had the option that enables us what to choose. I am a professional game programmer and have a published game which sells in stores. I programmed it with Game Maker 6 and I used precise collision check with the main characters and polygon collision check with the rest. It did not create any performance problems. I really cannot understand why you did not appreciate my critism and impose that this is what I should only have.

To reply Melissa's post, it may work but it would be a burden to create convex parts of the objects if you have 50 or more of those. It would have been really easy to have precise collision check with a check box just like in Game Maker 6 which toggles precise collision check. It is not that difficult to code it, but I expect it comes with the builder if I pay 500 dollars for it. Or at least, I expect a post that explains clearly why there cannot be such thing in TGB.

#6 The main reason I thought was that (correct me if I am wrong) GM uses pixels as the unit measurement? If an object is 20X20 in GM it is 20 pixels by 20 pixels and so on? (It's a while since I used it and I seem to recla that was how it worked). Now that is fine but TGB doesn't, space is arbitary, which allows objects to be scaled, rotated, moved, collide and so on without haveing to be exact with the number of pixels.
Like I said I could be dead wrong as it has been a while since I used GM.

#7 Yes, GM uses pixels as the unit measurement. In TGB it may not be the case, but it is not a valid reason not to have precise collision check. Actual image collision is always measurable and it does not depend on unit of measurement. At least multiple convex collision polygons could have been enabled to have concave polygons instead of creating convex parts of images and mounting them all to each other.

I am almost sure that TGB team is aware of this issue and working on it to have a solution. Because without precise collision check, it is nearly impossible to have a platform/adventure/strategy game with high visual quality.

#8 There are several issues with getting this to work properly in TGB. None of them make it impossible, but it does make it a much more difficult problem.

The fact that TGB scenes don't use pixel coordinates would make the implementation slightly more complicated and slightly less efficient. By no means a deal breaker.

The real issue is that TGB uses swept time collision detection. This means that collisions are essentially detected continuously instead of at specific intervals. Doing that with pixel perfect collisions would be extremely inefficient. The obvious solution to this is to not do swept detection on objects requiring pixel perfect collisions. That falls apart when trying to collide a swept polygon object with a pixel object. Plus, you lose the benefit of having swept collisions (eliminates tunneling, accurate physics responses).

Plus, in most cases, you are going to want to use pixel collisions only for specific interactions. Given a platformer, you definitely don't care about pixel colliisons when colliding the player with the ground. But, you probably do when colliding the player with a collectible.

To me, this all points to a completely different solution. Pixel collisions should have nothing to do with the existing collision system. Really all we need is a method that can be called anytime that can query what objects an object is colliding with on a pixel perfect level.

In the above platformer example, the existing collision system handles moving along platforms. Then, every tick, you could call the pixel collision method on the player, which would return a list of the objects being collided with. If one of the objects is a collectible, collect it.

We actually aren't actively working on a solution right now, unfortunately. It has been discussed before, but there are always other, more important things to work on since for most games pixel collision is not necessary.

I do disagree with the statement that it is nearly impossible to make certain games without it. It may make some things easier, but getting similar results with the existing collision system is well within the capabilities of the engine. It just takes a little outside the box thinking.

Maybe a community member wants to step up and take a hack at this? I'm sure it would find its way into the engine if that were to happen.

#9 You can accomplish quite a bit by combining multiple convex collision polygons to fit the shape. In the end this would not only net you better performance than pixel perfect collision, though should work for multiple situations (including adventure, strategy, platformer, etc).

The biggest limitation will be with animations, something that would benefit the engine would be different collision polygons for different frames of animations. With that said being able to define multiple collision polygons in the editor for a single object would be very beneficial as well. Though even though this functionality does not exist, it can still be achieved fairly simply via script. If you are curious on a solution rather than just focusing on the problem then I and many others would be more than happy to help you.

That said I agree completely with Adam and believe me, we all have thought on many features that would be quite nice in the engine... the truth of it is that we must evaluate time spent on said feature vs. how many people really would utilize this. In the end we don't get that many people requesting pixel perfect collision and often when they attempt other methods at achieving this they find them to be adequate and in some cases much more efficient.

#10 Sorry for side tracking, but I don't get this concept of "swept detection." It sounds to me that accuracy is sacrificed for speed, which is understandable. But your post made it sound like objects can't do things like say...pass through another collision polygon, which is simply not true. On numerous occasions I've had problems with the collision system using completely convex collisions for SIMPLE operations. Never involving more than 2 or 3 objects. Yet, I can still make objects go through each other, I still can't get accurate collision detection, and it even will slow down at times.

I can understand using only convex collisions for the speed increase - but something is fundamentally wrong with collisions. It is really annoying that I need to think of a way to make something like a platformer work different then I want because collisions don't work the way they should. It is really annoying that I need to stop working on my IK system because collisions don't work the way they should. I can name so many things I've been working on and I've had to stop because of the collisions.

This post isn't meant to be just purposeless bashing on the engine. Don't get me wrong - this engine is amazing, and I like working with it. But really now, I keep hearing the collision detection referred to as "unimportant" or whatever the case may be. What could be more important?? Make the engine EASIER to use? Making it more accessible? Foundations for an engine should be solidified before that, and collision detection is a huge foundation for a "Game Builder." Sure, the source could be modified, I could try and throw out the current physics system and put the verlet system I want in, and I could try and throw out collisions and put in a more reliable system - but that defeats the purpose of buying an engine.

Anyway, my rant is done. All I beg for in the next update - hell, I would even pay for it instead of download a new update - is some more accurate collision detection. I won't even complain about mounting and physics, all I ask is the collisions get worked on. Thanks.

#11 Actually Thomas, I completely agree with you. There are several issues with the current collision system and it's a little bit ridiculous that we haven't addressed them. The biggest problem, I think, is that it is difficult to use and set up correctly, particularly when using rigid collision responses. Still, even when set up perfectly, there are several issues, though I think they mostly exist in the collision resolution rather than the detection.

Still, pixel perfect collision detection in the existing system (or type of system), wouldn't really work that well. And, swept poly collisions are pretty much the best general purpose way to do things as far as I know.

There is hope. A port of the Torque X collision system (which is much cleaner and more accurate) has been started. It's not currently being worked on because the component system in TGB (also ported from Torque X) is not complete, but collision detection and response is working.

I don't want to get anyone's hopes up, because there's a long way to go to get it to the same level of completeness as what currently exists in TGB. But, I think people should know that we do plan on fixing this stuff - it just might take a while.

#12 Well, it makes me happy to see that something is going to get done. I just hope it is sooner than later. Thanks for the reply.

#13 I agree with Thomas' points. Collision system should never be out of the list till TGB gets an almost perfect one. I hope to see some improvement about it at least before TGB version 2.0. Thanks, thanks, thanks for every effort put on a more perfect collision system.