Week 16-18:
Catching up on some weeks in this blog post. Main focus has been on terrain for the environment; finishing the particulate and ashes; and getting the burned log textures to a rendering state.
Note: I did run into an issue with the Renderman servers being down for maintenance so I did not get to render this past weekend because I cannot access my license status.
Burning Log Textures:
This portion of the project I made great project on and I'm really happy with the result. With Houdini and the layering tools in the Renderman shaders, the method is simple to execute.
This is the initial result of a shader network for one of the assets:
I didn't find the render on the right bad by any means, but it needed refinement.
First thing I notice is that the burned area is a flat brown color. I want that to have more variation. To do that, I multiplied a saturated, clamped version of the diffuse map against the burned color.
I also wanted a little more break up in the glowing/burned area. I have other AO maps from lava and rock textures to mix in where I need to. I layered one of those in using a mask from a noise generated in SOPs.
The result is significantly better.
Final Result:
The great thing about the method I'm using is that the shader is dynamic. The burn_mask attribute is created using a sop solver so the mask grows with the fire. I also added a burn_glow attribute that is multiplied against the orange color to make the brightness of that ungulate to add another dynamic layer.
These calculations are not heavy and do not at to the render time.
Particulate and Ashes:
I added these lines of code to my advection wrangle to give each point a subtle sine wave motion. I calculate the distance between the original position and the current position and then multiply that against the velocity in the Y direction to ensure the points that haven't risen far and quickly receive a smaller amplitude of the sine wave.
f@dist = distance(v@P, @og_pos) * 0.1;
@dist *= v@v.y;
@dist = fit01(@dist, 0, 1);
float offset = rand(i@id * ch("seed"));
float wavex = (ch('amplitude_x') * @dist) * sin(ch('scale_x')-(ch('speed_x') * (@Time + offset)));
float wavez = (ch('amplitude_z') * @dist) * sin(ch('scale_z')-(ch('speed_z') * (@Time + offset)));
v@P.x += wavex;
v@P.z += wavez;The result looks a bit funny and very jittery with just the points, but once I retime the result a bit, drop a trail sop to calculate subframe position and connect those points with a poly line, the result is what I want. With changing the position attribute, I have recalculate the velocity attribute post-sim.
Week 19-20:
This is it! I've been focusing on rendering and rendering and more rendering to get this to the finish line. I've run into issues with getting everything rendered in time because I only have one computer.
Troubleshooting:
I will finish rendering after I get moved and rebuild my machine in California which will be sometime end of June. I will be past school so I'll be taking more time to refine and improve my project as well. There's a lot more layers I wanted to explore and still do with being responsible for the entire pipeline.
Had to start off these last two weeks with some troubleshooting. As my file has gotten bigger and the elements evolve, the renders are requiring more RAM. I ran into an issue where 60 frames of my particulate rendering chewed through about 45 GB. The render memory was being accumulated per frame.
I was lucky enough to have join Alexander Weide's Renderman for Houdini Discord (wished I had found it sooner to be honest) and also find his tutorials. I highly recommend those. He was able to point out to me that the RAM over-flush is a hbatch issue, not a Renderman issue like I had thought it was (confirmed by sidefx, had be implemented in 16.5), and then he provided me with an example of rendering using PDG to bypass this issue. hbatch is really meant for just being useful simulations where that memory is needed.
The requirement of this is that the TOP network needs to be in a separate file so the project is loaded into empty memory. If it is in the same file, Houdini is forced to deal with unnecessary data. The CPU count must also be set exactly to what you have so that each work item is run one at a item if you only have one Renderman license. Other frame will write empty or not write at all.
One snafu this does create for me is that $N will not work anymore for writing the subframe renders to be compatible with Nuke because each job will be counted as frame 1 and will continually overwrite the same file. I returned to using $F4 and then doing a batch rename using adobe bridge.
My mentor also suggested I break out my rendering into a separate file that's only reading in what I need to render because my working file is about 90MB and takes 14GB of RAM just to open. That helped a lot with loading time every time PDG ran a new houdini instance.
Rendering:
I got all the particulate rendered without much issue. There are some bokeh in the renders that are very large despite a 0.0001 pscale on the particulate because that is controlled by the f-stop on the camera which is a constant value applied to all geometry. It is not calculated on distance to the camera like how the pscale is.
Particulate frames rendered at about 5-7 minutes a frame at mostly good quality.
I rendered the flames next and I ran into times of 12 minutes a frame at low quality settings and at half resolution. I reduced the sampling further and removed in-camera effects and got the frames to 10 minutes a frame at very low quality sampling. I was confused why the time was so much higher than it used to be.
Then I comped the render on a bright pink background...
Top: what actually rendered
Right: what I thought was rendering
So this was an issue I addressed way, way back about rendering smokeless flames in Renderman. I multiplied the density by the temperature to remove density in area of zero temperature.
That for some reason got turned off and it wasn't on when I rendered. That is the result and likely the source of my increase in render time.
My goal is to rerender that and hopefully it won't take 24 hours this time for one shot because I have this turned back on.
Currently, I am rendering the smoke and that's looking to be about 7 minutes a frame.
Environment/ Rendering:
This is a test render for shot one with the lighting. I've added some cylinder lights for highlights since this render and other scattered assets including trees. I'm decently happy with the lighting. I want to add a volume atmosphere to the scene as well as some point.
Another test render for shot 4a. Again, a lot more has been added since this render and lighting has been improved.
