cerebero-blog

[cerebero-blog]

Channel Shortcuts for Wrangles

There are some nifty shortcuts for adding spare parameters to wrangles. These greatly simplify creating ad-hoc interfaces when writing VEX snippets. In your code, type a channel function, giving the function a name, then click the action button to the right of the snippet. The correct spare parameter will be added to the Wrangle for you.

The easiest one is ch(”foo”), which creates a float parameter called “Foo”, but there are several options available. These are the available shortcuts, as of Houdini 16:

 ch("flt1");             // Float  chf("flt2");            // Float  chi("int");             // Integer  chv("vecparm");         // Vector 3  chp("quat");            // Vector 4 / Quaternion  ch3("m3");              // 3x3 Matrix  ch4("m4");              // 4x4 Matrix  chs("str");             // String  chramp("r", x);         // Spline Ramp  vector(chramp("c", x)); // RGB Ramp

Here is how they are used:

[cerebero-blog]

Light Instancing for Mantra

Instancing lights for Mantra has had some excellent optimizations in Houdini 16, specifically since build 537. This is a simple demonstration of how to instance lights, and how to read attributes from the points onto each light instance.

Instance

To instance a light across points, you can use an Instance Object. Inside, you can either generate your points, or more likely merge them from another object. Just remember to move the display/render flag from the Add SOP which is on by default, so that your points are used by the instances.

The second important point (ha!) is to use Full point instancing, and not the Fast type. Because we are changing lights, which need to go into the IFD, we have to use Full Instancing (Fast Instancing is for render-time changes).

Don’t forget to hide/turn off the original light in your scene! You can also exclude the light from the Objects list on your Mantra ROP. An instance object instancing lights won’t show up in the light lists, just the object ones, but the lights will stil work fine.

Active Radius

There is an optimziation on lights to tell Mantra when to consider a light for contributions. By turning on Active Radius, and reducing the distance to just beyond the natural falloff of your light, you can help speed up renders a fair bit.

Variety

To add variations to each light instance, beyond the standard instance/copy attributes, we use the** instancepoint()expression. If we have a point attribute called intensity, we can place this expression in our light’s Intensity parm:

point("../light_geo", instancepoint(), "intensity", 0)

You can put a similar expression to use Cd for light colors, light shapes, etc...

Rendering with Many Lights

Since 16.0.537, rendering with light instances have been optimized dramatically. This scene with 528 lights took 11m 51s (without activeradius) while in 16.0.537 the time came down to 1m 18s in 16.0.537; with active radius turned on, the times were 8m 29s and 1m 9s respectively. Sweet!

Scene files

[cerebero-blog]

Hyper-Threading

A while back I did a tiny experiment to see how hyper-threading affects performance in Houdini. The places I’ve worked at all have different opinions about HT, some have it enabled on their machines, some don’t; but I’ve been wanting to try this out and finally got the chance.

**Update** See the bottom of the thread for additional info.

The scenarios aren’t very extensive, but I tested two types of geometry cooking (VDBs, and Copy-stamped deformation), and rendering with Mantra. The tests involved an excellent scan of a dark reef crab from threedscans.

SOP Cooking

For the first SOP test, I setup a copy-stamp test where the crab model is twisted, and copied onto each point of a sphere. The sphere has 42 points, so the copy stamp does a unique twist of the crab on each point and ends up generating 44,973,810 points and 89,947,452 primitives.

The other cooking test involved VDBs. The crab is rasterized into a level set, unioned with an SDF Test Pig model, and then the resulting grid is smoothed a bit. The voxel size is 0.0015.

These two tests seemed to represent single-threaded cooking (Copy-stamped Twist) and multi-threaded cooking (VDB operations), which are both prevelant when working in Houdini.

Rendering

For the rendering test, I rendered the crab several times as a Packed Disk Primitive, around a sphere. There is an Area light (grid) and a Sphere light which has the mandril.rat as a texture.

System

The tests were run on a single socket pc, with an 8c/16t Intel E5-2670 Xeon and 16GB of DDR3 RAM. The CPU runs at 2.6Ghz, but has a Max Turbo frequency of 3.3Ghz (relevant for more single-threaded operations). The tests used Houdini 15.5.632.

To test with Hyper-Threading turned off, I rebooted to the BIOS and turned off HT manually. This was to make sure only 8 threads were being used on the 8 cores.

Results

Copy Stamp - 46.64s with HT on, 43.17s with HT off

VDB - 7.9s with HT on, 9.16s with HT off

Mantra - 78s with HT on, 110s with HT off

I wasn’t actually expecting a lot of differences, especially since these tests are quite basic, but there was a difference. It seems that thread-heavy operations do benefit from having Hyper-Threading turned on, while single-threaded operations are slightly slower. And inversely, with HT off, the single-threaded cooks were a bit faster, and the mult-threaded jobs were slightly slower.

As indicated above, these tests aren’t particularly comprehensive, but served to give an indication of how hyper-threading affects performance. It’d be interesting to take more time, and with a larger variety of systems, to see what the results would be. It would also be interesting to see how HT affects a production scene, with lots of assets, all being accessed over a network.

Personally, I keep HT turned on, but I’m glad I finally got around to testing and seeing the effects, even on very simple and contrived scenes.

Update

Jason on odForce generously shared his experiences from HT tests: http://forums.odforce.net/topic/28961-tiny-hyperthreading-experiment/#comment-164289

[cerebero-blog]

String-splitting in VEX

There are some handy new string functions in VEX; well, they’re new as of 14.0 :)

Here we use them to split up the shop_materialpath attribute on some geometry imported from Blender. We can use the split() function to split the attribute, and only use the last section of the attribute as the group name.

Here is the VEX snippet:

//Split based on '_' string bars[] = split(s@shop_materialpath, "_"); //Use last element as attribute value s@mtlGrpName = bars[-1];

Then you can use a Partition SOP to group the different sections, and then a Material SOP to apply appropriate materials to each group.

Nice and procedural! :)

Further reading and links:

Scene file: https://d.pr/samN

Vex Strings: http://www.sidefx.com/docs/houdini/vex/strings

Model: http://www.blendswap.com/blends/view/77004

[cerebero-blog]

HQueue: No licenses could be found

Recently, a situation arose where each client was properly functioning, and could see the HQ server. Each machine could also run Houdini independently, both as the normal user and the hq client user. 

However, when I submitted jobs to those machines via HQ, they would all throw an error: No licenses could be found to run this application.

After quite some time digging around and troubleshooting, the solution turned out to be pretty simple: restart hserver:

Double-check the correct license server is running with hserver -l

Kill the hserver with hserver -q

Run the hserver with hserver

For some reason, hserver still has something still pointing to the wrong license server somewhere, but that was only being found when HQ fired up the jobs. Restarting hserver did the trick!

Here are some related links:

www.sidefx.com/faq/license-management/#faq6

www.sidefx.com/faq/license-management/#faq8

http://www.sidefx.com/docs/hqueue15.5/help/faqs.html

[cerebero-blog]

Textures as RAT, HDR, and EXR

Houdini supports an image format called RAT (Random Access Texture map), designed to optimize rendering by allowing only a part (tile) of the texture map to be accessed, and not the whole image. To me, this seemed like a studio-centric feature, where hundreds of very large texture maps are being accessed all over the network by hundreds/thousands of processes. So I decided to run a small test to see if/how this could also benefit smaller productions and indie artists.

First, I did two tests (one with 4 photographs, the other with 100) involving 4 relatively high-res images, set in picture frames. These scenes compares JPG, RAT, and EXR. The second test involved an environment light using a high dynamic range image, and tests HDR, EXR, and RAT.

The images were converted from their original format using the useful iconvert utility, which ships with Houdini. The Veranda HDR came from HDRI Haven, and the Ajax model from Jotero.

These renders were done under the following setup

Houdini 15.0.347

Xeon E5-2670 2.6Ghz 

16GB Ram

Debian 8.2

1 GbE network to shared directory

4 Frames

EXR – 00:02:16, 1.89GB

JPG – 00:02:04, 2.05GB

RAT – 00:02:04, 1.66GB

EXR_alt – 00:06:39, 1.92GB (see Update below)

100 Frames

EXR – 00:07:11, 1.90GB

JPG – 00:02:29, 2.02GB

RAT – 00:02:26, 1.63GB

EXR_alt – 00:13:12, 1.92GB (see Update below)

The renders using the different texture maps were nearly identical, though the EXR version seemed to be darker/higher contrast compared to JPG/RAT. And it seems that for some reason, Mantra isn’t as efficient as EXR.

As far as I know, Mantra loads the images and converts any non-RAT format to an in-memory RAT. Maybe there was something I missed when converting the EXR? I didn’t do anything special, just iconvert original.jpg original.exr.

Based on these results, it appears the advantages of converting texture maps to RATs revolve around a higher number of objects using them in a scene. You get better memory usage, and slightly better performance.

*UPDATE* – EXR_alt

I did a bit more digging, to try and figure out why the EXR is rendering so much slower. When I converted the EXRs, I originally converted them from RAT (which came from the JPG). However, when I created an EXR directly from the JPG, the EXR file sizes were almost half as large! YES! Finally figured it out! Or so I thought; turns out, those smaller EXRs, generated from the JPGs, take almost twice as long to render! I’ve updated the render times to include the EXR_alt entry.

Environment Lighting

EXR – 00:06:03, 1.81GB

HDR – 00:05:43, 1.80GB

RAT – 00:05:41, 1.80GB

For image based lighting setups, using EXR, HDR, and RAT all produced 100% identical renders (including the rendered env light in the background). And their memory usage was almost the same too; only in render times did we see that EXR was slower than RAT and HDR.

Interesting to see RAT’s benefits, thought perhaps not as interesting as EXR being noticeably slower than the other formats. That surprised me, I expected JPG/HDR to be the least advantageous formats to use.

While these results are good and interesting, I  wonder if Houdini’s PIC format would be better? I also didn’t spend time exploring any of iconvert’s settings, and might have left out useful optimizations. And what about lots of textures on lights? What about UDIM-mapped textures? Could be interesting to look at in the future.