Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Aardwolf on July 02, 2010, 09:33:39 pm
-
Sorry for cross-posting! I wasn't sure whether to delete the original post or what...
Proposal: Decals and Nameplates
props to Tomo for the idea
For some subset of the object's polygons, store an additional set of UV coords. These are the coordinates to be used by the decal texture.
These polygons are then drawn with the following render state info:
- Texture: the nameplate or decal texture
- Texture wrap: Wrap mode for both texture coordinates should be clamp (or possibly clamp to edge); there should be a 1-pixel transparent border*
- Depth: Depth testing enabled, depth function should be "equal", depth mask false (but it doesn't really matter)
- Blending: Blending enabled, alpha-opacity based blending
Because the polygons' vertices are identical to those of the model, there's no need to worry about z-fighting; the depth for the nameplate/decal is exactly the same as the depth for the 'hull' polygons.
*I've never used it, but OpenGL has some texture parameter options relating to a "border", which from my reading of the documentation, would let you control what color stuff is in the repeating portion of the texture (when it's set to not tile)
-
There was an implementation of decals in the FSO codebase. Most of it is commented out - I think Bobboau is the guy to talk to.
-
I know there was, although I don't know the details of it (or why it was disabled, although IIRC it had something to do with memory management?). Also I don't know how the old implementation's decals were set up, geometry-wise...
I suppose what I was trying to say is that we could possibly combine the Decal, Nameplate, and Insignia (or a replacement for the Insignia system) systems into a single thing, and it could work like that. Although as far as defining them (nameplates are on a per-ship, per-mission basis, insignias on a per-player/mission basis), I'm not sure how that might work either.
Perhaps a submodel flag that tells the engine to use decal render-state for the geometry (i.e. "equal" depth test, texture clamp, all the stuff I named in the first post)? And in the case of insignias, perhaps it would use a special texture ("blank_insignia.pcx" or somesuch) that would be auto-replaced in-game... That way it wouldn't conflict with the existing insignia/nameplate system, but would have the advantage of having the proper render-state so that there's no z-fighting and it renders "on top of" the hull.
-
I suppose what I was trying to say is that we could possibly combine the Decal, Nameplate, and Insignia (or a replacement for the Insignia system) systems into a single thing, and it could work like that.
Whatever you do, THIS is a good idea.
-
The Decal system referenced is the Damage Decals system. Not sure as to why it was deprecated in the code, but there are other functions related or in the same area of it that are also not implemented.
The biggest juggle that I see is making sure the existing framework for Nameplates (optionally if it was an SCP added feature) and Insignia (required as a retail function) are still available for use.
-
is it possible to alter the engine to handle this so we retain the original Decal, Nameplate, and Insignia with the addition of a new object that can handle all three? how adversely would it affect performance to do this?
-
I'd like to know why the old decal system is gone and why can't it be reintroduced (it'd be a launcher flag, I'm sure that once there was one for enabling decals).
I don't think it could break anything else and if it'd be buggy or look ugly, people simply won't use it.
Of course, if it would interfere break or otherwise cause problems with existing features, then I can go without it.
-
Aaargh.
Uninformed people are a bane.
First of all, the old decal system (AKA the system retail used for squad insignia) is still alive and well. It was never removed or disabled.
The damage decal system that Bobboau implemented was removed because the implementation was never finished. Kinda like the post-processing system.
Also, Dragon, if you know how to reintroduce it without breaking stuff (and not to forget, fixing it so it works properly in the first place), feel free to post a patch on the SCP board.
Now.
One thing I think you've missed is that nameplates and squad insignia _already work much the same way_.
Both are based on having a tiny rectangle above the actual ship's hull that the nameplate/squad insignia texture can be applied to. The only difference is where you define the replacement texture.
-
Also, Dragon, if you know how to reintroduce it without breaking stuff (and not to forget, fixing it so it works properly in the first place), feel free to post a patch on the SCP board.
I heard that it was commented out, since this is a separate feature which once worked (even though not very well), shouldn't it be possible to just reenable that code (and maybe get rid of the part which causes launcher to complain about the -decals flag being present)?
I wonder what Bobboau has to say about this, I think that he was the one who implemented the decals.
Also, once decals would have been reintroduced, it should be possible to hunt down bugs present in that implementation.
-
Again, if you know how to do it, do it. DON'T tell us that it should be easy. DON'T tell us that "once it's back in, it can be fixed". Just don't.
Do you see the mess that is post processing? Have you seen the cycle of breakages, fixes, and new breakages that happened after the original implementer (Hery) left?
You are talking about basically opening up a can of very similar and not very tasty worms. Get this through your head, we don't have the graphics coding expertise to get this done in any sort of plannable timeframe. We don't have the coding staff to be able to accept and maintain big gobs of code that get dumped into the codebase.
If we can get additional coders that are willing and able to commit to this project long-term, then we can maybe look at this again. BUT, for the moment, getting damage decals back is very, very low on the list of priorities.
-
I concur with both of The_E's posts.
-
One thing I think you've missed is that nameplates and squad insignia _already work much the same way_.
Both are based on having a tiny rectangle above the actual ship's hull that the nameplate/squad insignia texture can be applied to.
See, that's a bad way to do it. It shouldn't be a separate polygon "above" the actual ship's hull, it should use the same geometry the hull uses; by having the exact same vertex positions, an "equal" depth test will work. No z-fighting to deal with. Regardless of whether or not it's been in the code since retail, the current system (polygon slightly above the hull) is pretty much a hack.
Nonetheless, I'ma go build FSO with decals just to see what it's like.
Edit: well so much for that idea. It wouldn't build... linker errors. And I'm not interested enough to try to fix 'em.
-
Regarding Damage Decals:
Disappointing, but not surprising. Perhaps someday someone can get it reintroduced and fixed, but I completely understand that its not a priority right now.
-
See, that's a bad way to do it. It shouldn't be a separate polygon "above" the actual ship's hull, it should use the same geometry the hull uses
Do you mean literally drawing on the ship's diffuse texture a "decal" or do you mean having the same tiny rectangle used for insignia and all?
Do you also take into account that it means having to redraw the insignia/decals/nameplate to the diffuse texture every single frame?
Have fun with performance out the ****ing window.
-
One thing I think you've missed is that nameplates and squad insignia _already work much the same way_.
Both are based on having a tiny rectangle above the actual ship's hull that the nameplate/squad insignia texture can be applied to. The only difference is where you define the replacement texture.
That's not the way Aardwolf and I are talking about.
We quite often see the Z-fighting on nameplates and there are very few mods using them.
- Insignia of course have exactly the same problem, because they're done in the same way.
Now I've looked at the code, the old damage decal system appears to have been using new geometry as well, so it's not a good place to start.
Do you mean literally drawing on the ship's diffuse texture a "decal" or do you mean having the same tiny rectangle used for insignia and all?
Do you also take into account that it means having to redraw the insignia/decals/nameplate to the diffuse texture every single frame?
No it doesn't.
We hand the shader an additional UV map and texture containing the insignia and the shader paints this onto the existing geometry as part of the fragment shader processing.
- This is no different to having several textures used for one ship, as we already do.
This does consume some slots in bmpman - one for each unique insignia - though I think those slots are consumed anyway even though the image isn't currently used.
So one question for the people that know the engine well:
Does that sound feasible?
- Note that I'm *not* asking you to do it. I just want to know if it sounds feasible before anybody dives in trying to do it.
-
Having a blank texture buffer to write to does sound more feasable, but remember that it also depends on the layout of the UV map.
-
Having a blank texture buffer to write to does sound more feasable, but remember that it also depends on the layout of the UV map.
NO NO NO :mad: That's not what we're talking about. It's not being written to a texture, there's no drawing on textures anywhere... I've got no idea where you got that idea from.
And Tomo, actually I was thinking a second pass rather than additional shader parameter (using == depthfunc to make sure there's no z-fighting)... that way the same system could later be extended to allow for multiple decals, possibly overlapping (as would be the case for damage decals). I'm not sure what other differences there might be between the two ways of doing it (additional shader params versus redrawing w/ blend) though.
-
This thread was doomed from the beginning. Using the word decals implies damage decals, which horribly derailed the entire discussion. Maybe if we replace decals by insignia and start again it might do a bit better.
As an aside, should is a truly great weasel word when prefixed with another word like somebody, it or you.
-
Yeah I'm an expert at that particular weasel word.
On topic, I'm surprised at how much useful information is in this thread considering the overall tone of most of the posts. If we could keep this discussion going, but everyone realize that not only have their been several serious terminology issues leading to a near-meltdown, I'm inclined to let it continue. But seriously guys, keep in mind that a) not everyone knows this code's history as well as some of us, and b) getting frustrated isn't helping anyone. If you're about to hit 'Post' and you've put CAPS or :mad: faces in your post, maybe take 5 minutes come back and rethink whether that's helping the situation :P
Let's keep the SNR of this thread up ok? It has some potential left still I think.
-
Yeah I'm an expert at that particular weasel word.
I'm confused why people are talking about "should" being a weasel word. Basically the only places it's been used were describing the approximate difficulty of something, and describing the preferred implementation of something. I mean sure, in the first case it kind of implies that if you think it's more difficult than that, you're doing it wrong and need to go back and learn some basic stuff about OpenGL, and in the second case it implies that doing it some other way is bad... but that was my intention.
But I digress.
If you're about to hit 'Post' and you've put CAPS or :mad: faces in your post, maybe take 5 minutes come back and rethink whether that's helping the situation :P
It was the best I could come up with on such short notice! :nervous: Really though I just wanted to convey as concisely as possible that his understanding of the subject was completely incorrect and that he needed to go back to observation mode for a little bit.
Let's keep the SNR1 of this thread up ok? It has some potential left still I think.
1Signal-to-Noise Ratio; in this case, how much on-topic discussion there is versus how much meta-discussion and off-topicness there is.
/me looks up at what he just wrote.
****. Ok well, something constructive then: I actually did mean that my technique could work for all 3 kinds of decals, i.e.:
- Nameplates, with locations defined in the ship model, and textures set up in the mission file
- Insignias, with locations defined in the ship model, and textures determined by the campaign (I actually don't know the details of how that works, but whatever)
- Damage decals, which currently aren't supported, but would be created in-game when shots hit ships
The first two are of course similar in that both are be defined in the ship model, and the texture is specified elsewhere. The third case (damage decals) is different in that the texture coordinates are generated at run-time, but the textures used are defined in weapon table entries.
What I was getting at, though, is that those three kinds of decals could hypothetically be combined.
However, I believe the way the now-disabled damage decal system worked may not be "good enough", in that it looks like (i.e. from looking at the code... I couldn't get it to build) it worked by creating new geometry, rather than creating new texture coordinates and using the existing vertex positions... thus it would have had the same possible z-fighting issue.
I do realize people tend to dislike the "idea guy" who isn't actually doing anything, of course... I could hypotheticallyMIGHT produce some pseudo-code, if that would help.
-
A double-post was deemed necessary.
I wasn't 100% certain that people understand the concept I was proposing, or that the concerns people have brought up aren't things I had already taken into account, so I explained the whole concept on #SCP
The following is the IRC log, with most of the irrelevant comments/events removed for readability:
Aardwolf: i think i gotta explain first the storage / creation, and then the rendering.
Aardwolf: so, each ship would have associated with it a collection of "decals" (including nameplates, insignias, and "damage decals")
Aardwolf: (alternatively it might be associated with specific subobjects/submodels)
Zacam-Work: Associated how?
Aardwolf: well, there's more than one way to do it
Aardwolf: there could be a big table of all the decals in existence (i think that's how decals.cpp did it), and each ship (or submodel) would contain a collection of indices into that table
Aardwolf: basically just that somewhere in memory there's a list of decals (or multiple lists), and that each sublist goes with a specific model (or submodel)
Aardwolf: whether it's a list or a vector or a dictionary is at this point inconsequential
Aardwolf: there would be a decal structure, which all decals are instances of
Aardwolf: it would contain a reference (using the word in the loose sense, not a technical one) to a texture--i don't know the details of how bmpman does stuff, or how textures are normally referenced, but probably it'd be the same way
Aardwolf: additionally, it would have the info needed to get the vertex data; again, there's some wiggle-room with some details of the implementation, but basically each decal would need either a "hard copy" or some sort of reference to the vertex data of the submodel
Aardwolf: but considering a single submodel might be much bigger and more complicated than the area the decal covers, it might be better to store references to triangles of the submodel (a decal would typically only ever be on maybe 10 triangles anyway)
Aardwolf: then, for each vertex the decal is using, the decal would store a (u,v) texture coordinate
Aardwolf: i'm not sure if it matters whether it be on a per-unique-vertex basis or a per-triangle's-vertex basis. it might not matter, but one might be much easier to implement
Aardwolf: oh, one other thing; if there are multiple decals which use the same texture, but do not share any triangles, it might be useful to combine them into a single decal instance containing the combined data
Aardwolf: but if they would share a triangle, the decal would have to go into a new decal instance
Aardwolf: that's a little bit of an optimization though, just as a possibility, more than a "must do it this way"
Aardwolf: oh, lastly each decal would need to store some "timer" info, basically either a lifetime counter or a time when it will have "cooled down", so that the "burn" (decal glow) could fade or otherwise animate as the decal ages. probably the same as however animated textures work elsewhere, but without looping.
Aardwolf: Decal Creation:
Aardwolf: the nameplate/insignia decals would be defined (TBD later) in the model file, and would probably end up using texture replacement similar to how it works now
Aardwolf: they'd be instantiated when the ships come into existence (although because their geometry/texcoords are predetermined their could probably be some caching/other optimization done there as well)
FUBAR|Outside: how would a damage decal apply over a hull texture that is an eff already?
Aardwolf: when i get to the rendering part, i'll explain that, it should clear it up
FUBAR|Outside: Think shadow bio hull
Aardwolf: So yeah, damage decals (and any other sort of dynamically created decals, if there is a need for 'em) would be created at run-time. I don't know the best way (math-and-aesthetics-wise) to position and orient a decal on a surface, but that math would be done when a shot impacts (or whatever other event causes a decal to come into existence)
Aardwolf: Rendering:
Aardwolf: first, the ship is drawn as normally (depth testing on, depth mask on, etc.)
Aardwolf: next all of the decals on the ship get drawn...
Aardwolf: basically, depth test has to be on, and set to == mode. that is, if the depth of the pixel about to be drawn is equal to the depth already drawn on that pixel, it will draw, and otherwise it will not.
Aardwolf: because the decals would be using EXACTLY the same vertex coordinates as those of the ship's geometry, there's no need to worry about z-fighting. it will be a perfect match.
Aardwolf: depth mask (i.e. whether or not it writes to the depth buffer) could be set to false while drawing the decals... the depths wouldn't be changing, so overwriting the depth values might be unnecessary, but i'm not sure if it matters, or whether there'd be any speed boost at all
Aardwolf: blending would have to be enabled and the blending should be set to use alpha opacity... the more opaque the decal, the more visible it is, and the less visible the stuff underneath (i.e. whatever was drawn previously)
Aardwolf: alpha testing could possibly be used to save having to draw where the opacity is zero, but i'm not sure if that matters, or how well that'd work with GLSL; i've never used the two together
Aardwolf: the decal textures themselves would be set up (using whatever function we've got that's doing glTexParam or equivalent) to clamp (or clamp to border) so they don't tile weirdly in parts that aren't inside the decal, the border would be set to 1 (that might actually be a glTexImage thing rather than a glTexParam option), and the border color set to transparent
Aardwolf: that way parts of the decal-affected triangles that aren't part of the decal aren't just not tiled, they're transparent. with blending on, whatever color was there previously will stay there... it won't make the hull see-through
Aardwolf: then repeat the process for the rest of the decals. as i mentioned earlier, if some are using the same texture but don't share any geometry, it might be possible to combine them ... then again, if they use animated textures which aren't synchronized, that might not be possible until the animation finishes,
Aardwolf: ...unless FSO is using 3d textures for its animated effects. if it is, great. otherwise, decals with the same animated texture can't be combined
Aardwolf: i think that's pretty much it.