Normal Maps

[Argh]

I've taken a look at what it would take to render normal maps. Looks fairly straightforward, and there are is a lot of code available, including an older, non-shader method for older video hardware- that code is probably too CPU-intensive, but meh, it's available.

Moreover, the .SM3 map format contains a normalmap shader implementation (terrainFragmentShader.glsl), so we already have the code available, basically, so it's mainly just a matter of integration with .S3O- sending that shader the mesh data of the .S3O and the normalmap, so far as I can see (probably wrong here, but meh, I had forgotten that .SM3 already did most of what we'd need).

Assuming that we don't want to change the basic structure of .S3O, what is the best way to go about integrating this with Spring? I would think that just adding an optional rendering pass to .S3Os, enabled only if some new FBI tag was boolean TRUE, and a named bitmap, would be best.

[MR.D]

The map format uses bump mapping though doesn't it, never heard it mentioned that it would support full 3d Normal maps.

[user]

sm3 uses bump maps, not normal maps.

bump maps and normal maps aren't the same thing.

[jcnossen]

it uses normal maps actually. But that doesn't mean you can just use the shader for models. IIRC sm3 terrain rendering uses world space normals, whereas S3O would require object space normal and code to generate those.
In any case the shader code is usually the least amount of work, getting the C++ infrastructure for s3o normal maps will be much more work.

IMO bump mapping is an ambiguous term, people throw it around everywhere without specifying what they mean by it.
SM3 does directional lighting using dot product with light vector and transformed terrain normal + ambient lighting, which is known as normal mapping afaik.

[Argh]

S3O would require object space normal and code to generate those

Ok, so we're talking maybe code like this? Substituting a list of triangles from the S3O for the toroid in the demo?

[jcnossen]

A tutorial with some sample code doesn't change the fact that nobody has time/motivation to make this stuff work for spring.
Please correct me if im wrong tho..

[Argh]

I only wish that my time stretched to this, but it doesn't right now, I need to keep focused on P.U.R.E. When I'm finally done with the current build, I'll see about freeing up a month-long block for all of the stuff I want to do, this looks difficult but probably practical, once I've had a little more time to figure out GLSL.

[user]

GLSL is not hard, and there are a lot of tutorials out there.

[Argh]

I know, it's not the difficulty, it's finding time. Making content sucks it all up

[KDR_11k]

Just wondering but aren't normalmaps for maps silly since we don't have moving lightsources anyway?

[jcnossen]

You still notice it, but the effect is less yeah..

[trepan]

The specular lighting component variation is still
quite effective even when using a fixed light source
location. With little shader work (and with a height
component added to the nx,ny,nz texture), you can
also do fun things like parallax mapping and relief
mapping (modern vidcards can easily render a screen
full of relief mapped surfaces at reasonable frame
rates).



Image generated (quite same time ago) from 6 sided
cube meshes, using relief mapping with 2 textures
(RGBS and NxNyNzH).

[Argh]

Would you be willing to help get this done? This is really about the only major area of Spring's rendering environment that isn't amenable to a LUA solution, because of speed problems. And it's the last great step towards being current-tech... with LUA FX stuff gradually coming online, we're state-of-the-art in most other ways, at this point.

[jK]

may I remember to this?

-> it is doable in lua!
Also trepan and me always said that we are willing to write such a gadget if there are any models+normal maps (and preferable with LODs).

[Argh]

Tell ya what- show me working code, I'll show you what I can do with a hand-painted normalmap. Then we'll talk about a showcase model for screenies. Right now, I see a demo with a cube, not a working .S3O. Making the normalmap is really not very hard- I can hand-paint those.

LODs, on the other hand, are a royal pain in the ass.

[KDR_11k]

may I remember to this?

-> it is doable in lua!
Also trepan and me always said that we are willing to write such a gadget if there are any models+normal maps (and preferable with LODs).

If you can accept skeletal animation I have some normalmapped models in my work folder.

[Zpock]

I think that Trepan wants a guarantee that these things will be concretely used if he takes the time to code it, so he wants to see something that will be actually used, not some test object that he can make himself (cube or whatever).

Why take the time to write this if there arn't any modders cabable or willing to use it? Since noone made anything for the competition he posted it's easy to assume there aren't any...

Of course it's a bit of a c22 where no modder is willing to start learning how to make a normalmapped unit when it can't be tryed ingame yet, and instead just get nice standard models out and be done with it, instead of releasing your mod in 2012 (no joke think 2x time and hard mustered effort to get the unit done, and potential problems/delays with the gadget)...

Then consider that there is no way anyone is gonna notice all this fancy stuff except zoomed in, no organic units, there are no dynamic lighting (except LUA...) which makes it almost pointless and preshading probably works just as well for screenshots and few times the player zooms in and has a quick look.

However, having all those things someday, a better skeletal animation system, and an awesome (fantasy?) mod that uses them would be the ultimate way forward for Spring IMO...

[Argh]

Show me some code that works, and explain what files will be required and how to integrate my content into the Widget / Gadget, and I promise that it will get used.

Every other time I've said this, I've stepped up and made a spectacular demo, whether it was with CEGs, UpSpring, etc., etc.

If I've asked for something and got it, it has gotten used and promoted here. I dunno why this is even an issue, when it's how things work- when people make the stuff I actually want, they get used, and everybody else generally starts using it, too.

I don't personally care about LODs, until Spring's rendering system has been overhauled and they would perform acceptably, but I'll make some for a demo, once I have working LUA shader code to do normal / spec maps with. Heck, if the LODs are all using GLSL, maybe it'll become part of my workflow.

I'm just not writing a blank check on my time, is all. "Model first" puts me in the invidious position of hoping the coder won't waste my time, saying, "no, I don't like your model", which is not acceptable to me, given the time investment involved for something like this. I've already been in that position once, it sucked up three weeks of my life, and I'm never going to do it again.

[smoth]

I read arghs post and then remember why I have him on ignore. Normal maps are all well and good, in a game with light sources that show it off and when you are looking at things up close. However, the normal play distance normal maps are a waste. Normal maps belong in the map or in a FPS.

[rattle]

Or large structures. Or units when the game camera is limited to closer zoom.