I have created a terrain via a heightmap in Three.js and am using mrdoob's misc_controls_pointerlock for collision and movement. However, when I do objects.push(terrainobj); the performance goes down to about 3fps (from around 60) and there is no collision with the terrain. The collision is achieved via rays. How can I get around this?
If it's just a heightmap you could avoid using ray and do the collision checking right in the bitmap (using canvas and imagedata).
You just need to convert your XZ world position to the XY pixel in the heightmap. Then, if your Y position in the world is lower than the color vaue of the pixel then you move up the object.
Related
I'm simulating an earth using THREE.SphereGeometry with only 32x16 or 64x32 segments. It has very large flat spots several km deep. 1024x512 is nicer but not really an option. For the area I'm working in, I'd like to fill that area in with more segments so that the surface and the graphics match within centimeters.
I could use the phi and theta of SphereGeometry to define the portion I want...
But then I want to texture it. When I use the whole sphere texture for a portion, it squishes the whole image into that portion. Is there a way to just get the texture of the portion I want?
I'm new to UV mapping - are there options with that that can help?
This is more about geometry than level of detail. The LOD is very crude and I'm fine with that for now.
I have a MeshBasicMaterial which has a planegeomatry.the material is around the plane like an outline and will be green initially.i have a clock in the app.i need to reduce the length of the outline every seconds to alert user their time is running out.so the outline will flow from top of the plane clockwise fading and disappear when the time runs out.hope you get the idea.now can anyone help me how to achieve this.
One way to solve this: create a ring geometry and animate its property thetaLength using animejs or tweenjs.
Create a ring in a 3D app, that mapping coordinates that run down the length of the mesh. Then create a gradient texture, that is half black, half white, (1x256). Apply the texture to the material on the ring mesh. Animate the texture offset using animejs.
If you really want the best performance, create a procedural texture using glsl shader, and map that onto a plane.
I am trying to understand the 3D reconstruction of Object using 3D structured Lighting scanner and I am stuck at the point where a method of decoding set of camera and projector correspondences to use to reconstruct a 3D point cloud. How exactly is 3D point cloud information acquired from the information obtained from those correspondences? I want to understand the mathematical implementation, not the code implementation.
assuming you used structured light method which uses some sort of lines (vertical or horizontal - like binary coding or de-brujin) the idea is as follows:
a light plane goes through the projector perspective center and the line in the pattern.
the light plane normal needs to be rotated with the projector rotation matrix relative to the camera (or world depends on the calibration). the rotation part for the light plane can be avoided if if treat the projector perspective center as system origin.
using the correspondences you find a pixel in the image that match he light plane. now you need to define a vector that goes from the camera perspective center to the pixel in the image and then rotate this vector by the camera rotation (relative to the projector or world. again' depending on the calibration).
intersect the light plane with the found vector. how to compute that can be found in wikipedia: https://en.wikipedia.org/wiki/Line%E2%80%93plane_intersection
the mathematical problem (3d reconstruction) here is very simple as you can see. the hard part is recognizing the projected pattern in the image (easier than regular stereo but still hard) and calibrating (finding relative orientation between camera and projector).
I have been working on programming a game where everything is rendered in 3d. Though the bullets are 2d sprites. this poses a problem. I have to rotate the bullet sprite by rotating the material. This turns every bullet possessing that material rather than the individual sprite I want to turn. It is also kind of inefficient to create a new sprite clone for every bullet. is there a better way to do this? Thanks in advance.
Rotate the sprite itself instead of the texture.
edit:
as OP mentioned.. the spritematerial controls the sprites rotation.y, so setting it manually does nothing...
So instead of using the Sprite type, you could use a regular planegeometry mesh with a meshbasic material or similar, and update the matrices yourself to both keep the sprite facing the camera, and rotated toward its trajectory..
Then at least you can share the material amongst all instances.
Then the performance bottleneck becomes the number of drawcalls.. (1 per sprite)..
You can improve on that by using a single BufferGeometry, and computing the 4 screen space vertices for each sprite, each frame. This moves the bottleneck away from drawCalls, and will be limited by the speed at which you can transform vertices in javascript, which is slow but not the end of the world. This is also how many THREE.js particle systems are implemented.
The next step beyond that is to use a custom vertex shader to do the heavy vertex computation.. you still update the buffergeometry each frame, but instead of transforming verts, you're just writing the position of the sprite into each of the 4 verts, and letting the vertex shader take care of figuring out which of the 4 verts it's transforming (possibly based on the UV coordinate, or stored in one of the vertex color channels..., .r for instace) and which sprite to render from your sprite atlas (a single texture/canvas with all your sprites layed out on a grid) encoded in the .g of the vertex color..
The next step beyond that, is to not update the BufferGeometry every frame, but store both position and velocity of the sprite in the vertex data.. and only pass a time offset uniform into the vertex shader.. then the vertex shader can handle integrating the sprite position over a longer time period. This only works for sprites that have deterministic behavior, or behavior that can be derived from a texture data source like a noise texture or warping texture. Things like smoke, explosions, etc.
You can extend these techniques to draw gigantic scrolling tilemaps. I've used these techniques to make multilayer scrolling/zoomable hexmaps that were 2048 hexes square, (which is a pretty huge map)(~4m triangles). with multiple layers of sprites on top of that, at 60hz.
Here the original stemkoski particle system for reference:
http://stemkoski.github.io/Three.js/Particle-Engine.html
and:
https://stemkoski.github.io/Three.js/ParticleSystem-Dynamic.html
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.