I’m trying my first steps into Three.js and for this I have created a square shape with a square hole resulting in a simple square donut.
Now with my camera I’m looking at the center of my donut and with slider I can modify the angle so the camera position is calculated via the sin/cos calculations of the angle and the camera should arc over my donut. I was expecting that I would see all sides going over it. However when I’m at the top the camera seems to go back and not exposing the “north side” of my donut. I only see the top or “south side”.
I’m aware of the Three.js ‘ Y-up topology so my donut is in a Zup group. And as I understand my camera is moving in Y-up scene, so this may attribute to my misunderstanding but I still don’t know how.
Attached is the html with al the sources (inc sliders) and its also present in github please let me know if other information is needed.
index.html (3.7 KB)
1 Like
I see no replies so far.
I’m somewhat confused about the meaning of “top”, “bottom”, “north pole”, “south pole” of a “donut”. Also, I’m confused about what is the expected behaviour. Could you try whether this version does what you want to achieve?
https://codepen.io/boytchev/full/EaPXjXV.
dr-jerry: Nothing appears when I go to index.html, only the sliders.
I can see PavelBoytchev’s version just fine.
This is exactly what I was trying to achieve! I think I missed the camera.up.set. Leaving that from your version gives me the same behaviour as my version.
Now onto some documentation reading on camera.up.!!
Thank you!!
Stil the “camera.up” story is a bit mind bending. I’m also not sure about the calculation. I’ve done:
if (extrudeSettings.angle > 0) {
camera.up.set(0,1,0);
} else {
camera.up.set(0,-1,0)
}
Which almost works except when the angle == 0 and y-ax also has an offset (!= 3.5). Your solution with the up shifted Math.PI/2 from the camera position seems to work flawless regardless of the y-ax value. Still figuring out why!!
I also understand that .up correction is only needed for Z-up.
The up vector should never point towards the camera or away of it. It should point sideways, preferably, but not necessarily 90°.
Explanation for normal people
Imagine the up vector is a pointing hand, firmly attached to the scene. And you tilt your body so that this hand looks like pointing up. You could tilt left or right for any direction of the pointing hand … except when it points directly to you or away of you. The first three illustrations show various up directions. The fourth shows that even a small deviation of the pointing hand is sufficient to define direction. The last illustration has pointing directly to you, and there is no usable direction. (Sorry for the potential misinterpretation of the third illustration. )
Explanation for math people
The camera viewing is implemented as a matrix. All object’s vertices are multiplied by this matrix. This matrix is built from the position of the camera, the direction of looking (i.e. derived from lookAt), and the up vector. If the up vector is collinear with the direction of looking, the matrix is underdefined and its determinant is 0. As a result, the whole object that is viewed collapses into lower dimension space – a plane, a line or even a point.
Could flipping the up vector from (0,1,0) to (0,-1,0) fail?
Yes.
The first illustration shows rotating without flipping the up vector. The viewer will flip automatically.
What will happen if the up vector is flipped to point downwards? The viewer will not flip.
But in both cases if the viewer is exactly above the up vector, he or she could not see which direction the vector is pointing.
One way to resolve the issue is to have a “horizontal” up vector when the viewer is above or below. Like this:
The way I did it was to update the up vector continuously as the viewer moves.
6 Likes
Thank you! This answer deserves a reference in the documentation!
1 Like
