I think I understand the reason why it’s happening: PCG makes a line trace and finds a point for spawn, but the mesh is much bigger than the point. Thus, part of the mesh goes beyond the surface. But, is there any fix? Maybe there is a way to add some indents on surface edges to prevent such spawns? Or, somehow check if that PCG debug box fully covers the surface of a spawn and prevent spawning if it’s not?
The system probably conducts one line trace at the origin of the mesh to determine if placement is OK.
And it already takes forever to compute.
What you would want to do is to have it conduct a sweep test with its own collision, and it would still not tell you if you are completely within the landscape.
The easy solution is to do what everyone does.
Add roots to your tree meshes.
Thanks for the comment.
It’s sad to hear that there is no solution, at least not in the current versions of PCG.
I’m definitely planning to add roots for the trees and play around with spawn surfaces more. But the trees are just an example, still need to figure out how to deal with stuff like logs or trunks lying on the ground.
Happy to inform that I’ve found the solution (tried in UE 5.3). So, I was just exploring different PCG nodes and found the one which name was pretty straightforward: Discard Points On Irregular Surface.
It is, though I don’t think its good enough considering the quantity difference you get between the 2.
You’d be better off defining an octagon and checking if each point is able to collide individually.
8 line traces per object.
Provided you do this in editor and are Ok with waiting for rather lenghty compute times, the end result will be much better - for circular or elliptical things anyway.
You could potentially write up the precise code to make it variable based on a radius, and a number of checks you want to perform.
At that point, discard the radius, make it based off of an array of transforms.
Pre-compute the transforms based on whatever makes sense for the object, allowing you to check any shape you want.
Again, the problem isnt really with doing, the problem is ypur compute times…
I’m new to PCG so, I’m not completely sure what do you mean.
This might be a dumb question, but. Are you talking about creating a new analogue to PCG system from scratch of if there is a possibility to make sample points octagonal shape with multiple points instead of a single point in the built in PCG?
I agree that this could be a performance hit but I’m still exploring options and open to any suggestions. What I’m trying to do is based on a runtime generation, not in editor.
TLDR: I’m building a system for an infinite race track generation which is based on relatively small chunks which spawns one by one in front (and removes behind) when player reaches a certain point of each chunk. Each chunk is a BP with the PCG component inside, shaped in a different way and has its own additional surface mesh variations. Similar to infinite runner system. Each chunk takes ~7-20 seconds to pass depending on its length, so the new ones do not spawn very often.
Thus, pre-computing transforms won’t work here especially considering that I want a different layout of the spawned foliage on each repeating chunk to make it seem less repetitive.
Yes, i meant that you should create yur own function.
Also, you dont need to use pcg, you could use onbeginplay on the object to shift it where more appropriate (in the case of the tree you just want a few more units, for instance).
If you are spawning BPs thats possible.
If you are spawning meshes (which is better for performance) its not that easy and you do need to create a pcg analog to determine placement…
Within the PCG placement, perhaps you could mix and match the placement results (or invert them) to reduce the load a bit.
Somehoe use the results of the discarded point to determine if more calculation would be needed or not (given your sample points above, you wouldn’t really be saving all that much, but everything helps)…
I have spent some time yesterday throwing a lot of stuff on my PCG graph making it more complex for testing purposes. Didn’t spend much time optimizing the assets, their draw distance and overall graphics is not final but here is the PCG result for instance:
Tested that on iPhone 7 and 14 Pro. Both have solid 60 fps with no stutters or frame drops on each of the new track chunk generation which btw appear instantly like if they were hidden before. iPhone 7 becomes pretty warm after 5 minutes of playing and its battery drains fast, but that device is so wasted, it just does the same while browsing the web.
I’d say everything is fine. PCG generation is instant and does not cause any stutters. Sure, there is still a room for optimizing the whole thing and that’s what I’m planning to do next.
IOS is it’s own beast. So don’t be overly concerned with an old phone not keeping up. After all the engine is barely incapable of exploding the latest hardware unless you put a lot of care into just about everything.
That said - looking at FPS is wrong.
Your bottleneck here in regards to PCG generation is CPU, not GPU. If the generation is so bad that you are getting bottle-necked by the CPU you are in way too much trouble already (generally caused by loops that are too long, or many spawned things that have On Tick enabled and perform some CPU side calculations per tick etc.)
It probably is.
To see the CPU slow down from something like this you’d have to go back to an Iphone 4 or right around that time, when Phones were essentially for making phone calls, and not much more.
Now that doesn’t mean that you shouldn’t shave off however much you can shave off the PCG stuff.
After-all, faster performance means you can push the number of instances past what you originally thought possible.
Either way, glad you sorted it out. The screen cap looks great for being procedurally placed.
