Re: Shipyard

Here, various developers can tell you all about what they're up to, so you can yell at them for being idiots. "... and there was a great rejoicing."
Message
Author
User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12297
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Shipyard

#16 Post by Geoff the Medio » Sun Apr 11, 2010 5:30 am

Could one of you explain briefly how a decal texture channel would be used?

"Decal" to me sounds like a player-chosen or player-created texture that would be applied to meshes used by the player, but I don't see how a decal texture channel would be used to accomplish or facilitate this. Does the decal channel indicate the opacity of the decal texturing at any given location, with the actual decal texture provided as a separate texture? Or is the decal channel used to indicate the pattern directly, in which case how does it vary from player to player?

Or is the decal channel used to indicate the opacity of a the player's colour that's rendered over top of the existing texture? Would this be the equivalent of reserving one particular colour in the texture to be replaced with the player colour (but presumably faster to render)? Would the texture under the decal area be unused due to being "overwritten" by player colour?

User avatar
pd
Graphics Lead Emeritus
Posts: 1924
Joined: Mon Mar 08, 2004 6:17 pm
Location: 52°16'N 10°31'E

Re: Shipyard

#17 Post by pd » Sun Apr 11, 2010 2:28 pm

tzlaine wrote: What do you mean by "a b/w image and use this to determine the intensity of the self-illumination, but take the color from the color map"? Does this mean that the glow color is taken to be (diffuse red, diffuse green, diffuse blue)?
Exactly.
If that's the case, is the glow channel just 0.0 or 1.0? If not, how do values in between get combined with (diffuse red, diffuse green, diffuse blue) to get the glow color?
It's not just 0.0 or 1.0, but also everything in between. I shouldn't have written b/w, it's greyscale actually, like a single channel. Let's assume a scene without any light sources. A full black glow map would mean a completely dark model(A). A full white map would mean a completely illuminated model(B). Value's between 0.0 and 1.0 would produce a result that's between A and B. The glow map acts as a mask to show the color map, independent of light sources. If only the parts that are supposed to glow are described in the glow map, we get the result we need(C). All the glow color is already included in the color map.

Image

Granted, with the current way to handle glow maps, I don't need to include glow color in the color map, I could provide the color map, as if the light's were turned off(D). Now, there seems to be one advantage with the current way - in case we do want to turn of glowing parts of ships(for instance, if they are heavily damanaged) we can do so by using a different shader(which doesn't compute the glow part). If we would like to turn off the glowing bits with the way was describing, we would need to switch the color map.

Image
Also, we currently use the same value for gloss as for specular. It looks good to me as-is; is it sufficient?
I agree, it looks good and works fine.
The reason I like this is that, unless we really need a second decal channel -- which at this point I don't think we will -- we can vary the decals and the glow color, just like in your mockups in the Shipyard thread, by swapping in a single texture.
Geoff has raised the issue, that we might want to be able to distinguish between designs based on the same hull. Different decal patterns might be helpful. We don't have to do it like this though. We can come up with UI solutions as well, but doing it on the model, is the most straight forward I think.
The only hole in this plan is that the glowing bits will not illuminate any other nearby parts of the model; this may be a deal-breaker by itself.
Now you've lost me! What parts of the model are not illuminated? The result of both ways should be the same IMO. Or maybe you are talking about actually illuminating other ships/objects?

User avatar
pd
Graphics Lead Emeritus
Posts: 1924
Joined: Mon Mar 08, 2004 6:17 pm
Location: 52°16'N 10°31'E

Re: Shipyard

#18 Post by pd » Sun Apr 11, 2010 3:59 pm

Geoff the Medio wrote:Could one of you explain briefly how a decal texture channel would be used?
For my purposes I've been using the overlay blending mode to combine base texture and decal.

Image
(click for all 5 example colors)

Now there's a problem with that. The result depends to some degree on the brightness, hue and saturation of the base texture.

Maybe this can be resolved by using an additional channel, which includes basic shading and texture information(but no color). Something like this:

Image
(click for all 5 example colors)

Image
(click for all 5 example colors)

The empire colors with this method are much more true and punchy. I'm not sure if it's worth the effort though(I'll let tzlaine decide this). It might seem complicated looking at the images, but I assume one can do this using math quite elegant.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12297
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Shipyard

#19 Post by Geoff the Medio » Sun Apr 11, 2010 5:48 pm

pd wrote:
The only hole in this plan is that the glowing bits will not illuminate any other nearby parts of the model; this may be a deal-breaker by itself.
Now you've lost me! What parts of the model are not illuminated? The result of both ways should be the same IMO. Or maybe you are talking about actually illuminating other ships/objects?
If you take the glow colour from the diffuse texture, then the glow at any pixel has to be the same colour as the diffuse texture. This means that the glow can't be a different colour, so if there can't be self-illumination of a pixel with a different colour from a different pixel. For example, if I held an orange light up to a white wall in a dark room, the orange light couldn't scatter off the white wall to make the wall look orange; instead the wall could only glow white or not at all. Examples of this from your previous mockup are pointed out, where the inner orange glowy parts seem to illuminate the outer dark-grey sections with a different colour than the underlying diffuse texture at those pixels.
FO_Indirect_Glow.png
Glow scattering off surfaces that don't glow themselves.
FO_Indirect_Glow.png (35.75 KiB) Viewed 1596 times
An alternative to consider is making the glow colour a rendering parameter that is used over the whole model. Rather than using the diffuse texture colour, the glow colour would be passed in similarly to the empire colour for decals. The glow map would still be a single channel to indicate glow brightness, with no colour information taken from the texture. This way, a bright glowy part could be placed near a dimmer glowy part, and both would be illuminated in a different colour from the underlying diffuse texture. This would limit glow to a single colour per model, though.
Maybe this can be resolved by using an additional channel, which includes basic shading and texture information(but no color).
In your examples, the decal channel is only black or white (ie. not grey or otherwise textured). Given that, couldn't a key colour in the diffuse map be used instead, such as bright saturated magenta, which is always replaced with the empire colour? This would save a channel.

Edit: Another thought: What about glow effects that turn on or off depending what a ship is doing? It would be nice to have a ship's engine bits glow differently when it is moving than when it is stationary, or to have weapon effects illuminiate nearby parts of a ship, such as when a beam is being fired at or by a ship, or when something explodes near or on the ship.

Engine glow seems straightforward to do using a glow texture of some sort that is turned on or off depending what the ship is doing, but may not really be necessary if ships have an always-on engine-type glow such as in pd's recent examples.

Weapon firing glow would need to turn on or off depending whether the weapon is firing, though. It could also be done with a texture, but would need to be coordinated with the emitter points for any beam weapon effects. So far as I know, there's been no discussion about how to render beam effects in relation to ship meshes. My main concern is that beam effects should originate form a place on a ship that looks like a weapon component, but how will the effects rendering code know where to emit a beam weapon effect from on a model? If this can be indicated somehow, then the beam firing glow texture could be created to match. /Edit

User avatar
tzlaine
Programming Lead Emeritus
Posts: 1092
Joined: Thu Jun 26, 2003 1:33 pm

Re: Shipyard

#20 Post by tzlaine » Sun Apr 11, 2010 8:14 pm

pd wrote:
tzlaine wrote: What do you mean by "a b/w image and use this to determine the intensity of the self-illumination, but take the color from the color map"? Does this mean that the glow color is taken to be (diffuse red, diffuse green, diffuse blue)?
Exactly.
If that's the case, is the glow channel just 0.0 or 1.0? If not, how do values in between get combined with (diffuse red, diffuse green, diffuse blue) to get the glow color?
It's not just 0.0 or 1.0, but also everything in between. I shouldn't have written b/w, it's greyscale actually, like a single channel. Let's assume a scene without any light sources. A full black glow map would mean a completely dark model(A). A full white map would mean a completely illuminated model(B). Value's between 0.0 and 1.0 would produce a result that's between A and B. The glow map acts as a mask to show the color map, independent of light sources. If only the parts that are supposed to glow are described in the glow map, we get the result we need(C). All the glow color is already included in the color map.
Ok, but what's the point of values between 0.0 and 1.0 though? It looks like the color channels already have the glow color at the right intensity already, no? Should the glow channel be used to modulate the color channels?
Granted, with the current way to handle glow maps, I don't need to include glow color in the color map, I could provide the color map, as if the light's were turned off(D). Now, there seems to be one advantage with the current way - in case we do want to turn of glowing parts of ships(for instance, if they are heavily damanaged) we can do so by using a different shader(which doesn't compute the glow part). If we would like to turn off the glowing bits with the way was describing, we would need to switch the color map.
That might be nice to have, but as of right now I can't see any use for it.
Also, we currently use the same value for gloss as for specular. It looks good to me as-is; is it sufficient?
I agree, it looks good and works fine.
Ok.
The reason I like this is that, unless we really need a second decal channel -- which at this point I don't think we will -- we can vary the decals and the glow color, just like in your mockups in the Shipyard thread, by swapping in a single texture.
Geoff has raised the issue, that we might want to be able to distinguish between designs based on the same hull. Different decal patterns might be helpful. We don't have to do it like this though. We can come up with UI solutions as well, but doing it on the model, is the most straight forward I think.
Ok, but in that case we can just substitute a new decal, right? If I want to distinguish two green-decaled ships, they only need one decal channel, but need to use two different decal patterns.
The only hole in this plan is that the glowing bits will not illuminate any other nearby parts of the model; this may be a deal-breaker by itself.
Now you've lost me! What parts of the model are not illuminated? The result of both ways should be the same IMO. Or maybe you are talking about actually illuminating other ships/objects?
Forget it. The more I think about this idea, the less I like it.

Alright, can you summarize? What do the textures and channels look like now?

User avatar
tzlaine
Programming Lead Emeritus
Posts: 1092
Joined: Thu Jun 26, 2003 1:33 pm

Re: Shipyard

#21 Post by tzlaine » Sun Apr 11, 2010 8:18 pm

Geoff the Medio wrote:If you take the glow colour from the diffuse texture, then the glow at any pixel has to be the same colour as the diffuse texture. This means that the glow can't be a different colour, so if there can't be self-illumination of a pixel with a different colour from a different pixel. For example, if I held an orange light up to a white wall in a dark room, the orange light couldn't scatter off the white wall to make the wall look orange; instead the wall could only glow white or not at all. Examples of this from your previous mockup are pointed out, where the inner orange glowy parts seem to illuminate the outer dark-grey sections with a different colour than the underlying diffuse texture at those pixels.
Right; this is what I meant.
An alternative to consider is making the glow colour a rendering parameter that is used over the whole model. Rather than using the diffuse texture colour, the glow colour would be passed in similarly to the empire colour for decals. The glow map would still be a single channel to indicate glow brightness, with no colour information taken from the texture. This way, a bright glowy part could be placed near a dimmer glowy part, and both would be illuminated in a different colour from the underlying diffuse texture. This would limit glow to a single colour per model, though.
I don't think this works as a general solution, because the glowing bits might need to be in different colors. This is the case, for instance, in the mark1 model already. It's engine ports in the back should glow white, and its core should glow orange.

User avatar
tzlaine
Programming Lead Emeritus
Posts: 1092
Joined: Thu Jun 26, 2003 1:33 pm

Re: Shipyard

#22 Post by tzlaine » Sun Apr 11, 2010 8:24 pm

tzlaine wrote:
pd wrote:
tzlaine wrote: What do you mean by "a b/w image and use this to determine the intensity of the self-illumination, but take the color from the color map"? Does this mean that the glow color is taken to be (diffuse red, diffuse green, diffuse blue)?
Exactly.
If that's the case, is the glow channel just 0.0 or 1.0? If not, how do values in between get combined with (diffuse red, diffuse green, diffuse blue) to get the glow color?
It's not just 0.0 or 1.0, but also everything in between. I shouldn't have written b/w, it's greyscale actually, like a single channel. Let's assume a scene without any light sources. A full black glow map would mean a completely dark model(A). A full white map would mean a completely illuminated model(B). Value's between 0.0 and 1.0 would produce a result that's between A and B. The glow map acts as a mask to show the color map, independent of light sources. If only the parts that are supposed to glow are described in the glow map, we get the result we need(C). All the glow color is already included in the color map.
Ok, but what's the point of values between 0.0 and 1.0 though? It looks like the color channels already have the glow color at the right intensity already, no? Should the glow channel be used to modulate the color channels?
Nevermind, I figured out the answer to this. You're only indication of the relative brightness of the specular and reflected glow colors in a certain spot comes form the glow value.

This further implies that we should have a separate set of rgb glow channels, as I suggested in my breakdown previously, and as you suggested above.

Without separate channels, with the glow baked into the specular channels, bright specular reflections automatically cause the glow to increase too, which is bad. I now think that we should really try to keep the glow and specular maps separate.

I hope that made sense. :)

User avatar
Bigjoe5
Designer and Programmer
Posts: 2058
Joined: Tue Aug 14, 2007 6:33 pm
Location: Orion

Re: Shipyard

#23 Post by Bigjoe5 » Mon Apr 12, 2010 6:33 pm

I don't know if this will be at all useful or relevant in the context of FreeOrion, but maybe have a look at this?

http://www.infinity-universe.com/Infini ... &Itemid=26
Warning: Antarans in dimensional portal are closer than they appear.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12297
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Shipyard

#24 Post by Geoff the Medio » Mon Apr 12, 2010 8:43 pm

tzlaine wrote:1. rgb -> diffuse red, diffuse green, diffuse blue; a -> specular/gloss
2. rgb -> normal x, normal y, normal depth; a-> [unused (or decal 2?)]
3. rgb -> glow 1, glow 2, glow 3; a -> decal
Another thought occurs to me: this scheme doesn't have any alpha channel for the diffuse texture. This would seem to imply that we wouldn't be able to have any semi-transparent parts on ships or space monster models. If we ever wanted to have "energy" based ships, or if we wanted to make a "pleasure cruiser" ship with a big transparent dome on the top, or a variety of other interesting ship designs with transparent parts, it would probably be very useful to be able to have transparent parts on ships. I imagine that texturing with a low alpha channel would be a good way to achieve such an effect.

User avatar
tzlaine
Programming Lead Emeritus
Posts: 1092
Joined: Thu Jun 26, 2003 1:33 pm

Re: Shipyard

#25 Post by tzlaine » Tue Apr 13, 2010 1:35 am

Geoff the Medio wrote:
tzlaine wrote:1. rgb -> diffuse red, diffuse green, diffuse blue; a -> specular/gloss
2. rgb -> normal x, normal y, normal depth; a-> [unused (or decal 2?)]
3. rgb -> glow 1, glow 2, glow 3; a -> decal
Another thought occurs to me: this scheme doesn't have any alpha channel for the diffuse texture. This would seem to imply that we wouldn't be able to have any semi-transparent parts on ships or space monster models. If we ever wanted to have "energy" based ships, or if we wanted to make a "pleasure cruiser" ship with a big transparent dome on the top, or a variety of other interesting ship designs with transparent parts, it would probably be very useful to be able to have transparent parts on ships. I imagine that texturing with a low alpha channel would be a good way to achieve such an effect.
If needed, this could go in the channel marked "[unused]" above.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12297
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Shipyard

#26 Post by Geoff the Medio » Tue Apr 13, 2010 2:58 am

tzlaine wrote:
Geoff the Medio wrote:this scheme doesn't have any alpha channel for the diffuse texture.
If needed, this could go in the channel marked "[unused]" above.
I'd think it would be easier to understand and work with diffuse textures with an alpha channel if the alpha channel was in the same texture file as the diffuse colour information, like a standard RGBA image:
1. rgba -> diffuse red, diffuse green, diffuse blue, diffuse alpha
2. rgb -> normal x, normal y, normal depth; a-> specular/gloss
3. rgb -> glow 1, glow 2, glow 3; a -> decal

This arrangement would nicely keep the diffuse "texture" information in a single file, the light-source-direction-dependent normal and specular lighting informaiton in a single file, and the light-source-independent glow and decal information in the remaining file (assuming I understand what those all mean).

I was also implicitly asking whether transparent diffuse texture rendering would be supported and practical, since I gather that rendering complex scenes with transparency complicates the process significantly.

User avatar
tzlaine
Programming Lead Emeritus
Posts: 1092
Joined: Thu Jun 26, 2003 1:33 pm

Re: Shipyard

#27 Post by tzlaine » Tue Apr 13, 2010 3:51 am

Geoff the Medio wrote:
tzlaine wrote:
Geoff the Medio wrote:this scheme doesn't have any alpha channel for the diffuse texture.
If needed, this could go in the channel marked "[unused]" above.
I'd think it would be easier to understand and work with diffuse textures with an alpha channel if the alpha channel was in the same texture file as the diffuse colour information, like a standard RGBA image:
1. rgba -> diffuse red, diffuse green, diffuse blue, diffuse alpha
2. rgb -> normal x, normal y, normal depth; a-> specular/gloss
3. rgb -> glow 1, glow 2, glow 3; a -> decal

This arrangement would nicely keep the diffuse "texture" information in a single file, the light-source-direction-dependent normal and specular lighting informaiton in a single file, and the light-source-independent glow and decal information in the remaining file (assuming I understand what those all mean).
That's reasonable.
I was also implicitly asking whether transparent diffuse texture rendering would be supported and practical, since I gather that rendering complex scenes with transparency complicates the process significantly.
It's not that big of a deal. Ogre handles the messy details -- if you make something semitransparent it just does the right thing.

User avatar
pd
Graphics Lead Emeritus
Posts: 1924
Joined: Mon Mar 08, 2004 6:17 pm
Location: 52°16'N 10°31'E

Re: Shipyard

#28 Post by pd » Tue Apr 13, 2010 8:51 pm

I think there is still some confusion (on my side at least) about the glow issue. However, since it's working fine as it is and there are more pressing issues, I consider it a low priority. We should perhaps come back to it at a later point. Let's focus on the decals instead.

DECALS
Geoff wrote: In your examples, the decal channel is only black or white (ie. not grey or otherwise textured). Given that, couldn't a key colour in the diffuse map be used instead, such as bright saturated magenta, which is always replaced with the empire colour? This would save a channel.
The problem with this solution is, that all the decals would be a flat color. There won't be occlusion shadows and no texture elements either. If you take a look at the those starcraft 2 buildings(one, two), the player colors are not flat.
Also, here's a closeup of the Mark1 texture as it is and if the decals were flat.
Image


I've committed a decal map for the Mark 1. There are currently just 2 channels. The first is a neutral base texture, onto which the empire color is overlayed using the second channel, which is the decal mask.(see this and this).

Or you could just use the second channel to replicate this.



GLOW
tzlaine wrote:Ok, but what's the point of values between 0.0 and 1.0 though? It looks like the color channels already have the glow color at the right intensity already, no? Should the glow channel be used to modulate the color channels?
The color channels have the glow color at the maximum intensity(1). Parts that are actually glowing will be pure white(or very close to white) in the glow channel. Parts that are illuminated will be something between 0 and 1. So yes, the glow channel is used to modulate the color channel, I guess. Sorry for the confusion, I tried to say this before, but failed somehow :)

tzlaine wrote:I don't think this works as a general solution, because the glowing bits might need to be in different colors. This is the case, for instance, in the mark1 model already. It's engine ports in the back should glow white, and its core should glow orange.
Also, just the core alone is glowing in a multitude of colors(white, yellows, oranges, reds).
tzlaine wrote: Without separate channels, with the glow baked into the specular channels, bright specular reflections automatically cause the glow to increase too, which is bad.
While this is right, it can be solved by using black in the specular channel for everything that's glowing, which is what I'm doing anyway.


WEAPONS
Geoff wrote: Weapon firing glow would need to turn on or off depending whether the weapon is firing, though. It could also be done with a texture, but would need to be coordinated with the emitter points for any beam weapon effects. So far as I know, there's been no discussion about how to render beam effects in relation to ship meshes. My main concern is that beam effects should originate form a place on a ship that looks like a weapon component, but how will the effects rendering code know where to emit a beam weapon effect from on a model? If this can be indicated somehow, then the beam firing glow texture could be created to match.
Weapon effects are on my list of "mock-ups to-do"... Since we don't show actual ship parts externally, I don't think we need to have weapon effects come out of certain parts. Instead they can originate from the center of the ship, but only be shown starting at the boundary volume. Here's is something quick and dirty to illustrate this. The bottom two ships are shooting at the seed sphere.
Image
(click)

Transparency

Transparency is something nice to have. I still have plans for the seed sphere to grow and develop foliage, for which transparency is essential(to mask out leaves and branches). I had to laugh when I read about the pleasure cruiser with transparent domes, it sounds so cliche, but fun at the same time. We definitely should have something like this.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12297
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Shipyard

#29 Post by Geoff the Medio » Tue Apr 13, 2010 9:13 pm

pd wrote:I've committed a decal map for the Mark 1. There are currently just 2 channels. The first is a neutral base texture, onto which the empire color is overlayed using the second channel, which is the decal mask.(see this and this).

Or you could just use the second channel to replicate this.
What benefit does having a decal "neutral base texture" have over using the diffuse texture?

If the issue is colour mixing between the diffuse texture and decal colour, presumably an effective greyscale brightness for the diffuse texture could be calculated using a (possibly weighted) average of the three colour channels in the diffuse texture. Then the apparent colour of the decal wouldn't depend on the underlying diffuse colour, but the "intensity" of the texture would still be apparent.

And if additional texturing is needed for decals, beyond what's in or can be calculated simply from the diffuse texture, can't that be put into the "mask" itself? Currently the mask seems to be just 0.0 or 1.0, so couldn't you multiply the decal mask and the decal "neutral base texture" and store the result in a single channel?

User avatar
pd
Graphics Lead Emeritus
Posts: 1924
Joined: Mon Mar 08, 2004 6:17 pm
Location: 52°16'N 10°31'E

Re: Shipyard

#30 Post by pd » Tue Apr 13, 2010 9:40 pm

Yes, the issue is color mixing to some degree. What's also important for the overlay to work properly is that the base is roughly at a mid grey value. I imagine this would be hard to do by code, because there will be areas in deep shadow, which have to be neglected. So you need to know what areas are supposed to be mid grey.

Anyway, I've added a third channel including a mix of the base and mask, as you've described.

Post Reply