I tried to use CSS3DRenderer to transform my DIVs，but I encountered this problem.
Because CSS3DRenderer is totally based on HTML, so it just doesn't act like what WebglRenderer does.(WebglRenderer can identify Backside and FrontSide)
I did try to identify Backside or FrontSide by testing the dot product of CSS3DObject direction and camera direction.
const objectToward = object.getWorldDirection(new Vector3(0, 0, 0));
const cameraToward = base.camera.instance.getWorldDirection(new Vector3(0, 0, 0));
console.log(objectToward.dot(cameraToward))
But I found this way is still not perfect, because I am using perspective camera.
(I can still see the CSS3DObject even the directions are orthogonal, just like the picture above.)
I just need to know how to identify Backside or FrontSide even if the scene is rendered in perspective way.
There's no need to perform all the calculations you're trying. In order to hide the HTML element when it's facing away, you can simply apply the following CSS property to it:
backface-visibility: hidden;
This will automatically not render the object when its face rotates away from the camera. See here for more information on that CSS rule
Related
NOTE: It appears I oversimplified my initial question. See below for the edit.
I'm trying to combine the technique shown in the clipping/stencil example of Three.js, which uses the stencil buffer to render 'caps' when clipping geometry, with an EffectComposer-based rendering pipeline, but I am running into some difficulties. A fiddle demonstrating the problem can be found at https://jsfiddle.net/2vc76ajd/1/.
The EffectComposer has two passes: a RenderPass and a ShaderPass using CopyShader (see code below).
composer = new EffectComposer(renderer);
composer.addPass(new RenderPass(scene, camera));
var shaderPass = new ShaderPass(CopyShader);
shaderPass.enabled = false;
composer.addPass(shaderPass);
The first renders the scene as usual, the latter merely copies the rendertarget onto a fullscreen quad. If I disable the ShaderPass everything works as intended: the geometry is clipped, and cutting planes are drawn in a different color:
When the ShaderPass is enabled by clicking the 'copy pass' checkbox in the upper right, however, the entire cutting plane gets rendered, rather than just the 'caps':
Presumably there is some interaction here between offscreen render targets and stencil buffers. However, I have so far been unable to find a way to have subsequent render passes look the same as the initial render. Can anyone tell me what I am missing?
EDIT: While WestLangley's answer solved my initial problem, it unfortunately doesn't work when you're using an SSAOPass, which is what I was doing before trying to simplify the problem for the question. I have posted an updated fiddle at https://jsfiddle.net/bavL98hf/1/, which includes the proposed fix and now toggles between a RenderPass or an SSAOPass. With SSAO turned on, the result is this:
I have tried setting stencilBuffer to true on all the render targets used in SSAOPass in addition to the ones in EffectComposer, but sadly that doesn't work this time. Can anyone tell me what else I am overlooking?
I am developing a standard panorama viewer, where a 360 picture is placed inside of a sphere and the user can look around using mouse and touch. I am using OrbtialControls for this and it is working fine.
The user can also load a new 360 picture, after loading the picture, I am trying to set the camera direction so that the user is looking in a certain direction. As I am using orbitalControls, I am using control.target.set(x,y,z) to do so. However that causes the camera to lock at that point and if I use the mouse or touch to look around, the camera position changes and it revolves around that point, rather than looking around inside the sphere.
Has anyone else seen this kind of behavior? Do I need to do something
The code is pretty simple.
controls.reset();
controls.target.set(window.newLookAt.x,window.newLookAt.y,window.newLookAt.z);
The purpose of controls.target.set(x,y,z) is to set the pivot point, so what you are facing is the expected behavior
Instead of setting the target (that has to be (0, 0, 0) in your case), why not putting the camera inside a THREE.Object3D and rotate this object
var camera = new THREE.PerspectiveCamera()
var container = new THREE.Object3D()
container.add( camera )
camera.position.set( 0, 0, 0.1 )
var controls = new THREE.OrbitControls( camera, renderer )
controls.target.set( 0, 0, 0 ) // Optional
container.rotate.y = Math.PI / 2 // Or whatever you want
So I ended up solving this myself. The issue was that my understanding of orbitControls was slightly off. All I needed to do was to set the target point in the same direction but way closer to the camera and presto, issue solved and things are working fine now.
I have playing a little with clara.io and i want to reproduce an image done with it.
I have searched the web for days looking up to reproduce what they call "Realistic" rendering.
As you can see on the image the six round part have they own shadows on the (one piece) brick from multiple lights sources.
I have no idea how they done that, if it is a simple setup, or a complex shader.
the best i can do is that and i have no idea how to proceed to make and object shadowing itself depending of it's geometry.
any trails ?
actually you need:
renderer.shadowMapEnabled = true;
light.castShadow = true;
object.castShadow = true;
object.receiveShadow = true;
i know its a little counter-intuitive that both the light and the mesh have the same attribute "castShadow", but that's how it works.
also remember to check the near, far, and size of the shadow camera of your light if the shadow doesn't appear or appears incorrectly.
here is an example i made:
http://shahar.thenachts.com/threejs/examples/selfShadow.html
it takes some time to load the model (the model is the floor and walls) and it's textures, so be patient.
to see the code, right click anywhere and choose "inspect element".
ie. Actually it is a very simple setup. The THREE.Object3D has two attributes castShadow and receiveShadow You can achieve the effect you are looking for (ie. self-shadowing) by setting both to true
If you take a look at my fiddle:
http://jsfiddle.net/jmg157/Y35cQ/1/
You'll see I have grid labels on the cube axes. What I'd like to do is whenever the user rotates around the cube, have the text rotate as well so that the numbers are always facing the user.
I tried things like xMarks.rotation = camera.rotation, where xMarksare the text objects, but no success. Any suggestions would be greatly appreciated.
three.js is now quaternion-based.
To make the text created with THREE.PlaneGeometry face the camera, do this:
mesh.quaternion = camera.quaternion; // EDIT - see note below
Updated fiddle: http://jsfiddle.net/Y35cQ/2/
An alternative is to use THREE.Sprite, which always faces the camera.
three.js r.63
EDIT - mesh.quaternion = camera.quaternion; no longer works. You must use this pattern instead:
mesh.quaternion.copy( camera.quaternion );
three.js r.67
We have a model created in Blender by subtracting an extruded SVG from a “flat” base using a boolean difference operator. Or in other words, we carved a picture into it. The model renders just fine in Blender, but loading it into our simple, three.js-based web viewer (using the json exporter for Blender), we get some really odd shadows on the surface, and depending on the scale, shiny vertexes.
Here's my light and camera:
camera = window.camera = new THREE.PerspectiveCamera(45, $('main').width() / $('main').height(), 10, 10000);
loader = new THREE.JSONLoader(true);
var light = new THREE.DirectionalLight(0xffffff, 1.0);
light.position.set(-30, 30, 100);
light.target.position.set(0, 0, 0);
light.shadowCameraNear = 200;
Can anyone spot whether we did something wrong? And is that a Three-specific issue, or WebGL, or Blender, or our model?
Output (screenshot)
Fiddle
Looking at your fiddle, it seems that your vertexNormals are totally smoothed and thus shading is incorrect.
See here:
https://github.com/mrdoob/three.js/issues/1258
Does this help?
I'm not sure if this technically counts as a solution, but — worked around the problem by dropping the JSON blender export, and using P3D instead to load .stl directly.