As far as I know, that is not currently supported by Houdini Engine. The current workflow is to generate things at editor time, bake them to standard Unreal assets and then use that in a regular way.
It would be possible to generate many variations, bake those out and then in Unreal randomly pick one of those at the start of each level. The result would a good number of variations, which you could potentially better screen for issues and the result would be a more carefully crafted experience.
In Unreal randomizing between multiple heavy assets comes with its own gotchas, depending on how you do it.
For example if you have a blueprint that selects from a list of landscapes, make sure that the references are all soft and you only load the landscape that you actually use.
Found 452 posts.
Search results Show results as topic list.
Houdini Engine for Unreal » Is it possible to generate Terrain at Runtime?
- DASD
- 453 posts
- Offline
Houdini Engine API » Any starting documentation for Houdini API with Unreal Engine 4?
- DASD
- 453 posts
- Offline
Houdini Engine for Unreal » Build lighting
- DASD
- 453 posts
- Offline
Which Unreal Engine version is it?
Once you baked the hda out, you should have something like a Blueprint with instance static mesh component and a static mesh. Those assets would then be native Unreal assets. If you set the settings on those correctly it should be all good.
Once you baked the hda out, you should have something like a Blueprint with instance static mesh component and a static mesh. Those assets would then be native Unreal assets. If you set the settings on those correctly it should be all good.
Houdini Engine for Maya » Procedural Pipe - on Curve?? [just like the unreal demo shown]
- DASD
- 453 posts
- Offline
I was thinking that we first need to have this in Houdini and then we could apply the tech developed for that in Maya.
Probiner Probiner (Facebook account) has recently posted this:
WIP: Bezier Deform Offsets per control.
https://streamable.com/l7rb3?fbclid=IwAR0WlqugKymNefycp_n9K7ZM_cncgMDUOTPLdY1DtuaAaxwo_oTibFkjhgA [streamable.com]
This is Houdini and it is basically what I would expect as a solution for my RFE. Though I would also hope for additional sliders for arbitrary attributes that could be generated when needed.
I think something similar can be then achieved in Maya with (callback) scripts and custom attributes. You would then maybe have a shelf tool to create a special NURBS curve that has some scripts associated with it.
I have have seen in the Maya script editor, that even though the vertices do not have scale and rotation values, the calls are executed when you use the gizmos. (But I don't know whether you can get those calls.) The additional information could then be stored in custom attributes.
Obviously there would be a bit of overhead, but I think the overall workflow possibilities would make it worth it.
Maybe it makes sense to use custom NURBS shapes for controlling the knots of the curve (instead of locators, because those don't properly show scale).
In my experience it is desirable to have input curves as independent objects. The other important thing is that they are easy to use.
To clarify why it's useful to have input curves as separate objects: They could be (re-)used by multiple different scripts, models and HDAs. They can also be moved across scenes. They would not loose information from updates etc.
Probiner Probiner (Facebook account) has recently posted this:
WIP: Bezier Deform Offsets per control.
https://streamable.com/l7rb3?fbclid=IwAR0WlqugKymNefycp_n9K7ZM_cncgMDUOTPLdY1DtuaAaxwo_oTibFkjhgA [streamable.com]
This is Houdini and it is basically what I would expect as a solution for my RFE. Though I would also hope for additional sliders for arbitrary attributes that could be generated when needed.
I think something similar can be then achieved in Maya with (callback) scripts and custom attributes. You would then maybe have a shelf tool to create a special NURBS curve that has some scripts associated with it.
I have have seen in the Maya script editor, that even though the vertices do not have scale and rotation values, the calls are executed when you use the gizmos. (But I don't know whether you can get those calls.) The additional information could then be stored in custom attributes.
Obviously there would be a bit of overhead, but I think the overall workflow possibilities would make it worth it.
Maybe it makes sense to use custom NURBS shapes for controlling the knots of the curve (instead of locators, because those don't properly show scale).
In my experience it is desirable to have input curves as independent objects. The other important thing is that they are easy to use.
To clarify why it's useful to have input curves as separate objects: They could be (re-)used by multiple different scripts, models and HDAs. They can also be moved across scenes. They would not loose information from updates etc.
Edited by DASD - Jan. 7, 2019 16:17:35
Houdini Engine for Unreal » Curve Control Point Rotation
- DASD
- 453 posts
- Offline
@canonball900
I think you need to use the unreal_instance method as described here: https://www.sidefx.com/forum/topic/43041/#post-269302 [www.sidefx.com]
When you develop your HDA, you need to use the Unreal curve as inputs, so you can tell what is actually happening. The best process is to plug a curve that you created and manipulated in Unreal into an HDA and then open the whole thing in Houdini. This will give you the Unreal curve as Houdini sees it.
I think you need to use the unreal_instance method as described here: https://www.sidefx.com/forum/topic/43041/#post-269302 [www.sidefx.com]
When you develop your HDA, you need to use the Unreal curve as inputs, so you can tell what is actually happening. The best process is to plug a curve that you created and manipulated in Unreal into an HDA and then open the whole thing in Houdini. This will give you the Unreal curve as Houdini sees it.
Houdini Engine for Maya » Procedural Pipe - on Curve?? [just like the unreal demo shown]
- DASD
- 453 posts
- Offline
@juliap have you seen RFE ID=76877?
{
Summary: Splines/curves in Unreal 4 and other programs contain not just CV information but also rotation and scale information. This would be a great fit for Houdini.
Description:
Houdini offers many options to add information onto a user-created curve. One could use multiparm blocks or ramps to give the user additional control. But it would allow for faster and more intuitive interaction if points on the curve could receive information from standard gizmos (like rotation and scale). Compare this process with Unreal 4 splines: https://youtu.be/7YUxM0NDWRY?t=40 [youtu.be] As you can see, the interaction is very fast and intuitive. Rotate a point and it changes the orientation of your curve.
Now imagine you could also scale a point on the curve. Then you could create a path tool that creates a path that roates and scales directly with the user input. Furthermore these scale and rotation attributes could be mapped to completely arbitrary functionality. For example they could control randomization or color.
Additional gizmos could be mapped to arbitrary attributes. For example, each point on a curve could have several drag sliders that change values like speed or turbulence intensity.
This would also synergize with Houdini Engine for UE4 (https://www.sidefx.com/forum/topic/45507/?page=1#post-202962) and other Houdini Engine implementations.
I think you could get a lot of user-friendlyness for relatively little effort with this. And after all, the most important thing for any end-user is a comfortable interaction with the software. Even for highly technical professionals, a better UI means faster iteration and therefore better visual results.
}
{
Summary: Splines/curves in Unreal 4 and other programs contain not just CV information but also rotation and scale information. This would be a great fit for Houdini.
Description:
Houdini offers many options to add information onto a user-created curve. One could use multiparm blocks or ramps to give the user additional control. But it would allow for faster and more intuitive interaction if points on the curve could receive information from standard gizmos (like rotation and scale). Compare this process with Unreal 4 splines: https://youtu.be/7YUxM0NDWRY?t=40 [youtu.be] As you can see, the interaction is very fast and intuitive. Rotate a point and it changes the orientation of your curve.
Now imagine you could also scale a point on the curve. Then you could create a path tool that creates a path that roates and scales directly with the user input. Furthermore these scale and rotation attributes could be mapped to completely arbitrary functionality. For example they could control randomization or color.
Additional gizmos could be mapped to arbitrary attributes. For example, each point on a curve could have several drag sliders that change values like speed or turbulence intensity.
This would also synergize with Houdini Engine for UE4 (https://www.sidefx.com/forum/topic/45507/?page=1#post-202962) and other Houdini Engine implementations.
I think you could get a lot of user-friendlyness for relatively little effort with this. And after all, the most important thing for any end-user is a comfortable interaction with the software. Even for highly technical professionals, a better UI means faster iteration and therefore better visual results.
}
Houdini Engine for Unreal » Can you point instances at already existing Unreal Assets?
- DASD
- 453 posts
- Offline
Haven't touched this in a while, but I think the solution is the method described above.
You don't need to pack anything, just make use of the unreal_instance attribute.
I attached a file, that works for me (Unreal 4.21.1, Houdini 17.0.416).
- Basically the packing step makes the engine think that you generated the mesh, because it is not aware of the history of how the mesh was a reference to an existing thing in the first place. The unreal_instance attribute method on the other hand exists so you can reference things that already exist in your Unreal project.
- It probably makes sense to expose the string for the reference as a parameter, but I left it out to show that it is not necessary.
You don't need to pack anything, just make use of the unreal_instance attribute.
I attached a file, that works for me (Unreal 4.21.1, Houdini 17.0.416).
- Basically the packing step makes the engine think that you generated the mesh, because it is not aware of the history of how the mesh was a reference to an existing thing in the first place. The unreal_instance attribute method on the other hand exists so you can reference things that already exist in your Unreal project.
- It probably makes sense to expose the string for the reference as a parameter, but I left it out to show that it is not necessary.
Edited by DASD - Dec. 28, 2018 18:21:30
Technical Discussion » Default PolyWire UVs
- DASD
- 453 posts
- Offline
Technical Discussion » Default PolyWire UVs
- DASD
- 453 posts
- Offline
m4x
Theres only one thing: I wonder why the UV Projetion has to be scaled down by the exact number of 0.2?
Max
It has to do with the radius to length ratio of the polywire. The uvproject is in cylinder mode, so the radius is always mapped 0 to 1. The scale only affects one dimension and thereby effectively controls the stretching of the UVs along the cylinder. If you increase the radius of the tube, you need to adjust the scale.
To get it exact you just use ch(“../polywire1/radius”)*3.14159*2 for the scale. (3.14 etc. is Pi and we get this from https://en.wikipedia.org/wiki/Circumference).
I am working on a more complete solution. XD
Edited by DASD - Nov. 30, 2018 21:27:12
Houdini Engine for Maya » Support for Maya sets
- DASD
- 453 posts
- Offline
I am probably doing something wrong, but I cannot recreate what you are describing. I am curious about the workflow.
Either way, please do make an RFE. This should probably be looked at at the same time as the pivot input/output suggestions I made, because that also deals with multiple input objects.
Either way, please do make an RFE. This should probably be looked at at the same time as the pivot input/output suggestions I made, because that also deals with multiple input objects.
Houdini Engine for Maya » Support for Maya sets
- DASD
- 453 posts
- Offline
Oh I think I was not clear enough. I was thinking about the method to create selection sets to input into the HDA.
I think you are talking about the HDA-output of Houdini groups to selection sets.
Rethinking this, I suggest to add another way to set the input on the HDA. The goal should be, that you have an active component selection in Maya and when you set that to the input of the HDA, the HDA takes the objects and creates the Houdini groups under the hood and or assigns them automatically to a related group parameter.
So in my crappy picture. You selected the torus object, and make a component selection. Then you press set to selection on the HDA and the magic that should (in my opinion) happen, is that the object and the group input get filled automatically. Ideally without generating a Maya selection set in the scene. Or maybe it does generate a Maya selection set with some unique name and then deletes it after use.
Because Maya is actually not designed for handling those selection sets and we don't want to have an ever growing list of them.
As for your problem with name collisions on selection set output: Can't you use a string (or integer) parameter input on the HDA and use that to rename the output sets and use a python wrapper to keep track of the selection sets that already exist in the scene?
So basically every time you create a new HDA, the creation script puts in an incremented version of the existing set names, so that there is never a clash?
I think you are talking about the HDA-output of Houdini groups to selection sets.
Rethinking this, I suggest to add another way to set the input on the HDA. The goal should be, that you have an active component selection in Maya and when you set that to the input of the HDA, the HDA takes the objects and creates the Houdini groups under the hood and or assigns them automatically to a related group parameter.
So in my crappy picture. You selected the torus object, and make a component selection. Then you press set to selection on the HDA and the magic that should (in my opinion) happen, is that the object and the group input get filled automatically. Ideally without generating a Maya selection set in the scene. Or maybe it does generate a Maya selection set with some unique name and then deletes it after use.
Because Maya is actually not designed for handling those selection sets and we don't want to have an ever growing list of them.
As for your problem with name collisions on selection set output: Can't you use a string (or integer) parameter input on the HDA and use that to rename the output sets and use a python wrapper to keep track of the selection sets that already exist in the scene?
So basically every time you create a new HDA, the creation script puts in an incremented version of the existing set names, so that there is never a clash?
Houdini Engine for Maya » Pivots to and from Houdini
- DASD
- 453 posts
- Offline
Houdini Engine for Maya » Support for Maya sets
- DASD
- 453 posts
- Offline
What versions are you on? Do you have an example video or something, so I can see if my engine is working as expected (and whether I am doing it right)?
Houdini Engine for Maya » Support for Maya sets
- DASD
- 453 posts
- Offline
Hi,
I think it would be really cool if we the HDA's group parameter had a button to create and assign selection sets in Maya.
Basically it would work like the group selection button in Houdini (where you click, select in viewport and then hit enter). But it would create a generically named set and put that in the field instead.
What do you think?
I think it would be really cool if we the HDA's group parameter had a button to create and assign selection sets in Maya.
Basically it would work like the group selection button in Houdini (where you click, select in viewport and then hit enter). But it would create a generically named set and put that in the field instead.
What do you think?
Houdini Engine for Maya » Pivots to and from Houdini
- DASD
- 453 posts
- Offline
I suggest you implement it as I described and then get feedback.
I am researching Houdini Engine viability for our pipeline right now and this a required feature. If I get some version of this, I can quickly give feedback. Otherwise I would have to cobble it together via scripts.
If it was up to me, I would make it enabled by default and make it possible to opt out. Also, if somebody does not want to use it, they can just remove the primitive attributes from the geo before output.
I am researching Houdini Engine viability for our pipeline right now and this a required feature. If I get some version of this, I can quickly give feedback. Otherwise I would have to cobble it together via scripts.
If it was up to me, I would make it enabled by default and make it possible to opt out. Also, if somebody does not want to use it, they can just remove the primitive attributes from the geo before output.
Edited by DASD - Nov. 23, 2018 06:22:26
Houdini Engine for Maya » Hiding and Disabling Parameters in Maya
- DASD
- 453 posts
- Offline
Hi,
I am on Houdini 17.0.401, Maya 2017 Update 5. I am trying to use an expressions like { test == 0 } (test is a simple boolean parameter) in the “Hide When” field of a folder (type Collapsible). It does not seem to work in Maya.
Which part of this is probably failing? XD
I am on Houdini 17.0.401, Maya 2017 Update 5. I am trying to use an expressions like { test == 0 } (test is a simple boolean parameter) in the “Hide When” field of a folder (type Collapsible). It does not seem to work in Maya.
Which part of this is probably failing? XD
Houdini Engine for Maya » Pivots to and from Houdini
- DASD
- 453 posts
- Offline
@juliap Is any of this working already?
From my point of view it should work like this:
By default, when a mesh from Maya comes into the Houdini Engine (through input, merge, on sop or object level) it should always have a (maya-)pivot primitive attribute that describes the local position and rotation of the object pivot. It should be per primitive, because you can put multiple meshes into one input.
The same pivot primitive attribute should be interpreted on export to put things back out. The output should create different objects for different pivot locations.
What do you think?
From my point of view it should work like this:
By default, when a mesh from Maya comes into the Houdini Engine (through input, merge, on sop or object level) it should always have a (maya-)pivot primitive attribute that describes the local position and rotation of the object pivot. It should be per primitive, because you can put multiple meshes into one input.
The same pivot primitive attribute should be interpreted on export to put things back out. The output should create different objects for different pivot locations.
What do you think?
Technical Discussion » Generate help for custom vex functions
- DASD
- 453 posts
- Offline
I am making a custom Vex library. How exactly would I go about adding all the functions to Houdini's autocomplete and help (on my local machine)?
Is there an automated process I can use?
Is there an automated process I can use?
Technical Discussion » How do I make a custom enum in VEX?
- DASD
- 453 posts
- Offline
Technical Discussion » How do I make a custom enum in VEX?
- DASD
- 453 posts
- Offline
I imagine the code would be something like:
But I don't seem to be able to get it to work.
Can anybody tell me what I might be missing and how my syntax is wrong?
enum days{
monday,
tuesday,
wednesday,
thursday,
friday,
saturday,
sunday
};
enum day = tuesday;
But I don't seem to be able to get it to work.
Can anybody tell me what I might be missing and how my syntax is wrong?
Edited by DASD - Oct. 29, 2018 23:09:51
-
- Quick Links