Normal angle of a sprite at different positions

» Sun Sep 07, 2008 4:11 pm

It is possible to calculate an approximate normal to the surface of something. The ball behavior does this internally, and I wrote some of the code for it. However, it's complicated and I'm sure you don't need it here.

You should probably adopt a system a bit like the 8 direction movement's engine. The algorithm works like this:

Attempt to move in X direction
If X direction is blocked by solid, move back to original position
Attempt to move in Y direction
If Y direction is blocked by solid, move back to original position

This per-axis check means if you are blocked by something, you can still move along the unblocked axis. It might not work perfectly for all shapes and sizes of wall, but it seems to do the job for the 8 direction movement. It is also a suitable solution... the normal detection algorithm might be quite tricky in events, and is definitely overkill for something this simple.
Scirra Founder
B
414
S
245
G
92
Posts: 25,206
Reputation: 200,353

» Sun Sep 07, 2008 4:18 pm

To be honest I gave up on this angle fairly quickly after I realised there was no way it was going to be simple and there is obviously a better way. Didn't think to do it for per axis like that though, so thanks for that

I'd quite like an idea of how to find this elusive angle because I find it interesting, and I've not been able to come up with anything at all.
B
2
S
2
G
5
Posts: 236
Reputation: 2,122

» Sun Sep 07, 2008 8:42 pm

I was thinking, would this be a nice thing to add for the box object? (or maybe polygon object in future?)
B
2
S
2
G
5
Posts: 236
Reputation: 2,122

» Mon Sep 08, 2008 4:08 am

I would still certainly love to be able to find the normals though, however with the way the physics object is going there will soon be no need for me
B
3
S
2
G
5
Posts: 351
Reputation: 2,377

» Mon Sep 08, 2008 10:05 am

The way normals can be calculated is by moving objects in a circle. If a ball, say, has collided with the edge of an arbitrarily shaped sprite, you can move the ball out by a radius (16 pixels works OK) and then collision test in a circle (say, at 4 degree intervals). By working out the average angle of the overlapping angles, you can calculate the approximate angle towards the surface, and inverting this gives you the normal.
Scirra Founder
B
414
S
245
G
92
Posts: 25,206
Reputation: 200,353

» Mon Sep 08, 2008 10:19 am

Can we expect vector-based collision masks at some point? Or a polygon object? There would be a ready polygon editor with the physics behavior .
B
3
S
2
G
5
Posts: 263
Reputation: 2,201

» Mon Sep 08, 2008 9:33 pm

[quote="Drasa":8bjkiais]Can we expect vector-based collision masks at some point? Or a polygon object? There would be a ready polygon editor with the physics behavior .[/quote:8bjkiais]

[quote:8bjkiais]To be honest I gave up on this angle fairly quickly after I realised there was no way it was going to be simple and there is obviously a better way. Didn't think to do it for per axis like that though, so thanks for that

I'd quite like an idea of how to find this elusive angle because I find it interesting, and I've not been able to come up with anything at all.[/quote:8bjkiais]

i did mention what ashley was saying, although i dint really word it correctly, the part when i said push the object back the way its came,what ashley said is what i meant i problly should of said it clearer though.

and ashley

[quote:8bjkiais]The way normals can be calculated is by moving objects in a circle. If a ball, say, has collided with the edge of an arbitrarily shaped sprite, you can move the ball out by a radius (16 pixels works OK) and then collision test in a circle (say, at 4 degree intervals). By working out the average angle of the overlapping angles, you can calculate the approximate angle towards the surface, and inverting this gives you the normal.[/quote:8bjkiais]

ive tried something similar to this in a gear collision engine which i made (i checkerd for overlap every tick, and then once it caught one it would sping the gear using a loop and would stop spinning after it was not colliding or finished a 1 tooth increment movement), using fast loops and one problem arised, it has to be very precise to work properly, meaning it needs to check every pixel step, and it lags the system having to do all of these checks, also if something gets too far lodged into another object it would run a continuous loop
B
79
S
13
G
8
Posts: 1,977
Reputation: 9,947

» Tue Sep 09, 2008 5:13 pm

[quote="QuaziGNRLnose":p3dtl4sh]using fast loops and one problem arised, it has to be very precise to work properly, meaning it needs to check every pixel step, and it lags the system having to do all of these checks, also if something gets too far lodged into another object it would run a continuous loop[/quote:p3dtl4sh]
Yes, you have to do a lot of collision checks - doing this with the interpreted event system isn't going to be anywhere near as fast as the C++ implementation in the Construct runtime. Maybe it could be a system expression.

Still, I like the idea of all objects having an editable 'hull' - a polygon you can draw around it. Both Physics and the dynamic lighting engine need a polygon instead of a bitmap mask and it would save you entering the same polygon twice. And a 'vector' collision alternative for Sprites could actually be fairly handy, but that's less of a priority. Animated sprites would make this a little trickier though... maybe it should be in the picture editor...
Scirra Founder
B
414
S
245
G
92
Posts: 25,206
Reputation: 200,353

Previous