This doesn’t change mesh in the beginning it creates wedge by material and geometry boolean. If we consider that the boolean will be replicated and couple of parameters for that tree’s material state..it’s quite ok imo, still would like to hear your perspective since you have experience on those.
On this moment its not really cut, trunk is masked and a wedge plane is generated and placed.
In the back after maybe second cut is reached, I was planning to have top and bottom booleans ready as static mesh, slice cut on dynamics are made and copied to be ready.
I have one concern since I didn’t work on those too much..which is PCG, I am not sure how easy or efficient to access those and change on cut. Remove one mesh add the cutted trunk. Ofcourse we can always keep these logic as premade however I have some concerns with pcg especially if its networked things (I have no idea). However during cut its a single actor we can replicate or even we don’t do that, just call that trees material parameters and place a wedge static mesh there.
Another option maybe smart objects as persistent integrated to pcg. Still its PCG unless you write a networked spawning on those.
Depends on how we design it you know, maybe its just replicated during other players around only but not persistent. A tree chopped 2 times is removed after X seconds if not completed. Can be even viewmodel client side only but we have full cuts replicated maybe.
I put 1000 dynamic mesh (cubes) in a empty level and the FPS droped from 120 to 60.
I did the same test but using static mesehs and the FPS does not droped.
So i think Geometry Scriptis good for desing level bud you need bake and save as static mesh.
And also Lyra has one the level made with dynamic meshes. (someone forgot bake and save as static mesh) and the Lyra performance is really horrible.
For multiplayer (replication) you’ll need a blueprint actor. The actor itself will run on states replicated down by the server. OnRep functions managing the damage steps and FX per client.
For overall performance you’d want the initial map instance of the tree to be a foliage HISM (painted, procedural volume). I’m not familiar with PCG’s instance removals at runtime.
@RedGrimnir procedure would be managed by the replicated actor.
Initial hit (interaction), RPC server, server attempts. On success spawn replicated dynamic tree actor, set hit state to 1, remove server hism instance.
Clients get the replicated spawn command and spawns the tree actor. Begin play removes the hism, and the onrep state transitions to the 1st hit and applies the correct fx (chunk missing).
Tree gets another hit, server updates state and replicates. Onrep transitions to state 2. etc etc etc.
Hit FX on the autonomous client (the one hitting it) would be handled by that client. Responsive FX.
On complete damage (e.g. onrep state 5) the tree is split, physics fall. Actor then replaces the stump with a foliage HISM instance.
With multiplayer you have to assume another client is always in view of another. Player 1 watching player 2 chop down a tree. While Player 3 is over 1km away an unaware, no replicated data for the action at the current time. 10 minutes later Player 3 walks into the chopped trees area at which point he gets the replicated actor an it immediately replaces the default tree with a stump.
I continued to poke around the prototype around a bit.
Couple of findings
It would be better to use actor spawns as instance in PCG with static meshes so we can acess them more easy and have some logic on those. Is being cut, states, some notifies.
Masking works ok however if we want player to have cumilative cuts from every angle or cardinal angles, we can do it however we need to write a custom masking solution which can be done by generating a bw texture from cut actor operations.
Geometry scripts have no issues with any generative different meshes, we can adjust which trunk size can be cut in how many steps or can be pattern design of sizes for different types and biomes.
Actors we need to make persistent so when a new player comes basically they can see which one is cut etc. Probably after doing this much we can basically have growth mechanisms and even seasons on top. Can even have different growths with my lighawareness plugin which would be cool.
PCG will have networking problems at some stage possibly however actors state changes can be easy replicated so think it won’t be an issue, however its data in the end maybe tree stumps on ground also can be static or random 3 meshes so it lowers data consumption on network. Right now i generate the cut and send to instanced actors component to change which can be networked too.
We can keep fx client and have some audio events dispatched for immersion maybe. So players can know some body is chopping a tree nearby not a big deal.
Well we have to have a pattern or modular tree stumps for biome generation so it lowers developer work. N stump sizes, N trunk sizes, multiple texture, material for biome generation.
Right now it can be any angle and height. If hit can be reached.
Depending on TPS, FPS game can be handled with direct interaction if player holding an axe, or with an interaction system press E to chop from player facing angle.
Right now in proto its just puts actor makes cut steps on single actor.
Howewer for multiple cardinal cuts from different angles is not implemented or things like decay. Are we going to have decays if tree is not fully cut or cuts are persistent? We don’t know however imo should decay backwards.
(A) We handle masks customly, I can write a shader that generated B&W alpha mask on actor cut locations so any cut angle can be posible. (This is preferred however it needs to be written customly) for material UV.
(B) We make 4 cardinal angles and fit them in a patterrn.
Looks definitely worth it to make a git repo! My work is mostly c++ but I know a bit of everything, 3D and procedural generation algorithms too. Networking (game replication) is not my thing .
Also can be animation tricks to always hit same side even player is moving. However as i mentioned a multi mask UV shader can be done opening possility to cut from every angle.
I’m just looking at what players would do. In multiplayer I can see 3 players whacking at the same tree. Each cardinal generating a wedge plane. And logically you’d need a set number of hits on general region to fell the tree.
If a tree has pre defined possible combinations of cuts, and a table of such combinations are present at the client, you’d replicate an integer representing that combo and reconstruct the tree at the client? Again I don’t have the game networking knowledge here . It sounds similar to evaluating card combinations in poker (combinations are compared to a table and given a number to represent combination “strength” . This number represents how the tree looks and if it falls down or not (calculated by client side evaluator). The accuracy of the table just increases with the amount of client (stored) memory used. Once a player gets near a tree that has been hit from X sides he’d get a single integer over the webs to reconstruct the tree.
I think of that also like 4 cardinal sections always cut somewhere around player height. We can give actor transform over network to be replicated so just vector goes on that time.
It would cause some processing power on viewing clients since there would be a mesh generation on that time. We should limit how many actors can be present at a radius if its a highly demanding area with rare trees 100 player choppin.
I’m thinking you could get away with doing squib effects for all the hits and only applying the wedge for the final. Performance wise it’s the best option. Let the actor track the number of hits.
I’m envisioning it in a 8km x 8km world with 64 - 100 players on a dedicated server.
Think the stuff I made can be just client side. It will give a satisfaction to player itself.
Other stuff like wedge on final, sound, even we can skip physics simulation and just use kinematic so its easy multiplicated?
I am not sure if you see another persons cuts would make a gameplay difference.
All effects are client side. Servers do not render nor play audio. Servers shouldn’t attempt to execute FX unless there’s some level of physics interaction that has to be replicated down the line. For example physics particles in a fire effect that causes damage.
Code wise we use proxy roles to control flow logic. Or even go as far as split coding, proxy based actor components.
In general would be all client side, but controlled via server through replicated vars (repnotify).
It has an affect on immersion and ranging gameplay. Seeing a player behind a tree and it then falls for no given reason. No visual or audio effects implying any action. Just a tree out of nowhere falling over.
If I hear and/or see an action, a “cause”, I can foresee its “effect”.
unless you write a networked spawning on those.
actually when you think about it, a system like that different cuts from different people would open room for collaboration for faster grinding 
