rP21732 significantly increased the speed at which units disappear; this patch slows it down again, but decreases the delay time (to 10 s).
Also gives rubble the same delay time and removes the slower decay of other/hellenic_epic_temple.xml compared to other structures.
Details
Details
Check if it is more pleasing to the human eye.
Diff Detail
Diff Detail
- Repository
- rP 0 A.D. Public Repository
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Event Timeline
Comment Actions
Successful build - Chance fights ever on the side of the prudent.
Link to build: https://jenkins.wildfiregames.com/job/differential/433/display/redirect
Comment Actions
I could barely notice an FPS difference (something like from 22 FPS to 17 FPS if there are 100 chariots). I think it's relevant when there are thousands of units in a great skirmish.
With these numbers, the sinking of units seems to be just above threshold where one can notice it. (So maybe the number before the concerned commit was ideal with regards to the visual quality.)
The sinking proposed in this patch could be a good compromise between the intended performance benefit and an acceptable graphical effect.
(Maybe better if there was a very tiny acceleration that only becomes significant once the unit is underground (so it's moved out of world quicker).
On the other hand probably not, because we don't want the blood to disappear too early)
Check if it is more pleasing to the human eye.
(So this is how software developers will end up doing cruel animal studies?)
@Stan since you committed the original diff, are your eyes pleased?
| binaries/data/mods/public/simulation/templates/template_unit.xml | ||
|---|---|---|
| 22 ↗ | (On Diff #6465) | Maybe 15 Delay everywhere do for now already as long as we can notice the sinking with the (ideally human) eye |
Comment Actions
While at it, could you also look at the decay of siege weapons? And ships? They use different accelarations with 0 delay.
delay rate accelaration units (before) 40.0 0.01 0 units (rP21732) 30.0 0.15 0 units (D1467) 10.0 0.02 0 mechanical (siege) 0 0 2.0 ships 0 0.50 7.0 rubble 15.0 0.20 0
All values look rather arbitrary to me, but if one gives a clearly better performance and is visibly more pleasing, we might as well switch to that.
Comment Actions
I probably wasn't explicit enough as to why I wanted to see them sink into the ground faster. I agree it might look awkward.
First concern was performance. New units more polygons more graphical lag depending heavily on the card used. I also admit I'm a bit worried about people not being able to play the recent alphas for no explainable reasons.
Now that's kinda ruled out by elexis's tests there is something else I had in mind.
The audience. We have kids playing this and I am afraid the current amount of blood would be to much. And we can't make a noblood mod for the same reason that we are forcing people to install mods in order to be able to play with Asian people.
I feel like blood without corpses is pointless. If the corpse sank blood shouldn't be there anymore.
Comment Actions
Maybe we could have blood on/off option in settings.
Or corpse on/off. Simply if someone has performance issue, he/she could disable corpses or reduce number of corpses in the world on the same time.
Comment Actions
I dont think that reducing the sinktime would be the right thing if traumatization of children should be affected.
A blood on/off setting (why not a gore mod with intestines n things while at it? It would transport the idea that it wasn't fun what is depicted just like modern wars).
But the purpose of this diff is to fix a regression before the release and commit freeze is coming up, so I commit this now.
Ship sinking is a chapter of it's own. I remember there was a patch on trac that implemented some kind of mast sinking.
I hope we will fix these old patches one time.
Comment Actions
The original 0.01 is noticeable too, which is why the DelayTime is benefitial too actually.
What also wasn't mentioned yet is that corpses and blood remaining for a longer time visible adds value to the gameplay itself, since it acts as a marker for areas where battles took place recently.
In a 4v4 mutliplayergame, both when playing and observing there may be so many actions going on that one can miss some battles, and the corpses enable one to see where where something was missed.
That's also true for individual enemy units lost in ones own territory for instance.
The FPS impact only occurs when it's multiple hundreds of units. This was true especially for jebel barkal when there were 3000 gaia units in addition to the 1200 player units.
I'd rather have the FPS impact analyzed and precised a bit more before we reduce the benefits of the corpses.
(If we had this level-of-detail system, the renderer could switch depending on the number of units visible maybe)
| binaries/data/mods/public/simulation/templates/template_rubble.xml | ||
|---|---|---|
| 8 ↗ | (On Diff #6465) | Rubble might have different values since the entity is much greater in height than corpses of units. |
Comment Actions
Usually what is done is that there is a number of ragdolls set by the engine. The way it could be implemented would be to iterate through all decaying entities and remove the one that have decaying for the longest until you reach the number set.
I'd rather have the FPS impact analyzed and precised a bit more before we reduce the benefits of the corpses.
Could you write a small guide on how to profile that ? It'd be nice to have comparison between versions. Of course I know it'll be off because of the scripting and engine changes but it should still give insight.
Comment Actions
That'd probably be more expensive than just increasing the sink rate dependent on the number of corpses relative to the preferred max. Doing it that way doesn't require any extra iterations over the corpses and doesn't cause corpses to suddenly disappear.
Comment Actions
One can start a match, have a stationary camera, notice the FPS rate, then see how it impacts when units are moved into view without changing the camera perspective and having them die (units can be moved with controlgroups for instance).
If one wants more elaborate tests, code would have to be written to setup a scene I think.
Comment Actions
Fps count seems highly imprecise, also it shouldn't take pathfinder and other stuff into account if it is to measure graphic lag