[Plugin] jcw_trace (raycast)

Thanks, it is a very useful suggestion.

Here is the demo of reflecting using your plugin. (source capx)

I preserve 2 pixels space calculated in event.

It is better to have a property to set the preserved space since user might miss that, but not necessary.

I preserve 2 pixels space calculated in event.

When I said 'small distance', I meant something more along the lines of less than 0.1 units

I'll add the padding property to my mental to-do list.

I test preserved space to 0.1, it works well, too. And the result almost the same as preserved space to 2.

Thanks for your help.

Hey, great plugin. Thanks for sharing.

I made an icon you can use if you like it. icon

Great plugin!

Nice plugin. Here's a quick thought on the normal being wrong on flipped tiles. Normally the collision polygon have it's points ordered in the same way (cw or ccw). This is called winding. So when a ray hits an edge you can take the angle from one point of the segment to the other, and if the points have clockwise winding you can subtract 90 and get the normal.

Mirroring will switch the winding and so will mirroring. So if something is both flipped and mirrored the winding will be the same as they are originally. Negative sizes of sprites have the same affect as flipping and mirroring.

Roughly it would look like this, it might need to be swapped:

If mirrored xor flipped

EdgeAngle+90

Else

EdgeAngle-90

That can fail though if the user creates a collision polygon with a reversed winding. It's not common but it has happened before. I didn't handle it and instead had the user correct his collision polygon, but you can handle it in code by either checking the winding of the polygon or sampling a point on one side of the edge to know which side is inside the polygon.

As far as speed goes, the best improvement would be to do some kind of spacial partitioning of the objects you cast to. You can probably simplify the math too in areas but that may not be as significant of an improvement.

Ps.

You can also calculate the reflection angle without vector math.

ReflectAngle = 2*normal-rayAngle

Hey, great plugin. Thanks for sharing.

I made an icon you can use if you like it. icon

the 16x16 looks nice, but the larger ones look like they have been upscaled from that smaller one, and don't look as nice.

Nice plugin. Here's a quick thought on the normal being wrong on flipped tiles. Normally the collision polygon have it's points ordered in the same way (cw or ccw). This is called winding. So when a ray hits an edge you can take the angle from one point of the segment to the other, and if the points have clockwise winding you can subtract 90 and get the normal.

Mirroring will switch the winding and so will mirroring. So if something is both flipped and mirrored the winding will be the same as they are originally. Negative sizes of sprites have the same affect as flipping and mirroring.

Roughly it would look like this, it might need to be swapped:

If mirrored xor flipped

EdgeAngle+90

Else

EdgeAngle-90

That can fail though if the user creates a collision polygon with a reversed winding. It's not common but it has happened before. I didn't handle it and instead had the user correct his collision polygon, but you can handle it in code by either checking the winding of the polygon or sampling a point on one side of the edge to know which side is inside the polygon.

I am already aware of what causes it, and have been considering testing which side of the line the start point is on to fix it. But thanks anyway.

As far as speed goes, the best improvement would be to do some kind of spacial partitioning of the objects you cast to.

Isn't this what the collision cells do?

Ps.

You can also calculate the reflection angle without vector math.

ReflectAngle = 2*normal-rayAngle

Thanks! I'm gonna use this now.

Collision cells are a form of spatial partitioning. As I recall the cells are screen sized, so even when using them, your examples would still have to loop over all the objects.

I've updated the plugin again.

• Added padding property, to set how much space is left between the hit object and the result position
• Added 'Hit' condition which returns true if the last trace performed hit something.
• Fixed normal direction on flipped tiles and other polygons with alternate winding.
• Now using a simpler calculation for reflection.

The example now has an absurd reflection test on the tilemap layout.

I'm planning on adding hull traces, but I'll need to do some research on the math required for that.

Great additions

I updated the icon Icon

[ EDIT ]

Rexrainbow had problems with the icon above so here is another update

This one works for me and rexrainbow.

And I know much more about icons now.

Cheers

I've updated the plugin. If a trace starts inside of an object, the hit position will now be at the start, instead of hitting the inside of the polygon. I'm not quite sure what to do with the normal in this case, so I just set it to be opposite of the trace line. I also added a HitFrac expression, which is used internally to calculate the hit position. I find it useful for checking if the trace started inside an object, but I'm sure there are other uses for it.

Not much progress on the hull trace front. Resources on the topic are hard to find.

Hi Johncw87, this is an excellent plugin! I have come across one glitch, however - I am unable to export using minification - the minification fails as if java was not installed... If I remove the plugin then everything exports normally. Will you be able to add minification support at some stage? Thanks!!

Colludium

Of course. The one time I didn't update the example (which used the minifier), the minifier stops working.

The fix turned out to be easy, though. I had added default parameters to a Javascript function, which is apparently not yet standardized (but supported by Firefox). It would seem that the minifier didn't like this, so I took that out.

Re-download the plugin.

Awesome, Johncw87! Thank you .

Would it be possible to turn this into a behavior so different objects can store different trace results? I'm not a programmer so I have no idea how difficult that would be.