robcat2075

Here is a quick example of color map and displacement map at work...

On Saturdays from 12 Noon to 1PM Central Time I will be available on Google Meet and attempt to answer/solve/demonstrate any A:M question you may have. 1PM-2PM Eastern time 12 Noon to 1PM Central Daylight Saving Time 11AM-12 Noon Mountain time 10AM-11AM Pacific time 1700 Saturday Greenwich Mean Time (while US is on Daylight Saving Time) You will need your Google account and a microphone. You don't need a camera, I don't have one either but we can show each other what we are doing with screen sharing. To access the Google Meet, click on this link: https://meet.google.com/fzm-rhzy-dcr You will need to be signed into your Google account. Your browser may ask for permission to use your mic. If you have trouble, send me a PM. If possible, please add an avatar image to your Google account so you may appear as something other than a generic icon. Catch up with past Live Answer Times at Live Answer Time... less-live archived editions!

If the large building will be seen at distances and sizes like these shots I think the windows might be done with bump/displacement maps and color maps.

I've never seen an object drift without having been keyframed to do so, perhaps inadvertently. If you can make a sample PRJ that shows it that would be illuminating.

I would say that every workflow has limitations or impediments, on one end or the other. Slippage? You may have to explain that more.

I'm sure a mirror photo would work fine, too, since he's just using it as a reference.

I have sent reminders to all three.

When you can show it to us perhaps we can assess the possibilities better. There isn't a way to do that inside A:M. When people are talking about instancing they talking about dragging the one model into the chor many time. It would be possible with text editing and a spreadsheet to automate that process. I will note again, my series on "It Can't Be Done: Painting With Light" explains the process of text editing quite a bit.

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.