It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
So I was watching this video:

https://www.youtube.com/watch?v=PPaZZxPkkPs&list=LLgqvaRMMAe6_DzwDX8VofHg

It's a little "behind the scenes" look at Halflife from back when it was still in development. They mention that the game used a "new" system for modifying textures in realtime, which allowed them to do stuff like scorch marks, bullet holes, bloodstains, etc. It seems to me that this allows for a theoretically infinite number of modifications, leading to persistent bullet holes, scorch marks, bloodstains, etc, instead of the disappearing kind we're used to. In fact, that's exactly what happens in Halflife. You can put as many bullet holes in things as you'd like, and you won't ever seen them disappear.

So my question is, for anyone who knows anything about this sort of things, why don't more games do this?
Well, usually games use decals to put the scorch marks and whatnot in there, the more decals (textures) mapped onto a surface, the bigger the RAM impact, if there are too many relative to the available space in memory, it may start to stutter, so one way to alleviate that is to put a "life" into them, so they start disappearing after certain amount of time, or after certain amount of decals on screen.

Now, in relation to Valve´s technology I can´t say, it´d be interesting to know since there can´t be anything more disrupting of the suspension of disbelief than disappearing scorch marks (well maybe disappearing models :P). It´d be good to know the pros and cons of such implementation.
avatar
LoboBlanco: Well, usually games use decals to put the scorch marks and whatnot in there, the more decals (textures) mapped onto a surface, the bigger the RAM impact, if there are too many relative to the available space in memory, it may start to stutter, so one way to alleviate that is to put a "life" into them, so they start disappearing after certain amount of time, or after certain amount of decals on screen.

Now, in relation to Valve´s technology I can´t say, it´d be interesting to know since there can´t be anything more disrupting of the suspension of disbelief than disappearing scorch marks (well maybe disappearing models :P). It´d be good to know the pros and cons of such implementation.
I would love to know also. I've always loved it when games have persistent destruction/changes to the environment, even if it's something as simple as bullet holes and blood stains that don't disappear after 30 seconds.

Hmm... perhaps I need to find a Halflife modding community. They might know.
avatar
jefequeso: I would love to know also. I've always loved it when games have persistent destruction/changes to the environment, even if it's something as simple as bullet holes and blood stains that don't disappear after 30 seconds.
Take Dawn of War as an example, as it's a fairly good one. It's not nearly as easy to achieve with a modern computer with solid ammount of RAM, but the game's performance on my older computer took a serious hit with the persistent bodies feature on. Basically, DoW has battles where dozens of soldiers kill each other every minute, and with persistant bodies, all bodies and blood decals stay where they got created. Awesome effect, battlefields are filled with piles of corpses after a lengthy skirmish... Buut, it also progressively gets slower and slower.

Problem is that decals are basically textures applied over the original texture of a model, let's say a wall. And any given wall will only have a single texture applied on it - well it can have multiple, but the point is that they're fixed and pretty hard to change. And any given decal is another, completely different entity with a different texture that your computer needs to keep track of, and it needs to constantly redraw the displayed scene with all the original textures and then apply the decals on top of them, about 60 times every second. Now when there's just a few bullet holes, that's fine, but ... Just imagine what happens when it needs to keep track of 2000 or more.
avatar
Fenixp: Problem is that decals are basically textures applied over the original texture of a model, let's say a wall. And any given wall will only have a single texture applied on it - well it can have multiple, but the point is that they're fixed and pretty hard to change. And any given decal is another, completely different entity with a different texture that your computer needs to keep track of, and it needs to constantly redraw the displayed scene with all the original textures and then apply the decals on top of them, about 60 times every second. Now when there's just a few bullet holes, that's fine, but ... Just imagine what happens when it needs to keep track of 2000 or more.
The description in the OP (I confess I haven't watched the video) sounds like they just applied, for example, the bullet hole decal directly to the wall texture in memory, so that every time the wall was redrawn, it included the bullet holes. The problem with that approach is of course that every wall using that texture would then have the same bullet holes.

Maybe what they did was for every object that needed modification (for example every object struck by a bullet), a copy of the texture was created in memory, most likely transparent, but with the same dimensions as the original texture, and then the decals were applied to that. Then it wouldn't matter if it was a single bullet hole or 50,000 bullet holes, the wall would still only need to be drawn twice per frame. This would naturally take up quite a bit more memory, but would be less stressful to the GPU.
avatar
Wishbone: Maybe what they did was for every object that needed modification (for example every object struck by a bullet), a copy of the texture was created in memory, most likely transparent, but with the same dimensions as the original texture, and then the decals were applied to that. Then it wouldn't matter if it was a single bullet hole or 50,000 bullet holes, the wall would still only need to be drawn twice per frame. This would naturally take up quite a bit more memory, but would be less stressful to the GPU.
It doesn't really matter, you still need to keep the added textures somewhere and it will still lead to issues at one point or another. As awesome as persistant changes may be, limiting them in some way is still the best way to go from a programming standpoint (well the best way would be to set the limitations dynamically based on availible resources, but ... Hey, no one's gonna put that much work into bulletholes.)
avatar
jefequeso: So my question is, for anyone who knows anything about this sort of things, why don't more games do this?
Because not even Half-Life does it this way.

Note that in Half-Life decals do not just get merged into some texture. Proof? Hit the same spot multiple times with the crowbar. Earlier decals will sometimes disappear when a new one is generated nearby (which sometimes results in funny situations where a bullet hole will wander around the wall if you move the crosshair slowly). This means that actually each decal is and remains an individual instance. Another thing you should take into account is that Half-Life's saved games grow notably in size as new bullet holes are generated. So this system is not as perfect and limitless as it may have sounded in the video.
Post edited January 21, 2013 by F4LL0UT
avatar
jefequeso: So my question is, for anyone who knows anything about this sort of things, why don't more games do this?
avatar
F4LL0UT: Because not even Half-Life does it this way.

Note that in Half-Life decals do not just get merged into some texture. Proof? Hit the same spot multiple times with the crowbar. Earlier decals will sometimes disappear when a new one is generated nearby (which sometimes results in funny situations where a bullet hole will wander around the wall if you move the crosshair slowly). This means that actually each decal is and remains an individual instance. Another thing you should take into account is that Half-Life's saved games grow notably in size as new bullet holes are generated. So this system is not as perfect and limitless as it may have sounded in the video.
Really? Well, ok. My experience with Halflife was that you seemed to be able to make tons of bullet holes etc without having any of them disappear, but apparently it was just that it allowed for a ton of decals. From the way they talked in the video, I assumed that realtime changes were somehow being made to the texture.
avatar
jefequeso: From the way they talked in the video, I assumed that realtime changes were somehow being made to the texture.
Yeah, it sounds this way in the video and that method is being used by some 2D games to allow for an infinite number of bodies, blood, craters etc. but having one texture that spans a 2D map with a fixed size is a totally different story than generating another texture for each surface present in a 3D level. Either way, there seems to be something special about Half-Life's way of dealing with decals - sadly I'm having trouble to find any information on how the GoldSrc engine handles them in detail.
avatar
Fenixp: It doesn't really matter, you still need to keep the added textures somewhere and it will still lead to issues at one point or another. As awesome as persistant changes may be, limiting them in some way is still the best way to go from a programming standpoint (well the best way would be to set the limitations dynamically based on availible resources, but ... Hey, no one's gonna put that much work into bulletholes.)
Of course, TANSTAAFL. There Ain't No Such Thing As A Free Lunch. Whichever solution you choose, you will eventually run into a bottleneck. The trick is to choose the solution for which the bottleneck is the furthest away.