Re: Shipyard
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13603
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: Shipyard
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?
"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?
Re: Shipyard
Exactly.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)?
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.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?
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.
I agree, it looks good and works fine.Also, we currently use the same value for gloss as for specular. It looks good to me as-is; is it sufficient?
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 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.
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?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.
Re: Shipyard
For my purposes I've been using the overlay blending mode to combine base texture and decal.Geoff the Medio wrote:Could one of you explain briefly how a decal texture channel would be used?
(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:
(click for all 5 example colors)
(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.
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13603
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: Shipyard
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. 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.pd wrote: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?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.
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.Maybe this can be resolved by using an additional channel, which includes basic shading and texture information(but no color).
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
Re: Shipyard
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?pd wrote:Exactly.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)?
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.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?
That might be nice to have, but as of right now I can't see any use for it.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.
Ok.I agree, it looks good and works fine.Also, we currently use the same value for gloss as for specular. It looks good to me as-is; is it sufficient?
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.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 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.
Forget it. The more I think about this idea, the less I like it.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?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.
Alright, can you summarize? What do the textures and channels look like now?
Re: Shipyard
Right; this is what I meant.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.
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.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.
Re: Shipyard
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.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?pd wrote:Exactly.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)?
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.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?
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.
Re: Shipyard
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
http://www.infinity-universe.com/Infini ... &Itemid=26
Warning: Antarans in dimensional portal are closer than they appear.
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13603
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: Shipyard
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.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
Re: Shipyard
If needed, this could go in the channel marked "[unused]" above.Geoff the Medio wrote: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.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
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13603
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: Shipyard
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:tzlaine wrote:If needed, this could go in the channel marked "[unused]" above.Geoff the Medio wrote:this scheme doesn't have any alpha channel for the diffuse texture.
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.
Re: Shipyard
That's reasonable.Geoff the Medio wrote: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:tzlaine wrote:If needed, this could go in the channel marked "[unused]" above.Geoff the Medio wrote:this scheme doesn't have any alpha channel for the diffuse texture.
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).
It's not that big of a deal. Ogre handles the messy details -- if you make something semitransparent it just does the right thing.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.
Re: Shipyard
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
Also, here's a closeup of the Mark1 texture as it is and if the decals were flat.
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
WEAPONS
(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.
DECALS
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.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.
Also, here's a closeup of the Mark1 texture as it is and if the decals were flat.
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
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 somehowtzlaine 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?
Also, just the core alone is glowing in a multitude of colors(white, yellows, oranges, reds).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.
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.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.
WEAPONS
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.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.
(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.
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13603
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: Shipyard
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?
Re: Shipyard
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.
Anyway, I've added a third channel including a mix of the base and mask, as you've described.