Disclaimer: complete noob to 3D programming and three.js
I'm prototyping for an eventual scene which will contain multiple walls, devices, etc... As you can see in the screenshots, the cube representing one of our devices, casts a shadow on the wall next to the cube, but the shadow also passes through the wall. The walls are set to accept shadows but not to cast shadows on purpose as the walls are displayed shorter than reality but are assumed to go to the "ceiling" and therefore should not cast shadows. Any ideas what I am doing wrong for the shadow to pass through the wall. Again I apologize for the likely trivial nature of my question, but at this point I've been looking at this for a couple days with no solution in sight. Thanks!
screenshot showing issue
another screenshot showing a different view
Related
all!
I'm currently making a game in THREE.js and while I've got the 'vertical' collision with the ground sorted with a raycaster, I am having trouble with horizontal collision. I've consulted a few tutorials, but they don't do what I want them to.
Basically, I've got a load of cubes. I've given them a random y-axis rotation and used translate to make them move 'forward' - pretty basic stuff. How do I get a raycaster to point the same direction as the cube, almost like a line sticking out of its 'nose'? i.e. how do I get a raycaster's direction to copy that of an object?
It's been a while since I've been on here, but kind regards anyway,
Matthew
When using DeviceOrientationControls, I need to allow the user to reset their view to an arbitrary direction. Basically if I'm sitting in a chair with limited range of head motion, I want to allow the camera to switch to a different direction (how I trigger that change is not important).
alphaOffsetAngle works great for resetting the view to look left, right, or behind, but not for looking up or down (or left/right, but rotated).
I tried adding offset angles for Beta and Gamma, but that isn't as straightforward as I hoped. I also tried adding the camera to an Object3D and rotating the parent. That sortof worked, but the controls got all wonky when the camera's parent was rotated.
lookAt() is pretty much what I want, but the DeviceOrientationControls update() seems to blow that away.
Does anyone have a working example of this arbitrary camera direction with the deviceorientationcontrols?
This question is similar these, but I have not found a workable solution:
Add offset to DeviceOrientationControls in three.js
and:
DeviceOrientationControls.js - Calibration to ideal starting center
I want to make a 2D game that will use 2 kinds of lights (Spotlight and Point Light). I need the game to be completly dark unless there is a light in the area and the light to not pass through walls. I tried lots of stuff and plugins to try and make this possible but nothing worked for me.
So I thought I would try to add 3D walls with an Orthographic camera so that I would have the light stop at the walls and cast shadows and make it look 2D at the same time. (Top-down View)
My questions are:
Is there a better way to do this without needing the 3D stuff?
I believe that I will probably have some performance issues if I keep the 3D stuff. Is there a way to fix that since the final output from the orthographic camera is 2D? Like maybe an option to render it as 2D and not having the game process all those triangles? (I want it as light as possible because I also want to port on phones)
I am new to unity. I have two animation in .fbx format.They can move..Now i want when both will collide with each other a sound will produce.Is there any idea how i will do this.Thanks in advance
I think you need to read about how Physics work, and then how Trigger-Events and Colission detection is handled.
Read this here, and this. The first one gives you insight on how the Unity engine works. The latter provides a video tutorial on how to do Collision Detection.
If you don't want to do that and just want the code, I found this on a quick Google:
var crashSound : AudioClip; // set this to your sound in the inspector function
OnCollisionEnter (collision : Collision) {
// next line requires an AudioSource component on this gameobject5.
audio.PlayOneShot(crashSound);
}
You can add a MeshCollider to the fbx meshes. Anyway, this is not a good idea because this will cause performance issues.
You can create an empty gameobject for each character, and add to them: the fbx animation and a simple collider (some cube, sphere, capsule, etc). Then, when you use a script for them, you attach it to the parent object and from there you handle the whole thing.
If you want that the collider moves from specific places from the animation (Like the punch movement, or a kick),then you can ask to your 3D animator/modeler to add a simple mesh on that points. For example, a sphere on one punch, which will move with the animation. Then, in Unity, you will hide the mesh of the sphere but add a mesh collider to it. :)
Hope it helps!
Most of the time, if you apply an animation to an object then you'll loose the physics reaction. Don't trust me? See here: http://www.youtube.com/watch?v=oINKQUJZc1Q
Obviously, animation are not part of Unity physics. Think about it... Unity physics decide position and rotation of objects accordingly to Newton and friends laws. How do you think these laws can accord to a keyframe arbitrary animation? They can't: hence the crazy results you get when you try.
How to solve it? Use Unity physics also for animation: learn to master rigidbody.AddForce and all the other stuff described here.
You may always want to keep the physics and the animation separated. That's how you get out of trouble.
If you really want to know: here's my personal experience on how to mediate physics with animation.
Sometimes, even binding a simple parameter to the physics and another
to an animation (or a script which mediates user input) may result in
catastrophic results. I've made a starship: rotation controller by
user mouse (by flagging "block rigidbody rotation"), direction and
speed by physics. It was inside a box collider. Imagine what happens
if a cube, orientated by a few degrees angles, meets a flat ground: it
should fall and rotate until one of the faces lays completely on the
ground. This was impossible, as I blocked any physics interaction with
the rotation of the body: as a result the box wanted to get flat on
the ground but couldn't. This tension eventually made it move forward
forever: something impossible in real world. To mediate this error,
I've made the "block rotation" parameter change dynamically according
to the user input: as the ship is moving the rotation is controlled by
the user but as soon as the user stop controlling the ship the
rotation parameter is given back to the physics engine. Another
solution would be to cast a ray down the collider, check if the ground
is near and avoid collisions if the ship is not moving (this is how
the banshee in Halo Combat Evolved is controlled, I think). When
playing videogames, always have a look at how your user input is
mediated into the physics engine: you may discover things which a
normal player normally wouldn't notice.
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