I’m a student using Maya for the first time to try make a ‘proof of concept’ for my future research work. I’m a newbie and I’ve been struggling to try figure this out, any help would be really appreciated:
I’m trying to animate an effect similar to the ‘space-time’ images you often see (fig 1). I’d like to have a plane, and when a sphere (planet) is animated over it the plane bends as shown in fig 1. I’ve gone through all the deformers in Maya and I just can’t see how to do this. I found iCollision, which can do something similar, but it's not quite right (it's more of a footprint than a curve on the plane). The soft manipulation deformer in Maya can make something like (Fig 2), which would work great, but I’m not sure if you can animate this (if I try, it just moves the apex of the deformation, not the whole deform along with the sphere). Ideally the deform ‘depth’ should be defined by the size or some other attribute of the sphere as it moves along.
Could anyone help or suggest how I can do this?
Thank you!
Fig 1
Fig 2
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
I am using blender 2.77. I wanna ask why is the upper part of my cloth is flying upwards instead of dropping down when animated? And it is also slightly deform as well when animated. But the bottom part of it is work just fine...I had tried different setting, like adjusting the gravity, self collision distance, material mass, steps, cloth collision setting and it still do not solve the problem...Anyone can give me a solution regarding this problem? thank you :)
here is the link of the image: http://i.stack.imgur.com/NHIFT.jpg 1
I made a simple cubic guy and armature for this guy in blender. Then I made some animations which are walk and 3 aim animation to use in blend tree. In blender everything looks good but when I import this animations to Unity, I realise that rotation of the arms are different. Let me show my problem with some ss. This is how the model looks in blender.
and when I import this model to Unity it looks like this :
I believe you guys can see the rotation difference between the upper arms. I couldnt find what is wrong. Anyone know what I am doing wrong ?
It's possible that the problem could be an animation keyframe setting in Blender. I would scroll through the Blender timeline on that animation and see if anything appears wrong.
Also, this Unity script could help with rotation conversion between the different coordinate systems between Blender and Unity (just in case this might be the problem): http://wiki.unity3d.com/index.php/FixBlenderImportRotation
Is there a way to determine the max / min values for height and width in the threejs coordinate system?
I'm (kinda) aware of the Frustum / Projection matrix thing, but I can't quite see the whole picture, I'd be glad if someone could illuminate me on this, with some practical example, since I'm pretty new to all this and I'm struggling a little to get my head around it.
The first think that came to my head to solve this problem was to create a mesh and use it as a dummy to detect the boundaries of the canvas, but I was wondering if it would be a more convenient way to achieve this.
Just FYI I need this for a script that should draw a 2d grid of lines, with a fixed camera.
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