Tore Posted September 8, 2015 Share Posted September 8, 2015 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. Quote Link to comment Share on other sites More sharing options...
Hash Fellow robcat2075 Posted September 8, 2015 Hash Fellow Share Posted September 8, 2015 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? Quote Link to comment Share on other sites More sharing options...
Tore Posted September 8, 2015 Author Share Posted September 8, 2015 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? Quote Link to comment Share on other sites More sharing options...
itsjustme Posted September 9, 2015 Share Posted September 9, 2015 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. Quote Link to comment Share on other sites More sharing options...
Tore Posted September 9, 2015 Author Share Posted September 9, 2015 Hmm...converting the dispmap to greyscale didn't make any difference for me? But thanks, David :-) Quote Link to comment Share on other sites More sharing options...
NancyGormezano Posted September 9, 2015 Share Posted September 9, 2015 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) Quote Link to comment Share on other sites More sharing options...
itsjustme Posted September 9, 2015 Share Posted September 9, 2015 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. Quote Link to comment Share on other sites More sharing options...
NancyGormezano Posted September 9, 2015 Share Posted September 9, 2015 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Tore Posted September 9, 2015 Author Share Posted September 9, 2015 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? Quote Link to comment Share on other sites More sharing options...
NancyGormezano Posted September 9, 2015 Share Posted September 9, 2015 Bug report makes sense... Quote Link to comment Share on other sites More sharing options...
itsjustme Posted September 9, 2015 Share Posted September 9, 2015 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? Quote Link to comment Share on other sites More sharing options...
Tore Posted September 9, 2015 Author Share Posted September 9, 2015 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... Quote Link to comment Share on other sites More sharing options...
itsjustme Posted September 9, 2015 Share Posted September 9, 2015 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. Quote Link to comment Share on other sites More sharing options...
Developer yoda64 Posted September 12, 2015 Developer Share Posted September 12, 2015 I'm on this , Please file a bug report . And Nancy is right , it's a numerical problem ... Quote Link to comment Share on other sites More sharing options...
Tore Posted September 13, 2015 Author Share Posted September 13, 2015 I'm on this , Please file a bug report . Done! :-) Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.