Not sure if this should be here or in feature request. We can’t create instances for trailmeshes yet. How should I go about it if I wanted to ? Make a InstancedTrailMesh class ? Will this bloat the repo ? Or should I just write my own ? Also, complications with generator and original functions arise.
The original TrailMesh class was there long ago. The latest improvements were a no-brainer (low hanging fruits). I’m apprehensive of bloating the repo with a new class, particularly if use rate isn’t high.
All the trails in this ss are setup the same way (ie, same diameter, segments, sections etc), with each having its own generator, material, shader. 1 trail is consuming 1 draw call + 1 material. So 10 trails visible = 10 draw calls.
Ideally, I’d like to have them consume 1 draw call for all trails since they are all setup the same way. The only difference would be that each trail has its own respective generator. Is this doable?
The fact they do not have all the same length and such makes me think they won t have the same underlying vertex data so they would not be fit for instances.
Trails are supposed to be unique. Or, at least, there is no mecanism to detect if 2 trail meshes can be grouped together because of same verices, length,…
There are way to make trails non unique like deforming a mesh and have UV animation for example. Things will get a bit more complex as UV shifting will need to take world unit length for consistent speed across trails.
Is the number of trail mesh a performance issue? Are other meshes, like the towers, instanced meshes?
I remember my last time working on trails was to write a custom compute shader in C. Perhaps a vertex shader to hold all the trails vertices and update their positions every frame… hmm, agreed, not straightforward. Perhaps, I’ll kiv for now…
It might be, maybe not in the thousands region but >100 is certainly possible. Everything else in the early prototype has been instanced (towers, creeps, hp labels etc, needed the bandwidth for adding new stuff). I’m not seeing perf hits from trails on my rig nor from the live server, a real testament to bjs, rawr! Then again, I don’t have a stress test setup yet, lol…
I think a performance test scene set up for worst case is an interesting idea. Then, you’ll be able to profile it and do improvements based on metrics.
Sometimes you can be surprised by what is performant and what is not.
Pseudo stress test ss, maybe not a worst case but should be a sufficient stress case. 44 towers + a whole bunch of targets on Chrome+ffox. lowest fps was around 48 on my local rig. stats on both browsers are comparable, other than ffox not engaging the gpu.
I guess frameTime is the biggest bottleneck. Drawcalls don’t look too bad actually, hovering around the sub 200 region. Otherwise, perf seems pretty reasonable for a bare environment test.
Is it possible to do another perf tests with only 1 element removed per test. This to test the influence of each rendering element. I’m actually curious of the time it takes to render the jauges.
I see, you mean to still perform the stress test but to disable all trails, all vfx, all creeps, etc 1 by 1? Currently not setup that way but it could be done…
if you need more perf in the future, it might be interesting to replace trails with mesh+uv translation.
creeps are the little jauge on top of characters?
The trails are from the trailMesh class as shown the doc, trailMesh doc and example pg: trailmesh with uv shifting. I dont think I can squeeze anymore perf from it w/o an instanced trailMesh class, hence the OP.
Creeps are the characters, the little gauge on top is the hp label (simple quad mesh with shader), which are all instanced.