robcat2075

Hey, Dan, I liked your trailer! I look forward to hearing reports of your book's success.

That exact look would probably need a high-end fluid simulator. If you turn that picture upside down it looks like milk being poured into water which might be the way to approach it. I have done some cloud-looking things with A:M. Go to my tutorials link and search on "Cloud". There are three cases there, two with sprites, that may be springboards for further dev.

Have you ever seen "Man of Aran"?

Here is what i recall is the conventional work-around if you need one bone to partially, less than 50%, orient like another bone as it turns up to 180° In the PRJ is a model "Orient Tester" with an action, "Action 1 Test Constraints OrientLikeDemo.prj Bone 1 is the target bone Bone 2 is 25% Orient Liked to Bone 1. It will 25% follow Bone 1 until Bone 1 reaches 90°, then begin reversing Bone 3 is 50% Orient Liked to Bone 1. It will 50% follow Bone 1 until Bone 1 reaches 180°, then flip Bone 4 is 50% Orient Liked to Bone 3. Because it is doing 50% of Bone 3, which is doing 50% of Bone 1, it is also doing 25% of what Bone 1 does , all the way up to 180° of Bone 1 rotation.

The differences in the color of the ground is interesting. That is harder to explain. And get that guy a hamburger. He looks starved!

I think a gamma adjustment could probably make any of those look more like any of the others. Also, details like light falloff and surface falloff are probably not the same by default in each program so that may account for the different result even if the lights are in the same position.

If your enforcement is less that 50% the bone will reverse to cross back across the 0° If your enforcement is greater than 50% the bone will advance to meet the target bone at 180° and pass it to continue on the other side. If you have a situation where you need an Orient Like to rigorously behave at a certain percentage over any angle, no matter how large, then an expression is probably a better choice. Bring the case to the forum and we can investigate that. But those situations rarely arise in rigging characters as there are almost no cases where a character bone will rotate more than 180°. There are no bones in a real human that do that. That reality probably informs why A:M constraints have been made to work the way they do.

Are the lights always supposed to be in the same spot? The red light looks like it is coming from completely different angles in Messiah version

I believe there is some mathematical reason for this based on the angles being regarded as positions on a circle rather than as an abstract, continuously incrementing value and... the desire (in character rigging) for that follower bone to return to 0° rotation when the target bone is back at 0° (even if the target bone has done some crazy rotation to get there) Consider that if we are a point at 0° on a circle and the target bone is rotating away from us, it is also rotating towards us because it is traveling a circle and will eventually arrive back where we are, at 0°. If we are following that bone at anything less than 100% (say 40%) there comes some point on the circle of travel when we need to stop following the bone and head back across 0° so we can start being our partial percentage of rotation... as seen on the other side. And when the target returns to 0°, we want to be there also, because in our character rigging world, 40% of 0° should be 0° rather than 40% of 360° That is my attempt to visually understand the workings of this without understanding the math of it.

Thanks, John! Have a fine T-day!

OK, so you're tryign to create a spline That's interesting. I recall Shift-clicking in the middle of a mesh, but not on the edge.

I'm not sure either. I guess it HAS been awhile since he used A:M. Ken, patches should form automatically when four sides are enclosed by splines that are not all the same spline. You must mean something different.

I don't think that will get the result the top post is aiming for.

No, it is permanently lodged in the instrument, to counter the force of the strings and bridge against the front.

Remember that game "Operation"? Trying to get a sound post in a cello is like that.

A soundpost is a wooden support that fits between the front and back of a string instrument like a cello. The exact placement of it is a mysterious art involving much trial and error. However, because the front and back are not parallel surfaces, you have to create a new sound post of a different length if you want your soundpost in a different spot. Matching the slope of the interior surfaces is also difficult. This is my vision of an adjustable length sound post that could be put anywhere. The center is a "jack screw" which has opposing threads on each side. Turning it would push or pull the two wooden parts. The ball joints at the ends are held together by magnetism. Unfortunately, about a day after I thought of this someone announced a commercial product that does much the same thing... for 500 euros! But maybe I'll make this for myself. I figure it's about $15 in parts and postage.

This isn't something that can be done in one pass... within A:M. It requires compositing of three passes... the SSS pass, the non-SSS pass and the pass that shows the greyscale SSS-intensity pass. The additional render time for the SSS-intensity pass would be negligible. If someone wants to post me a simple SSS PRJ I can show how it's done. Something with an obvious SSS case like backlit ears.

Which one do you mean? My suggestion or another?

I notice in real life we don't do a lot of mouth shaping or it tends to be rather ambiguous. For example we can make an "ee" sound with almost any mouth shape besides the Preston Blair "ee" I'm thinking the motion tends to be more important than the shapes.

One path I see is to apply the grayscale map that indicates how strong the SSS effect should be, render with that as a greyscale image (flat shaded, of course) and use that to composite a SSS render with a non-SSS render and using the greymap to control how much of the SSS render shows thru vs. the non-SSS render.

First... Welcome back to A:M, Ray! I believe there are some code examples available, like a bare bones plug-in but that may be already bundled with the SDK. Someone knowledgeable will need to chime in on that.

I'm supposed to do a quickstart modeling tutorial and I think I will mak a point to mention the period-period thing. The mystery I'd like solved is, why does it make a difference?

I'll note that this should be the period key that is pressed twice to invert and un-vert the selection. That works for most cases. Almost all. Exceptions are when there is an additional dead end spline attached to one of the selected corners or the hook situation noted above.

It was fun while it lasted.

We'll be eager to see your results when you are ready to show them.