I have done the doubleSide rendering with depthTest off. This generate the rounded disc into my geometry I am curious to know the math behind this and why this happen.
My object is not transparent as you can see in the image Please explain about this.to me.
http://threejs.org/docs/#Reference/Materials/MeshDepthMaterial
In this example when you turn material doubleSide and turn of the depthTest you will get to know what I mean.
If you turn off depth testing then anything that is drawn later is on top of anything drawn before. Therefore if your object has parts that should be behind another part and you draw them later they will show incorrectly on top.
Related
Transparency artefact problem
Hello,
I have an issue with three.js. I import a "big" glb model on my scene which is not transparent, but if the model is covered by itself on the camera view, the foreground become transparent. (as you can see on the picture, the background montain is on foreground)
I tried some solutions like :
depthTest to false on glb material
sortOrder to false
Use logarithmicDepthBuffer
Change material transparent to false
Change alphaTest from 0 to 1 by 0.1 steps
But nothing works. If someone have the solution :)
Thank you !
Rendering of transparent objects cannot be done quite properly. You first need to render any non-transparent objects, and then render transparent surfaces from back to front, so that any new ones blend on top of what was behind it. There are a number of cases where this cannot be done, especially when rendering transparent objects that may overlap themselves.
Fixing this would involve cutting the problematic objects (even single triangles) into smaller pieces so that the ordering can be preserved, and that is often nearly impossible. Since you are working with Three.js, see if you could alter your design so that this isn't a problem, or that the artifacts of incorrect rendering order aren't too much noticeable.
Thanks to donmccurdy which have find my solution on the three.js forum.
Finally my glb file was Transparent :( So there is two solutions.
Solution 1:
Find how the model is transparent and fix it.
Solution 2:
Changing it back to opaque, and restoring the default depthWrite value.
mesh = content.getObjectByName('mesh_0');
mesh.material.transparent = false;
mesh.material.depthWrite = true;
I want to create a top down game, on which the "camera" rotates with the character (like in Tap Tap Dash). But Phaser does not implement camera rotation, so I followed this thread to create a world group, which will be rotated.
As you can see in the following screenshot, after rotating the Tilemaps (the road and the arrows) as well as the sprites (the coins), black areas occur. What is really strange is that the sprites are rendered correctly as you can see on the bottom of the screenshot, but the Tilemaps are not fully rendered.
I have tried to resize the world again and trying all kind of methods of the camera, world and layer object. But I am out of ideas. Hopefully someone can give me a hint how to approach this problem.
Thank you!
I have a quick question, may be someone will explain it to me.
The scene setup is show below. I have a sprite tree, a cube and a cubeCamera. Cube material has envMap set to cubeCamera.renderTarget. (CubeCamera is places where the cube is, and also i hide the cube before calling updateCubeMap method).
So, the question is why the sprite appears upside-down in the reflection?
This seems to happen only to sprites, other objects behave as expected.
In the actual project we manually flip sprites before updating cubeCamera, and it seems to work ok. But i want to actually know why is it so? Thanks!
UPD. Demo http://webgears.ru/public/wgdemos/spriteInEnvMap/
I'm having an issue with back faces (to the light) and shadow mapping that I can't seem to get past. I'm still at the relatively early stages of optimizing my engine, however I can't seem to get there as even with everything hand-tuned for this one piece of geometry it still looks like garbage.
What it is is a skinny wall that is "curved" via about 5 different chunks of wall. When I create my depth map I'm culling front faces (to the light). This definitely helps, but the front faces on the other side of the wall are what seem to be causing the z-fighting/projective shadowing.
Some notes on the screenshot:
Front faces are culled when the depth texture (from the light) is being drawn
I have the near and far planes tuned just for this chunk of geometry (set at 20 and 25 respectively)
One directional light source, coming down on a slight angle toward the right side of the scene, enough to indicate that wall should be shadowed, but mostly straight down
Using a ludicrously large 4096x4096 shadow map texture
All lighting is disabled, but know that I am doing soft lighting (and hence vertex normals for the vertices) even on this wall
As mentioned here it concludes you should not shadow polygons that are back faced from the light. I'm struggling with this particular issue because I don't want to pass the face normals all the way through to the fragment shader to rule out the true back faces to the light there - however if anyone feels this is the best/only solution for this geometry thats what I'll have to do. Considering how the pipeline doesn't make it easy/obvious to pass the face normals through it makes me feel like this isn't the path of least resistance. And note that the normals I am passing are the vertex normals, to allow for softer lighting effects around the edges (will likely include both non-shadowed and shadowed surfaces).
Note that I am having some nasty Perspective Aliasing, but I'm hoping my next steps are to work on cascaded shadow maps, but without fixing this I feel like I'm just delaying the inevitable as I've hand-tightened the view as best I can (or so I think).
Anyways I feel like I'm missing something, so if you have any thoughts or help at all would be most appreciated!
EDIT
To be clear, the wall technically should NOT be in shadow, based on where the light is coming from.
Below is an image with shadowing turned off. This is just using the vertex normals to calculate diffuse lighting - its not pretty (too much geometry is visible) but it does show that some of the edges are somewhat visible.
So yes, the wall SHOULD be in shadow, but I'm hoping I can get the smoothing working better so the edges can have some diffuse lighting. If I need to have it completely in shadow, then if its the shadow map that puts it in shadow, or my code specifically putting it in shadow because the face normal is away, I'm fine with that - but passing the face normal through to my vertex/fragment shader does not seem like the path of least resistance.
Perhaps these will help illustrate my problem better, or perhaps bring to light some fundamental understanding I am missing.
EDIT #2
I've included the depth texture below. You can see the wall in question in the bottom left, and from the screenshot you can see how i've trimmed the depth values to ~0.4->1. This means the depth values of that wall start in the 0.4 range. So its not PERFECTLY clipped for it, but its close. Does that seem reasonable? I'm pretty sure its a full 24 or 32 bit depth buffer, a la DEPTH_COMPONENT extension on iOS. For #starmole, does this help to determine if its a scaling error in my projection? Do you think the size/area covered of my map is too large, hence if it focuses closer it might help?
The problem seems to be that you are
Culling the front faces
Looking at the back face
Not removing the light from the back face because it's actually not lit by the normal - or there is some inaccuracy in the computation
Probably not adding some epsilon
(1) and (2) mean that there will be Z-fighting between the shadow map and the back faces.
Also, the shadow map resolution is not going to help you - just look at the wall in the shadow map, it's one pixel thick.
Recommendations:
Epsilons. Make sure that Z > lightZ + epsilon
Epsilons. Make sure that the wall is facing the light (dot of normal > epsilon) to make sure the wall is shadowed if it's very nearly orthogonal
Every technique that I've found or tried to render outline in OpenGL uses some function that is not avaliable on OpenGL ES...
Actually what I could do is set depthMask to false, draw the object as a 3 pixels wide line wireframe, reenable the depthMask and then drawing my object. It doesnt work for me because it outline only the external parts of my object, not the internals.
The following image shows two outlines, the left one is a correct outline, the right one is what I got.
So, can someone direct me to a technique that doesn't is avaliable on OpenGL ES?
Haven't done one of these for a while, but I think you're almost there! What I would recommend is this:
Keep depthMask enabled, but flip your backface culling to only render the "inside" of the object.
Draw the mesh with that shader that pushes all the verts out along their normals slightly and as a solid color (your outline color, probably black). Make sure that you're drawing solid triangles and not just GL_LINES.
Flip the backface culling back to normal again and re-render the mesh like usual.
The result is that the outlines will only be visible around the points on your mesh where the triangles start to turn away from the camera. This gives you some nice, simple outlines around things like noses, chins, lips, and other internal details.