Asteroids [NEEDS INTEGRATION]

[Deus Siddis]

Re: planet textures. The only requirement is that textures be POT. See e.g. the planet rings textures, they are 64x2048. What you need to assure when deciding texture size is the ratio of texture pixel to screen pixel. For planets you wrap the texture 360 degrees along the equator and 180 pole-to-pole. With a 2:1 texture you avoid pixel stretching; that is the reason for the selected ratio.

Coming back to this topic after a bit of a while . . .

Pixel stretching is not really an issue to be dealt with in this case because the spheres are icos, the textures are baked from procedurals (which cancels out uv warping and pixel stretching with each other thereby showing no end result effect besides a little uneven pixelation when you fly in close) and multiple different asteroid models reuse the same texture (which creates stretching regardless).

I also do not really care that a 2048x1024 texture takes up twice as much space as a 2048x2048 on a hard drive, because it's a png file anyway and there is always plenty of hardrive space.

What I do care about though is if a 2048x1024 texture is going to be converted to or take up the same resources as a 2048x2048 texture in the GPU when it is used in the vega strike engine / opengl? Chuck, Klauss or anyone else who knows the answer to this, I would very much like to hear your thoughts.

Because if it is half as demanding on runtime system resources then I need to go back and confine the uvs and textures to a 2-1 rectangular space. But if it demands no extra cpu/ram power from the GPU, then these asteroids models are already good to go and it is time to ship them out.

[chuck_starchaser]

Pixel stretching is not really an issue to be dealt with in this case because the spheres are icos, the textures are baked from procedurals (which cancels out uv warping and pixel stretching with each other thereby showing no end result effect besides a little uneven pixelation when you fly in close) and multiple different asteroid models reuse the same texture (which creates stretching regardless).

I don't have the time to read back through this thread, but just wanted to say, be sure that only asteroids of the same size share a common texture. Smaller asteroids should share a smaller texture. Larger asteroids should share a larger texture. Otherwise you'll get *inconsistent* pixel stretching, and THAT would look awful.

I also do not really care that a 2048x1024 texture takes up twice as much space as a 2048x2048 on a hard drive, because it's a png file anyway and there is always plenty of hardrive space.

Did you mean the other way around? If not I'm missing something. Anyhow, textures will be ext compressed format; not png. And png would be a very bad format to use for noisy textures, anyways; if anything you'd want jpg.

What I do care about though is if a 2048x1024 texture is going to be converted to or take up the same resources as a 2048x2048 texture in the GPU when it is used in the vega strike engine / opengl? Chuck, Klauss or anyone else who knows the answer to this, I would very much like to hear your thoughts.

Sorry, I never heard this issue before; I thought textures didn't need to be square; only powers of two. In any case, you need rectangular textures for asteroids, if you're going to wrap them cylindrically; and I can't think of another way that would make sense.

Because if it is half as demanding on runtime system resources then I need to go back and confine the uvs and textures to a 2-1 rectangular space. But if it demands no extra cpu/ram power from the GPU, then these asteroids models are already good to go and it is time to ship them out.

IF indeed it were the case that 2:1 textures take up 2:2 space in the videocard, I would simply put two asteroid textures in one split texture, top and bottom, and have some asteroids use the top one, and some use the bottom one. Problem solved.

[Deus Siddis]

I don't have the time to read back through this thread, but just wanted to say, be sure that only asteroids of the same size share a common texture. Smaller asteroids should share a smaller texture. Larger asteroids should share a larger texture. Otherwise you'll get *inconsistent* pixel stretching, and THAT would look awful.

I am not sure how that would be the case or if I am understanding this correctly, but since last I have seen VS and PU have only asteroids of the same size, it probably wouldn't come up immediately. If and when it does I can certainly bake smaller textures though, plus I will turn in all of the source files anyway.

I also do not really care that a 2048x1024 texture takes up twice as much space as a 2048x2048 on a hard drive, because it's a png file anyway and there is always plenty of hardrive space.

Did you mean the other way around? If not I'm missing something.

Woops, that is backwards, sorry.

Anyhow, textures will be ext compressed format; not png. And png would be a very bad format to use for noisy textures, anyways; if anything you'd want jpg.

I thought it retained the png compression, but I guess that wouldn't make much sense. I don't like the hideous compression artifacts jpeg produces on top of the nvidia compression, but when the confeds learn what I have been doing they'll probably convert everything to jpeg anyway.

If only there was a format to fill the gap between crappiness and budget. . . Look! Up there in the Sky- It's a bird, it's a plane! NO, it's. . . the ghost of dead JPEG 2000, hanging up there with the ghosts of other awesomely useful and needed formats that will never by like MPNG and a vaguely modern open realtime 3D format.

What I do care about though is if a 2048x1024 texture is going to be converted to or take up the same resources as a 2048x2048 texture in the GPU when it is used in the vega strike engine / opengl? Chuck, Klauss or anyone else who knows the answer to this, I would very much like to hear your thoughts.

Sorry, I never heard this issue before; I thought textures didn't need to be square; only powers of two.

Maybe it is just a myth then, but I have heard from a number of people and places that at least with openGL (perhaps an older version they were thinking) textures need to be square and power of two or they will be converted to a power of two square texture at runtime or it is more expensive to have non-square textures, etc.

In any case, you need rectangular textures for asteroids, if you're going to wrap them cylindrically; and I can't think of another way that would make sense.

They're based on icospheres though, which overall seems to warp less with azimuthal projection (though with less efficient and even texel coverage), but either unwrap fits best into a rectangle, so the question was the same for either.

Because if it is half as demanding on runtime system resources then I need to go back and confine the uvs and textures to a 2-1 rectangular space. But if it demands no extra cpu/ram power from the GPU, then these asteroids models are already good to go and it is time to ship them out.

IF indeed it were the case that 2:1 textures take up 2:2 space in the videocard, I would simply put two asteroid textures in one split texture, top and bottom, and have some asteroids use the top one, and some use the bottom one. Problem solved.

That could be useful if we wanted say, C-Type and S-Type Asteroids in the same system.

[chuck_starchaser]

What I said about jpg was rethorical. I don't know what artifacts you're talking about. Jpeg is magnificent.
But anyhow, the current VS standard is to compress all textures using ext1 or ext3 (dds) format, and name
them .texture; so neither png nor jpg are either here or there. And the reason we use ext compression
(which, unlike jpg, IS artifactuly), is that it's a very simple compression that the GPU manufacturers adopted
which keeps textures compressed IN the videocard's memory. The GPU decompresses them on-the-fly as it
reads them.

But to get back to asteroids; my instinct would be to actually pack 8 rectangular textures in one square
texture, and have, say, 8 asteroid meshes randomly get any of 8 random textures assigned. I could write a
modified shader that takes an input number between 0 and 7 and translates UV coords to one of the 8
rectangular sub-textures, if you're game. This would produce 64 random asteroid varieties.

EDIT:
Well, the AO and PRT's would have to be per-mesh; but diffuse and specular could be randomized.

[Deus Siddis]

But to get back to asteroids; my instinct would be to actually pack 8 rectangular textures in one square texture, and have, say, 8 asteroid meshes randomly get any of 8 random textures assigned. I could write a
modified shader that takes an input number between 0 and 7 and translates UV coords to one of the 8
rectangular sub-textures, if you're game. This would produce 64 random asteroid varieties.

The issue would be with the size the texture would end up being, because with the larger asteroids being measured in kilometers, a 2048 texels wide texture is warranted, which for 8 of those combined would mean a 4096 square texture that has to be loaded all at once unlike separate 2048x1024 textures (and maybe is not yet supported by too many average video cards?) On top of that you have at least 3 of those textures- diffuse, specular and normal.

The other thing, not really an issue but a consideration, is that reusing one set of textures is kind of a hack, that does create noticeable texture warping, but allows for a much bigger texture with the same resources. If having eight asteroid textures loaded at a time is more desirable, then instead of varying them, more might be gained from giving each of the 8 asteroid models its own dedicated texture so that the warping of the craters and such isn't visible.

Well, the AO and PRT's would have to be per-mesh; but diffuse and specular could be randomized.

I have tested AO on them, but because the craters are purely in the normal map and the asteroid shapes are otherwise so devoid of concaveness, AO has very little noticeable effect. Can't say about PRT's.

[chuck_starchaser]

But to get back to asteroids; my instinct would be to actually pack 8 rectangular textures in one square texture, and have, say, 8 asteroid meshes randomly get any of 8 random textures assigned. I could write a
modified shader that takes an input number between 0 and 7 and translates UV coords to one of the 8
rectangular sub-textures, if you're game. This would produce 64 random asteroid varieties.

The issue would be with the size the texture would end up being, because with the larger asteroids being measured in kilometers, a 2048 texels wide texture is warranted, which for 8 of those combined would mean a 4096 square texture that has to be loaded all at once unlike separate 2048x1024 textures (and maybe is not yet supported by too many average video cards?) On top of that you have at least 3 of those textures- diffuse, specular and normal.

That's only an issue compared with re-using the same texture, or two, for all asteroids, which would make them horribly monotonous.
All other things being equal, it is MUCH faster to use a 4k x 4k texture divided into 8 sections than it is to use 8 separate textures, 2k x 1k each. It avoids multiple texture set-up latencies.

The other thing, not really an issue but a consideration, is that reusing one set of textures is kind of a hack, that does create noticeable texture warping, but allows for a much bigger texture with the same resources. If having eight asteroid textures loaded at a time is more desirable, then instead of varying them, more might be gained from giving each of the 8 asteroid models its own dedicated texture so that the warping of the craters and such isn't visible.

You may be right. OTOH, if each roid has its own AO, the diffuse/specular textures don't really matter as much where they fall, as they represent only color of the material, which is probably some shade of gray or brown anyways, and noisy.

Well, the AO and PRT's would have to be per-mesh; but diffuse and specular could be randomized.

I have tested AO on them, but because the craters are purely in the normal map and the asteroid shapes are otherwise so devoid of concaveness, AO has very little noticeable effect. Can't say about PRT's.

I have a blender noodle, part of LaGrande, that takes your AO or PRT and your height map as inputs, and outputs a modulated AO or PRT that includes illumination variations as per the height map. Also useful for radiosity bakes.

[Deus Siddis]

That's only an issue compared with re-using the same texture, or two, for all asteroids, which would make them horribly monotonous.

When there's a bunch of different shapes swirling around with no super obvious landmarks, it might be difficult to tell if they all use the same texture. That's the effect I was hoping for at least. However I think having more than one type of asteroid (different types of asteroids just means different textures) in the same system might be visually more interesting as well as more realistic.

All other things being equal, it is MUCH faster to use a 4k x 4k texture divided into 8 sections than it is to use 8 separate textures, 2k x 1k each. It avoids multiple texture set-up latencies.

If all the textures are loaded into the gpu at runtime, then yeah that should be the best solution. But if only the textures that are used by a system are loaded in the gpu for only as long as you are in that system, then breaking the textures up could reduce video memory usage by 42 MBs. Maybe that isn't worth that much anymore though.

You may be right. OTOH, if each roid has its own AO, the diffuse/specular textures don't really matter as much where they fall, as they represent only color of the material, which is probably some shade of gray or brown anyways, and noisy.

The most important texture to consider is the normal map. You benefit the most visually if every asteroid has its own normal map. Only problem is with asteroid texture types that match up precisely between the diff/spec and norm maps, like the magnetite and pallasite asteroids. If one is warped and the other is not, the result will look kind of wrong.

I have a blender noodle, part of LaGrande, that takes your AO or PRT and your height map as inputs, and outputs a modulated AO or PRT that includes illumination variations as per the height map. Also useful for radiosity bakes.

That still doesn't help the AO situation that much from a realistic visualization standpoint because the craters are naturally a good deal lighter than the undisturbed surface matter, because they have less time to have been baked and darkened by the cosmic rays. AO then takes things the other way and makes those craters darker because of obscurred star light. So the two more or less neutralize each other.

I don't think the same would apply for the PRT though.

[chuck_starchaser]

...if each roid has its own AO, the diffuse/specular textures don't really matter as much where they fall, as they represent only color of the material, which is probably some shade of gray or brown anyways, and noisy.

The most important texture to consider is the normal map. You benefit the most visually if every asteroid has its own normal map. Only problem is with asteroid texture types that match up precisely between the diff/spec and norm maps, like the magnetite and pallasite asteroids. If one is warped and the other is not, the result will look kind of wrong.

Very true; so, in summary:
Diffuse - randomizable
Specular - randomizable
Shininess - randomizable
Glow Map - per geometry
Normalmap - per geometry
AO - per geometry
PRTp/n - per geometry

I have a blender noodle, part of LaGrande, that takes your AO or PRT and your height map as inputs, and outputs a modulated AO or PRT that includes illumination variations as per the height map. Also useful for radiosity bakes.

That still doesn't help the AO situation that much from a realistic visualization standpoint because the craters are naturally a good deal lighter than the undisturbed surface matter, because they have less time to have been baked and darkened by the cosmic rays. AO then takes things the other way and makes those craters darker because of obscurred star light. So the two more or less neutralize each other.

I don't think the same would apply for the PRT though.

The AO is is a "simplified PRT". A PRT is like a 6-way AO; or you could say an AO is an omnidirectional PRT. What I'm trying to say is, they are the same type of thing. Now, if I read correctly between the lines, I think that what you're worried about is that AO would darken the insides of craters. That would only happen if the AO were incorrectly used. The popular but incorrect use of AO is when people use it to darken the diffuse texture. The correct use of the AO, using current shaders, is as part of the glow map. You load the diffuse in Gimp, load the AO as a layer in multiply mode, merge, darken considerable, to about 1/8 of the brightness (use curves, drag the right end of the line down from 255 to 32 or so), and save that as your glow map. The end result is that the AO will be hardly noticeable, as it should be.

[Deus Siddis]

...if each roid has its own AO, the diffuse/specular textures don't really matter as much where they fall, as they represent only color of the material, which is probably some shade of gray or brown anyways, and noisy.

The most important texture to consider is the normal map. You benefit the most visually if every asteroid has its own normal map. Only problem is with asteroid texture types that match up precisely between the diff/spec and norm maps, like the magnetite and pallasite asteroids. If one is warped and the other is not, the result will look kind of wrong.

Very true; so, in summary:
Diffuse - randomizable
Specular - randomizable
Shininess - randomizable
Glow Map - per geometry
Normalmap - per geometry
AO - per geometry
PRTp/n - per geometry

Not quite, it is a little more complicated. You might want to take a quick look at the sample renders I posted on the first page of this thread. Those are the first 5 of 12 total texture sets. Basically each texture set loosely represents a different Type of asteroid or a different asteroid makeup that is often dominated more or less by one type of material.

Some of these asteroid type textures have been created in such a similar way that, at least when baked to the same asteroid model, they can share the same maps, aside from diffuse and specular. But not all. Basically:

The C-Type and S-Type sets can share some textures with each other but not others.

The Magnetite, Albite, Enstatite, Olivine, Pyroxene, Andesine, Jadeite and Labradorite can share some textures with each other but not others.

M-Type cannot share anything.

Pallasite cannot share anything.

The AO is is a "simplified PRT". A PRT is like a 6-way AO; or you could say an AO is an omnidirectional PRT. What I'm trying to say is, they are the same type of thing.

That is why it takes two textures right? You need data on 6 directions but you can only get 4 channels of information out of one image?

Now, if I read correctly between the lines, I think that what you're worried about is that AO would darken the insides of craters. That would only happen if the AO were incorrectly used. The popular but incorrect use of AO is when people use it to darken the diffuse texture. The correct use of the AO, using current shaders, is as part of the glow map. You load the diffuse in Gimp, load the AO as a layer in multiply mode, merge, darken considerable, to about 1/8 of the brightness (use curves, drag the right end of the line down from 255 to 32 or so), and save that as your glow map. The end result is that the AO will be hardly noticeable, as it should be.

I see, so then the ultimate goal would be to no longer use ambient lighting in VS mods, once every model has an AO bake built into its glow map to more accurately account for the ambient star light. And then once AO gets its own place in the shader, you could ramp it up or down and change its color when that ship entered an area with greater ambient light, like a system in a more massive star cluster, a nebula or an atmosphere, etc.

[chuck_starchaser]

Not quite, it is a little more complicated. You might want to take a quick look at the sample renders I posted on the first page of this thread. Those are the first 5 of 12 total texture sets. Basically each texture set loosely represents a different Type of asteroid or a different asteroid makeup that is often dominated more or less by one type of material.

Some of these asteroid type textures have been created in such a similar way that, at least when baked to the same asteroid model, they can share the same maps, aside from diffuse and specular. But not all. Basically:

The C-Type and S-Type sets can share some textures with each other but not others.

The Magnetite, Albite, Enstatite, Olivine, Pyroxene, Andesine, Jadeite and Labradorite can share some textures with each other but not others.

M-Type cannot share anything.

Pallasite cannot share anything.

Not sure what you mean by "cannot share anything". AO, PRT's, radio bakes and normal maps are tied to
geometry; not to chemistry. Chemistry gives you colors (diffuse, specular, shininess). Form gives you geometry, normalmap; and all the shadow maps (AO and PRT's).

The AO is is a "simplified PRT". A PRT is like a 6-way AO; or you could say an AO is an omnidirectional PRT. What I'm trying to say is, they are the same type of thing.

That is why it takes two textures right? You need data on 6 directions but you can only get 4 channels of information out of one image?

Exactly.

Now, if I read correctly between the lines, I think that what you're worried about is that AO would darken the insides of craters. That would only happen if the AO were incorrectly used. The popular but incorrect use of AO is when people use it to darken the diffuse texture. The correct use of the AO, using current shaders, is as part of the glow map. You load the diffuse in Gimp, load the AO as a layer in multiply mode, merge, darken considerable, to about 1/8 of the brightness (use curves, drag the right end of the line down from 255 to 32 or so), and save that as your glow map. The end result is that the AO will be hardly noticeable, as it should be.

I see, so then the ultimate goal would be to no longer use ambient lighting in VS mods, once every model has an AO bake built into its glow map to more accurately account for the ambient star light.

Exactly; and I think Klauss already got rid of ambient light in the VS shaders, anyways.

And then once AO gets its own place in the shader, you could ramp it up or down and change its color when that ship entered an area with greater ambient light, like a system in a more massive star cluster, a nebula or an atmosphere, etc.

Exactly again. I have a modified, non-CineMut shader in PU that accepts AO in the glow-map's alpha channel; the ony reason I haven't given it to VS is that Klauss made a number of VS-specific changes to the shader I submitted before, and I'm not sure what they are. But this shader is backwards compatible with having AO already baked in the glow map. If you have the AO in the alpha channel of the glow map, all you need to do is put emissive alpha low in the xmesh, and the shader takes that as its cue.

[Deus Siddis]

Not sure what you mean by "cannot share anything". AO, PRT's, radio bakes and normal maps are tied to geometry; not to chemistry. Chemistry gives you colors (diffuse, specular, shininess). Form gives you geometry, normalmap; and all the shadow maps (AO and PRT's).

The geometry of the asteroids you see on the first page of this thread all look more or less the same without textures, basically smooth amorphous rocks. But when they have the normal map (and to a lesser extent, the diffuse and specular) textures applied, they appear to have craters and be covered in dust, or some sort of interlocking or fractured crystal formation or fragments, or a smooth metallic surface, or a combination of any of those, depending on the intended look of that asteroid chemistry type. All of these are pseudo-geometric features are in the normal map. And as mentioned, without the detail in the normal map, the AO doesn't look like anything because of the lack of fine/concave geometric detail in the models alone, so AO (and my guess is to somewhat of a less extent, PRT's) is directly tied to the normal map. Radio bakes are not needed unless maybe there is something that could emits light on some asteroids.

Are asteroid geometric differences realistically believable based on their makeup? Yes. 1 2

Are all of these asteroid models/textures a realistic representation of these differences? Probably not, but there isn't yet enough imagery and data to know exactly what they actually do look like. Instead they are meant to strike a balance between realism and some aesthetic exaggeration (mostly in regard to detail scale).

For realism buffs though, the S-Type and C-Type asteroids could be used exclusively; I don't think they stray far from reality.

Exactly again. I have a modified, non-CineMut shader in PU that accepts AO in the glow-map's alpha channel; the ony reason I haven't given it to VS is that Klauss made a number of VS-specific changes to the shader I submitted before, and I'm not sure what they are. But this shader is backwards compatible with having AO already baked in the glow map. If you have the AO in the alpha channel of the glow map, all you need to do is put emissive alpha low in the xmesh, and the shader takes that as its cue.

That could be a solution, though the asteroids don't need to use a glow map otherwise, so the first three channels would waste some system resources.

[chuck_starchaser]

Not sure what you mean by "cannot share anything". AO, PRT's, radio bakes and normal maps are tied to geometry; not to chemistry. Chemistry gives you colors (diffuse, specular, shininess). Form gives you geometry, normalmap; and all the shadow maps (AO and PRT's).

The geometry of the asteroids you see on the first page of this thread all look more or less the same without textures, basically smooth amorphous rocks. But when they have the normal map (and to a lesser extent, the diffuse and specular) textures applied, they appear to have craters and be covered in dust, or some sort of interlocking or fractured crystal formation or fragments, or a smooth metallic surface, or a combination of any of those, depending on the intended look of that asteroid chemistry type. All of these are pseudo-geometric features are in the normal map. And as mentioned, without the detail in the normal map, the AO doesn't look like anything because of the lack of fine/concave geometric detail in the models alone, so AO (and my guess is to somewhat of a less extent, PRT's) is directly tied to the normal map. Radio bakes are not needed unless maybe there is something that could emits light on some asteroids.

Are asteroid geometric differences realistically believable based on their makeup? Yes. 1 2

Are all of these asteroid models/textures a realistic representation of these differences? Probably not, but there isn't yet enough imagery and data to know exactly what they actually do look like. Instead they are meant to strike a balance between realism and some aesthetic exaggeration (mostly in regard to detail scale).

For realism buffs though, the S-Type and C-Type asteroids could be used exclusively; I don't think they stray far from reality.

This is all very interesting, but still unrelated to what I was talking about. What I was saying is that you could have AO, (PRT's), and normalmap that are tied to each asteroid model; and a set of, say, 8 diffuse/specular texture sets that represent the underlying material and can be randomized. The only problem I can see is if you want to do something like in the last picture, where green patches in albedo correlate to crackly surfaces in the normalmap. Again, if that's really needed, you could make that type of asteroid special (and rare), and use randomized diffuse texture picks for other types.

Exactly again. I have a modified, non-CineMut shader in PU that accepts AO in the glow-map's alpha channel; the ony reason I haven't given it to VS is that Klauss made a number of VS-specific changes to the shader I submitted before, and I'm not sure what they are. But this shader is backwards compatible with having AO already baked in the glow map. If you have the AO in the alpha channel of the glow map, all you need to do is put emissive alpha low in the xmesh, and the shader takes that as its cue.

That could be a solution, though the asteroids don't need to use a glow map otherwise, so the first three channels would waste some system resources.

Very true. Well, once Klauss' Techniques mature, we could have a special shader for asteroids that doesn't look for stuff like damage textures and glow map, but optimizes texture channels to have ao and prt's somewhere. In the meantime, tho... maybe the best solution is ambient light in glow map, the current way.

[Deus Siddis]

The only problem I can see is if you want to do something like in the last picture, where green patches in albedo correlate to crackly surfaces in the normalmap. Again, if that's really needed, you could make that type of asteroid special (and rare), and use randomized diffuse texture picks for other types.

Right, that is what I'm saying. Except it is not just with the last picture, the pallasite, that has this correlation between the normal map and the other map types. Like the magnetite has grooves in the normal map that correspond to the silvery vains in the albedo texture. Or the M-Type has a very smooth metallic look from its normal map that matches its high spec and very low diff.

Very true. Well, once Klauss' Techniques mature, we could have a special shader for asteroids that doesn't look for stuff like damage textures and glow map, but optimizes texture channels to have ao and prt's somewhere. In the meantime, tho... maybe the best solution is ambient light in glow map, the current way.

I will do that then, plus provide an unaltered AO source file for the future shader.

[chuck_starchaser]

Right, that is what I'm saying. Except it is not just with the last picture, the pallasite, that has this correlation between the normal map and the other map types. Like the magnetite has grooves in the normal map that correspond to the silvery vains in the albedo texture. Or the M-Type has a very smooth metallic look from its normal map that matches its high spec and very low diff.

Ha! Interesting problem.
I think I need to think about this.
Maybe, if I could find the way to do the AO/PRT/radiosity modulation by normalmap in the shader, then the AO could be supplied un-modulated.
Actually, this is quite doable with PRT's in place; a bit more complicated but still doable with AO only.
But the problem is that if the normalmap is tied to the texturing, rather than to the geometry, the geometry still needs a normalmap that is
usually supplied as a corrective, from a higher, off-line LOD; so we'd need two normalmaps...
Need to think about it.

Very true. Well, once Klauss' Techniques mature, we could have a special shader for asteroids that doesn't look for stuff like damage textures and glow map, but optimizes texture channels to have ao and prt's somewhere. In the meantime, tho... maybe the best solution is ambient light in glow map, the current way.

I will do that then, plus provide an unaltered AO source file for the future shader.

Good plan; go ahead that way for now. I'm thinking that asteroids will need a very specialized shader of their own, eventually.

[Deus Siddis]

Right, that is what I'm saying. Except it is not just with the last picture, the pallasite, that has this correlation between the normal map and the other map types. Like the magnetite has grooves in the normal map that correspond to the silvery vains in the albedo texture. Or the M-Type has a very smooth metallic look from its normal map that matches its high spec and very low diff.

Ha! Interesting problem.
I think I need to think about this.

Hmm, I am beginning to think that the solution might be simply a matter of making the right sacrifices. Now that I am no longer operating under the illusion that textures must be square, texture requirements have been cut in half. Looking at the asteroid models again, I am thinking also that it could be much better to have rather than 8 okay asteroids, 4 much better ones with textures customized for both each of those models and for each asteroid type texture set. Using half as much texture space per model on half as many models makes this method a quarter as expensive as I had thought, which puts it in the running.

So. . .

Maybe, if I could find the way to do the AO/PRT/radiosity modulation by normalmap in the shader, then the AO could be supplied un-modulated.
Actually, this is quite doable with PRT's in place; a bit more complicated but still doable with AO only.
But the problem is that if the normalmap is tied to the texturing, rather than to the geometry, the geometry still needs a normalmap that is
usually supplied as a corrective, from a higher, off-line LOD; so we'd need two normalmaps...
Need to think about it.

Basically, I think this goes back to, for each model/texture combination I can bake one normal map that combines the 'bump' details with the higher LOD correctiveness like I usually do. Then any AO and PRT would just have to be baked from that all-encompassing normal map.

[chuck_starchaser]

Yep. I think your way is best for now.

Here's some food for thought, for the future:

[ELUCUBRATION:]
A good number (64?) of asteroid types, individually modeled and textured. Textures are 512 x 512, put
into an 8 x 8 atlas texture (512 x 8 = 4k, so a 4k x 4k texture). Don't panic about the 512-ness yet...
Instead of a diffuse or albedo "color", the colors painted into texture 1 are color keys representing
materials.
Another 4k x 4k texture set with its own albedo, normalmap, PRT's, etceteras, is also an 8 x 8 atlas,
but each of the 64 sub-regions represents a material corresponding to a color key; and these materials
are used like "detail textures", and are tiled at higher resolution, masking away the 512-nesss of the
main texture by adding smaller detail. (Say, at 4 times greater resolution, making the asteroid textures
seem as if they were 2k x 2k).
To make sub-regions tileable, they'd need to contain a tileable square of 256 x 256 in the middle, and
be padded around by copies of itself; or put more simply, each 512 subregion is a 2 x 2 tiling of a
256 x 256 tileable texture.
IOW, the larger features of asteroids, like craters and material changes would be represented at 512 x
512 resolution; but materials would show 2k x 2k apparent detail.
[/ELUCUBRATION]

[Deus Siddis]

[ELUCUBRATION:]
A good number (64?) of asteroid types, individually modeled and textured. Textures are 512 x 512, put
into an 8 x 8 atlas texture (512 x 8 = 4k, so a 4k x 4k texture). Don't panic about the 512-ness yet...
Instead of a diffuse or albedo "color", the colors painted into texture 1 are color keys representing
materials.
Another 4k x 4k texture set with its own albedo, normalmap, PRT's, etceteras, is also an 8 x 8 atlas,
but each of the 64 sub-regions represents a material corresponding to a color key; and these materials
are used like "detail textures", and are tiled at higher resolution, masking away the 512-nesss of the
main texture by adding smaller detail. (Say, at 4 times greater resolution, making the asteroid textures
seem as if they were 2k x 2k).
To make sub-regions tileable, they'd need to contain a tileable square of 256 x 256 in the middle, and
be padded around by copies of itself; or put more simply, each 512 subregion is a 2 x 2 tiling of a
256 x 256 tileable texture.
IOW, the larger features of asteroids, like craters and material changes would be represented at 512 x
512 resolution; but materials would show 2k x 2k apparent detail.
[/ELUCUBRATION]

I think that fitting rectangular textures into a square super texture would work better and produce either 32 1024x512 textures or 128 512x256 textures, but yeah, that could be an effective plan for the future. However for the repeating textures, unless I am really mistaken, I think VS already supports and uses some procedural textures, which for a natural formation such as an asteroid, might work better in a few ways than a repeating bitmap texture.

BTW, I think I should probably ask you first lest I risk meeting my waterloo (IOW my toon shaders )- would any of these asteroids be an improvement on the ones currently used by PU? If so, which 'type' or 'types' fit the style you want for PU?

I should probably ask the VT folks too. . .

[chuck_starchaser]

They are fantastic. Keep going. The asteroids in the original Privateer
looked like rolling stones. That's not a part of canon I care to adhere to.
What I would like to implement, some day, is asteroid systems that
include many sizes of asteroids, from rocks inches in size to kilometers.
For now, I'd import your large asteroids into PU as they are, and later
add smaller ones. The smaller asteroids need to be procedurally spawned
in front of the ship and harvested from behind, in like a 1 km size box
that follows your ship around. Long story.
Yeah, I forgot that wrap-around textures need to be unique for filtering
and anisotropy to wrap around as well. Can't atlas them together.

[Deus Siddis]

After much distraction, redesign and procrastination on my part, this asteroid content pack is finally complete and ready for (187 megabytes worth of) download:

Download Asteroids

From the Manual included with the download:

ABOUT

This is a 3D content package optimized for realtime 3D usage. It is meant to represent asteroids and asteroid fields of various make-ups and visual appearances.


LICENSE

It is released under the GNU General Public License Version 3, a copy of which should be included in this package, but can also be found here:

http://www.gnu.org/licenses/gpl-3.0.txt


CREDITS

Created By: Jonathan Kelly

Note: You are not legally obligated to credit me under the terms of the license, but I would greatly appreciate it if you did so anyway!


Special Thanks:

Dave Jarvis (For his helpful tutorial: http://www.davidjarvis.ca/dave/blender/ ... l-21.shtml)
Rene Sammler (For his helpful Vertex Noise script created for Blender: http://www.sammler-mediengestaltung.com)
Blender Foundation (For providing the FOSS content creation application Blender, with which this was created: http://www.blender.org/)


INSTRUCTIONS

In addition to the source .blend file, this package contains 4 asteroid models with 3 levels of detail each in the form of 12 .obj files and texture sets to represent 9 different kinds of asteroids using combinations of diffuse, specular and normal maps for each asteroid model, in the form of 71 .png files. So that you know which files go with which, an organizational naming convention is used:

Each .obj file uses the code "asteroidX_lodY" where:

X is the model number (from 1-4) that distinguishes one asteroid model from the next
Y is the level of detail number (from 1-3, with 1 being a level of detail of 1920 triangles, 2 being a level of detail of 480 triangles and 1 being a level of detail of 80 triangles.)

Each .png file uses the code "A_asteroidX_B" where:

A is the texture set this map belongs to (ctype, stype, mtype, magnetite or one of the special "crystal" texture sets [see below])
X is the asteroid model this texture is meant for (model number 1-4)
B is the type of shader this texture is meant for (albedo [used by both diffuse and specular shaders], diffuse, specular or normal)

Note that there is a special category of texture sets, called the "crystal" texture sets. All of the "crystal" texture sets use the crystal specular map and crystal normal map, BUT there is a different diffuse map for each of the following crystal texture sets as follows- enstatite, olivine, pyroxene and jadeite.


NOTES

* Using all textures in the same realtime environment would be extremely demanding, so it is recommended that you use only a portion of the available textures sets on the asteroid models, in one environment.

* The "jadeite" diffuse textures are purple instead of green because they represent the more rare Purple Jadeite. This is because, in addition to Olivine, the green "olivine" diffuse textures can also be considered to represent the more common Green Jadeite.

[Phlogios]

Screenshots or it didn't happen

[rivalin]

Good stuff! Let's hope someone gets it into SVN soon.

[Deus Siddis]

Screenshots or it didn't happen

You know Phlogios, the stype texture should be perfect for making a moon. So if you would like to see a realtime 3d (or even a pre-rendered) moon for dungeon hack, just tell me what polygon count you'd like for it and it's done.

As for screenshots, as you can read earlier in this thread, I gave it my all but ultimately I couldn't get VS to render any texture on the mesh (not even the diffuse) for some unexplained reason. With everything released now you're free to download the files and give it a shot yourself though, otherwise there are renders on the first page of this thread to look over.

There is also now the option to realtime opengl render them and capture them as screenshots in the new blender game engine with glsl. I have some access to a machine that could handle that.

Good stuff! Let's hope someone gets it into SVN soon.

Thanks, I certainly hope so too!

[chuck_starchaser]

This is good stuff!
I like the fact that it's down to Earth... er.. not the best expression in the context...
I mean that they are fairly un-complicated. I'd probably have succumbed to the
temptation to add more detail to the meshes; but it would have proven a mistake;
because the more unique the shapes, the more recognizable, and pretty soon
you'd realize they are exactly 4 shapes.
I think the level of detail you have is just about right for there being 4 types.
Guess we'll have to CineMutize them
Only thing I don't quite feel comfortable with are the bright specular textures.
I know nothing about asteroid geology, but I've a feeling that even the most
metallic of asteroids are covered in dust, at least. I don't think any of them would
look like shiny metal; but that's what they would look like with bright speculars.
Also a bit worrisome is to see color in the speculars. I hope you know what
colors you're using and why. Only metallic specularities have color, and the
color has to correspond to diffuse color. More specifically, diffuse color, for
any metal, is approximately the square of the specular color, toned down.
Say gold, for example, is yellow in specular.
Let's say some gold alloy is 0.9, 0.8, 0.6 in specular. Let's call that "specular
chroma", to give it a name.
Its "diffuse chroma" would be the square, or 0.81, 0.64, 0.36. Got it?
Now let's say the surface has very few microcavities, so that its specular
ratio is like 0.9.
Then, final specular color would be specular chroma * 0.9; and
final diffuse color would be diffuse chroma * 0.1.
If you don't observe this relationship for metals, you end up with psychedelic
materials.
For non-metals, specularity is always white; or rather "non-chromatic".
For mixed materials, the truth lies on a line between the two points above,
but never too far off that line. (Well, except that you can have a diffuse material
of one color mixed with a metal of another; but then you need to apply other
math rules to that, namely the mix-in diffuse color must obscure the specular
by the blending ratio in which it mixes with the metal's diffuse.)
And the other rule is that in no channel of no texel of no texture should diffuse
plus specular EVER add to more than one.
CineMut enforces all the above; but if you're targeting standard shaders you
have to observe the rules at texturing time.
Easiest way to do it would be to use separate xcf's for metallic and non-
metallic contents; then combine them by blending them based on yet another
procedural mask.
So, for a metallic xcf you'd have an albedo base; then duplicate layer, set to
multiply, save copy to square.png. Delete the duplicated layer; then Load
as Layer square.png; rename as diffuse_chroma. Then you generate a
procedural mask, monochrome, load it as layer, rename to "specularity".
Set the diffuse_chroma layer to normal blend 100%, invert the specularity
and set it to multiply, then save copy as metal_diffuse.png. Undo the
inversion of the specularity, hide the diffuse chroma, so that specularity
now multiplies the background texture, and save as metal_spec.png.
For non-metals you have a diffuse base and a specularity mask only.
Specular is simply the specularity mask.
Diffuse is the inverse of the specularity mask multiplying the diffuse base.
Call them diel_diffuse.png and diel_spec.png.
Now you generate another procedural mask, and use it to blend the two
diffuse and the two speculars, separately, into diffuse.png and spec.png.
Finally, you'd have another diffuse color base for mix-in, representing
dust or rusts or whatever, and a monochrome mix-in mask, pretty dark.
So, you multiply the diffuse.png AND spec.png by the inverse of the
mixin mask; and the new color base by the mask (un-inverted); then
blend the result of the latter in ADD mode to diffuse.png. Done.
Easier to do in Blender than in Gimp, really; with compositor nodes.
But besides all that, your specular masks should be pretty dark. Most
of the reflectivity would be diffuse, I would think. Bright specular is
pretty much a synonym with shiny metal. And whatever specularity
you do have should be very low shininess.

In CineMut, I'm planning to do something with detail textues to have
sparkly christals. Basically, dots that shine bright but only at some
angle, so that as you move relative to a rock or dust surface you see
fleeting sparkles.

So, no luck yet getting them in-game? I'm thinking, Vegastrike has
like two or three kinds of asteroid fields. Some are disabled I think.
Could it be that you picked one that is not used to replace yours for?
Or were you importing your roid as ships just to look at them?

[Deus Siddis]

This is good stuff!
I like the fact that it's down to Earth... er.. not the best expression in the context...
I mean that they are fairly un-complicated. I'd probably have succumbed to the
temptation to add more detail to the meshes; but it would have proven a mistake;
because the more unique the shapes, the more recognizable, and pretty soon
you'd realize they are exactly 4 shapes.
I think the level of detail you have is just about right for there being 4 types.

Yeah, I selected these four meshes for exactly that reason- lack of distinguishing details.

Guess we'll have to CineMutize them

Cool!

Only thing I don't quite feel comfortable with are the bright specular textures.
I know nothing about asteroid geology, but I've a feeling that even the most
metallic of asteroids are covered in dust, at least. I don't think any of them would
look like shiny metal; but that's what they would look like with bright speculars.

There's just the one metal (M-Type) asteroid with the high specular. This crazy thing gave me the idea:

http://en.wikipedia.org/wiki/216_Kleopatra

That is not a normal shape for an asteroid- to hold itself together in that shape, it must be pure or nearly pure metal methinks. Plus I'm not sure how the gravity would hold the dust onto something like that, the dust might just slide off of places or such as it spun, it is a weird thing to think about.

Anyway, it is just another option, mods can decide if they what to use some asteroids with that metallic look or stick to the more dusty asteroid texture sets.

Also a bit worrisome is to see color in the speculars. I hope you know what
colors you're using and why. Only metallic specularities have color, and the
color has to correspond to diffuse color. More specifically, diffuse color, for
any metal, is approximately the square of the specular color, toned down.

Actually, only specular color in the specular textures is an accident in this pack. Looking at them now, it seems I forgot to desaturate one of the pallasite specular textures, but I think this is the only one.

The colorful textures you are seeing are all meant as diffuse textures. The goldish looking ones are actually diffuse textures for mostly Enstatite textures, which is a kind of stone/crystal found alot in certain types of asteroids.

Take a look at the "Manual" document included with the download, that explains which textures are used how and in what combinations. It is a little complicated, I tried to explain it all in that document as clearly as I could come up with.

Say gold, for example, is yellow in specular.
Let's say some gold alloy is 0.9, 0.8, 0.6 in specular. Let's call that "specular
chroma", to give it a name.
Its "diffuse chroma" would be the square, or 0.81, 0.64, 0.36. Got it?
Now let's say the surface has very few microcavities, so that its specular
ratio is like 0.9.
Then, final specular color would be specular chroma * 0.9; and
final diffuse color would be diffuse chroma * 0.1.
If you don't observe this relationship for metals, you end up with psychedelic
materials.
For non-metals, specularity is always white; or rather "non-chromatic".
For mixed materials, the truth lies on a line between the two points above,
but never too far off that line. (Well, except that you can have a diffuse material
of one color mixed with a metal of another; but then you need to apply other
math rules to that, namely the mix-in diffuse color must obscure the specular
by the blending ratio in which it mixes with the metal's diffuse.)

The M-Type asteroid is the only metal one, and it uses 1 pixel diffuse and specular textures, which I think follow very close to that ratio, but if not it is instantly modifiable since all of the detail is in the normal map.

And the other rule is that in no channel of no texel of no texture should diffuse
plus specular EVER add to more than one.

They should all conform to that rule. If one does not, it is a careless mistake on my part.

CineMut enforces all the above; but if you're targeting standard shaders you
have to observe the rules at texturing time.
Easiest way to do it would be to use separate xcf's for metallic and non-
metallic contents; then combine them by blending them based on yet another
procedural mask.
So, for a metallic xcf you'd have an albedo base; then duplicate layer, set to
multiply, save copy to square.png. Delete the duplicated layer; then Load
as Layer square.png; rename as diffuse_chroma. Then you generate a
procedural mask, monochrome, load it as layer, rename to "specularity".
Set the diffuse_chroma layer to normal blend 100%, invert the specularity
and set it to multiply, then save copy as metal_diffuse.png. Undo the
inversion of the specularity, hide the diffuse chroma, so that specularity
now multiplies the background texture, and save as metal_spec.png.
For non-metals you have a diffuse base and a specularity mask only.
Specular is simply the specularity mask.
Diffuse is the inverse of the specularity mask multiplying the diffuse base.
Call them diel_diffuse.png and diel_spec.png.
Now you generate another procedural mask, and use it to blend the two
diffuse and the two speculars, separately, into diffuse.png and spec.png.
Finally, you'd have another diffuse color base for mix-in, representing
dust or rusts or whatever, and a monochrome mix-in mask, pretty dark.
So, you multiply the diffuse.png AND spec.png by the inverse of the
mixin mask; and the new color base by the mask (un-inverted); then
blend the result of the latter in ADD mode to diffuse.png. Done.
Easier to do in Blender than in Gimp, really; with compositor nodes.

I'll have to go over this more carefully later, my understanding of light reflection physics is still somewhat limited.

But besides all that, your specular masks should be pretty dark.

Only the crystals (like enstatite) have a fairly bright specular in this pack. Crystals I thought seem to put out alot of specular, but I might be wrong.

Most of the reflectivity would be diffuse, I would think. Bright specular is
pretty much a synonym with shiny metal. And whatever specularity
you do have should be very low shininess.

Not sure if VS supports shininess yet, but I didn't make maps for that. It would probably be just a 1 pixel texture or material setting though in this case, I think.

In CineMut, I'm planning to do something with detail textues to have
sparkly christals. Basically, dots that shine bright but only at some
angle, so that as you move relative to a rock or dust surface you see
fleeting sparkles.

I think that would look very fitting, from what I have gathered.

So, no luck yet getting them in-game? I'm thinking, Vegastrike has
like two or three kinds of asteroid fields. Some are disabled I think.
Could it be that you picked one that is not used to replace yours for?
Or were you importing your roid as ships just to look at them?

I did all of those things and it worked- my asteroids meshes were in-game. But they lacked textures of any kind. Maybe it was just my old graphics card, because pyramid did seem to indicate he got them to work for himself.

[chuck_starchaser]

There's just the one metal (M-Type) asteroid with the high specular.

Not so. Look at the magnetite speculars.
The pallasite speculars are spotted; but the light tone is waaay too light, IMO.
But the best thing for you would be to get them in-game and see the results.

This crazy thing gave me the idea:

http://en.wikipedia.org/wiki/216_Kleopatra

Yeah; that's radar imagery; and we've no idea what it looks like in visible
wavelengths; boy I'd love to know... But I think it's safest to assume even the
most metallic asteroids to be covered in dust.

That is not a normal shape for an asteroid- to hold itself together in that shape, it must be pure or nearly pure metal methinks. Plus I'm not sure how the gravity would hold the dust onto something like that, the dust might just slide off of places or such as it spun, it is a weird thing to think about.

I think it would. That's ultra micro nano gravity. Probably electric charges play
a bigger role in dust sticking to it; and there's plenty dust out there; and pretty charged. But once in a while I'm sure
something bigger than bowling ball hits the metal roid and the dust flies off, comes back a few centuries later.

Actually, only specular color in the specular textures is an accident in this pack. Looking at them now, it seems I forgot to desaturate one of the pallasite specular textures, but I think this is the only one.

Probably what I saw; can't find them
now; thought I saw some light pinkish color somewhere.

The M-Type asteroid is the only metal one, and it uses 1 pixel diffuse and specular textures, which I think follow very close to that ratio, but if not it is instantly modifiable since all of the detail is in the normal map.

Ahhh, I thought I was seeing invisible textures...

And the other rule is that in no channel of no texel of no texture should diffuse
plus specular EVER add to more than one.

They should all conform to that rule. If one does not, it is a careless mistake on my part.

I was just mentioning...

Only the crystals (like enstatite) have a fairly bright specular in this pack. Crystals I thought seem to put out alot of specular, but I might be wrong.

Well, sand IS chrystals, technically.
And technically, all reflections are specular.
The term "diffuse" is a graphics term, more than a physics term. "Diffuse lighting" (AKA Lambert) is a simplified model that
doesn't really exist in the real world. You see, the formula is dot( light_vec, normal_vec ), which is the cosine of the
angle between the light vector and the surface normal. Well, that's simply the amount of light arriving per unit of
surface area. IOW, Lambert assumes that photons arriving at the surface are reflected in perfectly random directions
in a perfectly hemispherical distribution. That's an absurdity; but it sort of works for "matte" materials, which typically
have microtopology in the surface so complex that light may bounce several times before it comes out again; which
is why the distribution is "kinda" random. So "diffuse reflectivity" you won't find it in a physics book; it's a Computer
Graphics hack, is all it is. Basically it models reflectivity of materials where light bounces more than once before
coming out. But that's precisely the case with sand, for the most part: Made of chrystals, all very specular, but because
of the complexity of all these chrystals piling on randomly, most of the light hitting sand bounces from one chrystal to
another, reflecting, refracting; and when it comes out it comes out pretty much in any random direction.

Most of the reflectivity would be diffuse, I would think. Bright specular is
pretty much a synonym with shiny metal. And whatever specularity
you do have should be very low shininess.

Not sure if VS supports shininess yet, but I didn't make maps for that. It would probably be just a 1 pixel texture or material setting though in this case, I think.

It does. Alpha channel in the
specular texture. Just give it zero alpha.

I did all of those things and it worked- my asteroids meshes were in-game. But they lacked textures of any kind. Maybe it was just my old graphics card, because pyramid did seem to indicate he got them to work for himself.

Damn!