Summary: In which decor items are made; cloth uses the mural shader; combat "stun-flashes" are changed; the combat AI sees some minor changes; and a frame-rate problem is found in combat, and fixed.
Greetings and salutations!
This week's screenshot shows some progress on props intended to populate level two's interiors:
The week just past was perhaps one of those odd miscellaneous weeks, in which I ended up working on a variety of things with only tenuous connections:
Monday, September 17. 2018
Interior Decoration
First of all, the items shown in the above screenshot: One of the major pieces of work done in the week just past went into things with which to fill out level two. It's a desolate place, long-abandoned--but it's not entirely empty. Various scraps and artefacts remain behind, echoes of the lives once lived there.
The element that I'm perhaps happiest with is the representation of frayed cloth, as seen above carpeting the floor, and in a scrap hanging from the wall. This uses the mural shader created for level one, but with appropriate textures and scales applied, I think that it works quite nicely for this purpose, too!
Doing so involved further parameterising the mural-shader: there were two factors that, while appropriate for the murals, didn't work out as well with my intended cloth textures. As parameters, they can now be further tuned to a specific use.
As a result of introducing these new parameters, I ended up re-exporting level one, with the relevant parameters added to its murals. A minor nuisance, but nothing serious. And it did allow me to test a potential optimisation that I had in mind--it didn't work out, but at least I have that answer now!
The bowl and wooden chest seen above are based on previously-made models, by the way, and the animated version of the chest re-uses the old chest's animations.
(Although I did attempt a more-complex version of the chest--only to find that it had over six thousand vertices, which seemed a bit much for such a model! I thus went back to an earlier attempt, building on that earlier chest-model, and produced something with only about one-and-a-half thousand vertices, as I recall.)
I also did some work on the combat mechanic.
To start with, I changed the "stun-flash" animation a little: where it previously appeared as two spikes entering from the sides, it now expands outwards from the centre. I think that it feels a little better this way, although I'm not yet confident that I'm happy with it.
I also attempted to force enemies to use attacks that they had been neglecting. This proved somewhat tricky, in particular in determining just what condition I wanted to look for. Should I be comparing the number of uses per attack to the average, for a given total number of attacks? How many attacks have been made since a given attack had been used? Something else? And should I be looking to break "streaks" of attacks?
What I have now seems to work, I think, although once again I'm not yet confident that I'm happy.
On a minor note, I increased the rate at which the second mummy-enemy's tendency to use their "flurry" attack increases when they're hit by rapid attacks from the player.
I think that it was during testing of one or more of the above combat changes that I noticed something odd: while the (admittedly simple) test-level ran happily at well over a hundred frames-per-second, combat ran at around seventy--despite being pretty simple itself.
Via Panda3D's performance tool, PStats, I saw that there seemed to be an increase in something to do with "bounds", which seems to have been of little importance in this case, and in drawing the scene, which was quite salient.
In particular, it seemed that the floor was the major culprit: removing it or having its shader just output pure white caused the frame-rate to jump up. Oddly, it seemed that the more frequently the floor's texture was repeated, the lower the frame-rate became.
But why should drawing so simple a scene be so expensive (relatively speaking, at least)? And why was the floor such a problem?
Asking on the Panda3D forum, it was suggested that the problem was a lack of mip-mapping. And indeed, a quick test indicated that this was the case: forcing the engine to use mip-mapping significantly increased the frame-rate!
Why then was mip-mapping not enabled? Especially as I had good reason to believe that it was enabled elsewhere in the game.
As it turned out, the answer was in how I was loading textures to be applied to the floor: in the method used for explicitly loading textures, the mip-mapping settings are optional. By setting mip-mapping as appropriate, the frame-rate in combat increased again, and now happily runs at well over a hundred frames-per-second, I believe.
And once again, a few things were done that don't seem worth detailing here.
That then is all for this week--stay well, and thank you for reading! ^_^
The element that I'm perhaps happiest with is the representation of frayed cloth, as seen above carpeting the floor, and in a scrap hanging from the wall. This uses the mural shader created for level one, but with appropriate textures and scales applied, I think that it works quite nicely for this purpose, too!
Doing so involved further parameterising the mural-shader: there were two factors that, while appropriate for the murals, didn't work out as well with my intended cloth textures. As parameters, they can now be further tuned to a specific use.
As a result of introducing these new parameters, I ended up re-exporting level one, with the relevant parameters added to its murals. A minor nuisance, but nothing serious. And it did allow me to test a potential optimisation that I had in mind--it didn't work out, but at least I have that answer now!
The bowl and wooden chest seen above are based on previously-made models, by the way, and the animated version of the chest re-uses the old chest's animations.
(Although I did attempt a more-complex version of the chest--only to find that it had over six thousand vertices, which seemed a bit much for such a model! I thus went back to an earlier attempt, building on that earlier chest-model, and produced something with only about one-and-a-half thousand vertices, as I recall.)
I also did some work on the combat mechanic.
To start with, I changed the "stun-flash" animation a little: where it previously appeared as two spikes entering from the sides, it now expands outwards from the centre. I think that it feels a little better this way, although I'm not yet confident that I'm happy with it.
I also attempted to force enemies to use attacks that they had been neglecting. This proved somewhat tricky, in particular in determining just what condition I wanted to look for. Should I be comparing the number of uses per attack to the average, for a given total number of attacks? How many attacks have been made since a given attack had been used? Something else? And should I be looking to break "streaks" of attacks?
What I have now seems to work, I think, although once again I'm not yet confident that I'm happy.
On a minor note, I increased the rate at which the second mummy-enemy's tendency to use their "flurry" attack increases when they're hit by rapid attacks from the player.
I think that it was during testing of one or more of the above combat changes that I noticed something odd: while the (admittedly simple) test-level ran happily at well over a hundred frames-per-second, combat ran at around seventy--despite being pretty simple itself.
Via Panda3D's performance tool, PStats, I saw that there seemed to be an increase in something to do with "bounds", which seems to have been of little importance in this case, and in drawing the scene, which was quite salient.
In particular, it seemed that the floor was the major culprit: removing it or having its shader just output pure white caused the frame-rate to jump up. Oddly, it seemed that the more frequently the floor's texture was repeated, the lower the frame-rate became.
But why should drawing so simple a scene be so expensive (relatively speaking, at least)? And why was the floor such a problem?
Asking on the Panda3D forum, it was suggested that the problem was a lack of mip-mapping. And indeed, a quick test indicated that this was the case: forcing the engine to use mip-mapping significantly increased the frame-rate!
Why then was mip-mapping not enabled? Especially as I had good reason to believe that it was enabled elsewhere in the game.
As it turned out, the answer was in how I was loading textures to be applied to the floor: in the method used for explicitly loading textures, the mip-mapping settings are optional. By setting mip-mapping as appropriate, the frame-rate in combat increased again, and now happily runs at well over a hundred frames-per-second, I believe.
And once again, a few things were done that don't seem worth detailing here.
That then is all for this week--stay well, and thank you for reading! ^_^
Trackbacks
Trackback specific URI for this entry
No Trackbacks