This should actually be fixed in the latest daily builds of 16.0. I forgot to update this thread. My bad.

Not entirely sure what you mean by “exporting”. If you just create a simple asset with a box and assign it a material with a texture, that should come across to Unity just fine.

What do you mean by “invalid asset”?

Maybe this will clarify things a bit: https://vimeo.com/158671974 [vimeo.com]

Splitting a mesh by group turned out be very much not ideal. That's because people tend to have other groups that have nothing to do with splitting, or overlapping groups, all of which will become their own static meshes.

The spliGeosByGroup option is off in UE4 because NOBODY should really be using that feature. It is pretty much deprecated and only there because some plugins still did not implement a better solution.

If you want a mesh in Houdini to be split in a specific way when coming into UE4 (or any other plugin), pack each individual “part” into a separate Packed Primitive and then merge them back into a single SOP. Each packed primitive, even if unique (not instanced), will become a separate StaticMesh in Unreal, with all the proper materials and attributes.

The benefit of using Packed Primitives to split is that even for plugins that don't support packed primitives, you will still get the splitting you desire because each packed primitive will be treated as a separate “primitive” when refining the whole thing to a triangle mesh.

Oh, ya, that still doesn't work. I haven't tried to fix it myself in a while but the problem usually came down to simply not being able to use any APIs not native to the platform the editor was set to.

For example, if you switch your platform to Android, I can't use windows APIs to check the registry for the location of Engine. That's even if you are still in the Editor. That's because Unity tries to limit all C# code to the platform that you are currently set to.

The other issue was that there was no way to tell if our code was actually running on Android or if it was running on Windows with the platform set to Android.

In any case, this request has not been forgotten. There just isn't anything in the pipe I can talk about at the moment.

That sounds like runtime support in which case the answer is “we're thinking about it”.

It's a hard problem that we know a lot of people would like us to solve. It's unlikely to be solved in the near future but I don't think it's impossible either.

Nice. I'll see if we can incorporate this into the plugin proper, but no promises.

Hmm, ya, that makes sense. Maybe submit an RFE to support@sidefx.com?

Actually, yes! You can check the HAPI_ENV_CLIENT_NAME env var for “unity”, “unreal”, “maya”, or “c4d”. Here's an example asset.

In the future, try to post Maya questions to the Maya forum here: https://www.sidefx.com/forum/46/ [sidefx.com]

I keep meaning to extract our C# bindings from the Unity plugin and offer them standalone. Might be worth submitting an RFE to support@sidefx.com to bump up the priority a bit.

Otherwise, yes, you'll want to use HoudiniHostLinker.cs and HoudiniCommon.cs. They should be pretty much standalone from the rest of the Unity project. HoudiniHostWrappers.cs might also be useful if you want automatic result code error checking but that might need more work getting it free from other Unity plugin dependencies.

4.15 support should come in the next daily build of Houdini 16 (today or tomorrow).

For a comprehensive list of changes (which will give you an idea of what's new) can be found in the Houdini Engine 3.0 docs here: http://www.sidefx.com/docs/hengine/_h_a_p_i__migration.html [sidefx.com]

But basically, the biggest change is that the concept of the “asset” has been replaced entirely by “nodes”. Everything is now a node and all APIs that used to take an asset, object, and geo id now just take a node id. It simplifies things a lot and also gives you more power over the underlying Houdini node network.

Among many small improvements, HAPI 3.0 also supports some of the new features in Houdini 16 like HeightFields (Terrain) and VOP-based materials.

Ok, then this sounds like a bug in H16 Unity plugin. Can you submit a bug report with an example asset to support@sidefx.com and I'll try to fix asap.

That said, in the H16 Unity plugin, operator path parameters are now in the main list of asset parameters. They are no longer in a separate “inputs” section of the Houdini asset Inspector tab.

I guess. But do the collision meshes really need to be different than the visible piece meshes? Why can't the piece mesh also be the collision mesh?

We don't currently send back the vertex colors from Unity to Houdini on meshes. We do if you use our painting tools but that's a separate code path. If you just set vertex color yourself on a mesh it won't be sent to Houdini.

If you'd like support for this, please submit an RFE to support@sidefx.com.

This was answered on the bug submitted. For the record, the problem with the above asset was that the material override parameter was on the points and not the primitives (faces). The “unity_material” attribute has to be a primitive attribute for it to work.

Which version of Houdini/Unity are you using?

You'll have to rename the pieces themselves to have the “_rendered_collision_geo” postfix in their name to in order to have the collision component be on the same GameObject as the part. There is no way currently in Unity to associate a collision geo with a different visible mesh on the same GameObject.

Currently, FBX is the only way to get a character rig from Houdini into Unity. Houdini Engine in Unity does not support this type of data yet. So, you can export whatever FBX supports.

The issue is that you're editing the Spare Parameters on the node instead of the parameters on the asset. These are, well, spare parameters. You can add spares on any node if you just need an extra parameter to help with channel references or usability. These spare parameters get saves as part of the .hip scene file and as part of the .otl/.hda.

To add real, permanent, parameters on your asset, right click on your asset node and go to “Type Properties”.

Here's a video that goes over some of this: https://vimeo.com/158671982 [vimeo.com]