And then I add bone sockets ( no parent, no deform )
for each branch to get them to follow the Trunk as it bends.
The Top part is attached to the last bone of the Trunk.
Is this a terrible solution or is it ok?
I also need the monster itself to follow the tree as it bends after it jumped on it, but I have no clue how to do it.
This is my first time going about something like this and I couldn’t find any reference online so links are also welcome.
That’s a lot of tris for what is essentially a cylinder.
Reduce the geometry like by 90% or whatever percentage you can without loosing details.
Aim for like 200 tris to a trunk.
Each Branch a max of 500 - verts, not faces.
It’s a horrible idea because you won’t be able to have more than 50 trees or so as skeletal meshes without a major performance drop.
You can double down on horrible when you consider the fact that really, the trees only have to bend and move when the monkey or enemy or whatever else is near.
If you only need 50 trees, you may be able to swing it.
If you need performance, you have to let each tree transform from an instance to a skeletal mesh based on proximity to whatever other actor.
You can check out the videos for a general idea of how it functions though.
You would then just replicate something similar in behavior to get performance out of it.
Getting monkey or whatever to move it’s a separate AI discussion of its own.
I would suggest coming back to it when you have the base going so that you can try out different suggestions for it.
Originally the trunk was lower in polycount but I bumped it up to get more detail.
Now I’m gonna get it to 200 as you said. The branches are already >500 verts.
Replacing static meshes with skeletal is actually a great idea, can’t believe I didn’t think about xd.
I can have them switch to skeletal only when monkey targets them to move to.
What about attaching branches to the trunk tho? I don’t really know how to get them to follow the trunk as it bends.
If it needs to match the instance, then you are forced to push a pre-made tree that looks identical, so the bones as you had them is a good pathway.
If somehow performance is good and you don’t need instance replacement you could potentially just position them randomly on previously created sockets.
Remember that using PHAT can come back to bite you in the but when Chaos is fully deployed…
Performance as a whole is down.
Performance of the chaos build was even worse last I tested it.
/ chaos is the reason I haven’t updated the plugin in forever.
It’s kind of pointless when the most the engine gets is 20fps on a good day.
To have a bit of variation I would suggest you use 4 to 5 instances that look different (have different branch hookups) and replace them with the appropriate skeletal mesh.
It won’t be the same as generating the branch placement completely random on the fly, but it also won’t be as unpredictable…
All of the branches on this tree are unique, is that what you meant?
I’m also going to have them sway a bit using materials ( they will all share 1 mat too ).
And what is PHAT?
Phat is the physics asset that skeletal meshes use.
You can save some performance by instancing and attaching the branches to sockets anyway.
If they aren’t all unique.
It’s a marginal saving though because you only have one or 2 skeletal meshes active at a time if you use the instances.
It’s an important saving if you don’t use the instance replacement.
The only potential issue I see is that you just can’t have it generated at runtime.
Matching to each instance would be almost an impossibility. You need a different instance for every branch combination.
That’s x to the power of x possible meshes where X is the number of branches…
Impossible, maybe not. A ton of work that would take forever? Definitely.
I planned to have the branches belong to their respective sockets. So each branch has its own slot and they don’t switch around.
It’s basically the exact same tree getting instanced, so I don’t see issues there.
I already tested it with static meshes too. I put ~50 of them in a level using foliage tool and it run 120FPS+ in the editor. It dropped by a tiny bit when I had all of them on screen at the same time.
The trees were ~20k tris.
That’s due to the tris count mostly.
You can lessen it a bit with proper LODs too.
Your only significant performance drop with 50 instances would come from having transparency on leaves.
Full trees are generally challenging for the engine to start with. Putting alpha sorting in pre-pass can help if you end up having issues with transparency on 50 instances too.
Since it’s a small number.
I don’t think you are adding leaves though, so it probably doesn’t matter.
Between reducing the initial geometry and LODs you should have a good baseline scene.
Look at the ms counts and the “stat rhi” tris count more than the fps.
You probably want a base cost around 12ms or so for something this simple with instanced foliage trunks…
The more tris on screen, the more dynamic light will cost.
For leaves I planned to uses atlases from quixel to put a bunch of leaves on a transparent plane and then put a bunch of planes on branches.
Not modelling individual leaves.
Then you may run into performance issues with overlapping alphas.
Obviously conglomerates of leaves on a transparent sheet are supposed to be cheaper than geometry right?
Right. Except this is unreal, so that’s not real… geometry costs less than transparency.
There’s ways to fix it, but you have to start with a finished asset to be able to change stuff around.
So finish the look of those, with a decent overall tris count.
Bench a base scene with all the trees on screen at LOD0- which is your worse possible scenario.
Move on from there.
Make the skeletal mesh after you finalized the instanced meshe(s). So you don’t have to waste time with the weight paint over and over
