Martin Wetischek

hey, since it's apparently possible to create custom PCG nodes and they have an event graph like blueprints, would it theorically be possible to create "wrappers" for houdini engine HDAs that create a temporary HDA actor, take some input data & wire it into the HDA, make it bake, delete it, then pass the generated data to the next PCG nodes? All of this with the goal of defining a complex multi HDA pipeline directly from within unreal, and using PCG for some of it wherever it's possible and faster than houdini

Hey, I got two different questions :

1 - If I make a custom actor class that contains a mesh as well as a bunch of booleans that can be ticked/unticked from the level editor then input into a HDA, is there any way to read those booleans from houdini for each actor? I want to make various types of volumes that affect procedurally generated content (ie landscape height, overriding foliage/props generation, etc) and wanna keep the UX as simple as possible for artists

2 - Is it possible for a HDA to output actors with a custom class? IE I have a HDA that creates a trees and an animation for that tree being destroyed, and I want the resulting actor in unreal to be of a custom class I already created that handles all the gameplay code for destruction, burning, and other stuff, instead of having to export each tree as a fbx and set up a blueprint with the geometry manually

CodyS
Yeah, you are pretty much spot on. You would need to embed the HDA processors in the HDA(this is not editable in Unreal). And there would have to be some level of deconstruction to ensure your pipeline works inside the PDG network. So if you had a process of terrain>road>terrain>road, this could be done with PDG, but each trip would need to be its own unique process(either through HDA, or edited directly in the TOP network). As PDG flows linear, and can't jump back up in the process.

To answer your one question, you couldn't just plug in a building gen HDA or a road gen HDA and have PDG automatically know what to do. You would build this inside PDG as a building gen hda processor, and road gen HDA processor. And its inputs could be other HDAs, but it would be the output of those HDAs from my understanding.

And you can pass information as attributes in your PDG network! But if you had a road HDA with an attribute @lane_count = 6. This attribute will not be processed because the output will be a bgeo file that is passed to your next node, and the @lane_count won't transfer. But you can create and pass these attributes in your PDG network, to inform the next HDA it's intended parameters, being the bridge between these HDAs.



I guess the high level idea is thinking of it like this. There are kind of two main methods of working with HDAs without PDG.

1.You either build all your HDAs individually, (between 6-12) and drop each one down in your world, (creating 100s of HDA actors). These HDAs have no communication, and each need to be managed by hand. ie, Changing X parameter for certain conditions, for X number of HDA actors. And any updates/changes to the HDA need to be managed by hand on a case by case basic.

2.You make one massive HDA, which has those 6-12 HDAs embedded, and you edit these all directly in sops. Full communication! But processing time is slow. One curve move will requires a massive recompile for every dependency. Move a road over 5 feet, every road needs to be rebuild. Then every street light, car placement etc. On top of that, changes to a level can only really be done by one person.


PDG sort of brings the best of both worlds.
1. You connect all of these in a TOP network, as if it was 1 massive HDA network providing full HDA communication.
2. All user edits/parm changes can be handled by your PDG network, automating tedious management in your level.
3. Performance is better. If you move this 1 road curve, PDG identifies what will need to be changed, and what doesn't. And procedurally recook only specific items, speeding up processing time.
4. And this allows for multiple users to edit inputs. And HDA edits to happen independently.

If an HDA is a procedural 3d artist. PDG is a procedural world builder(in this context). Did I sell you on it yet?! hahaha

Here is a fun little tutorial that walks through a PDG network from front to back.
https://www.sidefx.com/tutorials/foundations-build-a-city-with-pdg/ [www.sidefx.com]

I think I get it now, and while I'm probably gonna look into it further if only because it's cool, it's probably not what I need

The main goal here for me was to be able to make new types of assets and have full control over where they are in the world and what they generate, while also having intercommunication between HDAs where relevant
The problem with PDG here is that every time I'd create a new HDA I'd have to edit the PDG graph to integrate it, expose a ton of parameters in the graph to be able to have as much control as I need (basically all the HDA params + world position and rotation + external inputs), and even then I'd probably still have to split that HDA into several HDAs, one for each "passes"

I'm guessing what I was going for just isn't possible right now? which I guess is fine, it's probably a very niche workflow if it exists at all yet

afaik unreal's PCG allows for this kind of intercommunication between PCG actors or whatever they're called (ie PCG actors generating their data in multiple steps, with each step generating some data that's then globally accessible for all other PCG actors for the next step), hopefully that gets some degree of compatibility with houdini eventually