Why raycaster works with an array of objects and it doesn't work with scene.children?

I set raycaster ray from an object in the scene (not the usual mouse+camera) using:

depthRig.getWorldPosition(raystart);  
depthRig.getWorldDirection(raydir);
raydir.multiplyScalar(-1);
raycaster.set(raystart, raydir);

Then, when I pass the objects via an array, I get stable performance:

intersects = raycaster.intersectObjects( models, true );

But when I pass them via the scene:

intersects = raycaster.intersectObjects( scene.children, true );

I get a sweeping distance, that causes this effect:
raycaster_issue2

Of course, I could always use an array of objects to prevent this, but:
a) it might not be always convenient,
b) I wonder, is this a three.js raycaster issue, or there is a cure?

Iā€™m not sure what your issue is and what you mean by the sweeping distance.

Iā€™m guessing that raycasting performance is slow, if thatā€™s the case - I suggest you search the forum for words ā€œslowā€ and ā€œraycastā€ itā€™s a surprisingly popular topic with a lot of answers, including some from myself.

Spoiler: use a spatial index.

1 Like

Iā€™m not sure what your issue is and what you mean by the sweeping distance.

I thought the animated capture would clearly depict the problemā€¦

By ā€œsweeping distanceā€ I mean the returned distance by raycaster that sweeps in a sawtooth waveform style, between the intersection point (max distance) of the ray with the mesh, and the rayā€™s origin (minimum distance), which causes the ray to vary in length, as is shown clearly on the animated gif above.

You can also see in the console on the right part of the gif, the distance itself returned with the line console.log(intersects[0].distance)

So, this post is not about ā€˜slow performanceā€™, I have searched the forum, but 99.9% of the issues either refer to the classic mouse-camera case -which is not my case, or are irrelevant.

My question is very different:
Why raycaster works with an array of objects and it doesnā€™t work with scene.children?
I updated the title to this question.
Thanks.

1 Like

Nevermind, on a second thought, scanning the whole scene would be highly inefficient, so Iā€™ll keep using arrays and a spatial + model partitioning system to minimize processing time too.

That said, I think there is a three.js bug in such approaches, hiding somewhereā€¦ :ant:

1 Like

Iā€™m sure Iā€™m not a normal person, what it looked to me was a cut-out of a 2d picture of a woman, with a red line and a dot moving across the screen. On the right I saw a console with a bunch of numbers scrolling. And mysterious ā€œmax-msā€ and ā€œmin-msā€ numbers changing value. Apparently the console values were printed from line 251 of a file called ā€œscript.jsā€. To me thatā€™s too little info to answer following questions:

  • is the woman a 3d model being rendered in three.js?
  • if answer to above is ā€œyesā€, is the dot representing a 3d point?
  • is line representing direction of the ray? And if so, why does it suddenly cut off at some point?
  • if the red dot and a line represent a ray, does it actually intersect the model? Because on the image it seems to be overlaid above the model, so it seems like it never actually hits the model.
  • what are the numbers scrolling in the console?

I still donā€™t get it. You mean distance from ray origin to first(nearest) contact(hit)? Also Iā€™m not sure I understand the sawtooth reference, in signal processing world it usually refers to a triangular wave pattern, but Iā€™m not sure if thatā€™s the application here and if it is - I donā€™t understand what is X and what is Y on that graph, like for example X=displacement of ray origin along the ray direction and Y=distance from ray origin to nearest contact. I.e. I donā€™t understand the function that is being plotted.

Anyway, Iā€™m glad that you seem to have found your answer. If you still think thereā€™s a bug somewhere, maybe put together an jsfiddle or something similar to demo the issue. I know there are smarter people than me here, so even if I canā€™t help, Iā€™m sure others might, given more information.

2 Likes

LOL, weā€™ve turned a trivial thing to rocket-science! :grinning_face_with_smiling_eyes:

what it looked to me was a cut-out of a 2d picture of a woman, with a red line and a dot moving across the screen

That would be ā€¦offensive to the nature of three.js, weā€™re coding three.js here, not HTML! :grinning_face_with_smiling_eyes:
(look at ā€˜ENTER VRā€™ at the bottom).

You mean distance from ray origin to first(nearest) contact(hit)?

Yes.

Also Iā€™m not sure I understand the sawtooth reference, in signal processing world it usually refers to a triangular wave pattern, but Iā€™m not sure if thatā€™s the application here and if it is - I donā€™t understand what is X and what is Y on that graph, like for example X=displacement of ray origin along the ray direction and Y=distance from ray origin to nearest contact. I.e. I donā€™t understand the function that is being plotted.

sawtooth waveform:

sawtooth

X is time, and Y is the distance returned by raycaster that is measured between the rayā€™s origin and the rayā€™s nearest intersection point.
The issue here, is that instead of being stable with a stable ray and object, it ā€œsweepsā€ between zero (origin) and the nearest intersection according to the above waveform.
I borrowed the term from sweep generators that use a sawtooth waveform to sweep a frequency, to measure the frequency reponse of a circuit, a loudspeaker, or a room.

Anyway, Iā€™m glad that you seem to have found your answer.

Thanks!

If you still think thereā€™s a bug somewhere, maybe put together an jsfiddle or something similar to demo the issue. I know there are smarter people than me here, so even if I canā€™t help, Iā€™m sure others might, given more information.

Well, I donā€™t see much interest anywayā€¦ and in several posts Iā€™ve read, I saw that theyā€™re using arrays too.

1 Like

Usually, when one ray casts, one does not obtain negative values as the sawtooth diagram shows.

I had a similar experience in the past ā€¦ and it happened to be my bug. I casted a ray and the raycaster returned correct distance, casted again ā€¦ and the distance was shorter, ā€¦ casted again and ā€¦ the distance was more shorter ā€¦ The bug was this:

  • I drew an arrow for the ray
  • the next raycasting found intersection with the head of the arrow (instead of the object)
  • thus every next raycasting produced shorter ray ā€¦ until the back of the arrowā€™s cone became behind the ray origin
  • then the next raycast was again good.

image

For your case, Iā€™m not sure whether it is the same issue, but you could:

  • check the result of intersection ā€“ does it belong to the expected object?
  • intersect with only the objects that you want intersections (this may increase speed, especially if you have a lot of objects, that are not relevant to the intersection)

@ PavelBoytchev Thanks but this is a 2-year thread, I solved that problem 2 years agoā€¦

By ā€œbugā€ I was referring to the issue mentioned in the tittle.