Everyone: Please fix up viewallships.mission

[hellcatv]

so our 0.5.0 release included a mission called viewallships.mission
you can run it by executing
vegastrike viewallships.mission from the command line
or drag'n'dropping viewallships.mission onto the application itself.

Once you're in the mission you can see *all* the starships--and some of them look amazing. Some have fantastic textures but look poor because they're all white or too dark or don't have specular reflections.

It would be nice if bit by bit we could fix up the material properties in the BFXM, add normal mapping, add specular maps and glow maps to the ships so that while their geometry looks good already, their hulls look good in game.

99% of the work on most of these ships is done and it just takes someone to run through and make a specular map or draw some bump map hull lines then run a normal mapping program (nvidia has a nice plugin for photoshop and there's a nice one for gimp)

Can we make this our mission for 0.5.1: lets make all our good art look equally good instead of layering more and more art that would look good if someone bothered to tweak it.

How to do this: just run the mesher on some of the bfxm files
mesher myfile.bfxm 0_0.xmesh bxc
then edit the resulting *.xmesh files to put the right materials inplace
then
mesher 0_0.xmesh myfile.bfxm xbc
mesher 1_0.xmesh myfile.bfxm xba
...


Any questions folks? I think we could make 0.5.1 even more of a visual treat than 0.5.0 and it could be a good thing for artsy folks to be doing while the devs try to polish the MMORPG and Multiplayer modes as well as several other burning questions!

Thanks!

[bgaskey]

I'll do some work on this in my spare time. I have SAT's saturday and AP exams next two weeks, but I may have a minute or so...literally

[chuck_starchaser]

How about setting it as a goal for 0.5.2, and adding ambient occlusion too
http://vegastrike.sourceforge.net/forum ... hp?t=11159

[bgaskey]

I dunno...ambient occlusion sounds pretty intense. I'm not really an artist, or a 3d designer. It takes me several trips to wikipedia just to understand these threads.

[loki1950]

Not intense just tedious set up the lights(and colors) check all your materials make sure that the model is properly cleaned up(flipped normals and such) start the bake come back in the morning(they can take awhile)and go ^&%$# it's wrong and start again.

Enjoy the Choice

[chuck_starchaser]

I can explain it better than wikipedia. Ambient occlusion is the self-shadowing of a model. Assume you would surround a white-painted model into a sphere with hundreds of lights, all evenly distributed. Would the model look totally bright? No, some recessed or hidden parts of the ship would be in penumbra or darkness, due to self-shadowing. But standard OGL ambient light assumes the ship would be evenly bright, and that looks very unrealistic.

When you bake ambient occlusion with Blender, Blender takes its sweet time, but it does something extremely valuable for you: From each point on the surface of the ship, it casts hundreds of rays, and for each ray it checks whether it hits any other part of the ship, or wheter it "escapes" to infinity. If it escapes, it counts it as one; if it doesn't it counts it as zero. (Well, it's more complicated than that, because the angle to the surface matters too, I'm just simplifying it.) So, once it finishes testing all those hundreds of rays, it takes the final count of rays that escaped, and divides that by the total rays it tested. If half of them lived, then the number is 0.5, and so it writes that to the texture as 50% gray. And it proceeds then to the next point on the surface of the ship. That's why it can take hours.

But the result is easy to use in texturing, and it adds a ton of realism.

Here's an ambient occlusion baking, loaded back as a texture. I was just working on improving the looks of PU's refinery...



This is a delicate AO job, because the refinery re-uses sections of the texture a lot, so I had to group together sections that could share the same AO... And it will take quite a bit of manual editing to get right.

Of course, you don't use the ao as the texture; but you use it to modulate your texturing. I modulate (multiply) the diffuse texture by a brightened ao (gamma of 0.5); the specular texture by a darkened ao (gamma of 2), and then I multiply the diffuse by the plain AO (no gamma) and add the result to the glow texture with alpha of about 15%, to get a baked ambient light component. I have good reasons for those gammas, but it's a long story. It looks great, and that's what matters

EDIT:
Loki, that's about it; but there's ways to know whether the ao is working right in a few minutes. You can load a small, 512 x 512 texture, and you can set the samples down to 5 or 6. Then you get a real quick AO bake you can test with. Once you're happy with the results, you crank up the texture size to 4096, and the samples to 16; and then go to bed.

[hellcatv]

AO baking would be great
but I don't see why we need to wait TWO releases---lets get this done by 0.5.1

[chuck_starchaser]

Touche. I'd love to help, but I got a mod already; however, like I've said, I'm quite willing and eager to tutor people on the the black art of ao baking

Refinery ao progress:



See, guys? Doesn't take that long.

[klauss]

Chuck (and people), we'll soon have techniques to choose from in bfxms (I started working on it yesterday). The mechanism is that you add to the xmesh a:

<... texture="blah" ... technique="basic">

Then you have a subsection in vegastrike.config that defines a bunch of stuff for that "basic" technique.

This is the form your texture packing took chuck. Just name the technique after the version or type of texture packing.

I'm debating with myself whether or not to support multipass techniques, but in any case the very least you can do is have an AO technique - one that takes an AO texture, so you don't have to taint your diffuse/specular textures with it.

So it would be best, perhaps, if the AO map was baked and not mixed with those maps, but rather stored as a separate image (actually I'd mix the AO with diffuse and very very low gamma - ie high contrast, I'll try to explain with pictures when I get home). In essence, it would be best to work with this new feature in mind.

[chuck_starchaser]

Then you bake the lights onto separate textures, using Blender's radiosity tool...



(The lights are baked at high intensity for the sake of better utilizing the textures' 8-bit per channel color range; they are dimmed down during
the final mixing.)

[chuck_starchaser]

That sounds GREAT, Klauss; FANTASTIC! Thank you! Thank you!

I'm debating with myself whether or not to support multipass techniques,

I wouldn't bother at this stage. Our current texturing techniques are too far from reaching the level where multi-pass shading would be justified. We'll need dual UV mappings and PRT's before we deserve half a second pass. 6.0, I'd say. What we need for now is a speedy solution; I'm wasting a lot of time modulating diffuse and specular by the AO because I can't have a special shader yet.

but in any case the very least you can do is have an AO technique - one that takes an AO texture, so you don't have to taint your diffuse/specular textures with it.

Exactly! My current plan is for the AO to be packed (without gamma) in the alpha channel of the glow texture.

So it would be best, perhaps, if the AO map was baked and not mixed with those maps, but rather stored as a separate image (actually I'd mix the AO with diffuse and very very low gamma - ie high contrast, I'll try to explain with pictures when I get home). In essence, it would be best to work with this new feature in mind.

Definitely. I've found the ideal gamma for the ao that modulates diffuse to be 0.5; and the best gamma for ao modulating specular to be 2.0, which is good because we only need square rooting and squaring, respectively, rather than some other (expensive) power.

BTW, having AO in a separate channel will also allow the shader to compute ambient light component, rather than have it baked into the glow map; which in turn will allow for that ambient light component to be modulated by the ambient color input parameter to the shader.

[chuck_starchaser]

PU refinery retexturing done; and fragment shaders updated.





Now I'm using the 4th power of specularity to produce shininess; and it's still not enough... Can't raise specularity enough for metal without shininess becoming too high... And artifacts go up --apparently with the fourth power also ... And I positively can't have a normalmap for this baby without tangents...

Klauss, how's that programming coming along?

[pyramid]

I am daring to post a tentative list of units that urgently require retexturing after the new shader implementation (after 0.5.0 release, for SVN revision 12269 and later, i.e. with the new shaders):
* Archimedes (probably jackS has the updated model + textures already)
* Kahan (probably jackS has the updated model + textures already)
* GTIO
* Anaxidamus
* Agesipolis
* Leonidas
* Tesla
* Vigilance
* Agasicles
* Koala
* Entourage
* Robin
* Regret
* Hammer
I have only listed those that look like silver bars with full shininess all over, which means that they should be prioritized.

Admittedly, with all the different posts and reference materials about texturing with new shaders, the correct approach can be rather confusing. I see the following tutorial as the main starting place for documenting current requirements: HowTo:IntroToShaders

I am not sure however:
* a) If this tutorial is really the correct place to start, or should we open a Development:Modeling&Texturing main page that links the complete workflow and from which we could work down to editing and keeping up-to-date the individual components.
* b) How updated it is with respect to the released shader
* c) What is the naming convention we should apply for the different textures to include in bfxm files (see proposal below)
* d) If the rgb and alpha contents are still correct
* e) Where to find LaGrande and if we should link(externally) or copy it to trunk/modtools. Same for other tools being developed by chuck_starchaser.
* f) Naming convention for texture packing versions (e.g. "TexturePackingVersion1" or just "TPV1") and corresponding documentation

...let it suffice for now.

Proposal for texture naming convention for inclusion in bfxm files (I'm still a bit in the dark about the correct combinations):

Code: Select all

<Mesh ...  texture="llamaDIF.jpg"  texture1="llamaSPC.jpg"  texture2="llamaDMG.jpg"  texture4="llamaNRM.png" >

* diffuse: UnitDIF
* specular+shininess: UnitSPC (the acronym PPL doesn't tell me anything)
* damage(+glow?): UnitGLW
* normal(+???): UnitNRM
* anything else?

[klauss]

Didn't the GTIO already have a specmap?

[chuck_starchaser]

I see the following tutorial as the main starting place for documenting current requirements: HowTo:IntroToShaders

I am not sure however:
* a) If this tutorial is really the correct place to start, or should we open a Development:Modeling&Texturing main page that links the complete workflow and from which we could work down to editing and keeping up-to-date the individual components.

That editorial is very unfinished, obsolete in some ways, ahead of the game in other ways. Wrote it at a time I was planning to start working on shaders but didn't, for various reasons. That texture packing is obsolete. The most current *planned* texture packing is summarized in this post:
http://vegastrike.sourceforge.net/forum ... 5941#95941

* b) How updated it is with respect to the released shader

Ditto, both: behind and ahead of it. See note at the bottom.

* e) Where to find LaGrande and if we should link(externally) or copy it to trunk/modtools. Same for other tools being developed by chuck_starchaser.

LaGrande is both finished and in a state of flux. It is as finished as it will ever be. What happened was that I found that circumstances can be so different from one model to another, that LaGrande will never be a black box. It's a set of Blender noodles that do specific functions. Some modules are end-of-the-chain mixers. One module makes dirt streaks that trail bumpmap features. Another takes a bumpmap and a light baking as inputs, and puts out a light baking that is modulated by the bumpmap. And so on. I could give you the url of the svn folder for LaGrande, but the stuff there is rather obsolete; and the reason I haven't updated it is that with the upcoming new shaders, LaGrande will have to change (get simpler, for a change). So, I'd rather wait for Klauss' methods, write the new shaders, then modify LaGrange, and finally put it on SVN.

* f) Naming convention for texture packing versions (e.g. "TexturePackingVersion1" or just "TPV1") and corresponding documentation

Good question. I'll try to put all the planned shader features on at once, to avoid intermediate evolutions of the texture packing that might create confusion.

Proposal for texture naming convention for inclusion in bfxm files (I'm still a bit in the dark about the correct combinations):

Code: Select all

<Mesh ...  texture="llamaDIF.jpg"  texture1="llamaSPC.jpg"  texture2="llamaDMG.jpg"  texture4="llamaNRM.png" >

* diffuse: UnitDIF
* specular+shininess: UnitSPC (the acronym PPL doesn't tell me anything)
* damage(+glow?): UnitGLW
* normal(+???): UnitNRM
* anything else?

Good. I'd go even shorter names:

• diff
• spec
• glow
• norm
• damg

NOTE:
Sorry about all the confusion. I won't confuse matters further by talking about the texture packing now, at the risk it might change next week. Thing is, as soon is Klauss is done with the "methods" variable for xmesh, I can finally start working on the new shaders. There's really no point in producing textures for the current shader now, because the new shaders could be available a week from now. This doesn't mean that texturing work needs to halt and wait. People could start drawing bump maps for all the ships on that list; or coming up with albedo textures...
http://vegastrike.sourceforge.net/forum ... 8289#98289
It's only the final packing that is affected.

For example: To use self-shadowing with the current shader you need to multiply diffuse by the ambient occlusion, in Gimp. With the upcoming shader, all you'll have to do is copy the ambient occlusion and paste it on the alpha channel of the glow texture.
The next texture pack will also support a "is_dielectric" bit, passed as single bit alpha of the damage texture. Good for glass and glossy paints. I'll explain the details when I roll out the new shaders.

But people can go on texturing; and add these tings later.

BTW, I also started writing a "mega-tutorial" on the whole texturing chain, at the PU forum...
http://wcjunction.com/phpBB2/viewtopic.php?t=568
Also on hold, waiting for the new shaders.

[pyramid]

There's really no point in producing textures for the current shader now, because the new shaders could be available a week from now. This doesn't mean that texturing work needs to halt and wait. People could start drawing bump maps for all the ships on that list; or coming up with albedo textures... It's only the final packing that is affected.

This seems to be the most feasible approach for the time being.

Didn't the GTIO already have a specmap?

The GTIO is an exception here. It seems to have spec maps (haven't checked) but shows environment reflections on the unlit ambient side and that's why I have included it in the list.

[klauss]

Environmental reflections will always appear on the unlit side, they're not affected by direct lighting. Ie: that's ok. But, if it looks wrong, I guess it still needs a check right?

[chuck_starchaser]

Environmental reflections will always appear on the unlit side, they're not affected by direct lighting. Ie: that's ok. But, if it looks wrong, I guess it still needs a check right?

As a matter of fact, a bug in the original shaders was preventing reflections on the dark side; that was one of my fixes.