Faster Fur render - hints

[erikals]

‘Smallfoot’

https://www.cartoonbrew.com/feature...-smallfoot-a-yeti-sized-challenge-164770.html

The yetis had millions and millions of hairs, and that required a lot of rendering time. Imageworks found that once the hair density increased to a certain point, that it could take 30 minutes or more just in terms of ‘hair build time’ per frame. Sometimes it was even several hours per frame. That kind of render time was too long, and so a solution for this was also required.

“What we ended up doing instead,” detailed Karlsson, “was take the idea of our current system of calculating the camera distance from the hair but pre-baking some defined lower densities of hair which we would switch to based on the camera distance. This basically means that while we were still retaining the current system with the hair reducing in numbers as we go further away we would start at a much lower value in density.”

Things got even more complicated when there needed to be ‘hair on hair’ interaction. But Imageworks planned ahead for this. “Each clump of hair had at least one curve driving it,” said Karlsson. “This gives us enough fidelity to handle pretty much anything needed in terms of collisions. For example, Migo has over 1,500 curves being simulated on just his chest alone. The character Meechee has almost 4,000 in her shawl.”

 

[Kryslin]

I've actually noticed this in FiberFX. Maybe if I set fur density by camera distance...? I'd also have to figure out a way for clump size and count by distance to camera, too (they don't have texture inputs...)

Knowing my luck, I'd probably start a crash fest. FiberFx would crash, crashing Layout, which would probably crash Windows...

- - - Updated - - -

I've actually noticed this in FiberFX. Maybe if I set fur density by camera distance...? I'd also have to figure out a way for clump size and count by distance to camera, too (they don't have texture inputs...)

Knowing my luck, I'd probably start a crash fest. FiberFx would crash, crashing Layout, which would probably crash Windows...

 

[erikals]

Knowing my luck, I'd probably start a crash fest. FiberFx would crash, crashing Layout, which would probably crash Windows...

i've had some of these in 11.6 but suspect it is due to a too weak power supply. (perhaps)

as a sidenote, what really impressed me in Smallfoot was the Gi/Shading/Lighting

 

[Kryslin]

I can see some issues as well, what I'll call fur "rustling" as the density of the coat increases. Keeping it stable must have been one heck of a coding job.

 

[jwiede]

I've actually noticed this in FiberFX. Maybe if I set fur density by camera distance...? I'd also have to figure out a way for clump size and count by distance to camera, too (they don't have texture inputs...)

That shows a serious lack of forethought in designing the system. Regardless of whether the fiber generation can be done independent of scene-related context, it shouldn't be done that way. Hair/fur/fibers, particles, instancing/flocking, you name it, all have a very important (and very obvious) justification for having such info accessible: Controlling detail/complexity at distance is among the most obvious, fundamental and ubiquitous approaches for render performance management.

 

[Kryslin]

Trying to plug nodes into [T] buttons via the Node Editor procedural proved to be interesting... and rather futile.

While it is a fairly trivial matter to get the distance from camera, figuring out what density you need depends on...
Fiber Size, and the angle of incidence. I've run a few experiments, and while I did not get a cascade failure crash (FFX - Layout - OS), I did manage to crash layout while fiddling with the node editor procedural.

It would be nice if Newtek implemented my feature request for a return of the FFX node editor, but I have little hope.