robcat2075

I'm looking at it. Need to remember all the stuff.

Converting a video to an image sequence is also a useful work around.

If your CPU doesn't support SSE4 (mine doesn't) then the option will not appear. But it would be a box to check during installation.

After updating my NVidia driver i get slightly better behavior. A:M survives the switch to Bones Mode but crashes when do (T)urn. Now the computer doesn't need to be rebooted anymore, either, so that's progress!

Interesting. i can reliably create a freeze that way.

OK, I've discovered that the freeze happens if you are using OpenGL rather than OpenGL3. Try that.

I get a complete freeze when i do that. i have to press the hard reboot button on my PC.

Someone try this in v18d and tell me what happens.... -restart your computer -start A:M v18d -start a new Object window -Lathe a vase in the normal fashion -ctrl-a to select all -ctrl-c to Copy -ctrl-v to Paste -drag the still-selected copy a bit to the left -click in the background to deselect all -Press the Bones Mode button

Nice to see you back, John!

And the problem is that Steffen doesn't have a Mac with an NVidia card? that will make it harder. Is there a previous version of A:M that works correctly in these things?

I think yours are clearly new bugs and when you have time make a report on them.

Just to try... any or all of these -Options>Global switch the real-time driver. (may need restart) -Options>OpenGL switch "inverse sort order" (may need restart) -do Reset All Settings (will need restart) If those don't help then a bug report is in order. Until that can be fixed revert to the last version that worked appropriately.

If you need to get an AO appearance on bump-mapped surfaces there is a way to add it in

Here's a test Object I made in v17 with all normals facing out. When i load it in v18 it still looks right. normalsOutTest.mdl

Can you post that object (not re-saved in v18)?

v18d just went up. Try that. That's what I'm testing and i don't get a delay.

Can you post a sample model where the next step causes this lock up for you, or post a model and describe the steps that do it? I'm still not sure what the maneuver is to try it.

Fuchur, is it fixed in v18c? I can't reproduce the problem but I'm not quite sure what it looks like and I'm not on v18b

I've been meaning to do it. If anyone else has it done already, speak soon.

Here's a thing i did to investigate my multi-pass problem. The challenge is that with many passes each individual pass becomes less visible as it is averaged into the whole. I made a tiny white dot and shined a VERY bright light on it so that the average value of the white pixels + all the background color passes remained high enough to be seen. With that, I tested all the possible number of passes as it traversed a path and composited the renders together here. Most of them are correctly subdivided, but a few, like 125, 144 and 169 fall short of where they should have gotten to on the path. Others, like 196 and 256, overshoot their goal and end up with multiple passes stacked on top of each other at the very end. Eventually this will be part of an AMreport.

that's interesting Nancy. I know I've tried some combination of Displacement and Bump and it didn't work. I'll give it another go.

Those are the disease-fighting white corpuscles!

Hi Simon, Several random notes... - you can't really use Bump and Displacement on the same surface because Displacement uses "bump" shading" for its light and dark effects. If you have Displacement somewhere, you're already using "Bump" and adding the same map as a Bump map gets no additional effect. -25% displacement is typically invisible in most circumstances. i usually end up with numbers > 100 - the Thatch bitmap probably wont' be an effective Displacement maker as it is not really an elevation map where bright = high and dark =low. Also it is stretched very large so that its pixels are huge as seen by the camera. Setting the repeat higher helps a little. different views have different amounts of the dark squares, I'm not sure what causes that yet. - If you REALLY don't want to embed models in your PRJ, then it is SO much easier when you are working on a project to make a folder for it and copy the models or any other asset you need to that dedicated folder and load from there instead of loading from different directories from all over your hard drive. "Consolidate" works but it's still not easy for the end user. It is way easier to have a PRJ that either already has everything embedded OR is only looking in one simple place for things it needs. This is also easier for you later when you return to a project and may have any of many circumstances that may make paths to files not the same as they were before.

Yes, I meant to post that, it is posted now under the episode 6 link.

Other problem i notice is that the hair is jittering. I've reported that too.