+1
Submitted an RFE. Hope SideFX is not sleeping away this development.
Found 15 posts.
Search results Show results as topic list.
Houdini Lounge » GLTF 2.0 file format
- rayfoundry
- 15 posts
- Offline
Technical Discussion » Manjaro Update Ruins Houdini again
- rayfoundry
- 15 posts
- Offline
HongMao
Thanks, I went for re-naming both libfreetype and zlib, since zlib errors came up with only dealing with libfreetype…
Works great!
Technical Discussion » Houdini 16.5 on Linux (in the Cloud)
- rayfoundry
- 15 posts
- Offline
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?
Cheers,
Daniel
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.
<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?
Cheers,
Daniel
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.
Edited by rayfoundry - April 26, 2018 08:02:15
Technical Discussion » FBX import / export updates
- rayfoundry
- 15 posts
- Offline
dpernuit
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:
Import
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..
Export
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.
Edited by rayfoundry - Feb. 24, 2018 00:21:57
Technical Discussion » FBX import / export updates
- rayfoundry
- 15 posts
- Offline
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.
Best,
Daniel
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.
Best,
Daniel
Technical Discussion » FBX import / export updates
- rayfoundry
- 15 posts
- Offline
Great stuff dpernuit!
I have a question regarding the # Syntax to specify the object to load from the FBX: Since node names don‘t have to be unique in a FBX file (and often aren‘t), how can we specify the correct object without using namespaces? Or can we use namespaces?
Example:
Root
——— CarA
———————— Tire
——— CarB
———————— Tire
Thanks in advance,
Daniel
I have a question regarding the # Syntax to specify the object to load from the FBX: Since node names don‘t have to be unique in a FBX file (and often aren‘t), how can we specify the correct object without using namespaces? Or can we use namespaces?
Example:
Root
——— CarA
———————— Tire
——— CarB
———————— Tire
Thanks in advance,
Daniel
Technical Discussion » Export instanced geometry with FBX
- rayfoundry
- 15 posts
- Offline
Talking to myself in this topic
I've created an issue in the FBXExport repo on github which has been open sourced recently:Issue Link [github.com]
Can someone with experience with C++ have a look there and specifically on line 529 of the ROP_FBXDerivedActions.C file?
The comment there says something about not beeing able to copy attributes with FBX, but the FBX SDK docs [autode.sk]state that it's possible with lTargetMesh->Copy(lSourceMesh) for example.
For those in doubt why this functionality could be awesome: It would reduce files sizes considerably depending on the scene structure and most important, it would allow easy GPU instancing of meshes (think trees etc.) without the need to post-process the assets in the game engine (to de-duplicate same meshes).
I've created an issue in the FBXExport repo on github which has been open sourced recently:Issue Link [github.com]
Can someone with experience with C++ have a look there and specifically on line 529 of the ROP_FBXDerivedActions.C file?
The comment there says something about not beeing able to copy attributes with FBX, but the FBX SDK docs [autode.sk]state that it's possible with lTargetMesh->Copy(lSourceMesh) for example.
For those in doubt why this functionality could be awesome: It would reduce files sizes considerably depending on the scene structure and most important, it would allow easy GPU instancing of meshes (think trees etc.) without the need to post-process the assets in the game engine (to de-duplicate same meshes).
Edited by rayfoundry - Feb. 10, 2018 15:44:25
Technical Discussion » Export instanced geometry with FBX
- rayfoundry
- 15 posts
- Offline
I just realized that there's a new version of Houdini available which changes some FBX handling. It does not solve the issue though. But they open sourced the FBX importer. https://github.com/sideeffects/HoudiniFBX [github.com]
Technical Discussion » Export instanced geometry with FBX
- rayfoundry
- 15 posts
- Offline
Enivob
I imported your FBX using Blender and Houdini and they both bring in all three cubes as meshes.
Thanks for your effort, but I'm trying to export instances via FBX Instance Mesh feature to Unity (which also supports FBX Mesh Instances). The roundtrip Houdini-FBX-Houdini is not required and the the Houdini FBX documentation does only state “Instancing” support for export, not import. So the behaviour you describe is expected.
Enivob
If I dig deeper into the FBX import I can see that the File node references the Mesh using an index (.fbx#Mesh (2)). When I export the FBX in ASCII mode I can review what is stored inside the file. I am no expert but I do only see 1 set of vertices for the entire export. This implies to me that the instancing is being written to the file correctly from Houdini. If it were not an instance, there would be a set of vertices stored in the file for each cube.
Again you shouldn't focus on roundtripping Houdini. The provided FBX file (generated in Modo) does get instanced in Unity. (3 prefabs with references to the same mesh get imported).
Enivob
You are correct that the Houdini FBX importer is not constructing instances when detected inside the FBX, but the exporter does seem to create them. Contact support@sidefx.com to report the bug.(reference this thread)
Will do, but regarding export. AFAIK import of Instance Meshes from FBX to Houdini is not supported. (See http://www.sidefx.com/docs/houdini/io/fbx.html)
EnivobSure, I've attached the FBX as ASCII. One Geometry is defined in it's ASCII text with three Meshes referencing it.
Can you export FBX from Modo in ASCII mode? Maybe compare each ASCII export in a text editor.
Edited by rayfoundry - Feb. 9, 2018 03:50:28
Technical Discussion » Export instanced geometry with FBX
- rayfoundry
- 15 posts
- Offline
Enivob
My take on reading the Houdini help is that instance will be exported as meshes, and not ignored or exported as empty nulls.
I have never heard of FBX supporting instances because instances are supported by the app that reads in or renders the FBX.
Can you post the FBX file that you exported from Modo that contains instances? What happens when you import that into Houdini? Do you get instances or meshes?
FBX does support mesh instances. It's described in the above link and it works in many DCC apps and game engines.
Edited by rayfoundry - Feb. 8, 2018 10:20:19
Technical Discussion » Export instanced geometry with FBX
- rayfoundry
- 15 posts
- Offline
Hi there,
according to the Houdini FBX documentation (http://www.sidefx.com/docs/houdini/io/fbx.html) the export function supports instances. If I export via FBX ROP and open the file in Modo or Unity, the instances are gone though and have been converted to unique mesh items.
Since FBX itself supports instances (see http://autode.sk/2Ebvr7F) and because of the above Houdini document I expected that instanced geometry will be carried through. It's not. Modo-Modo or Modo-Unity work in this regard btw.
On the Houdini side: The setup for instancing I'm using is working for alembic. Just not for FBX. If anyone wants to give it a try, I have attached a minimal example hip.
EDIT: Changed URL of documentation link
according to the Houdini FBX documentation (http://www.sidefx.com/docs/houdini/io/fbx.html) the export function supports instances. If I export via FBX ROP and open the file in Modo or Unity, the instances are gone though and have been converted to unique mesh items.
Since FBX itself supports instances (see http://autode.sk/2Ebvr7F) and because of the above Houdini document I expected that instanced geometry will be carried through. It's not. Modo-Modo or Modo-Unity work in this regard btw.
On the Houdini side: The setup for instancing I'm using is working for alembic. Just not for FBX. If anyone wants to give it a try, I have attached a minimal example hip.
EDIT: Changed URL of documentation link
Edited by rayfoundry - Feb. 8, 2018 11:01:55
Work in Progress » Instant Meshes Bridge Sop
- rayfoundry
- 15 posts
- Offline
Christopher_R
Has the overlap issue been fixed ? Instant Meshes is already part of Modo but I'd love to paint areas that I want to re-topologize manually as so those areas are deleted automatically for edge flow etc ?
Interesting. Do you have a reference (link) somewhere that they included/licensed InstantMeshes in Modo?
Technical Discussion » FBX Importer - Issue with "Import Null Nodes as Subnets"
- rayfoundry
- 15 posts
- Offline
This is still an issue for me. Can anyone please confirm if it is working for them? Thanks.
Technical Discussion » FBX Importer - Issue with "Import Null Nodes as Subnets"
- rayfoundry
- 15 posts
- Offline
Hi all,
I'm having issues with importing FBX files into Houdini recently. The option “Import Null Nodes as Subnets” ceased to work for me. I could swear that at some point (Houdini 15.0) it worked as described (as I understand it) in the documentation:
If enabled, create a separate (nested) subnet for each null you find in the FBX.
What I'm getting with the versions of Houdini I have at hand (15.5 16 16.5) is that regardless of the option enabled or disabled, I get a single subnet with the hierarchy of the FBX re-created with connected Null nodes ending at the leaf with a geometry node.
Can anyone confirm if he/she is able to import a FBX as a group of nested subnets instead?
Note: The reason why I want nested subnets is that I need to retain the transform and shape names of the original FBX within Houdini because I need to later export it again with the same hierarchy and naming. And if imported into the same subnet, node names need to be unique for Houdini which is why it is altering the node names.
Thanks all,
Daniel
I'm having issues with importing FBX files into Houdini recently. The option “Import Null Nodes as Subnets” ceased to work for me. I could swear that at some point (Houdini 15.0) it worked as described (as I understand it) in the documentation:
If enabled, create a separate (nested) subnet for each null you find in the FBX.
What I'm getting with the versions of Houdini I have at hand (15.5 16 16.5) is that regardless of the option enabled or disabled, I get a single subnet with the hierarchy of the FBX re-created with connected Null nodes ending at the leaf with a geometry node.
Can anyone confirm if he/she is able to import a FBX as a group of nested subnets instead?
Note: The reason why I want nested subnets is that I need to retain the transform and shape names of the original FBX within Houdini because I need to later export it again with the same hierarchy and naming. And if imported into the same subnet, node names need to be unique for Houdini which is why it is altering the node names.
Thanks all,
Daniel
Edited by rayfoundry - Dec. 21, 2017 07:16:12
Houdini Lounge » Poly reduce and uv's
- rayfoundry
- 15 posts
- Offline
cb
This is something we will be addressing very soon – not as a quick bug fix: as a game changer.
Cristin
Sounds great. Is this already launched as part of H16 or something to come?
-
- Quick Links