Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: ##UnknownPlayer## on May 10, 2002, 06:43:11 am
-
Currently I've managed to think of two ways to do this though my relative inexeprience with 3D programming means it would take me ages to implement them.
The first is the traditional method where we draw a whole lot of blended polygons textured and blended with the decal. This has a number of problems - beam cannons leave a lot of decals, and ships take a lot of hits so this method would very rapidly pile up the poly count of a scene.
The second method would be to not actually use polygons but instead dynamically modify the textures of the ships themselves. This has a lot of problems though since textures are shared in memory across several models and in different parts of a model. However, it involves no extra poly's but it will need a creative way around the problem of shared textures and such.
So, does anyone have any additional solutions or refinements on my proposed two methods?
-
Uhm, yeah - the way it's always been done in games: paste on a new decal where a weapon hit occurs - oveerlaid on the ships texturing. No need for extra polys.
-
As I understand it not quite otherwise why would we have decal limits? Each decal is a sprite and a sprite has to be drawn on to a polygon - its just blended so only the 2D sprite is visible. The polygon then sits at a certain point on the model. Hence why in some FPS's you can get decals sitting off the walls sometimes.
-
Originally posted by ##UnknownPlayer##
As I understand it not quite otherwise why would we have decal limits? Each decal is a sprite and a sprite has to be drawn on to a polygon - its just blended so only the 2D sprite is visible. The polygon then sits at a certain point on the model. Hence why in some FPS's you can get decals sitting off the walls sometimes.
no, that's not the way it works: look at the shield effect for exemple. A decal would be a bitmap, that's all, but instead of being projected as a 2D bitmap (like engine glows), with only Z scaling, the bitmap will use the normals of the poly were it is applied ( note that it won't use the UV projection of the map applied to this poly ), which will give it rotation and scaling on all the axis, making it look really 3D ( which it is not I think ).
-
decals are handeled in a completly diferen't way, there more like the sheild hit effect, exept they arn't animated (although it would be cool to have a few that were and the last frame was held as a normal decal), and they are blended onto the existing textured polys not the untextured sheild mesh
-
Originally posted by Bobboau
and they are blended onto the existing textured polys not the untextured sheild mesh
nah, otherwise, they'd be stretched. In other games like FPS, maps aren't usually applied on perfect square surfaces, and still they are generally square (256*256 etc). If it was blened on the maps, the decal would be completly deformed most of the time.
-
Didn't they implement this feature in XWA?
-
Originally posted by sandwich
Uhm, yeah - the way it's always been done in games: paste on a new decal where a weapon hit occurs - overlaid on the ships texturing. No need for extra polys.
That is generally how it's done. There are decal limits because each poly that has decals that need to be applied has to have its texture stored seperately, instead of sharing textures as the program would in a normal situation. This dramatically increases the amount of memory required.
-
In Bridge Commander, it took a certain amount of damage at the point to cause a damage decal. If it continued to get hit there, the hull is "burned" away and a separate mesh is shown through the hole in the outer mesh. This caused some pretty interesting effects, like a Galaxy-class with it's forward torpedo tube are burned away or with a large chunk of it missing on the back.
-
Ok, well I doubt we''re going to be putting something like geo-mod in any time soon so let's focus on how we should do decals.
EDIT: People I did some research and it turns out that I'm right and your wrong. Yes we do just paste a decal there, but the decal as I said has to be pasted onto a new polygon (a square to be precise) that gets sized to be no larger then the face the decal is going onto. For more info go here: http://www.flipcode.com/tutorials/tut_decals.shtml (http://www.flipcode.com/tutorials/tut_decals.shtml)
-
that is A "simple way to do it"
-
Still, if you'll note the end it is also the way Quake III does it and I imagine that the id guys would know a thing or to. Still, I'll keep looking for examples of other methods but as far as I know this is the most common (thought that could be coz Quake engine games are among the most common).
-
I don't know if some one said this but couldn't you make a special map of the ship (damage) then weapon hits would 'uncover' the map so a long line of damage wouldn't be just a line of damage decals???
-
Hmm...its possible. The easiest way to do it would be to just chnage the texturing of individual polygons. Problem is it would have to be solid otherwise it might not create the right effect for weapons. And on capchips we'd have issues....
-
Originally posted by ##UnknownPlayer##
Still, if you'll note the end it is also the way Quake III does it and I imagine that the id guys would know a thing or to. Still, I'll keep looking for examples of other methods but as far as I know this is the most common (thought that could be coz Quake engine games are among the most common).
That is the most common method of doing it. I had thought it was pasted on the original poly (it actually is in some games), but that requires more texture memory, so they avoid that nowadays by using the method you said, because it allows both the original textures and the decal textures to be in memory only once. The drawback is that it increases the poly count, but unless there's a LOT of decals, it isn't likely to matter.
-
Originally posted by Mysterial
That is the most common method of doing it. I had thought it was pasted on the original poly (it actually is in some games), but that requires more texture memory, so they avoid that nowadays by using the method you said, because it allows both the original textures and the decal textures to be in memory only once. The drawback is that it increases the poly count, but unless there's a LOT of decals, it isn't likely to matter.
a lot, indeed. a quad= 2 polys :p
-
The polycount thing is the problem - beams cannons would leave A LOT of decals on a ship so we'd probably want to cull them and tile the decal across just one or something, which would be a fairly complex thing to do. Then we've also gotta handle hits from fighters, which there are several thousand in any given mission where we attack capships. Lots of code would be needed to intelligently handle them.
-
we'd want to handel beams diferently, like takeing the start and end points and have a few specal beam decal textures
-
Really good idea there! I hadn't thought of that.
-
There are two ways to approach this problem in general.
- Paste-on decals. You project a rectangular or cone shaped volume onto the model and generate vertices where the volume clips against the polys of the model. In theory this is the "best" way to do it since you're generating the smallest possible polys for the decals. But it suffers from the venetian blind problem. That is, because the vertices of the decal poly aren't the same as the vertices of the poly its being drawn on top of, inaccuracies in the 3d rotation/projection code will cause them to have slightly inconsistent Z values. So the two of them will end up "fighting" for the zbuffer in a view-dependant manner. There are 2 fixes for this. First is to use the "z bias" setting available in D3D. The squad logos use this to work properly. Alternately, you can multiply 1/z value of each of the projected verts by some slightly-greater-than-1 value to fake their depth "out" of the wbuffer. For small decals (where "small" means small onscreen) this is the preferred method. But if you do this for blast decals which could be applied to, say, the side of a capital ship, they could potentially end up very large onscreen. In this case, you'd need to use a larger value to mess with the 1/z depth and that's going to result in really ugle view-dependant warping of the decal. Which brings us to method 2 :
- Multi-pass decals. As with the paste-ons you're projecting a 3d volume onto the model and "clipping" it against each relevant face. But the difference here is that instead of calculating vertex points, you just calculate texture UV's to map the decal texture onto the existing model verts. Kind of like a lightmap. As long as you draw the decal face with clamping enabled, you're all good. The main advantage is that you'll never have zbuffer fighting. The main disadvantage is that you're going to end up drawing more pixels per decal. In theory this could eat away framerate. But on newer 3d cards, maybe that's not an issue.
I'm not sure which I'd use in this particular case. If I were going to implement this for a "real" game in this circumstance, I'd probably go with method 2 and impose some hard limits on the # of decals per ship or something like that, to make sure fillrate doesn't skyrocket.
-
hmmmm... you talk a lot about the poly count drawing too much mem, but here's what I think:
What really may slow the game are textures. Why?
Take starlancer for instance: a fighter there has 1200 polys!! Darn too much for FS, but in Starlancer in my old 800 MHZ with an ATI Rage 2, the last mission (where you have lots of caps and fighters - BOE mission :) ) works just fine, while in FS the mission of the Colossus vs Repulse, when the Colossus jumps, the game slows down... I think this is mainly because in Starlancer trhey change a ships textures when it is a BIT far away to a lower resolution, and don't use lods... while in FS the game only changes LOD's and textures, when the ship is pretty far away (of course, that can be changed in the .tbl file...)... So the big probs with slowing downs are the textures, not the models. Am I right??
So what we need to do first is find a better way of texture changing before doing anymore tweaks in the graphical engine...
I say NO to LODs (not the debris, of course...), but yes to better texture changing only...
-
I am beond sure SL uses LODs
-
100% sure that they use LODs. I've looked at the model format a bit and thats a for sure. There's a bunch of reasons why they can pull off 1200 polys on a fighter.
1) They have a more recent engine with more features and taking advantage of a faster DirectX version.
2) They have a fairly efficient LOD system but its kind of noticeable. On the highest of details, do a flypast into the sun. Watch as a few details from the ship disappear (especially the underslung missiles).
3) The way StarLancer works, your close to a ship less often than in FreeSpace.
-
FYI, the Robotech MOD uses some fighters with 1096 polys. Granted, not all of them are shown at one time (due to the fake turret transformation system) but that's still a lot of polys for a fighter with only 1 LoD. And it works, though I think too many fighters may cause my computer to crash with that mod. But I just have a several year old V3. :)
-
My X-wing has 1500 polys and works fine in FS2. Admittedly, it is in 3 subobjects, but....
-
well it has to be with that many polys
-
Also, the third subobject is so you can blow up R2....
-
:D
anyway I like Dave's Idea
(#2)
-
Originally posted by Raven2001
hmmmm... you talk a lot about the poly count drawing too much mem, but here's what I think:
What really may slow the game are textures.
More polys inpact mostly the CPU, where more/larger textures have a greater impact on the video card. Which slows down things more depends on which is the bottleneck on your system.
I like Dave's method #2 too :)
-
The real question now is, does anybody know how to implement it?
-
dave does. :p
Umm...regarding damage. Maybe it'd be best to start with damage decals applied only for beam weapons and bombs - which would immediately cut down the number of possible decals that could be applied. Fighter weapons might not do enough damage to leave noticeable damage other than the usual spark trails...
-
I'd feel satisfied with that for sure Kellan. A big mother of a bomb leaving no mark sometimes feels a little silly :)
-
Actually....if you could have a fairly simple design, you could use a second hullpate- a 1 sided plane - which gets blown off to reveal damage... tough, but probably do-able if you are very careful with clipping.
Obv. not ideal, but it;s a workaround until someone figures out how to code real decals.
-
for gighters, maybe switching to an alternate damaged map when the hull drops under 50% would be way enough, i think.
-
what about only leaving say 60 decals from small weapons, only 20 per ship, then swich damage skins
-
check out the damage modeling in Homeworld, then look at it on cataclysm.
-
LordHavoc implemented a "damage" style thing for the world geometry in darkplaces http://sf.net/projects/darkplaces/ that could probably be adapted for models, etc. He calls them "stainmaps" he uses them for blood and slime, etc. in the game. You can't use any code at all from his project in the freespace2 source because of the license issues, but you'll need to do somewhat different anyway, so read for an example to get ideas, then write your own...