-
Posts
28,248 -
Joined
-
Last visited
-
Days Won
399
Content Type
Profiles
Forums
Events
Everything posted by robcat2075
-
That's for anti-aliasing. For other effects you may have to do MP. the lighting and the flickering textures do look seriously weird, but that's another battle.
-
load it into your objects folder. It's just a light with lens flare on and tweaked a bit.
-
Make your 3d models a reality cheaply.
robcat2075 replied to tbenefi33's topic in Work In Progress / Sweatbox
interesting. Eugene is a very old model from before 5-pointer and hooks and has many splines that wouldn't be necessary today. Some judicious thinning before export might improve the results. The anatomically correct teeth are probably a lot of that. -
The Sun wouldn't have any part of it shaded or in shadow. The sun is light and nothing else. You'd have to set that sphere to 100% ambient intensity. But why are you not using a lens flare? lightWithFlare.zip
-
lights themselves are not visible by the camera. You need to add a lensflare, which is really just a trick that adds the flash around the light location. Any sort of light should work. a sphere with glow may do fine also with out a light at all.
-
a "lens flare" can make that fuzzy brightness around the sun. Do a search in the help for specifics.
-
Judging from the Crazybump video, bumps made with normalmaps seem to do better at showing a raised surface occluding a lowered surface when you tilt the texture to see it at an angle, while bump maps fail at that. Do Normal maps rendered in A:M do this? Edit: I take that back, the Crazybump people are also extracting displacement maps, so I guess that is what is responsible for the good tilting effect? A:M does take lighting into account when rendering bump maps, otherwise you wouldn't see the bumps since they are suggested by shading shanges on the surface of the object.
-
Those are all good comments, particularly about how the ball moves. It immediately leaves the ground when he pulls on it then stops instantly underneath him as if the momentum of it moving backwards suddenly disappeared. You couldn't even do that with a weightless ball because your arms would at least have some momentum themselves to be accounted for. The arms could be pulled straight to show the weight they are carrying, but they never really change from the slight bend they have when he addresses the ball at the start. He does have some anticipations at the right places but the motion of the ball is undoing the appearance of effort. The basic posing is usable, but I think a more convincing heavy lift would have him squatting his butt much farther down, grasping the ball and then carrying it with him as he stood back up. (I always heard the phrase was "lift with your legs, not with your back") But the back lift could be improved with some bending of the back to show the weight of the ball pulling the shoulders down. Also he only grasps the ball on the sides as if it were a cube, which would require a lot of squeezing force from the arms and hands (not exhibited here). Better to slide the hands as far under the ball as possible to cradle it, a more natural way to control a heavy object. A heavy box presents a problem in this regard since you can't get your fingers under it initially. To do it right you'd need to tilt it to get one hand under it, then the other or quickly jerk it up and reposition the hands underneath it. Basic rule of Body Mechanics... bodies try to do things in a a manner that requires the least effort. This will look different than what is the least effort for the animator. You have to be careful that the solution you found for a motion wasn't what was easiest for you to keyframe but was what most likely for the character to do. And... the weightless foot sliding at the beginning isn't helping. This one is not nearly as weak as some other heavy lifts you can find on Youtube but it's not "heavy" yet.
-
You got your key in the email, right? email them back, explain the situation, ask if a new key would solve it, maybe it's something else entirely?
-
an example of three characters stepping and turning and anticipating and dipping their hips while they do it. post #26
-
Because it is abrupt. the motion takes off with no anticipation or even a slight easing into it. It's like a machine part that has been activated. Then it stops the same way. Suddenly. Like it hit an invisible backstop. It's also very linear. It moves directly from point A to point B. My first gambit in any hip move is to dip it in the middle. That usually works well. If it doesn't I try something else. But it usually works. and then, his other body parts are moving in lock step with the hips. For example his right arm moves rigidly with the torso which moves rigidly with the hips. Typically these things would lag a bit then catch up. This whole step-and-turn move is an advanced topic involving many "fundamentals" working in concert at once. So don't feel bad that it isn't perfect the first time out. That you recognize it isn't perfect is good.
-
Something to do with the end of daylight saving time? You may have to ask Hash to make a new key for you.
-
I always save chors, not PRJs. If you load a chor it loads all the things you need anyway. And I always save my chors with version numbers so I can go back to some previous state if I decide I've been going down a bad path for a while. Same with MDLs. I frequently save out to a new version number so i have a trail I can go back on. It's easy to swap different versions of an MDL in the Chor.
-
Since the starting point of the hose never moves, one 50% constraint will work. If you were trying to float between two moving points, two 50% constraints would probably be needed. (I think two 100% constraints would do as well) Yes. And that's why character animators spend a lot of time trying to get their characters move in a natural way, rather than float/move between poses. The floating looks odd and distracts from the performance of the character.
-
In the model the roll target null was placed at the beginning of the hose, and then"Translate To" constrained to the nozzle bone. That makes it jump all the way to the nozzle, but setting the enforcement to 50% makes it jump only half way. It probably isn't necessary but in my initial test some of the hose segments were flipping as i moved the nozzle. I wasn't sure why, but I just eliminated that entirely by making them all point their roll handles at that null. on the actual gaspump model it will probably be best to adjust the spline rings and bones on the hose so they are evenly spaced.
-
waiting for cloth to simulate is tedious, but that happens before rendering so not a rendertime issue. because it has to be antialiased yes, because objects seen in mirrors need to be rendered. not in itself. The non-multipass MB is pretty snappy although rarely it will create odd looks. MB by multipass, of course requires quite a few passes to blend together. every pass adds time. The only gain is that each pass isn't anti-aliased. I think Martin said that the regular render's AA is equivalent to a 4x4 multipass (16 passes). The regular render will almost always be faster than a 16 pass multipass render. It takes quite a few passes to exceed the anti-aliasing of the regular renderer. The main benefits of MP are more accurate motion blur and possibly more accurate Depth of field effects. very hi # multipass renders may be useful for scenes with fine details that defy good anti-aliasing with regular settings. I find a 1-pass multipass render useful for testing lighting without eating up time with anti-aliasing that I don't need to see.
-
Hmmm... could be. I think part of the problem is calculating all the details of the material, and the other part is A:M has to anti-alias all those details.
-
materials that use complex combiners (noise) can increase render times. ray-traced shadows multiple lights particle effects like hair or liquids
-
For all of you embarking on character animation (That's why you got A:M) here's an opportunity to develop your eye. A Heavy Lift that doesn't look very heavy: Lifting things is something everyone should be able to do convincingly with their characters. But some basics have been forgotten. What do you see going wrong here? You can rip this one because it's not by anyone here, and it's always easier to see the log that is in someone else's animation, which makes it even more useful.
-
The bitmap onthe ground looks like it's been stretched to almost infinity. That might be part of it. Try a higher res bitmap and see what happens.
-
Fine vulture! (I hope that's a vulture) I preferred the blue, it was more cartoony.
-
Is there a bitmap on that ground? Are the patches on that ground large or small compared to the other objects in the scene?
-
unless you have dynamic constraints on other face bones, simulating dynamics shouldn't have any effect on them. make sure the origin of the first bone in your chain isn't right on the surface of the head. It should be a little bit off.
-
possibly simpler solution: hose.mov the hose is a chain of bones with a Kinematic constraint to follow the nozzle, but they are all also Aim At Constrained to point to the "bottom target" null to make the hose always hang down. They are also all Aim Roll At constrained to "HoseRollTarget" to keep them from flipping sometimes. "HoseRollTarget" is constrained to float 50% between the two ends of the hose you animate the nozzle first, then move the "bottom target" at each keyframe to make the hang of the hose look right. All you animate is those two bones, the rest take care of themselve. more hose bones and more spline rings would make for a smoother looking hose. MDL and CHOR you can examine. hose.zip
-
on the duplication or your original head? I can't tell which one you mean is not working. only when you simulate or also just play without simulating. I'm pretty sure the simulating isn't making anything shrink