Normal Maps

[Argh]

Is there something I missed?

For a normalmap for things with flat facets, that aren't making use of heavy welding, you can just do it as a grayscale bumpmap and run it through nVidia's tool. That's how you do stuff like walls in FPS games, and it'd work just fine in Spring, too, for stuff that's basically flat.

It won't look as good for rounded things, or really complex stuff crossing a lot of seams, though, because you'll see where it's projecting at a funky angle at the intersections of the facets.

I specifically designed the stuff in P.U.R.E. to make use of this, because I thought Trepan was going to release it months and months ago, which is one of the reasons I picked that strategy for the models. Without the normal maps to give it bumps and define all the greebles, I'm not satisfied with the results, which is why I brought this up again, seeing how I'm getting closer to the next big release.

Not that doing stuff like tessellating the model heavily, for rounded stuff, wouldn't be very cool and useful, but meh, Spring's rounding shader, which basically just does that automagically, is doing something very similar, I think, but I dunno, I haven't read the code yet, and most of JC's hardcore stuff I find very hard going still, as my knowledge of how all this works is still very incomplete.

Adding a normalmap interpretation to the blue channel would be possible, and probably the easiest way to put this into Spring's hardcoded side... however...

1. I'd rather have this as a Widget, if that's really possible, so that players choose whether or not it runs, or it could auto-disable itself if GLSL isn't available, use an older rendering mode, etc.

2. They'd have to be converted to normal maps anyhow, according to what I've read thus far. So, we'd lose the ability to custom-tweak them when converting to DXT5-Twist (I think that's the right term), which would be bad, since it'd leave us at the mercy of however the shader chose to interpret the map.

If you haven't played with making normal maps with nVidia's texture export tool, try it out, it's not really rocket science, but you can make a lot of adjustments to the mips, sharpening steps, etc.- it'd be very bad to lose all of that, imo, because between not controlling the process, and being at the mercy of the shader code's re-interpretation of the grayscale, I think the results would probably look bad sometimes.

[smoth]

argh, normal map needs a vector created by using each of the three channels to produce a vector for the normal. You would need more then one channel. unless you mean a bumpmap, I know I get the terms mixed up sometimes when I am talking to people about it

yeah I tried that tool a long while back when sm3 was still in a small executable that jc had posted. The tool is really bad for what I need

[Argh]

argh, normal map needs a vector created by using each of the three channels to produce a vector for the normal. You would need more then one channel.

Smoth, the nvidia texture tool creates that for ya. It just treats the image as a flat surface, basically, so all of the projections would then face directly "out" from the tangent normal (I think I got that term right). So, basically, it functions as a "bumpmap".

Like... this is the grayscale I used:



Then ya just run it through the nVidia Texture tools for Photoshop, if you own it (my copy's 100% legal, btw, but it's only 7):



And voila, you have a normalmap. For anything that's mainly flat surfaces, this works fine, and is just as accurate as a "bake". All a bake does is create a normalmap automatically, using the uv worldspace coordinates of the mesh, but taking into account any areas that stick out by treating them as higher values on the initial grayscale, and doing some sort of calculation of the angle of the normals at the same time, which gets integrated into the final normalmap. That's how they use normalmaps to fake rounded areas, projections, and other fancy crap - because it's using the "rounded" normal values when tessellating a model that's actually fairly flat. I don't really pretend to understand how the hell that works, tbh, the math makes my head hurt.

That's massive overkill for anything in Spring, imo, except for maybe stuff like KDR_11K's spacecraft, if he wanted to do crinkled gold or something, or if somebody wanted to do a massive model with organic bits, like if I ever get around to Xect vs. Mynn again. It's not that that isn't cool, it's just that it takes soooo much longer than doing it the simple way, because you have to make a master, low-rez mesh, uvmap it, then subdivide it, detail out the surface, and bake it. Having watched the Zbrush people do that stuff, it looks like a huge waste of time, if you don't have all of their equipment, and frankly it's too slow for anybody doing this as a hobbyist.

For ultra-low-poly stuff, a handpaint's just fine anyhow, imo. All we need is minor bumps and details that feel a bit more 3D- I could have done fake "battle damage" or whatever on this example, but I refrain from that particular kind of grunge on my models.

Combine that with a RGB specmap, so that not every area has as much specularity, and it's not all just the same color, which is what causes the "plastic" effect... and this would work well.

[Argh]

So... I guess this about sums this up. Trepan, now you know why I want this. I built P.U.R.E.'s art around the idea that you were going to actually release some working code, man, and I've been very disappointed that you haven't released it.

I've demonstrated here how it can be used, here, so we even have the start of a rudimentary tutorial. I just need code that works, preferably supporting a RGB spec map, but meh, I know that eats up some GPU, so I'd settle for plastic-land, it'd still look hotter than anything we have now.

If you really, really, really aren't going to budge until somebody decimates a model for you, well maybe KDR will supply what you want. I'm not interested in a 10K model with 6+ LODs, though. Even if only 3 of them were on-screen, combined with the lower-rez meshes that would be in the distance, I'd be over the polycount spec I set for the largest encounters I expect to see, as a game designer... which is why I've continued to say no. If KDR will not provide, then I'll just do this myself when I'm done with this version of P.U.R.E., but I'd rather have this now, and do this now.

[Sheekel]

im definitely in support of this, it would certainly help my project out in the visuals department because as Snipawolf put it, it would be good if the blocks actually looked like blocks. if such a shader is implemented in lua would it also be used on 3DOs?