New baked system for datas hair simulation issue on last frame #44711

New Issue

matthieu barbie · 2015-05-14T14:28:22+02:00

matthieu barbie commented

2015-05-14 14:28:22 +02:00

System Information
Windows 7 x64 I7 860 and two Geforce Zotac 670 GTX 4GB

Blender Version
Broken: Blender 2.74 Hash 000dfc0
Worked: (optional)

Short description of error
Send a fur animation render, all working good and fast for 249 frames and they took a long long time to compute the last frame of the simulation. On gpu, frame 249 was computed without error, at the frame 250 get the famous TdrDelay error. Tried to use CPU, same behavior on frame 250. No problem at frame 249 with CPU too, like with GPU. Only the last simulated frame take long time. Seems like, more you go to the end of the cached datas, longuer is the rendering.

Exact steps for others to reproduce the error
Go to frame 250, launch render.

Scene : https://drive.google.com/file/d/0B2ylYG5fzOLLOHdDSkR4WDFhVnM/view?usp=sharing

**System Information** Windows 7 x64 I7 860 and two Geforce Zotac 670 GTX 4GB **Blender Version** Broken: Blender 2.74 Hash 000dfc0 Worked: (optional) **Short description of error** Send a fur animation render, all working good and fast for 249 frames and they took a long long time to compute the last frame of the simulation. On gpu, frame 249 was computed without error, at the frame 250 get the famous TdrDelay error. Tried to use CPU, same behavior on frame 250. No problem at frame 249 with CPU too, like with GPU. Only the last simulated frame take long time. Seems like, more you go to the end of the cached datas, longuer is the rendering. **Exact steps for others to reproduce the error** Go to frame 250, launch render. Scene : https://drive.google.com/file/d/0B2ylYG5fzOLLOHdDSkR4WDFhVnM/view?usp=sharing

matthieu barbie commented

2015-05-14 14:28:23 +02:00

Changed status to: 'Open'

matthieu barbie commented

2015-05-14 14:28:23 +02:00

Added subscriber: @matthieubarbie

matthieu barbie commented

2015-05-15 09:11:21 +02:00

Hi,

So here, more informations about this behavior. Here the test protocol I made and the rendering time :
CPU I7 860 6 core used on 8 / 16 Gb ram

1st frame took 25min25sec - 391.99M
frame 100 took 36min18sec - 443.77M
last frame took 8h31min18sec - 443.88M

I know that the ray paths are more complex during the first frame and the last due to intersection and co in fur, but as memory is quite the same, the ray path not explode at all. And the difference between first and last frame (rendering time) is to big for the same amount of data displayed and rendered. I rendered, as I said, the first 249 frame on gpu and the time was between 8min and 20 min. The 250 cause a driver crash for gpu (solved with TdrDealy), but the computation time was 6h for information / comparaison. I ever encounter this on an other engine in production and was the Alembic cached data in cause (multiple datas for same object).

Hope can help,

Matt

Hi, So here, more informations about this behavior. Here the test protocol I made and the rendering time : CPU I7 860 6 core used on 8 / 16 Gb ram - 1st frame took 25min25sec - 391.99M - frame 100 took 36min18sec - 443.77M - last frame took 8h31min18sec - 443.88M I know that the ray paths are more complex during the first frame and the last due to intersection and co in fur, but as memory is quite the same, the ray path not explode at all. And the difference between first and last frame (rendering time) is to big for the same amount of data displayed and rendered. I rendered, as I said, the first 249 frame on gpu and the time was between 8min and 20 min. The 250 cause a driver crash for gpu (solved with TdrDealy), but the computation time was 6h for information / comparaison. I ever encounter this on an other engine in production and was the Alembic cached data in cause (multiple datas for same object). Hope can help, Matt ![FUR_SYM_100_frame_36min18sec.PNG](https://archive.blender.org/developer/F175057/FUR_SYM_100_frame_36min18sec.PNG) ![FUR_SYM_first_frame_25min25sec.PNG](https://archive.blender.org/developer/F175058/FUR_SYM_first_frame_25min25sec.PNG) ![FUR_SYM_last_frame_08h31min18sec.PNG](https://archive.blender.org/developer/F175059/FUR_SYM_last_frame_08h31min18sec.PNG)

Bastien Montagne commented

2015-05-15 12:04:27 +02:00

Added subscribers: @Sergey, @LukasTonne, @MartijnBerger, @ThomasDinges

Bastien Montagne commented

2015-05-15 12:04:45 +02:00

Added subscriber: @mont29

Bastien Montagne commented

2015-05-15 12:04:45 +02:00

Can confirm the huge slowdown on last frame…

Can confirm the *huge* slowdown on last frame…

matthieu barbie commented

2015-05-15 12:05:25 +02:00

Hi, again,

So I found the problem. It's come from alembic. Ok, with our rendering engine we used for movie, when at the last frame, the alembic cache containt no more datas for the motion blur on the last frame, the engine just trun off motion blur on the alembic file for the last frame.
Here not, so Cycles get a semi-transparent object at samples level, that explode the rendering time... and that's why also, if you looking the screenshot the frame 250, the fur seems more smooth, cause not datas for frame 251 for motion, so sampled semi-transparent fur... the "not do that on fur", semi-transparency.

Don't think is really a bug, but will be great to encode with the last frame (during the bake) a duplicate last frame for solve issue if motion blur on last frame (to have datas for sampling). Or put a line in the doc to say "hey guys, encode one more frame if you don't want issue with motion blur".

Best Regards,

Matt

Hi, again, So I found the problem. It's come from alembic. Ok, with our rendering engine we used for movie, when at the last frame, the alembic cache containt no more datas for the motion blur on the last frame, the engine just trun off motion blur on the alembic file for the last frame. Here not, so Cycles get a semi-transparent object at samples level, that explode the rendering time... and that's why also, if you looking the screenshot the frame 250, the fur seems more smooth, cause not datas for frame 251 for motion, so sampled semi-transparent fur... the "not do that on fur", semi-transparency. Don't think is really a bug, but will be great to encode with the last frame (during the bake) a duplicate last frame for solve issue if motion blur on last frame (to have datas for sampling). Or put a line in the doc to say "hey guys, encode one more frame if you don't want issue with motion blur". Best Regards, Matt

Sergey Sharybin commented

2015-05-25 20:27:01 +02:00

Changed status from 'Open' to: 'Archived'

Sergey Sharybin closed this issue

2015-05-25 20:27:01 +02:00

Sergey Sharybin self-assigned this 2015-05-25 20:27:01 +02:00

Sergey Sharybin commented

2015-05-25 20:27:01 +02:00

With the data missing at the frame physics can indeed go crazy and generate some weird and wonderful strands, making render time much slower because of permanent hit to some invalid hair. Wouldn't really consider this a bug.

As for documentation -- yes, makes sense. Do you mind re-submitting a report to #Documentation project with more clear title and description about what is to be done?

Thanks for the report, archiving this one now.

With the data missing at the frame physics can indeed go crazy and generate some weird and wonderful strands, making render time much slower because of permanent hit to some invalid hair. Wouldn't really consider this a bug. As for documentation -- yes, makes sense. Do you mind re-submitting a report to #Documentation project with more clear title and description about what is to be done? Thanks for the report, archiving this one now.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

New baked system for datas hair simulation issue on last frame #44711