Embedded Files
I really wanted to figure out this shape grammar stuff. I did not finish this assignment. I did learn more about how PCGs work through this, so that's what this breakdown will be about. I would like to spend a few more days making this something I can be proud of putting in my portfolio.
I used shape grammar, subgraphs, and data tables. I learned about data sets, partitions, loops, branches and selecting. I realized that the PCG plugin has sample content and extra subgraphs we can use that are hidden as developer files.
1. Sampling
1. Sampling
Shape grammar uses splines instead of volumes, but because of the original project requirements and my desire to store extra variables on each section of building (for what meshes to be spawned on them), I stuck with volumes.
However, I put that in a child actor with its own PCG graph since I couldn't sample individual component bounds from the Get Actor Data node. I make a spline from the component's (actor) bounds, and forward the bounds themselves into the output too.
The drawback I've currently found is that moving these child components does not automatically update their output in the main PCG. I'm not sure if there's a node to force updates, but right now I have to flip flop a blueprint variable to force an update. Also, in hindsight I could've used a spline inside a child blueprint for variables.
2. Datasets
2. Datasets
In the main PCG, I get actor data from components. This outputs 4 separate data sets. In the picture above, there's a cyan and a blue line going into the output. Those are two different data sets. We're seeing four in the main PCG screenshot down below because I have two child components both outputting 2 data sets.
I have added a tag called BuildBounds onto the non-spline dataset and will use it later to cull overlapping building areas- they are the bounds I was unable to get from Actor Data before. I can filter them out when unneeded.
2. Shape Grammar
2. Shape Grammar
Shape grammar is a system that spawns assets on a spline based on user-defined strings of "modules" and "grammar". In the above screenshot I have [FirstFloor][Mid*][Roof], which means to spawn the first floor, then the middle as many times as possible, then the roof. I have not specified meshes yet.
I stored the height of each box in their spline earlier. When I duplicate cross sections, it creates several more data sets of splines based off the height of each spline and the box's height. These have to be separate sets because they're all separate splines.
In Module Info on the right, I feed it the corresponding grammar and give it heights and pick whether or not it should scale meshes to fit better.
FirstFloor, Mid, and Roof are not very specific. But with Select Grammar, I can elaborate. Now the first floor spawns "doors" as many times as possible, and the other floors spawn "walls". One could add variations of walls and windows, multiple kinds of each, etc.
I then repeat the process again but with actual meshes for Door and Wall.
I specify the meshes in a data table. Hypothetically I could have several data tables to chose from so each building piece could easily swap meshes, determined through a variable on the child component.
The row name doesn't matter. The index must line up with Module Info...or maybe I don't need the add attribute node, and could move the module info in the data table itself.
The Attribute Partition node splits data into separate data sets based off an attribute. This can be important when you're using nodes that only take a single data input (like Branch), because it'll give a warning when you give it multiple rows. It took me awhile to figure that out.
The Match and Set attributes node applies the mesh and other information to the corresponding points. The subsequent nodes adjust the mesh so it fits the spline it's meant to be on- they will scale to fit, if the boolean is true. Those nodes and most of the PCG Make Mesh Info subgraph are taken from the PCG Shape Grammar example in the plugin, accessible if you enable viewing developer and plugin content.
This was where my major roadblock was.
The subgraph adjusts the offset and size to make sure all meshes fit properly together, no matter their original pivot. The example content worked alright, but my modkit pieces were rotated 90 degrees. Given the variety of meshes in this modkit, I thought it should be simple to fix it with code instead of going into each model and adjusting things...I added a variable to my data table to rotate my stuff accordingly, but there was still a big gap between pieces.
It took me way too long to figure out that Unreal. Was miscalculating. The bounds of the mesh. Which messed up the pivot point the subgraph and such would offset by.
(This was on meshes that I baked a manual rotation fix onto, when I decided to do that instead of fixing through data set because it wasn't working)
And now I can't show a picture of the error in the static mesh preview right now because it seems to have fixed itself on the two meshes I tested after I had to manually input adjustments.
The red box was smaller than the mesh itself previously.
I really would like to finish this. I want to add sockets to the static meshes because there's a subgraph that'll make points off of sockets, which probably means I could dictate where air conditioners, signs, or clutter could spawn. I've got corners and can probably get wall trims in. I'm currently creating a surface based off the roof spline and sampling it to create the roof mesh but that doesn't fit with the walls well, so I think I should try doing the cross-section splines but horizontally for that. Or snap all corner points to a grid.
Conclusion
Conclusion
Resources
Resources
Modkit: PurePolygons
Report abuse