I'm trying to use Three.js to create an ’asteroid field' using particle systems or point clouds or stuff like that. One of the problems I've bumped into with all of these is that when the camera rotates around the z axis, the particles rotate individually with the camera, preserving the same orientation no matter how the camera is turned. I want the simulation to look as if the user is flying through a bunch of asteroids, and obviously asteroids don't magically spin whenever you tilt your head, so I was wondering if there is any way to prevent them from turning when the camera turns. Must particles always be upright?
If you want to rotate sprites you can use attribute SpriteMaterial.rotation:
var sprite = new THREE.Sprite( new THREE.SpriteMaterial({map: texture,rotation: Math.PI/4}));
see this http://threejs.org/examples/webgl_sprites.html
In your case, rotation of all sprites should be equal to camera rotation.
Related
I'm using ThreeJS, but this is a general math question.
My end goal is to position an object in my scene using 2D screen space coordinates; however, I want a specific z position in the perspective projection.
As an example, I have a sphere that I want to place towards the bottom left of the screen while having the sphere be 5 units away from the camera. If the camera were to move, the sphere would maintain its perceived size and position.
I can't use an orthographic camera because the sphere needs to be able to move around in the perspective projection. At some point the sphere will be undocked from the screen and interact with the scene using physics.
I'm sure the solution is somewhere in the camera inverse matrix, however, that is beyond my abilities at the current moment.
Any help is greatly appreciated.
Thanks!
Your post includes too many questions, which is out of scope for StackOverflow. But I’ll try to answer just the main one:
Create a plane Mesh using PlaneGeometry.
Rotate it to face the camera, place it 5 units away from the camera.
Add it as a child with camera.add(plane); so whenever the camera moves, the plane moves with it.
Use a Raycaster’s .setfromCamera(cords, cam)
then
.intersectObject(plane)
method to convert x, y screen cords into an x, y, z world position where it
intersects the plane. You can read about it in the docs.
Once it’s working, make the plane invisible with visible = false
You can see the raycaster working in this official example: https://threejs.org/examples/#webgl_geometry_terrain_raycast
I'm trying to add clouds to my scene using the approach in https://codepen.io/teolitto/pen/KwOVvL, which is to make a large number of plane objects at random positions that each rotate continuously around their z axes.
But I would like to be able to move my camera, change its target, etc., and still have the cloud planes look right.
What I need to do is rotate the planes so that as the camera moves and changes target, the cloud planes stay perpendicular to the camera's axis. And I need to do this without changing the planes' rotation around their own z-axis, because otherwise that would break the cloudlike appearance.
I've tried cloudplane.lookAt(camera.position) but of course that doesn't work. It aims all of the planes at the camera, instead of making them all perpendicular to the camera axis. It also sets the object's z-axis, so the clouds don't evolve.
Any advice is appreciated. (I'm new to three.js, so if I have some of the terminology wrong, I apologize for that.)
Edit:
Setting the cloudplane's rotation.x and rotation.y to match the camera's rotation.x and rotation.y seems to get me pretty close, but it doesn't quite get there - its still possible to orbit the camera to a position where the clouds are all invisible because they're all parallel to the camera.
I want to realize a 3D interactive globe with three.js and I wonder if there is a way to intersect over Sprites primitive with the Raycaster?
If you check the source code for RayCaster at
https://github.com/mrdoob/three.js/blob/master/src/core/Raycaster.js
it would appear that the intersectObject function only checks objects that are instances of THREE.Particle or THREE.Mesh, not THREE.Sprite. Possibly this is because sprites could be set to use screen coordinates, and so a ray that projects into your 3d scene wouldn't make sense in this situation, or if placed in the scene as the sprite image always faces the camera, it doesn't act like your standard 3d mesh.
Perhaps you could attach a PlaneGeometry or a very thin CubeGeometry to the position of your sprite, set its rotation to the rotation of the camera so that it is always parallel to the view plane of the camera like the sprite is, and then check for intersections with the mesh instead?
I'm learning webgl, threejs and glsl shaders. The scene you see below is my attempt at working with instanced geometry. I have 3 patches of "grass". The grass is actually made of instanced cones around the central position of the mesh I'm building.
As you can see, if the central position (marked with a white wireframe cone) of the mesh is no longer in the camera view, all instances disappear.
How can I prevent this?
And to be even more specific: Are all the grass patches, or all fire instances, or all particles of the same time supposed to be instanced at once and place around the scene how we see fit? My assumption is that they should. Right?
If you are using InstancedBufferGeometry, there are two ways you can deal with frustum culling.
One way is to turn frustum culling off for the mesh:
mesh.frustumCulled = false;
The other option is to set the bounding sphere of the mesh's geometry manually, if it is known in your case:
geometry.boundingSphere = new THREE.Sphere( new THREE.Vector3(), radius );
three.js r.88
I want to realize a 3D interactive globe with three.js and I wonder if there is a way to intersect over Sprites primitive with the Raycaster?
If you check the source code for RayCaster at
https://github.com/mrdoob/three.js/blob/master/src/core/Raycaster.js
it would appear that the intersectObject function only checks objects that are instances of THREE.Particle or THREE.Mesh, not THREE.Sprite. Possibly this is because sprites could be set to use screen coordinates, and so a ray that projects into your 3d scene wouldn't make sense in this situation, or if placed in the scene as the sprite image always faces the camera, it doesn't act like your standard 3d mesh.
Perhaps you could attach a PlaneGeometry or a very thin CubeGeometry to the position of your sprite, set its rotation to the rotation of the camera so that it is always parallel to the view plane of the camera like the sprite is, and then check for intersections with the mesh instead?