For a simulation project, i need to detect the edge of a costume. For this task, i use the "ray length to" block (RLB).
Sometimes, RLB is detecting an invisible edge on the right.
I've made a quick project to demonstrate the bug to you
Can you make a much simpler one that shows the bug - that's far too complex 
In this project, turn around a share and i perform a 360 degree turn on me and if ray length return something different to -1 (edge detection), i draw a red line... As you see, a false detection occurs sometime (always on the right of the sprite) (the arrow is pointing the false detection)
bug:
expected result:
bug:
expected result:
i thought that there would be some sort of pixels that are somehow detected by the sprite, but even when i checked there were just transparent pixels
(btw, 143 is also the width of the original costume so the pixels that were in contact with the cuting rectangle are just turned into invisible pixels)
Originally I thought the bug came from the "cut from" block, but now, I think the bug came from the "ray length to" block
It may be that when the rectangle cut from the shape the first time it showed a bug, it was directly adjacent to the right edge of the shape, thereby creating a microscopically thin line on the right edge.
This shape isn't cut... It's a fresh draw from the editor
that's what i thought, but there isn't any visible pixel on the edge (i checked using the (pixel of costume ) reporter)
Different color costume, 50% transparent, ray cast from the inside of the costume’s area: similar result:
But not with all costume shapes:
Every pixel of the costume at 0 offset is false positively tested as the rightmost one of the prev line. Maybe tracing line vs bounding box intersections should be slightly (+/-1) adjusted.
.
At the pixel level.
black - costume pixels
green - bounding box right edge
red - traced ray
gray - misinterpreted pixel
I've checked v9.2 but there has been no progress.
Brian, can we get some feedback if this problem gets any attention? Any pixel adjacent to the left sprite edge makes "ray length" fail.
Oops, that's a bug for sure! I've always only used ray-length inside another sprite / maze. Will investigate. Thank you!
Interesting. For some costumes it works flawlessly:
and
for others it doesn't:
especially for self-drawn ones:
it also appears to be influenced by the target sprite's tilt:
vs.
It works better i.e. not work ;), for concave shapes
Also, there are only a few pixels at the left edge that correspond to the visible anomalies
.
BTW: A shark costume (from SVG) has only blank pixels at the left edge.
on further investigation it seems that everything works fine in all my browsers unless 1) the ray is cast to the left instead of right, and 2) the target's heading is exactly 90°, and 3) the ray is cast from outside the target's bounding box. I'm almost 100% sure this happens because I suck at geometry. If you have any ideas I'd welcome any help!
sprite.bounds seem to be wrong (1px wider, higher than costume size).
For a costume 10px wide, sprite bounds - offset, should be
origin: (0,0)
corner: (height-1,width-1) => (9,9)
In the world of discrete pixels, 1px sized rectangle should have [(0,0),(0,0)] bounds
not [(0,0), (1,1)]
Make-shift test works as expected
Process.prototype.reportRayLengthTo = function (name, relativeAngle = 0) {
...
targetBounds = thatObj.bounds;
...
right = targetBounds.right()-1;
But permanent solutions (Rectangle .setWidth, .setHeight) might break other parts of the Snap
An internal cache of the rotated costume has no opaque pixels at the left edge.
There is a test project with the exact test image, created by code. Sprite has opaque black pixels exactly at the left edge and clear path to the right.
Thank you for this brilliant analysis, Dariusz!
Yes, I dimly remember having had to make bounding boxes one pixel wider in the early days because of a bug in Firefox at the time. Then, when that was fixed there used to be an issue for some years even with fractional Canvas drawings in Chrome, that also resulted in edge cases when the bounds were zero width. Geez, I'd forgotten about this!
Hmm... your make-shift patch does indeed work as expected. This is fantastic. You're also right that I'm reluctant to change the bounds computation for all morphs, as this might have unexpected downsides elsewhere. But I'll give it some testing.
Thank you!
Thank you guys