The following illustrates the rendering order I would like to obtain for two plane geometries:
http://jsfiddle.net/Axy2F/8/
This works fine under r58 but under r61 the red square is obscured regardless of how I structure the scene graph. I'm unclear whether this is a bug in r61, or whether I was doing things incorrectly in r58, in a way that just happened to work.
Am I right in assuming that behind.add(child) should suffice to have the red square "beneath" the indigo one in the scene graph, and therefore rendered on top of it?
If not, what is the correct way to establish the rendering order by controlling the construction of the scene graph (that works with r61)? I would like to avoid setting renderDepth explicitly. Note that setting rendered.sortObjects to false does not help.
The object that is in front is the object that is closest to the camera. Being a child has nothing to do with it.
Both your objects have position ( 0, 0, 0 ), so they are the same distance from the camera.
This will lead to z-fighting, which is worse with CanvasRenderer than it is with WebGLRenderer.
Change the position of the child to render it in front. For example,
child.position.z = 1;
FYI, r.61 has a different tie-breaker rule than r.58 did. This is why the rendering is different in r.61.
Related
In order to solve the problem of z-fighting, I limited the near and far of camera to a small range.But when I want to add a larger object,it was culled by view frustum.
I tried object3d.frustumCulled property,not working as expected,the reason is as follows:
https://github.com/mrdoob/three.js/issues/12170
So,is there a way to ensure that some specific objects are not frustum culled without changing the camera near and far? THX.
Culling doesn't mean that an object is drawn or not. It can be either drawn or not drawn depending on where it is. It is an optimization that tries to say something like this:
Hey, i have a really cheap check (plane/sphere intersection) that i can do and tell you if you need to attempt to draw this at all.
So you do a cheap check, and if the object is guaranteed to be entirely out of the frustum, you never issue the draw call. If it intersects, you have to issue a draw call, but you may still see nothing if none of the triangles are actually in the frustum.
If you download something like specter.js and inspect your draw calls, you will infact see that with frustumCulled = false you get a draw call for every object in your scene. Your screen may be empty.
I am working on a CAD type system using threejs. I have thin objects next to other objects (think thin 2mm metal sheeting fixed to posts on a building measured in metres). When I am zoomed in it all looks fine. The objects do not intersect at all. As I zoom out the objects get smaller and I end up with cases where the post object 'glimmers' (sort of shows through) the metal sheet object as I rotate it around.
I understand it's the small numbers I am working with that is causing this effect. However, is there a way to set a priority such that one object (the metal sheeting) is more important than another object (post) so it doesn't get that sort of effect?
To answer the question from the title, it is possible to prioritize drawing orders with.
myMesh.renderOrder = 5
myOtherMesh.renderOrder = 7
It is then possible to apply different depth effects, turn off the test etc.
Another way is to group objects with, layers. Set the appropriate layer mask on the camera and then render (multiple times).
myMesh.layers.set(5)
camera.layers.set(1)
renderer.render(scene,camera)
camera.layers.set(5)
renderer.render(scene,camera)
This is called z-fighting, where two fragments are so close in the given depth space that their z-values are within the margin of error that their true depths might get inverted.
The easiest way to resolve this is to reduce the scale of your depth buffer. This is controlled by the near and far properties on your camera. You'll need to play with the values to determine what works best for your senario. If you can minimize the distance between the planes, you'll have better luck avoiding z-fighting.
For example, if (as a loose estimate) the bounding sphere of your entire model has a diameter of 100, then the distance between near and far need only be 100. However, their values are set as the distance into camera space. So as you zoom out, and your camera moves further away, you should adjust the values to maintain the minimum distance between them. If your camera is at z = 100, then set near = 50 and far = 150. When you pull your camera back to z = 250, then update near = 200 and far = 300.
Another option is to use the WebGLRenderer.logarithmicDepthBuffer option. (example)
Edit: There is one other cause: the faces of the shapes are actually co-planar. If two triangles are occupying the same space, then you're all but guaranteeing z-fighting.
The simple solution is to move one of the components such that the faces are no longer co-planar. You could also potentially apply a polygonOffset to the sheet metal material, but your use-case doesn't sound like that is appropriate.
I'm learing three.js and I faced a z-fighting problem.
There are two plane object, one is blue and the other is pink.
And I set the positions using the flowing codes:
plane1.position.set(0,0,0.0001);
plane2.position.set(0,0,0);
Is there any solution in three.js to fix all the z-fighting problem in a big scene?
I ask this problem because I'm working on render a BIM(Building Information Model, which is .ifc format) on the web.
And the model itself have so much faces which are so closed to each other. And it cause so much z-fighting problems as you can see:
Is three.js provide this kind of method to solve this problem so that I can handle this z-fighting problem just using a couple of code?
Three.js has given a general solution like this:
var renderer = new THREE.WebGLRenderer({ logarithmicDepthBuffer: true });
The demo is provided also here:
https://threejs.org/examples/webgl_camera_logarithmicdepthbuffer.html
It changes the precision of depth buffer, Which generally could resolve the z-fighting problem in a distance.
At least for the planes on your screenshot, you can solve that problem without switching to the logarithmicDepthBuffer. Try to set depthWrite on the material to false for the planes. Sometimes you also have to override renderOrder for meshes.
There is an example
.depthWrite Whether rendering this material has any effect on the depth buffer. Default is true.
When drawing 2D overlays it can be useful to disable the depth writing in order to layer several things together without creating z-index artifacts.
.renderOrder This value allows the default rendering order of scene graph objects to be overridden although opaque and transparent objects remain sorted independently. When this property is set for an instance of Group, all descendants objects will be sorted and rendered together. Sorting is from lowest to highest renderOrder. Default value is 0.
What is your PerspectiveCamera's zNear and zFar set to. Try a smaller range. Like if you currently have 0.1, 100000 use 1, 1000 or something. See this answer
https://stackoverflow.com/a/21106656/128511
Or consider using a different type of depth buffer
I just stumbled across z-fighting using multiple curved planes with front and backside textures placed along the z-axis of the scene. Even though depthWrite would remove the artifacts, I kinda lost the correct visual placements of my objects in space. Flatshading did the trick for me. With enough segments, the light bouncing is perfectly fine and z-fighting is gone.
When several objects overlap on the same plane, they start to flicker. How do I tell the renderer to put one of the objects in front?
I tried to use .renderDepth, but it only works partly -
see example here: http://liveweave.com/ahTdFQ
Both boxes have the same size and it works as intended. I can change which of the boxes is visible by setting .renderDepth. But if one of the boxes is a bit smaller (say 40,50,50) the contacting layers are flickering and the render depth doesn't work anymore.
How to fix that issue?
When .renderDepth() doesn't work, you have to set the depths yourself.
Moving whole meshes around is indeed not really efficient.
What you are looking for are offsets bound to materials:
material.polygonOffset = true;
material.polygonOffsetFactor = -0.1;
should solve your issue. See update here: http://liveweave.com/syC0L4
Use negative factors to display and positive factors to hide.
Try for starters to reduce the far range on your camera. Try with 1000. Generally speaking, you shouldn't be having overlapping faces in your 3d scene, unless they are treated in a VERY specific way (look up the term 'decal textures'/'decals'). So basically, you have to create depth offsets, and perhaps even pre sort the objects when doing this, which all requires pretty low-level tinkering.
If the far range reduction helps, then you're experiencing a lack of precision (depending on the device). Also look up 'z fighting'
UPDATE
Don't overlap planes.
How do I tell the renderer to put one of the objects in front?
You put one object in front of the other :)
For example if you have a camera at 0,0,0 looking at an object at 0,0,10, if you want another object to be behind the first object put it at 0,0,11 it should work.
UPDATE2
What is z-buffering:
http://en.wikipedia.org/wiki/Z-buffering
http://msdn.microsoft.com/en-us/library/bb976071.aspx
Take note of "floating point in range of 0.0 - 1.0".
What is z-fighting:
http://en.wikipedia.org/wiki/Z-fighting
...have similar values in the z-buffer. It is particularly prevalent with
coplanar polygons, where two faces occupy essentially the same space,
with neither in front. Affected pixels are rendered with fragments
from one polygon or the other arbitrarily, in a manner determined by
the precision of the z-buffer.
"The renderer cannot reposition anything."
I think that this is completely untrue. The renderer can reposition everything, and probably does if it's not shadertoy, or some video filter or something. Every time you move your camera the renderer repositions everything (the camera is actually the only thing that DOES NOT MOVE).
It seems that you are missing some crucial concepts here, i'd start with this:
http://www.opengl-tutorial.org/beginners-tutorials/tutorial-3-matrices/
About the depth offset mentioned:
How this would work, say you want to draw a decal on a surface. You can 'draw' another mesh on this surface - by say, projecting a quad onto it. You want to draw a bullet hole over a concrete wall and end up with two coplanar surfaces - the wall, the bullet hole. You can figure out the depth buffer precision, find the smallest value, and then move the bullet hole mesh by that value towards the camera. The object does not get scaled (you're doing this in NDC which you can visualize as a cube and moving planes back and forth in the smallest possible increment), but does translate in depth direction, ending up in front of the other.
I don't see any flicker. The cube movement in 3D seems to be super-smooth. Can you try in a different computer (may be faster one)? I used Chrome on Macbook Pro.
Here is my test application inthree.js- http://zheden.elitno.net/
There are 2 cubes - green is the upper one. If you uncheck "Cube 2" (yellow inner cube), it becomes invisible. And when you rotate then camera and after rotating check back "Cube 2", it becomes outer. It reproduces not with all angles of rotation.
Adding "renderer.sortObjects = false" fixed the problem. But could you please explain me the reason of this behavior? Renderer sort objects based on their positions. Why order of rendering is changed when some object is transparent? It's position is not changed.
Is this related to Transparent textures behaviour in WebGL ?
Thanks,
Zhenya
There are no transparent objects in your demo, only opaque ones. You are changing the visibility.
WebGLRenderer sorts objects based on their distance from the camera, and renders objects in the sorted order. It renders opaque objects from front to back.
The rendering order can change due to how the sorting algorithm breaks ties when two objects are the same distance from the camera.
However, the render order is not necessarily changing when you toggle the visibility off and then on again. What can be changing is the distance to the depth buffer in the least significant digits due to roundoff when you move the camera. Hence, sometimes the second object renders, and sometimes it does not.
You have two cubes of exactly the same size and orientation in exactly the same location. Do not do that. It can cause you all sorts of rendering problems -- the most common of which, is flickering.
three.js r.58