The 5 Second Lock

[Wildsided]

Hi everyone,

 

Not a complaint or a bug report, but does anyone else here know what I mean when I say the 5-second lock?

 

It doesn't matter what version of A:M I've ever used across at least 4 systems or varying specs. 32bit or 64bit. 1 light, 6 lights, no effects or a whole whack. There doesn't seem to be a particular cause. But whenever I tell A:M to render a scene with (Q) render mode one of 2 things will happen:

 

1) The scene will render over the course of however long it takes depending on the complexity of the scene or..

 

2) The counter in the bottom left of the screen will count up to 0.00.05 (occasionally 04 or 06 but mostly 05) and lock up. The program will stop responding and after a little while, it will cancel back to the unrendered choreography/model/action/pose window.

 

This happens seemingly at random but across any given session of using A:M I am guaranteed to encounter this phenomenon and I was just wondering if any of you guys have experienced the same thing or if any of the smarties know what causes it. Not because it bothers me particularly, just curious.

[robcat2075]

I haven't noticed 5 seconds, but I notice that on-screen renders only persist until the next selection/deselection event.

 

If an inadvertent click or keypress somewhere would cause something in the PWS to become selected or deselected, that event can be queued until the render is finished then process, causing the render to immediately disappear.

 

I always prefer to us Shift-Q for a progressive render as that gives me a quicker sense of things like lighting without needing to finish every pixel. These can still be accidentally restarted by errant mouse clicks.

 

Of course, a regular render to file will take no longer than a Q render and doesn't disappear like onscreen renders can.

[detbear]

I first noticed this on windows 10. It locks on both progressive and "Locked" render modes. It is very annoying,

but I have just been working around it.

 

I'm using V.18p

[Guest]

Before Win 10 when you outlined a region to do a screen render you saw just the model through the woi. Now when you draw the woi, you see a stored image of the last thing you rendered. (The first time you do this after starting A:M the woi is blank not see-thru.) I haven't written code since the last century but I believe this problem has something to do with how Win10 assigns that video memory. I can minimize this issue by keeping my woi about one quarter of the full window. If I need a larger woi I open a large view of a simple model and wait through a quick lock up which seems to assign a larger block of memory that I can use on other models. However, if I switch to any other program, I lose this block and have to re-assign it when I go back to A:M. (Lately I've been using a secondary tablet for web searches so I can leave my desktop on A:M exclusively.) One process where this doesn't work is tweaking material parameters with a large window render. I can let the entire woi finish, supposedly assigning that memory, but I select any parameter to change it and I get instant lock-up.

[Wildsided]

Robert is right of course a shift q render does give you a decent idea of what things will look like when rendered. Although it doesn't do toon lines for whatever reason.

 

Another weird quirk (which I'm sure is entirely my own fault) is that a lot of my models tell me there's a file missing when I import them. A:M doesn't identify this missing file. Just asks me to locate [blank field] then I click cancel and it loads with no issue.

[Rodney]

A:M doesn't identify this missing file.

 

This would be a useful enhancement to that dialogue (to identify the missing file's last known name and location).

Recommend submitting that to A:M Reports.

[Wildsided]

That's the thing, Rodney, usually, it says Locate xxxxxxxxx.jpg for example. But for a bunch of my models, it just asks me to locate nothing.