I get a sweeping distance, that causes this effect:
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.
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.
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ā¦
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.
LOL, weāve turned a trivial thing to rocket-science!
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!
(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:
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.
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.
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)