Per-pixel collision?

[Ralf Van Bogaert]

Hi,

I'm working on setting proper bboxes per frame. Ideally I'd like to have 3 per frame - one for the head, another the torso, and the legs. Obviously this depends on the position of the character.

Having to do this for each and every frame is a daunting task, and because boxes are rectangular there's always going to be empty space around the character that's going to be hittable.

So a very welcome and time-saving feature would be to allow OpenBOR define bboxes automatically, one for each vertical line, with x being the utmost left non-transparent pixel on that line and width the distance to the rightmost, and I'm sure there's more room to optimize this further.

PC's these days are more than capable of handling the increased collision calculation load, right?

To illustrate what I mean:

Sprite:



Auto-generated bbox:



This would give excellent results in general and greatly reduce the amount of time and effort required to develop OpenBOR modules.

 

[ABK]

Yes this shape would be best to represent the whole body but in practice its overkill, can you show actual examples where current method with one bbox fails?
If you want separate reaction for head area, torso and legs in openbor - use bindentity, the 3 binded entities will communicate with the parent and force the proper pain animations.
Openbor is not using GPU, so no it actually would slow down/drop frames, it slows down on various graphical effects.

Imo You are overthinking it, and in practice the problems you think are big deal are not really happening during gameplay, some uncovered parts of the body etc.. it does not matter much cause hitboxes are wide and tall enough to reach anyway.

Even if it would be possible, its insane amount of work to mark head,torso and legs on each frame... compared to setting your bbox just once for many animations at once. but you say you have a script that does this ? But its just one maked area on this pic, youd need head and torso and legs but...

You gave me an idea, maybe i can do a script that creates single bbox by detecting first non transparent pixel from left top and from bottm right to create bbox.
But i think this will fail, bbox moving like this on every frame can cause some issues between pain and idle anims during combo, especially if pain looks way different than idle frame so in the end the hit wont connect cause precision is not always what you want - you want coherency between all animations so all hits will connect properly.

 

[DCurrent]

@bWWd is partially correct. No, you don't have to use a bunch of bound entities to substitute collision boxes. That's kind of absurd really.

However, in every other aspect he is on the money.

PC's these days are more than capable of handling the increased collision calculation load, right?

No, they are not. Not even close. I gave a detailed explanation on this a while back here:

Post in thread 'Theoretical question about Bbox' Theoretical question about Bbox

You gave me an idea, maybe i can do a script that creates single bbox by detecting first non transparent pixel from left top and from bottm right to create bbox.

I already did this, remember? I even posted the code for you. It's how my raindrop script works. But no, it's not a smart idea for collision.

What you can do for area specific collision is get the engine's built in hit location coordinates, wisth, and model/animation height, then do some math to calculate where in the model's area it falls:

Model/Animation height is 100px, the hit is at Y88. That's 88% height, so it's a head hit.

See also, I did this years ago and posted all the code. It's not hard and uses minimal CPU.

But all of that is silly these days. 4.0 gives you multiple boxes. Use them. All those little workarounds you're coming up with aren't saving anything. Much smarter people than you or I already figured out the best way to do this stuff, and that's how the engine works.

DC

 

[Ralf Van Bogaert]

The main appeal would be to have precise and accurate hitboxes without having to spend any time making them. It would save me literally months of work.

OpenBOR would automatically create a 1-pixel high bbox per line. The example above is 93 pixels high, so that would be 93 hitboxes.

If 2 or more touching hitboxes have the same x and width values, they could be merged into a single one.

Or maybe it would create the example as the first pass, and a second pass would apply simplifications.

At any rate, OpenBOR could do quite a few things to help us out here.

 

[DCurrent]

The main appeal would be to have precise and accurate hitboxes without having to spend any time making them. It would save me literally months of work.

Sorry, that's just part and parcel to game making. Until somebody rewrites math or makes a profound leap in ANI, shaped collision is good as it gets. There are lots of time savers like CMT and workforce procedures, but at a point it's just buckling down and doing the work.

As mentioned in my linked post, the closest thing to what you're asking for is hardware sprite collision, which hasn't been supported anywhere for about 30 years.

DC

 

[DCurrent]

OpenBOR would automatically create a 1-pixel high bbox per line. The example above is 93 pixels high, so that would be 93 hitboxes.

If 2 or more touching hitboxes have the same x and width values, they could be merged into a single one.

Or maybe it would create the example as the first pass, and a second pass would apply simplifications.

This is beyond unworkable. I already explained why.

At any rate, OpenBOR could do quite a few things to help us out here.

You don't yet have the knowledge to make an assertion like that.

I suggest you go play with Unity, Unreal, GoDot, Mugen, Gamemaker, or anything else. Then come back and tell us how hard, limited, or whatever else OpenBOR is.

DC

 

[ABK]

Yeh it is obvious that you can even store height of the hitboxes in entityvars to acquire by enemies but this is not the problem - the problem is with jumpattacks that hit head or torso, or air weird attacks that can hit head or torso or body at diferent heights of their animation and youd need to calculate how hight theyre from the enemy feet , but id say its doable.

 

[Smart Kitty]

Per pixel collision it's useless and it's costly in engine speed and hard to understand in engine logic, just add more bboxes to characters and done. I never have seen hitboxes issues before, they works perfectly (if you readed at least the guide manual)

 

[DCurrent]

Yeh it is obvious that you can even store height of the hitboxes in entityvars to acquire by enemies but this is not the problem

You don't need to do that at all. The values you need are all native. Every model has a height and width setting. Every animation can temporarily override them. No variables necessary.

The hitpoint is also native. The engine already calculates the point of contact. That's how it knows where to spawn the flash model.

All the script needs to do is read those values, combine them with in world position and take action from there. In my case, any hit >= 75% height was a head hit for reactions and blocking. 25-75% was a body hit, and < 25% was low. This isn't theory. I did it, tested it, used it. Works perfectly.

Again though, 4.0 makes every last bit of this superfluous other than a special case (scaling) that doesn't apply to our discussion. If you want area based reactions, then just define a low, body, and head collision like the pros do. Maybe another one or two for edge cases like weird shapes and shields or whatnot. Then in your script, get the collision box index that detected hit (it's provided as a localvar) and that's all you need.

DC

 

[oldyz]

@DCurrent or @bWWd - is terrain interaction somewhat similar to hitbox stuff?

I have been meaning to ask, i saw a while back a video of some kind of game engine that is used to make sonic style Games, and i noticed that is seemed to make terrain by basically using what seemed to be a hand-drawn method, using like a brush.
basically terrain was made by painting the stuff black, the sonic sprite would react accordingly.

this remind me of a weird idea i had shared where a non visible sprite or sprites could be used to do collision data...

either way i will try to find that video, but it seems weird to me, how would such accuracy be implemented in the case of that engine, i am sure there must be some limitation...

 

[DCurrent]

@DCurrent or @bWWd - is terrain interaction somewhat similar to hitbox stuff?

Iit's identical in principle. Walls, platforms, and basemaps can use different shapes, but collision detection is collision detection. It works pretty much the same way for every type in every engine.

I have been meaning to ask, i saw a while back a video of some kind of game engine that is used to make sonic style Games, and i noticed that is seemed to make terrain by basically using what seemed to be a hand-drawn method, using like a brush.
basically terrain was made by painting the stuff black, the sonic sprite would react accordingly.

Ive seen it. That's just a fancy looking toolkit. Under the hood it's still the same. All they're doing is reading the brush area, then setting up collision shapes (a combination of arcs and squares) to closely approximate it.



OpenBOR's collision shapes are triangular prisms (basemaps) and hexahedrons (everything else), so it's more appropriate to direct draw them as shapes in CMT.

DC