Shaders Operational

[chuck_starchaser]

LOL, totally lost me. I don't know what binorma means, much less "s space". It seems to me a baker should have all the info it needs, though. Okay, wait a minute: If I have a vertical wall at the back of a ship, "nose points up" becomes meaningless. Now, if I keep left to the left and right to the right, that will keep the red channel consistent... Nope it won't, left and right are relative to the surfaca --not absolute-- when unwrapping the main body of the ship... It's not like left is port, right is starboard; it reverses at the bottom; so at the back there's no "right way" to call left and right; so I guess you're right...

But wait: The baker has all the info it needs; it can derive the texture rotation just by looking at texture coords in neighboring vertices... But the shader has no way to know. Is that what you're saying?

[klauss]

But wait: The baker has all the info it needs; it can derive the texture rotation just by looking at texture coords in neighboring vertices... But the shader has no way to know. Is that what you're saying?

Exactly. Only DX10 geometry shaders could.

[chuck_starchaser]

Well, until you or Hellcat add tangent to bfxm, or until DX10 is the norm, we'll just have to pretend that normalmaps work. I'll tell the PU modellers not to expect bumpy myracles on any front- or back-facing areas, I guess.

[DualJoe]

Does this mean that baking high-poly-detail into the normal-map is out too? No way that you can avoid back and front facing geometry if you want to bake a model. Actually I'm having problems even envisioning models without back and front facing polys.

The baking feature was the main reason, I was looking forward to normalmapping. If baking high->low is not supported in the current engine, then I don't see much point adding normalmaps at all. They all have to be completely redone for ogre (or future rendering-systems) anyway. Rivets and panels can be done quite convincingly in specmaps.

[safemode]

since when would DX10 be the normal rendering engine for VS? DX10 isn't crossplatform, so whatever artwork and features put into VS, would have to be done in a cross-platform framework.


Also, what format are we going to be making the bumpmaps and normal maps in because i've been seeing conflicting artwork. The schroedinger bump map is tiff greyscale, the llama bump maps are rgba png.

Can we decide on some standards for artwork so we dont have 20 different codecs and 30 different formats ?

What codec should a master bump map be ?
What format should a master bump map be (bpp)?

What codec should a master normal map be?
what format should a master normal map be (bpp)?

etc etc.

The codecs should be cross-platform and open. When possible, the master image should be in a format that is lossless.

speaking of master, i'm going to start a thread about creating a master artwork repository and get a general idea of how those masters get into the dataN.x usable repository.

[klauss]

Well, until you or Hellcat add tangent to bfxm, or until DX10 is the norm, we'll just have to pretend that normalmaps work.

Good call - then when properly computed tangents do appear, everything will magically work
BTW, people, baking is not off the question, it's only not perfect (by far) for now. If you bake small details (as to get a practically flatly blue normalmap), then I believe it will work nice enough to be able to ignore inconsistencies. Problem is when you use baking to fake large-scale geometry - like smoothing. And as chuck cleverly pointed out, eventually proper tangents will have to be added, and when that happens your baked normalmaps will work as they should by art of magic.
About DX10, Ogre will eventually have DX10 support (when I stopped getting updates from them because I stopped browsing their forums, they were working on it - I bet they have something by now), and Ogre is platform independent. Of course, features not possible on OpenGL will be limited to Windows, but both ATI and nVidia have vendor-specific extensions to OpenGL to support some of the geomerty shader stuff (though I hear it's far from complete/perfect). I don't know... but certainly don't rule out DX10 features from linux. At the very least, OpenGL 3.0 will introduce them.

[chuck_starchaser]

Okay, so I take it whichever way things go, we should do our normalmaps normally and ignore the present in-game shortcomings, and trust that the results will improve in time.

[hellcatv]

there should be a way to make an offline tool that rotates the red/green channels depending on the tangents to make them what VS expects...
it's probably a lot less effort to invest in such a tool than to port to DX10 or whatever.

an advantage of the VS technique over the tangent technique is that it allows for mirroring of textures without artifacts (since the normals always assume +x is to the starboard)

in the meantime--I suspect we could even make an approximate tool to allow artists to manually rotate groups of textures to where the normals face "up" in the map.

I really think it's a matter of having the tools to do it rather than revising the enigne

[chuck_starchaser]

How about vertical walls, like the backs of "hatch-back" ships? There's no "forward" direction there to align North on the texture; so vertical grooves might look okay, but horizontal ones not work at all? Also, I'm not sure I fully understand the intricacies, but I get the feeling that the intensity of the normamap will vary with the angle of a surface normal and the z axis. For groovie jobs that might be okay, but if we're using xNormal to bake normal corrections from high poly meshes to low poly meshes, these corrections need some absolute angular accuracy, --not just relative correlation--, to work as intended.

I'm not suggesting we can't use the normalmap system as is, for now, but perhaps it would be a good idea not to rule out putting one more vector per vertex eventually. It would be worth it even with DX10, if it saves a couple of shader instructions. Per-vertex data is cheap, memory-wise, as texels outnumber vertices by 3 orders of magnitude, typically.

[klauss]

Yep - besides, right now, the real problem with tangents is compatibility with the macs. I'd be willing to let the macs make up tangents while the rest use true tangents, if that mac issue can't be overcome. It's really naive to expect everything to work without tangents, unless you go for objectspace normalmaps, and those don't even allow texture reuse of any kind. Even if you could fix normalmaps to account for the unexpected orientation of tangents, this tangent building algorithm has serious problems at times (it's unstable at uncommon yet possible angles). Perpetuating this dirty technique by making normalmaps that only work with it would be condemning all platforms for the (aberrant) shortcomings of one (which frankly seems it has a much smaller user base).

[chuck_starchaser]

Hahaha, no kidding; what's Mac compatibility good for, anyways? My last girlfriend was a Mac user and she only cared for 2D scrolling games. Wouldn't be Playstation or XBox compatibility be better selling points for an engine? And if Macs are so limited, 'tmeans Apple are giving up on themselves already, anyways. Why is that, btw? Can't the same gpu's be used in the Mac world?

[hellcatv]

if someone wants to add tangent space support to VS then I'm all for it---the current bump maps look "good enough" on the mac---I'm sure the mac users will not object.

Of course the other solution is to wait for ogre---so really klauss:it's up to you...waste time now adding tangent support to meshes and a way to compute the tangents for all our meshes---or just wait until the ogre dev port is fully baked--I'm neutral right now--and I still can't see the problem with object space tangents and a converter that takes in a mesh with tangents, a normalmap and computes the appropriate r/g rotations.


i.e. don't let a mac bug stop you---also there's a good chance the apple folks have fixed it in an upcoming update (I did at least report a similar problem)

[chuck_starchaser]

Excellent! Thanks!
Are you up to it, Klauss?
Or just tell me what needs to get done.

[klauss]

Actually, I was advocating against the converter app, rather than for true tangents. Mostly because of what Hellcat said: it's a matter of where to spend time and effort. The problem with the converter is that it conditions the artwork to a specific technique (and an incompatible one at that). So, what I know will happen is that once the tangents are there, nobody will use them, be it either because of inertia or because they've lost the originals.

Now... about adding tangents. As you probably know by now chuck, my problem is with computing the tangents per-se. I have no problem with adding support for them in the engine, however, we'll have to bind them as a new texture coordinate set rather than a proper tangent. For one, last time I checked Ogre does this. For two, I think (IIRC) that's the most mac-compatible way of doing it (if at all). The first, however, is the most important - I wouldn't want to have to heavily and manually process meshes when moving to Ogre - if we can keep things similar to what Ogre expects, the transition might be easier.

So... you get mesher to compute tangents (store them wherever you want, just compute one for each vertex), and I'll handle the rest

[chuck_starchaser]

Okeydoc. This is going to take some thinking, though; and for today I'm tied up trying to fix my broken texturizer, as the pu modellers (other than myself ) are working pretty fast on redoing all ships for PR/PU and I need to come up with more scaled reference images soon. So, basically, the tangent is a vector perpendicular to the normal, and pointing left on the mapped texture, right? Or is it to the right?
And what format will I be working from? How's the mesh represented in mesher? I'll ask you more questions at the PU forum, as I'm not sure I remember what the topic of this thread was, anymore.

[klauss]

So, basically, the tangent is a vector perpendicular to the normal, and pointing left on the mapped texture, right? Or is it to the right?

I believe it's right - it's +s (or +x, whatever letter you like).

And what format will I be working from? How's the mesh represented in mesher?

There's an XML struct in mesher (can't remember the header where it's defined, it's either mesh.h or something like that), that has a list of vectors (positions, texture coordinates, normals, etc...). You'd have to add a "tangent" one and compute them - if you want to figure a way to serialize them into .obj and .xmesh, fine (it's not hard), otherwise I'll handle that.
But please do see how Ogre does it, there are ways to do it, and not all yield the same exact results (it depends heavily on triangle winding) - Ogre's is compatible with most modellers/bakers, so lets use that one. Then we can add options to "compatibilize" the tangents with other bakers if needed. You'll see the commandline interface is a tad awkward but very extensible once you get the idea.

[chuck_starchaser]

Damn! I wrote the code already...
http://wcjunction.com/phpBB2/viewtopic.php?p=2673#2673

[safemode]

I'm not a big fan on the llama normal map (i think the normal map is responsible). It's way too shiny and it makes the material of the ship look like shiny plastic, rather than a used ship made of aged metal. I much preferred the llama to look grungy, a little worn. hrm .

[klauss]

You hit the nail, safemode. But it's a combination of factors, specmap, normalmap... all should be revised IMO.

[chuck_starchaser]

I think the biggest factor is the lack of shininess control. With high shininess, surfaces look glossy no matter how low you set the specularity; unless you set it down to zero, of course.
This has been the problem since the beginning of time, with ships always looking like shrink-wrapped in glossy plastic. Easy fix in the shader, but someone has to come up with a shininess texture.
The new shaders and tools will force you to have a shininess map; so hopefully this will be resolved soon.

You can see here, with my current shader, how the glass of the cockpit looks glossy, the gray paint semi-glossy and the metal non-glossy, even though the metal has high specularity:



Just a matter of adjusting mipmap bias of the environment mapping as a function of shininess.