So I am trying to improve performance as much as i can. My question is if i have a modular building with lots of parts… and i want to replace the collision with one mesh that is just a box. How would the game know if i hit the glass or wood or concrete materials for physics reactions? All the modular parts have collision removed in favor of one large collision object that is very simple.
Whats the best approach for performance?
What are Physical Materials for $100.
That doesnt really answer my question since none of the modular parts have collisions. A seperate collision for the entire building is used.
Shouldn’t matter.
Visibilty trace will pull whatever material was hit, regadless of the collision.
ah i didnt know that… i always assumed it was associated with the mesh that it collided with.
So question does visibility trace work even when there is no collision at all?
Or does it begin at the point it collides with something?
Trying to figure out the best way to do bullits. And the best way to walk on things for apporiate footprint sound fx… and the best way to bump into things for simple collision in general…
Im assuming for some of that i could use collision layers or whatever.
Trying to over optimize and get the most out of perfromance…
Check out the trace channels.
Visibility traces what is visible, so no.
collision is required. And the channel for it needs to be set correclty to allow visibility hits.
Physical materials and obviously the material maps they use are one of the best ways to provide interactivity.
For a character to walk on and bump you still need collision ofc.
That’s a physical interaction more than a check to determine what sound or action etc.
so if i wanted to spawn a deferred decal of the type of damage per material id use visibility?
And if i wanted a sound effect specific to what im stepping on… or a foot print decal what would that be? Can that also be done with visibility even though i may not be looking toward the ground…?
Yes, channles are what you use to trace against, and its called visibility because you can see it (ei: a mesh of any kind thats not hidden in game?), not because you physically see it.
It is probably faster for you to test this with simple line traces than anything else.
Also worth noting that because the engine is such s*it of recent, you probably want to just grab a bunch of your scene actors and use the acor merge function to generate a single actor our of them.
Normally that is what you do with modular kits once you are happy and done fussing about with placement.
Also normally, the actor merge process generates simplified collision hulls for you (of which you need to be mindful since it could potentially close out a doorway).
On that note, try not to shoot yourself in the foot?
Make a copy of the level before you merge things, so you can revert to it if you ever need to.
Regarding footstep sounds, line trace on visibility based on something in the animation;
Notify is reliable enough - you don’t really care that all sounds play, in fact, you probably dont want it to be super accurate anyway.
That too is easier done than said.
Once upon a time the docs had some halfa**ed tutorials on getting them working, and I’m sure that in spite of it being around 25% of what you really need for a proper project, it’s a decent enough start to get you running and testing.
Cant merge because im using nanite meshes in part. Would just increase memory alot. Not so sure how nanite streaming works. Not sure if it streams clusters with distance and visibility and not entire mesh but cant be sure… for now i use packed level actors to get nsnite and non nanite in the same blueprint… reducing stray drawcalls from non nanite.
So is visibility trace bad for performance in anyway? Why even have simple collisions if it wasnt?
Simple collisions are used for physical interactions.
Visibility is just what is present on screen, like i mentioned.
Im not sure about nanite, but i think the point of it aside from promising to do everything and factually doing nothing was to have it to where meshes and drawcalls are re-factored and aggregated for you.
I would hope this addresses collisions as well, but its the Epic team we are talking about here.
They likely just left collisions alone.
Still, I don’t really see how merging actors is a bad thing - its not. You’ll prpbably still get increased performance if you do it right.
And a reduction in memory footprint and cpu usage.
Afterall Nanite has to merge the meshes himself somewhere. Less meshes = less operatipns, less operations mean less computing, less computing should mean less performance, so long as the memory isnt flooded.
yea but if u merge them… arent u in essence creating new meshes… which means more memory… no longer duplicated instances. But ill probably end up doing some tests some time.
Also does polycount of a mesh somehow make a difference for visibility trace?
And then begs the question does visibility trace work on objects that have collision disabled?
Some tutorials ive seen is disabling all the smaller mesh collisions and just using one invisible box or shape as an overall collision overlapping those objects.
Try it.
Its faster than asking and its something you need to learn about the engine anyway - probably along with defining your own custom collision channels.
Overall, collision channels reflect your object defined collision - so no hull at all in an object means no response unless Complex as Simple is enabled.
There are some exceptions to that by using specific kismet functions or line traces.
But it generally applies everywhere.
Yes, but woould you rather load a wall made of bricks by putting the bricks up one at a time, or just saying “let this be a wall” and being done with it?
Same concept here, but for the engine.
If you build things smart, and you have 1 wall made from 1000 bricks which are merged it loads fine.
If you build things sillu and/or forget to merge, you won’t be able to get above 2fps much past the 10th wall you create.
Instancing doesn’t really matter either - it does in the sense you can have tons of bricks before you get down go 2fps.
But it doesnt because the dofference between 1000 drawcalls and 1 is so drastic that the one call will always win out.
See above. Usually no. Depends on how that collision is being looked at (and how that mesh is configured).
The overall collision will stop the player, but probably doesnt help in sorting out what mesh out of the many was impacted with.
For that, you need some kind of a map if you go with the swapping and removal of collisions.
A good idea is to just re-map your object to the new collision so that the hit can determine the same information the individual meshes provide.
I do think using Actor Merge will actually end up doing this for you on the physmat as well but i only think so and do not know this to be a fact.
The textures are all adjusted and re-calculated when you merge. Physmat definition is kind of like a texture, which is why i would assume it just gets re-calculated as well.
Good question - no, unless you use complex as simple, then yes.
Poly count should be as low as you can always, but with Nanite I suppose its no longer as big of a deal breaker as it once was.
In terms of hit results, the face you hit is automatically returned. Makes no difference to the engine id you have a billion faces or one, since a line trace or any hit really, will always return just the one face where the hit occurred.
(Im sure something for hadinling absolute center of a vertex instead of a face is done internally somewhere, but I don’t think i have ever seen that practically occur?).
So to recap:
Collision channels are definitions that still requires you to have collision set up and marked at the proper channel.
What Nanite may or may not do internally to get you that hit result information is a separate story.
If enabled, the material is aggregated and adjusted by the system. This should empower to run a trace on it and get a response on the Nanite object which uses a collision that is likely automatically composed of whatver objects the nanite mesh is made up of.
Maintaing said collision as simple as possible will indubitably always be beneficial.
Merging actors as desired to promote easier procsssing times will always almost always be beneficial.
Tris count on individual meshes doesnt matter too terribly, but it shpuld always be kept the bare required minimum as a matter of general best practice.
Swapping out collision from many objects to some other hull requires that you either:
A) merge the objects, create the new mesh, and re-create the collision hull.
Or
B) create a custom X/Y/Z to instance mapping that enables you to translate info from the hit location to the instance that needs to be affected - and, in the case of a wall where that is simple, to the spot whithin that instance where you will need to fetch a new hit result.
Hope that clears it up.
One addedndum (likely the reson for the confusion):
Line trace hit result will hit/miss based on defined collision.
After that, it breaks apart the underlying LOD0 mesh to return the info of the face + normal you factually hit.
Therefore, you can have the simplest of collisions (one box) to cover a mesh made up of a googleplex of tris, and (assuming you could render it and run it) get a result of the individual face that was hit under that simple initial box collision.
The kismet line trace (default function for BP) is what is in charge of doing this - but it will only do it if the initial collision is true…
So you would need 2 traces? One for the larger collision object that covers them all then a 2nd that gets fired off from another line trace from that first hit to the per instance collisions on another collision layer? Leat thats what i think your saying. Would that even save petformance?
Also draw calls im not concerned with. As i mentioned for packed level actors it basically makes it all same draw call for non nanite… and as for nanite that is done automatically per material.
Also i am familiar with line trace… and what you stated… which is why i was asking if i can do it with a seperate collision object.
Is line trace different then visibility trace?
Its only done at the line trace event, so maybe there is a use case where it would.
No.
Line trace is a thing, visibility is the channel you check against.
You can break apart the kismet function and review it a bit to extract how to manually put a face from LOD0 - but you still need a starting point that responds to your collision channel and starts the process…
Whats only done at the line trace event? Im confused what you mean
The calculations which would impact performance.
The system works like this:
Run collision, detect hit, figure out what face is hit.
Therefore,
the only elevetated cost (from figuring out the face, the normal, etc) happens on a verified impact.
The simple collision hull is used to determine that initial impact.
Like you did say;
Many collision hulls in the scene potentially do cause performance issues.
However,
The whole replacing things to remove collision is something you are doing, not something I would generally suggest - but - its not an overall bad idea.
There is some definite use case for it, particularly with wall like aggregations.
Doing 2 traces, one of which is essentially on a “virtual” object, would probably offer some performance boost to the scene.
However, I seriously doubt this - or anything except using actor merge - is required to help performance along. Cpu is much faster than a dacade ago where these could have been useful.
That help?