Mystery of the day!

[Tore]

This has had me puzzled for some time. I have a scene where the camera cranes down toward an object. The frames 0 + 2-10 renders normally, but frame 1 takes ages - at first I thought that A:M had crashed, but then realized that it just rendered and rendered and rendered and rendered...even if nothing at all is in the frame.

 

The culprit seems to be the displacement on the object. If I turn of the displacement (or change it to bump) the long wait on frame one disappears.

 

But why, oh why? What is happening in frame one?? Why ONLY in frame one? And why superlong rendering in an empty frame?

 

If anyone like to take up the challenge I have attached all files here.

[robcat2075]

I'm short on time so I haven't tried it.

 

It looks like a good candidate for a bug report. "One frame in sequence doesn't render"

 

 

Just to try, what happens if you shift EVERYTHING...3 frames later? Does it still hang anywhere?

[Tore]

The scene file as it is attached here is minimized and shortened to just ten frames. The original scene is 400 frames and contains more objects, textures etc. In the original scene frame zero renders normally but from frame 1 and forward appr. 50 frames the render time increases drastically (up to 15 minuttes pr. frame). Then as the camera closes in on the figure the render time normalizes to appr. 30 seconds.

Strangely it seems that (except for frame 0) the extreme render times is when the camera turns its back against the displaced object. As the camera eventually turns around og gets the object in view, the render time drops.

Sounds kind'a weird, doesn't it?

[itsjustme]

The problem is with "sigm_krop_Default_disp.png"...since it is being used as a displacement map, it needs to be a grayscale image. Currently, this image is an RGB image and has a blue background. When I converted it to a grayscale image, the problem went away.

 

Hope that helps, Tore.

[Tore]

Hmm...converting the dispmap to greyscale didn't make any difference for me? But thanks, David :-)

[NancyGormezano]

I think the mapping for your displacement image is strange and wonder why you are using it? I substituted it for the color map just for illustration purposes to show how it is being mapped. (see 2nd image)

 

Perhaps you might want to use the ConcreteStucco image for both displacement and bump? I think it looks better, more texture. (3rd image)

 

Or even use the sigman hoved col image for displacement (50%) - see 4th image? Looks better to me.

 

As for why A:M takes so long using your original assignments? who knows? I suspect it's just a quirk in math related to camera angle and weird displacement calculations, on an extremely dense mesh. (also not sure why it has to be so dense, other than it came from another program)

[itsjustme]

Hmm...converting the dispmap to greyscale didn't make any difference for me? But thanks, David :-)

 

What I did was change the image Mode to grayscale using GIMP...I don't think just changing the blue color to gray would fix it.

 

Hope that helps, Tore.

[NancyGormezano]

 

Hmm...converting the dispmap to greyscale didn't make any difference for me? But thanks, David :-)

 

What I did was change the image Mode to grayscale using GIMP...I don't think just changing the blue color to gray would fix it.

 

Hope that helps, Tore.

 

It may help the computational error - but I've always used RGB mode images for displacement without problems. I think A:M uses the luminosity value for the computation of displacement, regardless of color.

 

However - In Tore's model, it really looks to me that the displacement image (sigm_krop_Default.png) should be part of Decal1 container (body patches) and NOT the Decal2 container (head patches). If you look at the image, it shows the body, not the head.

 

I also think what he meant to do was have nytestangular_Default_disp.bmp be the displacement image for Decal2 container (head). I've converted the .bmp to a jpg in order to upload it here (2nd image).

Edited September 9, 2015 by NancyGormezano

[Tore]

Ah, yes, sorry I have totally messed up with the assigning of the images - sorry about that! Thanks for pointing that out, Nancy! Attached is the corrected files, including 8bit displacement maps. Unfortunately it didn't make much difference. Still looooong rendertime on select frames.

I discovered that the very long rendertime even sometimes appears on some arbitrary camera angles when rotating around/zooming in on the object.

Maybe a bug report candidate as Robert suggested?

[NancyGormezano]

Bug report makes sense...

[itsjustme]

I rendered the first seventeen frames and had no problems...all at about the same amount of time. Maybe it is hardware related? Or maybe I'm using different render settings...could you post your settings, Tore?

[Tore]

David, the render settings I'm using is as set in the camera render options. But even if I turn of multi-pass, or try other render settings, the result is the same. That you had no troubles rendering it really baffles me. Wonder if someone else can replicate my slow rendering frame 1...

[itsjustme]

David, the render settings I'm using is as set in the camera render options. But even if I turn of multi-pass, or try other render settings, the result is the same. That you had no troubles rendering it really baffles me. Wonder if someone else can replicate my slow rendering frame 1...

 

I wasn't using the camera settings. Now that I'm using them, I'm getting the problem.

 

If I turn the displacement down to 3% the problem goes away. At 4% or higher it slows down again.

 

I transferred the camera render settings to the render panel and the results were the same, so I don't think there is an issue with the camera.

 

Hope that helps.

 

 

-----------------------

EDIT

-----------------------

 

I did another test render and reducing the displacement to 3% did not get rid of the problem this time. I'm thinking it's a bug now.

[yoda64]

I'm on this , Please file a bug report .

And Nancy is right , it's a numerical problem ...

[Tore]

I'm on this , Please file a bug report .

 

 

Done! :-)