I am having some difficulties getting shadows both working on my meshes. I want the mesh to both receive and cast shadows, but when I turn receive on I get some strange shading issues as seen below;
The other side however is fine, looks like this;
Initially thought it was a normal issue but all the normals look fine and are as expected. I have recomputed and done a normalsNeedUpdate = true on the geometry just in case. Anyone have any ideas on how to fix, or even what the cause may be?
r71.
Related
screen_shot_showing_diagonal_lines
My THREE.js project is rendering these weird diagonal lines. I searched online and see that the issue is due to object casting shadow on itself.
While changing the shadow.bias property did help, it also created a gap between the object casting the shadow and the plane receiving the shadow ("peter-panning"). Note the directional light here is the only light source casting shadow in my scene.
this.directionalLight.shadow.bias = -0.001
I thought I might resolve this instead by changing the "castShadow" property of the ground plane meshes to false in the json file it is reading from so it will not cast shadow on itself but this doesn't seem to change anything in the rendering.
"castShadow": false,
"receiveShadow": true
I wonder if the shadow casting property is set somewhere else? or perhaps the issue is not with shadows at all (shadow.bias worked so it should be a shadows issue)? or there might be some other way to resolving this.
Thank you!
I'm having an issue where the material is not showing correctly. I checked the MTL file and all looks correct but for some reason, the material seems to be flipped(I can see it through some parts while it should be the screen). Initially I thought there was something wrong with the MTL or the OBJ but here comes the funny part. On 3dviewer.net the model looks completely perfect(last screenshot).
Therefore, does anybody have a clue on what's happening?
By default, Three.js only renders the front side of faces, since there's often no reason to render the inside of objects. The problem is that the asset you've exported has the face of the screen pointing inwards. There are two ways of solving this problem:
Open the asset in a 3D editor, flip the direction of the faces that are pointing inward, and re-export.
You could change the default material.side attribute of your material. My best guess is that: material.side = THREE.BackSide would solve your problem, but you could try the other values in that documentation page.
I am trying to render a "landscape", with three.js. Now I changed the material for the plane from MeshBasicMaterial to MeshLambertMaterial or MeshPhongMaterial and awaited to get some light effects rendered.
Strangely I see no rendering other than flat.
Can someone tell me, what I am doing wrong or what the actual requirements for Fragment rendering are?
Seems like I was missing plane.computeFaceNormals();.
I had:
plane.computeBoundingSphere();
plane.computeVertexNormals();
before and was expecting computeVertexNormals to call computeFaceNormals implicitly. Seems like this is not the case.
After changing to:
plane.computeBoundingSphere();
plane.computeFaceNormals();
plane.computeVertexNormals();
lighting works. Is there any documentation about under which circumstances the compute* functions need to be called?
And what is computeVertexNormals doing, when no face normals were generated yet?
In two cases, I have a THREE.ShaderMaterial that doesn't doesn't correctly render an object, omitting its texture.
On both examples, the middle object is a basic THREE.MeshPhongMaterial
Example1: http://jsfiddle.net/sG9MP/4/ The object that's closest to the screen never shows.
On this one, it works with renderer.render(...) but not composer.render(...).
renderer.render( scene, camera );
//composer.render();
Example2: http://jsfiddle.net/sG9MP/5/ Here I'm trying to duplicate the MeshPhongMaterial shader as a base so I can modify it. I tried to replicate it perfectly. I copied the uniform, vert, frag, and replicated what's in the object. I can't see anything different, so I don't get why it's not working the same as the standard Three.js phong shader.
So it's two cases where I'm using THREE.ShaderMaterial and it's not rendering the shader correctly, and I can't figure out why. On the second example(which is the one where I really need fixed. The first was an old test), in the webGL inspector I see the scene often looks fine until there is a "bindTexture(TEXTURE_2D, null);" call that happens under the hood by three.js. Though sometimes it just draws without it. In the first example, it's always drawing without it.
I feel like I must be missing some sort of flag in the renderer, or composer, or something. Or in my second example, where I'm trying to copy the Three.js phong shader, maybe I didn't copy something perfectly.
The goal here is just to copy the phong shader, so I can modify the uniform, vert, and frag on it. Sadly, I can't simply .clone() it since the vert and frag can't be modified after it's compiled.
It looks like while ShaderMaterial.map was being set, ShaderMaterial.uniforms.map.value was not consistently set.
I really don't understand this, though. In some cases I had issues not setting things at the top level under ShaderMaterial. Other cases I have issues not setting uniforms.
In my material, I just went and added this:
for(var k in phongMat){
if( typeof phongMat.uniforms[k] != 'undefined' ){
phongMat.uniforms[k].value = phongMat[k];
}
}
I am upgrading my application from three.js -r51 to -r57 (I got started before -r58 was released). When I did, I noticed that any of my 3D collada models that did not have in them a line like this:
<extra><technique><double_sided>1</double_sided></technique></extra>
did not render.
It appears that the polygons are being culled. If I force _gl.disable( _gl.CULL_FACE ); my model shows up as expected. But why would it cull all of my faces all of the time? (even if I had the winding order backward, I should see the other side of the object, right?)
It turns out that my parameter to setFaceCulling wasn't right. I was passing false instead of a culling mode.
With the r51 implementation, false happened to disable all culling.
With the r57 implementation, it dumped me into the new default behavior ... which is to enable culling and set it to cull both front and back faces.
So, I was able to fix it ... but I'm not sure I would have made that the default behavior. ;o)