• Please make sure you are familiar with the forum rules. You can find them here: https://forums.tripwireinteractive.com/index.php?threads/forum-rules.2334636/

A (semi) technical question on gore/enviroments

Angry Hillbilly

Grizzled Veteran
Mar 20, 2009
175
38
Hampshire, England
I've read the PC gamer articles a hundred times over in excitement and something that has really caught my eye is the permanent gore system and I noticed how you said that you are modifying the textures live in game to save a ton of memory so the gore can stay.

This got me and my flat mate talking on the ways you might have done this. Because we were both saying that with the amount of constant (awesome!) gore and layers building up reloading that texture constantly would also eat up memory.

The only way we could think you may do this is in bulk by still using projected gore and converting to texture in bulk (after a certain amount of memory use reached or a timer) or if it is real time you have some mega optimisation there. Or is there some really cleaver third way I can't think of ;)

Also does this texture swapping only apply to gore? Do other decals such as bullet holes apply? Can I have the pleasure of writing in the wall in bullets and having it stand for the entire game? :p
 
Computationally cheap and easy way would be like the blood overlays in RO2:

Essentially you have a blood texture, your base texture, and a number of masks whose alpha is assigned to scalar parameters (that the game's code can alter.) So in RO2 you call a function on the pawn when he gets blown to hell that modifies these parameters and suddenly he's covered in blood like he ought to be!

Now, take note of this screenshot from the article, right around where the blood is being talked about:

CXHvLmz.jpg


Now look how I've marked what appear to be square areas:

eTpXxiM.jpg


This makes me think that the level's textures have a sort of grid layed over them. Each square in the grid is perhaps a separate entity with its own texture that somehow reacts to zed deaths within it , or shots passing through a zed and into it etc. The grid squares would seem to (literally) bleed over into adjacent and bloody squares to prevent a tic-tac-toe board effect (bloody squares with clean outlines.) So they could have a bunch of different variations on the masks that show the blood for variety and to blend with adjacent squares. Then you scale the amount of blood on each square with the amount of zed deaths etc. that have happened in each.

I don't know much about memory consumption or rendering, but I can surmise from Ramm's statements in the article that the method they're using is designed to minimize the rendering cost. So assuming all the grid squares are the same size and cost the same to render initially (say R) and you have n squares, you're looking at an initial cost n*R = O(n). If all the squares are identical, then the cost of changing one (to any given blood setting!) is most likely a constant C, where C = O(1) especially if there's a clever way of accessing the square triggered by something dying on it, without iterating through all the other squares.

So if I learned anything this semester :D, the total cost of rendering every square and then covering every square inch of them with blood is C*n + R*n = O(n). It can be done in linear time.

On the other hand, if you've got n squares without this capability and you've got j decals to project at a cost of m then the cost is R*n + j*m = O(n+j*m). Since neither j nor m are constant with respect to the number of squares that cost can get really high really fast, especially considering what Ramm said about the relative costs of projecting decals (m). So normally there's a limit on the number of decals. If you only allow n decals you're back at O(n) assuming m is constant. That of course severely limits how much blood you can have on the map (unless you only use a single blood decal the size of a square to flood the map... Lame!) So for a decent effect I'd say that in general the cost m*j of rendering the max number of decals is going to be a lot higher than the cost R*n of rendering all the squares. In other words this other method would be O(m*j) and less efficient than the first method. Also less effective!


That's not even going into the resources required to remove old decals once the limit is reached or any logic to prevent multiples showing up in the same spot (and wasting yet more resources) whereas the first method could still reset the level in linear time.

So that's my $.02 :) It might be BS, I'm still sweating out my finals knowledge :D
 
Upvote 0
I think my answer didn't require a Computer Science degree. :p


Very nice thoughts though. Although I don't believe a pawns death alone would cause it to create some of the effects, 'cause there are some areas under the bodies without any (noticeable) blood effects. That and there's blood all over the walls (and I don't see any crawlers!). There's gotta be some sort of projection from the Shooter to the wall, and from gibbed objects that touch an area, and potentially the blood sprays themselves (looking at the lower ceiling with splatter on it).
 
Upvote 0
so you kind of mean like:

1)base level textures are present.
2)above level textures, there are blood textures covering the whole map.
-blood texures are initially made invisible (but still present) to give the impression that all you see is just a clean level
3)once zombies have limbs severed or killed, calculations are performed to determine how much more visible the blood texture above the kill spot is
 
Upvote 0
so you kind of mean like:

1)base level textures are present.
2)above level textures, there are blood textures covering the whole map.
-blood texures are initially made invisible (but still present) to give the impression that all you see is just a clean level
3)once zombies have limbs severed or killed, calculations are performed to determine how much more visible the blood texture above the kill spot is

Yep, that about covers what I think happens. In much fewer words too :D
 
Upvote 0