I am generating multiple curves in Unity, and need to merge them together, and input them into my HDA. Before merging, I also need to classify the curves into different groups, as well as assigning an id primitive attribute, to identify each curve. Is this possible with the current API v2? Or would I have to create a custom Y-merge HDA, with two inputs, group and id parameters, and concatenate a string of these to merge all curves together?
In similar manner, I will also need to generate a point cloud in Unity, assign point attributes and group, and pass these into an HDA input.
Full Version: Merging Inputs
Curves are a special case because they are not a real mesh in Unity so they need to be input as a HDA. Currently only 2 types of inputs are supported via Unity plugin and those are mesh and HDAs. To use curves as input, change the input type to HDA and set the curve asset gameobject as the input.
Note that you can only supply 1 HDA input via the input field, while multiple mesh inputs can be supplied for mesh type inputs. Also for mesh type, they will have a primitive attribute named unity_input_mesh_name set with the name of the mesh they belong to.
To supply multiple curve assets (as HDA type), make the object merge's object path UI (the multiparm) as a parameter, allowing to add any number of inputs. See screenshot.
You'll have to do the groups inside your asset once you get the curves via the object merge.
For point clouds, there is no way to currently input points. You'll have to submit as mesh and just grab the points in your asset.
Note that you can only supply 1 HDA input via the input field, while multiple mesh inputs can be supplied for mesh type inputs. Also for mesh type, they will have a primitive attribute named unity_input_mesh_name set with the name of the mesh they belong to.
To supply multiple curve assets (as HDA type), make the object merge's object path UI (the multiparm) as a parameter, allowing to add any number of inputs. See screenshot.
You'll have to do the groups inside your asset once you get the curves via the object merge.
For point clouds, there is no way to currently input points. You'll have to submit as mesh and just grab the points in your asset.
Thank you for the explanation. The target HDA wouldn't know what the curve is (could be a road, a river, a zone if closed etc.) unless it is grouped and id:ed before the merge. Also, for point clouds, each point needs group and parameters. The points would go through the HDA, and be output again, possibly modified. A point could be e.g. an object in a game, that could e.g. be snapped to a terrain, and then, handed back to a instancer in the game. The instancer would need to know things like the id. I know the Houdini Engine can do instancing as well, but in the end, each game is unique, and will likely have to implement their own instancers. As a core feature, I think being able to pass in and pull out point clouds, curves etc. are most important, while out-of-the-box terrains with instancing etc. might be convenient for getting up and running quickly, but will become too limited eventually.
How would you want to supply point clouds into an HDA since Unity doesn't support standalone points as a geometry type. The input data structure would have to be a custom format specific to the plugin. Where is the point cloud data coming from initially and how is it handled by Unity?
Note that you can edit points attributes directly currently by making the node editable. See https://www.sidefx.com/docs/unity/_painting_editing.html#PaintingEditing_Editing [www.sidefx.com]
I've added an RFE to add support for Curve inputs.
Note that you can edit points attributes directly currently by making the node editable. See https://www.sidefx.com/docs/unity/_painting_editing.html#PaintingEditing_Editing [www.sidefx.com]
I've added an RFE to add support for Curve inputs.
The Houdini application itself is very elegant and clever about giving the user full control, through things like VEX and VOP. I think that is what I am missing on the Unity side. A low level API that allows you to call e.g. addpoint() to add a point. If the API was similar to VEX, it would be very easy to learn. Both C# and VEX are C-like languages, so with the same naming, one could almost copy paste from VEX code. Then I just need to call addpoint(), addpointattrib() etc. when I generate my points in Unity.
(I think my workaround for now will be to write a geo file exporter, write the geometry to a temp file, and then load it in my HDA using a file cache node.)
(I think my workaround for now will be to write a geo file exporter, write the geometry to a temp file, and then load it in my HDA using a file cache node.)
While the Unity plugin doesn't currently directly allow to submit point clouds (mainly because Unity doesn't support these natively yet), you can write your own C# script to do so using the plugin's imported HAPI functions, found in Assets/Plugins/HoudiniEngineUnity/Scripts/HAPI/HEU_HAPIImports.cs
Here is documentation on getting point clouds into Houdini via HAPI:
https://www.sidefx.com/docs/hengine/_h_a_p_i__asset_inputs.html#HAPI_AssetInputs_MarshallingPointClouds [www.sidefx.com]
Additionally, these are all the current Houdini Engine API (HAPI) that we expose to allow to programmetically work with Houdini:
https://www.sidefx.com/docs/hengine/_h_a_p_i_8h.html [www.sidefx.com]
If the Unity plugin is missing any of these imports, let me know and I can add them. Most should be in already.
If any functionality is missing, you are welcome to submit RFEs
Here is documentation on getting point clouds into Houdini via HAPI:
https://www.sidefx.com/docs/hengine/_h_a_p_i__asset_inputs.html#HAPI_AssetInputs_MarshallingPointClouds [www.sidefx.com]
Additionally, these are all the current Houdini Engine API (HAPI) that we expose to allow to programmetically work with Houdini:
https://www.sidefx.com/docs/hengine/_h_a_p_i_8h.html [www.sidefx.com]
If the Unity plugin is missing any of these imports, let me know and I can add them. Most should be in already.
If any functionality is missing, you are welcome to submit RFEs
Perfect, HAPI seems to be exactly what I needed!
It turned HAPI covers all I need from the Houdini Engine, so I am using that exclusively in my project. HEU_SessionHAPI is also a convenient wrapper, though it was missing some methods, like saving geometry to file. Most other parts of the Houdini Unity Engine have hardcoded x-axis flips everywhere, so in the end, I can't use most of that. Some things I noticed that could be improved are:
1. HAPI passes a ref to a session structure everywhere. In C-Sharp, classes are reference types by default, so if you could use a class instead, it would be possible to pass a null session easily, as described in the HAPI documentation. This would be a HUGE improvement for any user of node based coding tools like Bolt, as connecting the session to every single node is making the graphs quite unreadable (I figure many Houdini users are fond of node-based workflows, and might want use node-based coding as well).
2. A Unity wrapper for HAPI would be nice. The wrapper could return strings instead of string handles, wipe away all ref arguments and replace these with proper objects, convert float arrays to Vector3 arrays etc. You have some Vector3 array helpers in other places, but these are mangling the x-axis, and can't be used. A clean pure API, that speaks in C-Sharp/Unity language, but doesn't do any extraneous things like mangling the coordinate system would be very useful.
3. The out of the box curve editing, terrains etc. are all nice for smart-props kind of things, and as a reference on how to use HAPI, though, you are never going to catch up to the need of every developer, or even most developers. I would give top priority to an easily accessible HAPI interface instead. With HAPI, it is already possibly to spawn trees or grass on terrains with full control, and you get full access to any attribute, instead of being limited to predefined attributes for selecting materials etc.
4. Split Geo by Group is normally the default behavior. I tried extending HEU_SessionHAPI to expose this flag, but could not get this to work. The expected behavior is that each of my groups would become one part in the geo, named after the group, is that right? When I set this flag, it appears no parts are created at all in the geo. I definitely want to split by group. Otherwise, I would have to instantiate group nodes, and cook each one individually, or iterate over each point and check their group. But either multiple cooking, or manual iteration over millions of points, would be quite slow, compared to Houdini doing the splitting for me. (Using packed primitives seem to achieve the split, but generates two parts per group, one packed primitive and one mesh, which seems a bit hacky. The part name becomes the geo name with a random number suffix, which is quite useless. With this method, there is no way to identify the parts, without digging into point attributes, which is also more messy than it should be.)
1. HAPI passes a ref to a session structure everywhere. In C-Sharp, classes are reference types by default, so if you could use a class instead, it would be possible to pass a null session easily, as described in the HAPI documentation. This would be a HUGE improvement for any user of node based coding tools like Bolt, as connecting the session to every single node is making the graphs quite unreadable (I figure many Houdini users are fond of node-based workflows, and might want use node-based coding as well).
2. A Unity wrapper for HAPI would be nice. The wrapper could return strings instead of string handles, wipe away all ref arguments and replace these with proper objects, convert float arrays to Vector3 arrays etc. You have some Vector3 array helpers in other places, but these are mangling the x-axis, and can't be used. A clean pure API, that speaks in C-Sharp/Unity language, but doesn't do any extraneous things like mangling the coordinate system would be very useful.
3. The out of the box curve editing, terrains etc. are all nice for smart-props kind of things, and as a reference on how to use HAPI, though, you are never going to catch up to the need of every developer, or even most developers. I would give top priority to an easily accessible HAPI interface instead. With HAPI, it is already possibly to spawn trees or grass on terrains with full control, and you get full access to any attribute, instead of being limited to predefined attributes for selecting materials etc.
4. Split Geo by Group is normally the default behavior. I tried extending HEU_SessionHAPI to expose this flag, but could not get this to work. The expected behavior is that each of my groups would become one part in the geo, named after the group, is that right? When I set this flag, it appears no parts are created at all in the geo. I definitely want to split by group. Otherwise, I would have to instantiate group nodes, and cook each one individually, or iterate over each point and check their group. But either multiple cooking, or manual iteration over millions of points, would be quite slow, compared to Houdini doing the splitting for me. (Using packed primitives seem to achieve the split, but generates two parts per group, one packed primitive and one mesh, which seems a bit hacky. The part name becomes the geo name with a random number suffix, which is quite useless. With this method, there is no way to identify the parts, without digging into point attributes, which is also more messy than it should be.)
Thank you for the feedback. It helps to guide our development path.
Good to hear that HAPI provides what you need. The goal of HAPI's design was to keep the interface simple, and leave it up to the host plugins to build on it.
I'll take a look at adding more HAPI calls to the wrapper. Also there is a ticket to refactor out the coordinate mapping.
The Split Geo By Group is not something we recommend using as it introduces further issues when using groups without wanting to split them. But if you do want to use it, it should give you a part for each group. Are you setting the cook option before cooking? You can test this in the Unity plugin by setting the cookOptions.splitGeosByGroup to true in HEU_SessionHAPI::GetCookOptions. Now if you are using packed primitives, you can ignore or not generate the instanced parts by checking HAPI_PartInfo::isInstanced.
Note the intention of the Houdini Engine for Unity plugin is two-fold:
1. Provide a convenient out-of-box solution to use Houdini from within Unity. This covers majority of use cases, and intended for artists and most teams.
2. Provide a working, up-to-date, useful example of how HAPI can be leveraged within Unity. This is intended for programmers wanting to extend or customize functionality.
For Unity, most teams are small and would prefer to have things working out of the box, as opposed to having to dedicate resources to write tools for it. There will be other teams and users like yourself who are able to or want to extend it further, or don't need certain features. I am sure the plugin can be streamlined or features deemed unnecessary for some, but that comes at a cost of reduced functionality or usability for majority of cases. Regardless, if there are things that need improvement or further support, please submit RFEs, whether for HAPI or the plugin.
Good to hear that HAPI provides what you need. The goal of HAPI's design was to keep the interface simple, and leave it up to the host plugins to build on it.
I'll take a look at adding more HAPI calls to the wrapper. Also there is a ticket to refactor out the coordinate mapping.
The Split Geo By Group is not something we recommend using as it introduces further issues when using groups without wanting to split them. But if you do want to use it, it should give you a part for each group. Are you setting the cook option before cooking? You can test this in the Unity plugin by setting the cookOptions.splitGeosByGroup to true in HEU_SessionHAPI::GetCookOptions. Now if you are using packed primitives, you can ignore or not generate the instanced parts by checking HAPI_PartInfo::isInstanced.
Note the intention of the Houdini Engine for Unity plugin is two-fold:
1. Provide a convenient out-of-box solution to use Houdini from within Unity. This covers majority of use cases, and intended for artists and most teams.
2. Provide a working, up-to-date, useful example of how HAPI can be leveraged within Unity. This is intended for programmers wanting to extend or customize functionality.
For Unity, most teams are small and would prefer to have things working out of the box, as opposed to having to dedicate resources to write tools for it. There will be other teams and users like yourself who are able to or want to extend it further, or don't need certain features. I am sure the plugin can be streamlined or features deemed unnecessary for some, but that comes at a cost of reduced functionality or usability for majority of cases. Regardless, if there are things that need improvement or further support, please submit RFEs, whether for HAPI or the plugin.
That sounds like a good approach. A new user would probably be overwhelmed if there was no way to get things running easily out-of-the box, and for the users who need more customization, it serves a good examples for learning HAPI. One thing I am missing are some more demos. The bending pine-tree is good for learning how to set parameters and cook, but doesn't really showcase the true capabilities of Houdini.
I am working with point clouds, and as these tend to get quite big, I divide them into groups, so that I can fetch the relevant data only for a particular use case. Split-geo-by-group would be perfect for me, especially if the part names mirror the group names. As I make the HDA, I have full control of how I group things, so I can avoid overlapping groups and the like. Point clouds do not have primitives, so my groups are point attributes. When using the split-geo-by-group option, zero parts are generated. Could it be that split-geo-by-group only looks at primitive group attributes, and ignores the point groups?
Adding a pack node, and looking at the first point to determine the group for that part is a workaround, though it required the extra steps of peeking into the point attributes, to decide whether or not the part is the one I am interested in. For volumes, the volume names are mirroring the terrain layer names, which is very convenient. Being able to use part names would simplify processing mesh geometry (including point clouds). Just putting names like mygeo_01, mygeo_02, is kind of a waste of a part name field, so please consider using the group name, the “name” attribute (used by the pack node) or a custom attribute as source for the part name instead.
I am working with point clouds, and as these tend to get quite big, I divide them into groups, so that I can fetch the relevant data only for a particular use case. Split-geo-by-group would be perfect for me, especially if the part names mirror the group names. As I make the HDA, I have full control of how I group things, so I can avoid overlapping groups and the like. Point clouds do not have primitives, so my groups are point attributes. When using the split-geo-by-group option, zero parts are generated. Could it be that split-geo-by-group only looks at primitive group attributes, and ignores the point groups?
Adding a pack node, and looking at the first point to determine the group for that part is a workaround, though it required the extra steps of peeking into the point attributes, to decide whether or not the part is the one I am interested in. For volumes, the volume names are mirroring the terrain layer names, which is very convenient. Being able to use part names would simplify processing mesh geometry (including point clouds). Just putting names like mygeo_01, mygeo_02, is kind of a waste of a part name field, so please consider using the group name, the “name” attribute (used by the pack node) or a custom attribute as source for the part name instead.
Looks like Split Geo by Group is only available for primitive groups, not point groups. You could submit an RFE to add it, but I am not sure if we are planning to provide more support for the split feature. In fact, it is currently considered a deprecated feature that is only available due to backwards compatibility.
You can also submit an RFE to specify part names from custom attributes. This has been requested previously as well, so we might be able add it in. I don't think it makes sense to use the group name as part name since again we don't officially support split by groups.
Also, for providing more examples in the Unity plugin, anything in particular you are looking for?
You can also submit an RFE to specify part names from custom attributes. This has been requested previously as well, so we might be able add it in. I don't think it makes sense to use the group name as part name since again we don't officially support split by groups.
Also, for providing more examples in the Unity plugin, anything in particular you are looking for?