[Aardwolf]

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)

[portej05]

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.

[Aardwolf]

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.

[Galemp]

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.

[Zacam]

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.

[headdie]

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?

[Dragon]

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.

[The E]

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.

[Dragon]

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.

[The E]

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.

[Zacam]

I concur with both of The_E's posts.

[Aardwolf]

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.

[Trivial Psychic]

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.

[sigtau]

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.

[Tomo]

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.

[sigtau]

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.

[Aardwolf]

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  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.

[Spicious]

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.

[chief1983]

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 faces in your post, maybe take 5 minutes come back and rethink whether that's helping the situation

Let's keep the SNR of this thread up ok?  It has some potential left still I think.

[Aardwolf]

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 faces in your post, maybe take 5 minutes come back and rethink whether that's helping the situation

It was the best I could come up with on such short notice! 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 SNR¹ of this thread up ok?  It has some potential left still I think.

¹Signal-to-Noise Ratio; in this case, how much on-topic discussion there is versus how much meta-discussion and off-topicness there is.

* Aardwolf 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.