robcat2075

Yes, it's a long series of nested lists. A list of splines defined by a lists of CPs. A list of patches with the list of CPs that make up each one. And many more It's all saved in readable ASCII text. You can load an A:M file in a text editor to see the XML tags that start and end each list. My "It can't be done: Painting with Light" has an introduction to looking at files in a text editor. A:M loads all data in RAM while you are working and doesn't revisit the hard drive until you save again. As far as I know... A:M writes the file fresh from RAM every time you save and only uses what it has in RAM while it is rendering, it doesn't reference the last version of the model on disk while it is rendering and doesn't reference the last version of the file while writing a new one. Saving before rendering is for safety, really, in case you crash during the render.

I'm surprised it works at all. Here is an example of shape ("Right Angle") modeled once , then distributed along a circular path ("Path 1") in the chor with the Multiple Models on Path plugin. Select a path inthe chor and >Plugins>Wizards>Multiple Models on Path to bring up the settings.

It is indeed possible to use a random expression to vary something multiple instances of a model. There is a thread about it and I have a sample PRJ in it. There is also a plugin in called SimpleScatter that will distribute multiple copies of a model on a selected plane, although I just tried it and it is behaving oddly. Also behaving oddly is the Multiple Models on a Path plugin , but it does exist.

Instancing, modeling parts separately, then assembling them in the chor, as noted above, are important tips. I'd be curious to see the RAM usage of your computer while you have all this loaded. Maybe even 8 GB is getting overrun and A:M has to resort to "disk swapping" which is a term you don't hear much any more.

Fun Fact: To get my nails ready for their close-up I soaked them in Palmolive liquid. Medal winners... I'm still working on the design for the medal. As always, I am paralyzed by the small details.

OK, now I see it!

I can't see it. It's in a weird codec... "LAGS" ?

I've looked at some of the new math and it's not like it's insane but it seems like they've made confusing changes to the process that have no benefit. When i was growing up I gave up asking my parents for homework help. Between my mom who couldn't help because she knew nothing about it and my dad who couldn't help because he knew everything about it... it was basically hopeless.

"Fuse" I'm sure that won't be a problem if they find that on my laptop at the airport.

Once again... wonderful work!

that looks positively reptilian!

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.