R Reynolds

Thanks, Robert.

I've discovered a render glitch in v19j1 and I need to send the entire project to Mantis. Is Consolidate sufficient or do I need to Embed All as well?

I remember going down this road with you before when I submitted my contest image. I was able to reproduce your monitor photo results almost exactly with my image also displayed beside a calibration image. But it's not like I'm going out of my way to produce dark images, it just depends on the subject matter because my lighting setup never changes. The render shows the unlit interior of a diner on a sunny day. The first attached image shows the driver of a cab (partially reflected in the diner's window) standing outside using the same sunny day lighting. Next to him is my reference white sphere. The RGB value on the sphere's surface facing the sun is 255, 255, 255 and the surrounding area somewhat saturated as I suspect it would be to your eye. The RGB value on his shadowed dark brown shoe is 11, 9, 7, so just barely visible. I chose my lighting intensities to achieve this dynamic range. All my materials' colour values are chosen by how they work when they're sitting outside in the sun next to my reference sphere. The second attachment shows the cab driver next to the calibration image on my monitor. The increased contrast comes from the imager in my cheap phone. Would you prefer to see the first Netrender image of the cab driver? As you can see, it's histogram is pretty limited as well. Perhaps I should take the monitor calibration image, decal it to a surface and render that?

Before I begin trying to find the source of this bug I'd like some opinions as to what might be happening. Attached are two "versions" of four sequential TIF files (545 through 548) from an on-going Netrender job. If there is a "b" (for bad) in the filename it is the first frame rendered by any one of the my four cores. If there is a "g" (for good) it was either not a Netrender first frame or it could be any frame rendered within A:M itself. I've numbered the files so you can sequentially show them bad, good, bad, etc. When I cycle through them on my monitor, the bad ones seem a bit darker and noisier but nothing that says "obviously this is what's wrong"; they're just poorer quality. All subsequent Netrender images are totally fine. The work-around is trivial but wastes some render time. Debug will take stripping down the choreography until this stops happening but I'm open to suggestions as what to change/remove first. 01_b0545.tif 02_g0545.tif 03_b0546.tif 04_g0546.tif 05_b0547.tif 06_g0547.tif 07_b0548.tif 08_g0548.tif

This became a good news, bad news, good news story. I successfully reproduced your example in v19e. GOOD Used the technique in a car steering project but every time the project was saved, closed and re-opened, the constraint aiming the steering bone roll handle at the null went wacky and needed repairing meaning it couldn't work using Netrender. BAD Used your technique to properly position a null under the car's front axle, then constrained a second null to translate to and orient like the front axle null, then constrained the roll handle of the steering bone to point at the second null. This always survived the project close and re-open. GOOD Thanks again for your efforts Robert.

That's wonderful Robert. Since I'm stuck at v19e (unless Steffen can solve the Enhance:AM issue) I'll have to use that v18 workaround forever. Thanks very much.

I can't supply a link because my password to the Hash server doesn't work anymore and my once-free FTP program seems to have expired. The best I can offer is this inferior quality H.264 AVC. cab_drive_by_01.mp4

Hmmm. I tried it after posting and had no problems. I it may be a codex problem. When I first started producing clips from PowerDirector using H.265 HEVC, VLC had no problem but when I tried the Windows native media player it gave an error message and a link to the Windows store to buy the new codex for something like $1.25. After the install, it was happy. I'll see what I can do.

I found that I get a slightly more believable driver response if I constrain the chest (at -50%) and skull (at +50%) to the bone that automatically aims the chassis and turns the steering wheel (see image). And about that null; for the whole rig to work it has to follow the same path as the car's model bone but stay centered between the front wheels. At present the only way I can figure out how do that is to set correctly chosen key frames for the ease of both the car and null. This is trivial if the ease timeline is a straight line from 0 to 100%. But it became trickier if the car changes speed during the chor. Can anyone suggest a way to constrain the null to the path as well as the car and keep a constant path distance between the two? cab_drive_by.mp4

To the best of my recollection there was no installation .exe for Enhance:AM. All I got were zip files containing .trb and .atx files; one of each is attached in case you can find a way to make these compatible with the new SDK. Speaking of the SDK I'm curious why a change was mandatory. Is it getting increasingly more difficult to keep A:M's code up to date? Can you foresee a time when the tools to keep A:M running just aren't available and A:M will be truly dead as a Windows program? EnhanceAM_Dirt_64.atx EnhanceAM_BlisterCombiner_64.trb

I suppose it's worth a try.

I'm moving this topic to WIP since I don't have access to the Animation Master forum. To reiterate; I've very lax in loading the latest versions and have been using 19.0e since it came out. I just installed 19.0j and upon starting AM got the error message:"Unable to load plugin" (followed by a sequential list of all the .atx and .trb files I bought from Enhance:AM) "The specified procedure could not be found". I made sure this version was looking in the correct folder.I loaded v19.0i and got the same result. I don't have ver.g or ver.h but ver.f had no problem loading them. However ver.f has a decal application crash and this is the only version that's available on the FTP, I couldn't find version f1. So I'm back to ver.e. Looking at the fixes for ver.g I see that the SDK was changed so all plug-ins need to be recompiled which explains why Enhance:AM combiners cause trouble. I'm curious as to why this was necessary. It's not like any 3rd party writing software even cares about A:M let alone recompiling something for it. By the way, you can delete the link to Enhance:AM on the 3rd party software section of the Hash website since it's dead; so no recompiling. My apologies for sounding ticked off but this new feature has made many hundreds of my materials useless. I hope the new SDK was worth it.

I've very lax in loading the latest versions and have been using 19.0e since it came out. I just installed 19.0j and upon starting AM got the error message: "Unable to load plugin" (followed by a sequential list of all the .atx and .trb files I bought from EnhanceAM) "The specified procedure could not be found". I made sure this version was looking in the correct folder. I loaded v19.0i and got the same result. I don't have ver.g or ver.h but ver.f had no problem loading them. Do I need to supply a sample EAM .atx and .trb file to determine what broke?

I just went to the store and selected Hash, Inc. Software (3). The center choice is the one I've always purchased.

Thanks for your efforts Robert. I don't think I had ever used that frame block view of a chor. After watching your experimentation I decided to start from scratch to see if I could reproduce it using a new project, chor and just the tree trunk and branch model ... and I couldn't … still had the same problem. After playing around fruitlessly with the various parameters you suggested I wondered whether my problem was related to the fact that I was using the same model as an action object in both actions. And sure enough when I made the second action with a renamed copy of the branch model, everything worked as you had shown and as I had expected in the first place. So I'll have to re-think my plan to populate a distant tree with only one branch model. Thanks again.