robcat2075

HI Charles, That Option setting seems to be broken and broken back to v17 at least. So, what to do? First, If you just want three channels and no more, you want Euler, because Vector has X, Y, Z and Roll. But either way, do this: Start a new Action with your character. Set the Key Skeletal Rotations filter and Key Model filter Do Shift-Force Keyframe, this brings up an option window. Choose "In all filtered channels" and press OK. This creates rotation keys on all the bone without needing to do it manually. Those rotation keys will be all Quat. Select the first bone in the Action, then in its Properties>Object's Properties, on Rotate and choose Convert Driver To > Euler (or Vector if you really want that).... 5. Repeat step 4 for all the other bones 6. Animate your bones. They will continue with the interpolation that has been set. If you plan to make many Actions with this character, save this Action out before you animate further. You can re-use it as a starter action that has your desired interpolation method already established.

That percentage for "lifetime of the particle" refers to a percentage of the life that is set in the "Life" parameter a few lines up , "00:01:00" in the image above. A keyframe that happens at 50% will happen at 0.5 seconds in the particle's life. If you changed the particle's Life to 3 seconds, the keyframe at 50% will now happen at 1.5 seconds.

The horizontal axis is the lifetime of the particle. The vertical axis is the property being controlled, in this case the opacity.

Try this... 1 make sure Curve View is selected 2 Use the magnify tool to squeeze the top scale so that 100% is visible 3 put values into "Over Life"

Is this something all the sprites will do... be born at 100% and fade over time?

HI Tom, Eliminate the Keyframes for Opacity in "Sprite Test 1" and try keyframing 100% --> 0% for Opacity in "Sprite System" The value in the Sprite Image ("Sprite Test 1") parameters changes the opacity of sprites currently being emmitted The value in the System changes the opacity for all the particles at once. Note that if you want each particle to have a fade or change over its own life regardless of when it was emitted, that needs to be key framed in the original material.

You're not missing anything. You can't keyframe volume level changes in an A:M Chor. It has been a requested feature but it hasn't happened yet. Typically you will prepare your sound track in some dedicated editing program like Audacity and export a single file to use in A:M When I've done a shot with several wavs that I had to move around to get them synced to my animation, I'll render that out to get the rough mix out of A:M, then plop that in Audacity and use it a model to make a version with the same wav parts but with the volume levels (and other effects) I really want. I mute the original A:M wave, export my good mix from Audacity to a new Stereo wav and swap that into my A:M chor.

Here is the same test, except that the EXR maps were rendered with 1 pass instead of 4. One pass actually got a smoother progression of gradient values, even though the number of pixels in the decal is the same either way. I can't imagine what math mishap would cause the difference. But there it is.

This image compares seven different narrow grayscale gradients rendered to EXR and used as displacement maps. These results roughly align with what I've read... the precision of floating point variables decreases as the value gets farther from zero. From RGB 0 to RGB 1 the increments are so small that the stepping is nearly invisible, but from RGB 254 to RGB 255 the precision only allows a few steps. I can't explain why these have uneven steps and don't match the previous examples. Possible difference... these were shot with an orthogonal camera instead of a perspective camera... ??

This 16 bit floating point is turning out to be more complicated than I thought... An EXR rendered with a gradient from RGB 64 to RGB 65 has 16 steps instead of 8. If the gradient was 192-193, we get 2 big steps and 4 small ones...

Edit: the side discussion of displacement effects has been split off into its own topic at...

One of my false memories from childhood is the Ajax commercial with the White Knight who got your clothes "whiter than white". But it never really said that! Ajax is just "stronger than dirt."

If I render a map from the patch with a negative light on it, that creates data for blacker than black... negative numbers. Something the TGA version can't do.

I just get a blank page. Lets turn on the @Jason Simonds light!

Now this is interesting... I took the single-patch rectangle and lit it with one very bright Kleig light set to 100% width softness and rendered that with no other lights on it to a TGA and to an EXR. If you load and view those images they look like the top frame, below. It looks like the light has very quickly clipped out to full white in the middle. When I apply those as Displacement maps we get the result in the lower two frames. The TGA version on the left shows that the gray values reach "white" and go no further. But the EXR version has recorded values that surpass white and create displacement above and beyond what the TGA map could do. This shows that A:M displacement is able to interpret EXR values beyond 1.0. If we could make maps with those extra values we could probably have smoother displacement effects.

[Edit: This side discussion has been split off from topic AMC Gremlin] Investigating further... Here is a comparison of displacement effects: First with a Gradient Material set to transition from RGB 128 to RGB 129 and Displacement set to 100000% Second is that gradient rendered to a TGA and used as a Displacement map Third is that gradient rendered to an OpenEXR and used as a Displacement map The Material is able to calculate an exact value for every pixel between the 128 and the 129 levels, creating a perfectly smooth slope. The TGA map, as expected, has one stair step from 128 to 129 The EXR has 8 steps. EXR uses a 16 bit floating point format to store values, but it maps our 0-255 range for black to white to -1.0 to +1.0. From what I read about 16-bit floating point numbers, there 1024 possible values between 0 and 1 (and thus, 2048 between -1 and +1) which matches the result above , with 8 steps between our 128 and 129 gray values. So it seems that A:M is capable of rendering finer displacements, but EXR doesn't store the finer values needed. According to OpenEXR docs, EXR can have 32-bit floating point data. Maybe there is an easy way to get A:M to write those?

I recall someone on this forum getting windows 10 to work but I can't find the post

OpenGL<> OpenGL3 is on the Global Tab. In your video, I see a very brief flicker on a few of the buttons, but it doesn't seem to be slowing you down. Is it causing a problem? I always use the keyboard shortcuts for those buttons.

I'm sure what you are describing... but when I run v17 on Windows 10 it seems to operate normally for me. Perhaps try switching OpenGL<>OpenGL3 inteh Options window Or try Help>Reset Settings

That's a good one, John! The head bounce.

The CD based versions can possibly still be run with this work-around. I've only tried it on Windows 7...

If you get stuck on something, there's Live Answer Time every Saturday (see link in my sig) Of course you can ask here anytime.

That is something I've wished for for a long time. No, there isn't an easy re-fit for that. The source code would be needed and since that isn't in A:M already that must have been a third party plugin by someone. Do you know who made it? Incidentally, @Rodney and i have been learning C++ and we're about try to figure out how to write a plugin. That sounds like it might be a plausible early project.