Hi everyone,
I'm pleased to let you all know that we have started to work on a version 2 of the plugin.
Similarly to what we did with version 2 of the Unity plugin, this will be a significant rewrite of the core of the plugin that will allow us to add new features more easily, and increase the overall performance and stability of the plugin.
Here are some of the major new features that we plan to add to the plugin for V2:
- Update the core architecture of the plugin, to improve stability and make the runtime module lighter, by moving the HAPI / cooking logic to a third module.
This would remove the need to bake out Houdini assets when packaging / shipping your game.
- Blueprint support, allowing Houdini assets to be embedded in blueprints in order to easily combine or preset your tools.
- PDG Asset link, that will give full access to the power of PDG and TOPs in Unreal.
For the rest, we also plan on enhancing the UX/UI of the plugin, and improve the workflows we currently have in place in the plugin. Here are some of the improvements that are planned:
- Reduce the mesh creation time to improve the reactivity of the plugin when editing placed HDAs.
- Wider generic UProperty attributes support.
- Have the ability to seamlessly move HDAs between levels.
- Support for world composition.
We do intend on making sure that version 2 supports all the existing workflows. HDAs made for version 1 of the plugin will also work with version 2 without needing to be modified, and should give similar results than they did in when used with version 1 of the plugin.
However, with the amount of changes that we intend on doing to the core of the plugin, we currently do not plan on supporting backward compatibility with version 1.
What this means is that upgrading to version 2 of the plugin will likely require that you reimport and recreate all placed HDAs in Unreal.
We currently plan on having a public beta of the new version of the plugin by the end of the year. In the meantime and until version 2 is released, please be assured that we will keep supporting version 1, though we'll be mainly focusing on major bug fixes and support for upcoming versions of UE4.
We've already compiled a list of the most requested features over the past few years, but now would be a good time for you to share with us any feature requests or needs that you might have so we can take them into account while we work on version 2 of the plugin.
Thanks
Edit1: As we ended up rewriting/optimizing a lot more of version 1's code than we originally intended, public beta for version 2 will likely be delay by a few months. I'm currently aiming at having the public beta around March/April (2020).
Edit2: See Cristin's post [www.sidefx.com] for the latest update regarding v2's upcoming alpha/beta/release.
Edit3: The plugin is currently in private Alpha (Alpha3), and we're aiming at the end of August for the public beta.
See my postHERE [www.sidefx.com] for some more details and , as well as a list of some of the changes and new features currently available in the Alpha.
Full Version: Houdini Engine for Unreal - Version 2
I love to see the new development going forward. I'd love to test it out when ready.
A few things that I'd love to see
Be able to set inputs to hda's from other levels.
Better spline support
A few things that I'd love to see
Be able to set inputs to hda's from other levels.
Better spline support
Finally! This is awesome!
It would be great if we could send back painted information to Houdini.
Like Vertex Colors on generated Meshes - as far as i know this doesn't work yet.
Presets are awesome! Thanks for that!
It would be great if we could send back painted information to Houdini.
Like Vertex Colors on generated Meshes - as far as i know this doesn't work yet.
Presets are awesome! Thanks for that!
PDG IS HERE!
THANKS!
THANKS!
HOT! ♥♥♥♥♥ When XSI died, I wasn't sure if I would ever find 3d love again. Now Houdini and I we've been together a long time and the ♥ is just as strong. With Unreal, it's such a great threesome. Thanks for working so well with Unreal and the great work!
@Diego:
- Be able to set inputs to HDA's from other levels.
If you mean being able to use actors (via HDA/Landscape/World inputs) from other levels than the HDA's, this is already planned for v2, but recent version of the current plugin should already have a better support for this.
- Better spline support: we do have a lot of improvements planned for curves/splines support in v2.
Some of them will likely happen after release of the new plugin.
@Ron:
- Painting of attributes is also planned for v2, but also after its release.
- Be able to set inputs to HDA's from other levels.
If you mean being able to use actors (via HDA/Landscape/World inputs) from other levels than the HDA's, this is already planned for v2, but recent version of the current plugin should already have a better support for this.
- Better spline support: we do have a lot of improvements planned for curves/splines support in v2.
Some of them will likely happen after release of the new plugin.
@Ron:
- Painting of attributes is also planned for v2, but also after its release.
1. Please support all manners of animated mesh baking. So Skeletal mesh baking and (different forms of) animated mesh baking.
2. Please have a Houdini-side 1 to 1 Native version of the Unreal spline. (For testing, development and general parity).
3. Please standardize the baking system. You should be able to seamlessly switch between the type of bake by changing one attribute. The exact same setup should easily switch between baking to one static mesh, baking to separate static meshes (using on mesh or baking multiple new ones), instanced static meshes, hierarchical instanced static meshes, or even placements of assets existing in Unreal.
More detail: You could, for example, always require packing and use a per packed prim attribute to determine the type of bake and another attrib for the name that asset should have after bake. To bake as placements of assets existing in Unreal, you could add another string attribute for the path (or you could put it in the name attribute) and you would change the bake type attribute.
The advantage of a standardized system allow for easy development of wildly flexibile tools.
4. Pleas make it possible to bake to Unreal's foliage system. Technically Unreal's foliage are just Hierarchical Instanced Static Meshes, but the system allows for far more sophisticated user control than baking to a Blueprint with a HISM component.
5. Please support nested multiparms.
6. Please support inputs in multiparms. This also should support per input parameters that are clearly (visually and functionally) associated with the input.
7. Please allow for the development of context sensitive menus in Unreal that would allow you to modify settings in the Hda. Example: you make a building generator that assembles a building from modular panels. Once the user generated the building and put it in the scene in Unreal they can select any of the generated panels and switch it to another from a dropdown or via a button that randomizes seed of that particular segment.
8. Please add example files to the docs.
9. Please support baking box, sphere and capsule collisions. They are more efficient than simple custom convex collisions and gamedevelopers care about that.
10. Please allow Blueprints to set Hda parameters.
11. Please allow Blueprints to contain HDAs.
Finally please take the time to do this right so we don't have to wait years for another rework in case a feature did not make it. I would not mind a beta stage that would last a year or more if the system is super solid by the end.
If you have any questions about my suggestions or you think some of this makes no sense, I am jumping at the opportunity to elaborate on everything.
Do you need RFEs for any of this?
2. Please have a Houdini-side 1 to 1 Native version of the Unreal spline. (For testing, development and general parity).
3. Please standardize the baking system. You should be able to seamlessly switch between the type of bake by changing one attribute. The exact same setup should easily switch between baking to one static mesh, baking to separate static meshes (using on mesh or baking multiple new ones), instanced static meshes, hierarchical instanced static meshes, or even placements of assets existing in Unreal.
More detail: You could, for example, always require packing and use a per packed prim attribute to determine the type of bake and another attrib for the name that asset should have after bake. To bake as placements of assets existing in Unreal, you could add another string attribute for the path (or you could put it in the name attribute) and you would change the bake type attribute.
The advantage of a standardized system allow for easy development of wildly flexibile tools.
4. Pleas make it possible to bake to Unreal's foliage system. Technically Unreal's foliage are just Hierarchical Instanced Static Meshes, but the system allows for far more sophisticated user control than baking to a Blueprint with a HISM component.
5. Please support nested multiparms.
6. Please support inputs in multiparms. This also should support per input parameters that are clearly (visually and functionally) associated with the input.
7. Please allow for the development of context sensitive menus in Unreal that would allow you to modify settings in the Hda. Example: you make a building generator that assembles a building from modular panels. Once the user generated the building and put it in the scene in Unreal they can select any of the generated panels and switch it to another from a dropdown or via a button that randomizes seed of that particular segment.
8. Please add example files to the docs.
9. Please support baking box, sphere and capsule collisions. They are more efficient than simple custom convex collisions and gamedevelopers care about that.
10. Please allow Blueprints to set Hda parameters.
11. Please allow Blueprints to contain HDAs.
Finally please take the time to do this right so we don't have to wait years for another rework in case a feature did not make it. I would not mind a beta stage that would last a year or more if the system is super solid by the end.
If you have any questions about my suggestions or you think some of this makes no sense, I am jumping at the opportunity to elaborate on everything.
Do you need RFEs for any of this?
12.Please add a viewport preset (and or shader) that would mimic the base shader and look of the default Unreal shader in Houdini.
13. Please make it possible to create an instance of a material that already exists in Unreal and to set parameters on it and to assign that to a baked mesh.
13. Please make it possible to create an instance of a material that already exists in Unreal and to set parameters on it and to assign that to a baked mesh.
14. Please add some general information about licenses and how Houdini Engine and assets behave when you don't have Houdini Engine installed, as well as risks and safeguards for workflows when you implement and use Houdini Engine. Programmers and Producers in the games industry, that have not used Houdini before, always ask the same essential questions. They see all kinds of risks cause they don't know technical details about how it is supposed to work.How does it affect the build system, that sort of thing.
We need a good standard primer document to make risk assessment easier.
We need a good standard primer document to make risk assessment easier.
Hey DASD,
Thanks a lot for the feedback.
I may have misunderstood some of your requests, so please chime in and add more details if needed, but a few of them have actually already been implemented in the current version of the plugin.
1. Support for skeletons / animated meshes (both in and out) is something that we'd like to add at some point, but that's not something that we'll work on for the first versions of v2.
2. I can definitely see the benefits of having this, but this is very unlikely to happen as unreal splines and houdini curves do not work in the same way at all (unreal lets you set tangents, and has different type/interpolations than houdini curves), and would require a new type of curves on the houdini side.
For version 2, Unreal spline components will still be brought in “resampled”, but we do intend on making the houdini splines a lot easier to use, as well as independant of a HDA's curve input.
3. I assume that by “baking” you're talking about the unreal output of the HDA, not the actual baking process…
Some of this is planned for v2. We do want to make it easier to decide, when instancing, if the result will be Instanced Static Mesh Components, Hierarchical ISMC or separate Static Meshes Components when possible.
Since we do plan on supporting previous workflow, we cannot enforce a standard on this, even if the “official” way of instancing will remain packed prims / unreal_instance attributes.
4. Baking to foliage has been added to the plugin a few months ago.
If your HDA generates instances, you should be able to use the “bake to foliage” button.
That's only baking, but we do plan for v2 on seeing if we could have the HDA directly generate/update foliage instances after cooking.
5. Nested multiparms support was added quite a long time ago, but there might still be some issues with it in certain cases.
6. Unless I misunderstood what you want, that should also already be supported in the plugin:
You can expose an object merge's multiparm on an HDA, allowing you to dynamically add/remove instances of objpath parameters, (which will become inputs on the UE4 side). You can add any parameter to that multiparm's children.
7. Could you give a little more details on that?
Assuming you're instancing the panels on your building generator, you can swap those panels on the ue4 side via the instanced inputs. What we can't do though, is swap a single instance with a different mesh..
8. Yes, adding examples to the docs is something that we'll do. The docs definitely need a little more love.
9. Box / Caps / Cylinder and KDop colliders support has been added to the plugin a long time ago, via the collision_geo_simple_box etc.. groups.
(more in the docs [www.sidefx.com] )
10/11 That's part of the BP support we have planned for V2.
12. Have you tried the new viewport / principled shader in H17.5 ?
Matching results from mantra, Unreal, marmoset etc.. was exactly what it was made for.
(see here [player.vimeo.com])
13. Unless I misunderstood what you want, this is also already supported in the current plugin.
The unreal_material_instance attribute will automatically create an instance of an existing unreal material, and you can change that material instance's exposed parameter by using unreal_material_parameter_ attributes.
(more in the docs [www.sidefx.com])
14. Yes, that will be part of updating the plugins docs:
- more info on how licensing works, when a license is taken.
- some details/guidelines on how to integrate the plugin in a project.
For v2, the new architecture will make it a lot easier to remove the need for an installed houdini for people that dont need it, as well as to prevent accidental cooks (then taking a license).
Please feel free to submit RFEs, as that's still the only way to properly track feature requests.
Thanks a lot for the feedback.
I may have misunderstood some of your requests, so please chime in and add more details if needed, but a few of them have actually already been implemented in the current version of the plugin.
1. Support for skeletons / animated meshes (both in and out) is something that we'd like to add at some point, but that's not something that we'll work on for the first versions of v2.
2. I can definitely see the benefits of having this, but this is very unlikely to happen as unreal splines and houdini curves do not work in the same way at all (unreal lets you set tangents, and has different type/interpolations than houdini curves), and would require a new type of curves on the houdini side.
For version 2, Unreal spline components will still be brought in “resampled”, but we do intend on making the houdini splines a lot easier to use, as well as independant of a HDA's curve input.
3. I assume that by “baking” you're talking about the unreal output of the HDA, not the actual baking process…
Some of this is planned for v2. We do want to make it easier to decide, when instancing, if the result will be Instanced Static Mesh Components, Hierarchical ISMC or separate Static Meshes Components when possible.
Since we do plan on supporting previous workflow, we cannot enforce a standard on this, even if the “official” way of instancing will remain packed prims / unreal_instance attributes.
4. Baking to foliage has been added to the plugin a few months ago.
If your HDA generates instances, you should be able to use the “bake to foliage” button.
That's only baking, but we do plan for v2 on seeing if we could have the HDA directly generate/update foliage instances after cooking.
5. Nested multiparms support was added quite a long time ago, but there might still be some issues with it in certain cases.
6. Unless I misunderstood what you want, that should also already be supported in the plugin:
You can expose an object merge's multiparm on an HDA, allowing you to dynamically add/remove instances of objpath parameters, (which will become inputs on the UE4 side). You can add any parameter to that multiparm's children.
7. Could you give a little more details on that?
Assuming you're instancing the panels on your building generator, you can swap those panels on the ue4 side via the instanced inputs. What we can't do though, is swap a single instance with a different mesh..
8. Yes, adding examples to the docs is something that we'll do. The docs definitely need a little more love.
9. Box / Caps / Cylinder and KDop colliders support has been added to the plugin a long time ago, via the collision_geo_simple_box etc.. groups.
(more in the docs [www.sidefx.com] )
10/11 That's part of the BP support we have planned for V2.
12. Have you tried the new viewport / principled shader in H17.5 ?
Matching results from mantra, Unreal, marmoset etc.. was exactly what it was made for.
(see here [player.vimeo.com])
13. Unless I misunderstood what you want, this is also already supported in the current plugin.
The unreal_material_instance attribute will automatically create an instance of an existing unreal material, and you can change that material instance's exposed parameter by using unreal_material_parameter_ attributes.
(more in the docs [www.sidefx.com])
14. Yes, that will be part of updating the plugins docs:
- more info on how licensing works, when a license is taken.
- some details/guidelines on how to integrate the plugin in a project.
For v2, the new architecture will make it a lot easier to remove the need for an installed houdini for people that dont need it, as well as to prevent accidental cooks (then taking a license).
Please feel free to submit RFEs, as that's still the only way to properly track feature requests.
1. Makes me sad to hear that it's not supported. Please do reconsider skeletal mesh baking. It would make a world of a difference, if implemented well.
2. I do indeed suggest a new curve type in Houdini. I have made at least one RFE to this effect, before.
The thing is, that Houdini would actually greatly benefit from this curve type - even independently of use with Unreal. Just imagine how much more intuitive control you would give to a user of any procedural tool (that uses curves as inputs) by having additional attributes on a user-created curve in Houdini.
3. Personally, I would poll users whether they would prefer new standards over backwards compatibility.
IMO, the important thing is that you prepare for all output types in the exact same way and that you can easily decide which type you want on a case by case basis. I would also give the HDA developer the primary choice of which bake types they want to allow and which one would be the default.
4. Ah I missed that. Then my only concern is that it should also be considered in the same way for point 3. There should not be a special button or checkbox for a certain type of output.
I think you should allow the HDA developer to create drop down menus for all possible output types (or let them lock it down inside the HDA).
5. Nvm.
6. Nvm. - I need to try that, but I won't get to my PC for a while. Stupid holiday. XD
7. In Unreal, I think, you can create right-click menus depending on context. - I am a bit fuzzy on this, because it's a relatively new thing to have that in Blueprints and I have not gotten around to it, yet. Anyway, the asset that was placed or instanced or whatever by the HDA would probably need to be tagged as having been manipulated/created by the HDA and maybe with some other meta info. Then in the context-sensitive menu on Unreal side, we could have some custom logic. Then we want to query parameters on the HDA and set those with custom logic in Unreal to new values. I suppose it boils down to adding tags, reading and writing parameters on an instanced HDA via Blueprints and triggering bakes via Blueprints.
8. Great!
9. Those are not the same ones as the ones that you get when you import FBX. See those that you implemented are generated on the overall worldspace shape of the mesh. When you export a static mesh via FBX, you can make a scaled and oriented cube and name it
UBX__##
then that cube gets perfectly recreated on import into Unreal as a simple collision box with the same orientation and scale. This is super powerful and a very basic and essential workflow. You typically create multiple such boxes for one static mesh. Spheres and capsules are also occasionally used for this. The box thing you implemented doesn't take orientation into account - or I have not used it right.
10/11. Great!
12. Honestly my Houdini viewport looks pretty terrible most of the time. Maybe it's because there is no good HDR map set by default. But my viewport looks shaded flat and lifeless and the colors look washed out. I don't know what I am doing wrong. Maybe you can share a good setup?
13. Ah great, totally missed that.
14. Great!
Also, just to clarify, will V2 mean that Houdini generation can then be used at runtime/loadtime in a deployed game?
2. I do indeed suggest a new curve type in Houdini. I have made at least one RFE to this effect, before.
The thing is, that Houdini would actually greatly benefit from this curve type - even independently of use with Unreal. Just imagine how much more intuitive control you would give to a user of any procedural tool (that uses curves as inputs) by having additional attributes on a user-created curve in Houdini.
3. Personally, I would poll users whether they would prefer new standards over backwards compatibility.
IMO, the important thing is that you prepare for all output types in the exact same way and that you can easily decide which type you want on a case by case basis. I would also give the HDA developer the primary choice of which bake types they want to allow and which one would be the default.
4. Ah I missed that. Then my only concern is that it should also be considered in the same way for point 3. There should not be a special button or checkbox for a certain type of output.
I think you should allow the HDA developer to create drop down menus for all possible output types (or let them lock it down inside the HDA).
5. Nvm.
6. Nvm. - I need to try that, but I won't get to my PC for a while. Stupid holiday. XD
7. In Unreal, I think, you can create right-click menus depending on context. - I am a bit fuzzy on this, because it's a relatively new thing to have that in Blueprints and I have not gotten around to it, yet. Anyway, the asset that was placed or instanced or whatever by the HDA would probably need to be tagged as having been manipulated/created by the HDA and maybe with some other meta info. Then in the context-sensitive menu on Unreal side, we could have some custom logic. Then we want to query parameters on the HDA and set those with custom logic in Unreal to new values. I suppose it boils down to adding tags, reading and writing parameters on an instanced HDA via Blueprints and triggering bakes via Blueprints.
8. Great!
9. Those are not the same ones as the ones that you get when you import FBX. See those that you implemented are generated on the overall worldspace shape of the mesh. When you export a static mesh via FBX, you can make a scaled and oriented cube and name it
UBX__##
then that cube gets perfectly recreated on import into Unreal as a simple collision box with the same orientation and scale. This is super powerful and a very basic and essential workflow. You typically create multiple such boxes for one static mesh. Spheres and capsules are also occasionally used for this. The box thing you implemented doesn't take orientation into account - or I have not used it right.
10/11. Great!
12. Honestly my Houdini viewport looks pretty terrible most of the time. Maybe it's because there is no good HDR map set by default. But my viewport looks shaded flat and lifeless and the colors look washed out. I don't know what I am doing wrong. Maybe you can share a good setup?
13. Ah great, totally missed that.
14. Great!
Also, just to clarify, will V2 mean that Houdini generation can then be used at runtime/loadtime in a deployed game?
Hi,
This is really exciting news. We're using Engine heavily in our Unreal environments builds and would love to see improved support. Besides general performance improvements, we'd love to see
* The ability to duplicate an instantiated Houdini Engine Actor (keeping it's set parameters). Currently this crashes UE for us.
* The ability to input multiple Houdini Engine actors into another Houdini Engine Actor. We can do this one at a time but we'd really like to be able to select a set of them in the same way we can with Static Mesh inputs.
Probably more requests to come but these are the ones tripping us up currently.
Brett
This is really exciting news. We're using Engine heavily in our Unreal environments builds and would love to see improved support. Besides general performance improvements, we'd love to see
* The ability to duplicate an instantiated Houdini Engine Actor (keeping it's set parameters). Currently this crashes UE for us.
* The ability to input multiple Houdini Engine actors into another Houdini Engine Actor. We can do this one at a time but we'd really like to be able to select a set of them in the same way we can with Static Mesh inputs.
Probably more requests to come but these are the ones tripping us up currently.
Brett
Maybe this is already planned but:
@Brett - duplicating Houdini Engine Actors crashes here too. Not always, but most of the time.
- Beeing able to set ANY property on a blueprint (like exposed parameters etc.). I think the uproperty attribute only works for the standard UE4 parameters.
@Brett - duplicating Houdini Engine Actors crashes here too. Not always, but most of the time.
I'd like to propose a custom ‘Unreal Material MultiSub’ node for attaching Multiple Unreal Material Attributes to one mesh via groups, with the ability to see them in the Houdini viewport via a defined PNG.
I've made a mockup also.
I've made a mockup also.
I'd like the ability to assign a UE4 physical material to a landscape layer (unless there's a better way to associate physical materials with landscape layers created from an HDA). I created a PR for this in the HoudiniEngineForUnreal github project [github.com] and also implemented it in a branch of HoudiniEngineForUnreal that I use with my own UE4 project.
Hi,
@doug: noted , I saw your PR but didn't pulled it back because on my side I'd need to make it a little more general, adding support to physical material overrides generally, on landscapes, but also on other physics bodies..
@brett/ron: one goal of v2 is to get rid of those annoying serialization bugs (duplicate, undo/redo etc.. ).
I'm already making sure duplicate, undo/redo etc is stable on v2.
For v1, I had a look at that duplicate issue and dont have a fix for it yet (crash happens 100% on second duplicate).
For now, the workaround is to copy paste instead of duplicating.
Regarding inputs, currently inputs in v2 are designed so that they all can take any number of objects, so yes, you'll be able to select multiple HDAs in a single asset input.
@doug: noted , I saw your PR but didn't pulled it back because on my side I'd need to make it a little more general, adding support to physical material overrides generally, on landscapes, but also on other physics bodies..
@brett/ron: one goal of v2 is to get rid of those annoying serialization bugs (duplicate, undo/redo etc.. ).
I'm already making sure duplicate, undo/redo etc is stable on v2.
For v1, I had a look at that duplicate issue and dont have a fix for it yet (crash happens 100% on second duplicate).
For now, the workaround is to copy paste instead of duplicating.
Regarding inputs, currently inputs in v2 are designed so that they all can take any number of objects, so yes, you'll be able to select multiple HDAs in a single asset input.
Can the authorities provide a series of tutorials or examples of houdiniPDG and UE4 game scenarios?
Re: “- Have the ability to seamlessly move HDAs between levels.”
Is there a way to do this at all currently? Even “non-seamlessly”? I just see a message saying this when I try it and then it deletes my HDA asset.
LogHoudiniEngine: Warning: Failed to import from copy: Duplicated actor not found
LogActorComponent: UnregisterComponent: (/Game/Dev/Maps/testMap
ersistentLevel.HE_box_stair_tool_0.StaticMeshComponent_0) Not registered. Aborting.
Is there a way to do this at all currently? Even “non-seamlessly”? I just see a message saying this when I try it and then it deletes my HDA asset.
LogHoudiniEngine: Warning: Failed to import from copy: Duplicated actor not found
LogActorComponent: UnregisterComponent: (/Game/Dev/Maps/testMap
ersistentLevel.HE_box_stair_tool_0.StaticMeshComponent_0) Not registered. Aborting.
On v1, Copy-pasting should work fine.
Cut/paste, or Move to current level.. do have issues (generally, the cut HDA will just disappear).
Cut/paste, or Move to current level.. do have issues (generally, the cut HDA will just disappear).
Is there an ETA? And do you have the source on github as well?