Daniel Zimmermann


About Me

Not Specified
Not Specified


Recent Forum Posts

Houdini 16.5 on Linux (in the Cloud) April 26, 2018, 8 a.m.

Hi there,

<TLDR>Performance issues with a headless Houdini Linux install on Amazon EC2</TLDR>

I'm getting strange performance metrics from Houdini on Linux compared to Windows 10 which I cannot explain. I hope there's someone with experience running a similiar use-case to mine.

This is the situation:

Houdini 16.5.439 on Amazon Linux (Redhat EL/CentOS family) on a c5.18xlarge instance. The c5.18xlarge has 72 vCPUs (each vCPU = 1 Xeon hyperthread) and 137GB memory. This is (one of) the biggest instance type for compute intensive stuff on AWS and it's quite a monster in benchmarks.

I'm not running Houdini GUI on this machine, but hython, which I'm using to loads a HIP file and cook it (headless).
The thing is, I'm not rendering with Mantra, but cooking geometry files. This absolutely works for me and not part of the issue. The issue is the performance. I read so many good things about Houdini on Linux and expected it to at least as fast as Windows on the the same hardware.

The other machine I'm comparing to, is a single CPU Xeon E5 2620 v4 with 8 cores and 16 Hyperthreads, 64GB memory running Windows 10 Pro. From previous benchmarks, the performance should be about 50% of the C5.18xlarge for real world use-cases where you also have disk IO etc.

The thing is, that my Windows machine blows the Linux machine out of the water. It's up to 100% faster on certain tasks which are just CPU bound and involve no IO. An example is UVLayout which can run on multiple cores with 100% utilization.

There's no dedicated GPU in the cloud server and also no desktop installed except for the stuff hython expects (mesa-libGL, …). There have been strange performance issues with certain NVidia drivers for seemingly graphics unrelated actions such as cooking a node before, so that's currently my best guess but would also mean that running Houdini on a server without a GPU is not really meaningful?


P.S.: The desktop machine just ran the job twice in the time I'm writing this and the cloud server is still crunching with 72 cores each at 100% and not finished yet.

FBX import / export updates Feb. 24, 2018, 12:07 a.m.

Hey everybody,

Our FBX importer/exporter has received some updates recently in H16.5.
I'll be listing some of these here, all of these features are available in 16.5.345:


Most of the recent import updates were done on the file SOP.
When importing FBX files via the File SOP, all the objects found in the FBX file are now imported by default (unless an object is specified with # in the file path).
All the different objects transforms will be baked directly into the points, and their normals modified accordingly.
The baked transforms are added as point attributes, and a “fbx_node_name” primitive attribute is created in order to be able to identify the FBX object the geometry was created from.
The material names are also added as primitive attributes, and custom FBX properties will also be converted to primitive attributes.

Via File > Import, LOD group parameters are now imported as spare parameters. Those parameters can then used by the exporter to rebuild the LODs properly..


LODs can now be exported to FBX file.
If imported from an existing file, the spare parameters created on the LODGroup node will be used for export.
To create the LODs manually, the meshes only need to be parented to a null node named LODGroup.
The order of the different LOD meshes can be determined by their name if they are all named LODXXX, if not their parenting order will determine it. See the attached image for the minimal setup require to export those.

There is now a new option on the export dialog to disable the export of end effectors null nodes as these can be problematic in some cases. However, FBX files exported without the end effectors won't reimport properly in Houdini afterwards. (the skeleton will miss “end” bones due to the missing end effectors)

The imported custom FBX properties (available as spare parameters) are now exported.

Finally, the FBX exporter source code is now open source, and available on our GitHub:
https://github.com/sideeffects/HoudiniFBX [github.com]

Let me know if you have any questions!

Regarding custom FBX properties: How can they be created in Houdini if the import FBX does not have them. Can we create them somehow by creating spare parameters in the geo node? There's a hint about it in the LODGroup handlich, but it seems to be just a tagging marker which is when it exists is handled in a if/else of the FBXExporter.

UPDATE for others: Ok, you can create custom properties if you add a spare parm at the obj level starting with a “fbx_” prefix. The parm and value will then be written into the fbx as a custom property.

FBX import / export updates Feb. 15, 2018, 4:04 p.m.

The issue seems to be that FBX imports are not working well when the FBX has duplicate geo nodes. I have several files with the above structure and they fail to import via File –> Import FBX and also the new file option.

In the end I used the FBX SDK in a Python SOP to rename the FBX nodes to unique node names. The FBX files import now proper.

These node name collisions probably are something which should be accounted for in the FBX import/ new file functionality.