Greetings and salutations!
Before I begin, I've only recently joined up here on IndieDB, and so I'm somewhat jumping in at the middle of this devlog. If you want to see previous entries, you can find them either on my personal website (Thaumaturge-art.com) or in my TigSource devlog-thread.
This week's screenshot is an excerpt from the work-in-progress intro-cutscene to level two. It's an establishing shot of the location of the level, Tenereth:
The week just past was largely another art-week, but in which a few other things were dealt with, too--including one surprising, initially-mystifying, and slightly annoying issue...
To start with, the art: During the week just past I continued to work on the intro cutscene for level two. I finished off the backdrop for the fourth scene, painted the backdrop for the second (which is shown in the screenshot above), and started in on the backdrop for the third. Furthermore, I implemented the second scene; like the first scene, it's a simple one.
Overall, I'm fairly happy with my progress there! ^_^
On the technical/gameplay side, what should happen when the player falls from sufficient height that it incurs a warning that too great a fall results in death? Up until the week just past, such a fall (or rather, the impact that ended it) had three effects: First, a red border signifying "pain" would appear on the screen--much as when the player is injured in combat. Second, the character exclaimed in pain. And third, the player's movement was briefly slowed a little.
In the week just past, I removed that last effect. In short, I felt that it added little, and that the gradual recovery of movement speed made the point of complete restoration somewhat hard to detect. Indeed, it occurs to me that in a game in which leaps are so important, and in which jump-distance is affected by speed, having the player's current maximum speed be unclear--even if briefly--was likely a poor idea.
I also fixed or tweaked a few things in level two.
To start with, a particular curb no longer visibly pops into view, and I changed the distance at which a few objects were examinable. (The latter to prevent them from being examined before taking the jump that leads to them.)
Perhaps more interesting was an odd issue involving transparency:
I think that it was in the week before last that I discovered that there was a rendering issue at at the edges of certain stains on a certain table-top: through those edges I could see objects behind the table.
Thinking that I had simply forgotten a tag on the stain-objects, I checked them--but they seemed to be comparable to various other, well-behaved stains around the level.
I activated a debug mode in Panda3D that flashes transparent objects, and looked at the stains. And here I discovered something very odd: it looked as though the tables were draped by some unknown, fully-transparent object!
And indeed, having transparent objects overlap can result in rendering issues.
And yet, when I examined the scene in Blender, I found no such object. It was perplexing.
Eventually, I realised what was likely happening: there was indeed no such additional object. The transparent object was, in fact, the table itself--or rather, part of the table--some of it was being treated as opaque, and some of it was being treated as transparent!
It would seem that the reason for this was that some of its vertices had vertex-colours with alpha-values (that is, "opacity" values) less than one (one being "fully opaque"). Panda3D was detecting that transparency, and thus sorting those elements into the "transparent" rendering-bin.
Furthermore, I discovered that there were a number of such objects scattered around the level--although these others were fairly harmless, I think.
In some cases I think that it was due to the use of vertex-colours to store information for my shaders; in others, it was likely the result of their use to inform some of the scripts that aided me in building level two. (And there may have been some that gained such colours by accident.)
It was a bit of a frustrating issue, as I recall. :/
Thankfully, however, the solution was quite simple: asking on the Panda forum, I was directed to a tag that I could add to such objects that essentially marked them as "not transparent". With this in place, the troublesome table is (and other such objects likewise are) treated as being opaque, it seems--and thus no longer incur transparency-ordering issues with stains placed atop!
That then is all for this week--stay well, and thank you for reading! ^_^