Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Nighteyes on August 03, 2009, 07:49:14 pm
-
Hi guys :)
I assume you all know how when a capship propagates when dieing, the resulting explosions stack onto each other, creating a very bright\white effect, without really being able to see the details of the explosion itself...
this is caused because the game uses an "add" filter on the explosion, similar to the one in photoshop, now, if its possible to change the filter to something like "screen" filter(as in displaying the effect with its opacity, without intensifying it when on top of another effect) in photoshop, the explosions will look 10 times better :D
on a side note, is there a way of determining the time it takes the ship to propagate? the Colossus if I remember correctly took ages to finish propagating, but other ships propagated very fast...
Thanks :)
-
It doesn't use a shader for that...
And anyway, the problem is that in order to make them not add up the way they do, they'd have to be sorted and drawn in order from back to front (based on distance from the camera), which would eat up processor time. The current setup produces the same results regardless of the order the explosions are drawn in, and thus avoids the need to sort them.
Simply put, though, it's not as easy to do photoshop-like 2d blending as you might think.
-
The time it takes is determined by either the hitpoints of the ship or the damage caused by the explosion of the ship. I know the more damage an exploding ship does the longer it takes to explode (overrideable by the kamikaze flag).
-
It doesn't use a shader for that...
And anyway, the problem is that in order to make them not add up the way they do, they'd have to be sorted and drawn in order from back to front (based on distance from the camera), which would eat up processor time. The current setup produces the same results regardless of the order the explosions are drawn in, and thus avoids the need to sort them.
Simply put, though, it's not as easy to do photoshop-like 2d blending as you might think.
Well considering that it would "eat up" the processor in the same manner as using alpha mapped explosions, I don't really think its a factor, and as the ability to add alpha mapped effects was added to the code, I assume there is someone here that is familiar with how these things work :)
I know its not that simple,but as I said, we will have a much nicer game if possible :)
-
they'd have to be sorted and drawn in order from back to front (based on distance from the camera)
This will eat your processor. Also I'm not sure that the infrastructure for sorting that kind of effect currently exists.
-
they'd have to be sorted and drawn in order from back to front (based on distance from the camera)
what I meant is keeping the way they are drawn out the same as it is now, as in all facing the camera, not based on distance, just remove the brighten filter thing :)
What I mean is use effects only based by their opacity, If we want certain explosions to look brighter, we can add the glow\adjust brightness when creating the explosion... not having the game force this brighting thing on us...
as it is now, it doesn't really matter what explosion I use, as we get to see mostly white centers, and only the outskirts of the actual explosion...
here is an example I made:
(http://img9.imageshack.us/img9/3281/comp1000971.jpg)
By gbtf67 (http://profile.imageshack.us/user/gbtf67) at 2009-08-04
(http://img23.imageshack.us/img23/4544/comp100097.jpg)
By gbtf67 (http://profile.imageshack.us/user/gbtf67) at 2009-08-04
-
Nighteyes, rendering explosions additive is very simple.
You don't have to sort them.
When two explosions overlap, on each pixel in the overlapping area, the color values from the corresponding pixels of the explosions will be added to the color of the pixel of the background.
The order doesn't matter. 1+2+3=6 2+3+1=6 3+1+2=6
Once there is alpha you have to sort them.
FS2 didn't really sort this stuff originally, afaik.
Taylor improved the sorting a lot already, but don't underestimate it.
With camera-facing sprites, it might still be "easy", but once you've odd-shaped alpha geometry, there will be some situations when it will be impossible to sort them right.
Just an example. Two meshes with an alpha texture intersect like this:
(http://i28.tinypic.com/2hrl3br.jpg)
Now... the engine has to render one of them first and it will cover the other one.
Which one would you render first? :drevil:
So much for the sorting.
The other thing you request sounds like a pretty complex shader+screen effect system.
It might be possible with just a shader and a modified blending (not just additive) though.
-
When two explosions overlap, on each pixel in the overlapping area, the color values from the corresponding pixels of the explosions will be added to the color of the pixel of the background.
This is what I want to remove, I don't want them to add the color to the pixel under it... this is what creates the super bright explosions...
The other thing you request sounds like a pretty complex shader+screen effect system.
It might be possible with just a shader and a modified blending (not just additive) though.
Yeah, a modified blending shader is what we need, modified to not add to the color :) no need for a complex screen effect :D
If this can be achieved... ahh... the pure beauty of what awaits... :D
-
Well, the only things you can do without sorting are "add" ""subtract" and "multiply".
Once you mix them, you'll have to sort again...
-
ahh so it looks like some sorting is in order... :(
how hard is it? maybe I can give it a go? where do I check stuff like this out? will someone be able to give this some time? :)
-
It would have to be in the rendering engine. Something I don't feel like touching with a 10-foot pole at the moment. :p
To be fair, my motivation is low... as I've mentioned before, I like the stacking effect, since it makes for a sort of "poor man's bloom." I actually prefer the first screenshot mockup to the second one. :D
-
Wait, that's a comparison? Yeah, I like the first one better, too. Until it was pointed out I didn't even see a difference.
-
sushi, you don't get what I'm saying, if we can fix this thing, we can create this fake bloom in a controlled manner, by just adding some glow to the effect...
those shots aren't good, the game generates much more explosions then I had in my test... as your a tough crowd, here are some test ingame...
Original explosion, without stacking... very natural, has depth and detail...
(http://img190.imageshack.us/img190/383/screen0392.jpg)
By gbtf67 (http://profile.imageshack.us/user/gbtf67) at 2009-08-04
(http://img33.imageshack.us/img33/5756/screen0393.jpg)
By gbtf67 (http://profile.imageshack.us/user/gbtf67) at 2009-08-04
same effect stacked 20+ times in the game... superbright stacked explosion, no detail at all in the middle, just one big white blob, especially ugly when looking at a white blob filling half the screen... in motion its even worse, since all the middle part is white and static while the outer parts are moving...
(http://img16.imageshack.us/img16/4219/screen0388.jpg)
By gbtf67 (http://profile.imageshack.us/user/gbtf67) at 2009-08-04
(http://img33.imageshack.us/img33/3580/screen0390.jpg)
By gbtf67 (http://profile.imageshack.us/user/gbtf67) at 2009-08-04
-
I understand that it allows for more artistic freedom (including bloomy effects) but my big worry is the computational complexity and overhead involved (what DaBrain was talking about). If it turns out that the cost is overstated, then I'll be as happy as anyone else. :D
In the meantime...maybe a MAX filter? Instead of adding the two values, it would simply take the brightest of the two and use that? That at least sounds easy (I'm not familiar with the rendering engine) and might give less washed-out results... anybody more familiar with rendering want to chip in on that?
-
hmm a MAX fillter? I can make one... but does the engine supports things like that?
-
So yeah, we've all been saying the same thing, and you've been ignoring it.
The reason we can't "not add them" is because any other blending alternative would require us to sort them based on depth.
And furthermore,
hmm a MAX fillter? I can make one... but does the engine supports things like that?
No, as I said in the first reply you got (or tried to explain, anyway), the engine does not support 'filters' period.
And the engine's support for alpha-blended explosion sprites seems to be shoddy anyway.
-
I do understand that it will need to be sorted based on depth... similar to the way it does alpha blended explosions... only a bit differant...(always showing the brightest pixel)
-
just because photoshop or max can render something like that, doesn't mean the math can be done in real time fast enough to allow a playable frame rate. for example try working on a huge texture (were talking 4096^2 or bigger) on an average computer. you will be twiddling your thumbs for at least a couple seconds every time you change something.
-
I think you may have misinterpreted the 'MAX filter' statement.
I read that as meaning "For each pixel, if NEW_PIXEL brightness > CURRENT_VALUE, then CURRENT_VALUE := NEW_PIXEL"
That will automatically prevent the existing 'clamping to white', isn't dependent on processing order and doesn't actually require an Alpha channel at all.
However, I don't know how easy that is to implement.
-
Nighteyes, rendering explosions additive is very simple.
You don't have to sort them.
When two explosions overlap, on each pixel in the overlapping area, the color values from the corresponding pixels of the explosions will be added to the color of the pixel of the background.
The order doesn't matter. 1+2+3=6 2+3+1=6 3+1+2=6
This seems to simple to work but..
What if you averaged it?
1+2+3=6/3 = 2
-
Then around the edges of explosions (where it's black), you'd be darkening stuff from whatever brightness it was to half that brightness. It would look crazy.
-
Then around the edges of explosions (where it's black), you'd be darkening stuff from whatever brightness it was to half that brightness. It would look crazy.
.... then dont count zeros? or lower than any number not considered visable?
-
Well then, it's no longer the 'simple' formula you proposed.
-
Per-pixel Maximum function as suggested by Sushi is relatively computationally cheap, but I'm not sure how it'll look in practice.
- I don't think Photoshop has that filter, so it's hard to try out.
-
Well then, it's no longer the 'simple' formula you proposed.
why not? just ignore the values? just add a ( x >= y) before the average. or you can still ad 0's just divide the average by the visible pixels present, for example, lets say we have 5 pixels; 1, 3, 3, 0, 0,
if n<=0 then, y+1, x+1
if n>0 then, x+1
(1+3+3+0+0)/(X-y)
X = total intergers added to average
y = intergers equal to or less than 0
or if its simpler, change the equation to take out 0's without ever averaging them in the first place.
-
Well then, it's no longer the 'simple' formula you proposed.
why not? just ignore the values? just add a ( x >= y) before the average.
I believe that would require depth sorting. But it's the best I've heard so far, actually.
or you can still ad 0's just divide the average by the visible pixels present, for example, lets say we have 5 pixels; 1, 3, 3, 0, 0,
if n<=0 then, y+1, x+1
if n>0 then, x+1
(1+3+3+0+0)/(X-y)
X = total intergers added to average
y = intergers equal to or less than 0
or if its simpler, change the equation to take out 0's without ever averaging them in the first place.[/color]
AFAIK that's not (easily) possible, because there's no (easy) way to keep track of all of the colors drawn to a certain pixel. At least, not without all-out support for deferred rendering, and even then I don't know.
-
What stops you from sorting depth by order of effect creation? Or is the system already so f--ked up that something that hackish is still a royal pain in the balls.
-
So far as I know, we don't have depth sorting of any kind right now. See Mantis 1583 (http://scp.indiegames.us/mantis/view.php?id=1583)
-
for particles and weapon effects there is no sorting, they are drawn more or less in the order they were first created, IIRC.
interestingly the SHIPS could be drawn sorted relatively easily if the internal geometry format was just a tiny bit more flexible.
-
Depth sprites are usually used by most game engines today to make explosions seem rounder/ clip to the surrounding geometry spherically. It's a pretty simple concept, get a pre rendered depth map of a sphere then using shaders, use the values of that map based on the Texture coords of the explosion sprite and add them to the depth values of the fragments. Then we let z-buffering take it from there.
Too bad fireballs are renderred using the fixed pipeline right now. Maybe I or someone else should work on that :p
-
Well then, it's no longer the 'simple' formula you proposed.
why not? just ignore the values? just add a ( x >= y) before the average.
I believe that would require depth sorting. But it's the best I've heard so far, actually.
No, it would not require depth sorting. It does not matter in which order the values are added before the averaging of the non zero values. This is no different than the MAX(x,y) function, it does not matter in which order you find the MAX of a list of numbers, you will still find the same maximum number.
As for accessing the colour information, I don't know how the engine processes and renders explosions and cannot comment on it. But algorithmically MAX(x, y) and average_non_zero both on about the same level, except average_non_zero would require keeping track of both the zero values and the total values for the average.
-
Depth sprites are usually used by most game engines today to make explosions seem rounder/ clip to the surrounding geometry spherically. It's a pretty simple concept, get a pre rendered depth map of a sphere then using shaders, use the values of that map based on the Texture coords of the explosion sprite and add them to the depth values of the fragments. Then we let z-buffering take it from there.
Too bad fireballs are renderred using the fixed pipeline right now. Maybe I or someone else should work on that :p
That would be a requirement to allow custom shaders anyway... so there is no way around it.
-
Per-pixel Maximum function as suggested by Sushi is relatively computationally cheap, but I'm not sure how it'll look in practice.
- I don't think Photoshop has that filter, so it's hard to try out.
lighten only.
-
Well then, it's no longer the 'simple' formula you proposed.
why not? just ignore the values? just add a ( x >= y) before the average.
I believe that would require depth sorting. But it's the best I've heard so far, actually.
No, it would not require depth sorting. It does not matter in which order the values are added before the averaging of the non zero values. This is no different than the MAX(x,y) function, it does not matter in which order you find the MAX of a list of numbers, you will still find the same maximum number.
As for accessing the colour information, I don't know how the engine processes and renders explosions and cannot comment on it. But algorithmically MAX(x, y) and average_non_zero both on about the same level, except average_non_zero would require keeping track of both the zero values and the total values for the average.
It would be a good idea to use proper alpha value from the texel, this would allow smooth gradient from invisible to visible.
The problem with custom blending is that no hardware supports it, so it must be made with couple of tricks.
Easiest might be rendering explosions into a different buffer and composite later with the image.
Finding MAX should be possible by writing the explosion brightness into a Z-Buffer and right color would be the last visible. (if one needs blending between explosions, sort particles and render them as feathered particles.)
Write alpha into texture. (how you blend here affects the transparency of explosion, not color.)
Now we have color and alpha and transparent buffer ready to be composited to a final image. (before post processing.)