Spring RTS Engine

Blending normal maps really works well?

Blending normalmaps is what JC did, yes, although it operates differently than what I'm proposing (theoretically).

There is no reason at all that you can't interpolate each final result from a depthmap shader, for example, using the blending value, in your progress towards reaching the final resulting fragment value.

How about using just a bump map? RGBH textures, still 12 per pass.

SM3 uses normal maps right now?

But that would defeat the purpose. Instead of obvious tiles of color, you'd have obvious tiles of specular values. It'd be like the "detail texture" we use now- anything other than the most subtle values leads to obvious and ugly tiling.

And yes, SM3 allows normalmaps. The demo I posted in the SM3 thread has them for each layer, btw.

How does taking away normal and specular maps make the exact same tiles look more tiled?

using specular lighting will give different results depending on the camera angle -> the same tile will look different depending on the camera angle.

Okay. So maybe it is important to have it, despite the shader work, maybe a compromise can be made to fit textures into fewer passes etc.

Two additional notes to what you said in your large post, Argh:
1. If it's a performance issue to use all these textures in shaders, you can bake it into your suggested map format during loading. And face the memory consequences.
2. I think you underestimate the effect your desired map format has on file size. 4x detail increase means 16x texture size increase, and then 3x the number of textures, maps are suddenly 50 times larger. And that's using DXT1 compression on your normal maps and artifacting them.

this discussion makes my head hurt.

lurker wrote:1. If it's a performance issue to use all these textures in shaders, you can bake it into your suggested map format during loading. And face the memory consequences.

You rarely can bake multiple layers into one texture (even if sm3 tries it), because the different layers use different pixel sizes (note: pixel != texel size). Also you would have to use multiple baked textures for the whole map cause of the texture size limit. In the end such a mechanism isn't usable imo.

It's not extremely important to preserve differing layer DPIs. I don't think it's a very good plan anyway because of the massive texture size, I'm just pointing out that splat maps can be converted into what Argh wants as a map format relatively easily.

Multiple textures.. just like smf works with its 1024x1024 tiles? How is that at all a complaint?

You rarely can bake multiple layers into one texture (even if sm3 tries it)

It doesn't seem to, but IDK, haven't read the source in awhile, maybe JC used a FBO to store each pass, instead of doing it all in one giant shader. Kinda slow if so, but it would reduce the complexity and make it easier to be flexible.

If it's going to be such a performance hit to do live, you can always bake all the layers into a final texture and use that.

That might work, and if the baked version of each texture (final diffuse, normalmap) can be saved... OK, I can buy that. It'd get rid of a lot of the problems, if it basically rendered everything to FBO for each sector of the map and then stored the final values as textures. You wouldn't want to "bake" the light- jK's entirely right, it's important that the normalmap's its own texture.

That would address jK's objection- it'd be irrelevant what pixel sizes were used, render on a quad, store in FBO, save the final result as DDS. The final fragment values would be what they were, period, so people could use arbitrary tile size values, etc., and that would even allow for unlimited layers (up to memory limits and time, ofc).

If you saved the resulting textures as 1024 DDS with the appropriate auto-generated script for re-assembling them at runtime, you'd then basically have SMF 2.0 (kinda), only it would be delivered to the end-user in a much smaller format. I can buy that actually working, once all the driver issues were worked out and it didn't bork on ATi, etc. That sounds like a good idea.


And yeah, 48X SMF's filesize would be bad, for non-commercial distributions. Keep in mind, though, that due to compression, it doesn't scale linearly, IIRC, PicassoCT's huge map was only 200MB or so. But even 10X would be pretty much verboten for free hosts. I can see that. I don't deploy very many huge maps, so it's less of an issue for me.

smf compression is based on finding bits of the map that look exactly the same and combining them. It's not going to help you all that much when you make your same texture so much larger.

And I'd be less worried about file size at this point, and more worried about the 2GB ram ceiling.

Right now, a 20x20 map has 100 half-megabyte 1024 tiles once reconstructed. Multiply that by 50 and you're out of ram without anything else helping.

I'm not talking about SMF's crude compression, I'm taking about when you 7zip it.

And I didn't think that you loaded the entire SMF into RAM. I thought it was only the immediate sectors around the POV. If not, that's a possible optimization- store a crappy version that gets replaced with the full-rez version when your hd catches up.

Anyhow, I like the idea of an end-user-assembled map format, that makes sense. Gonna be a bitch to get debugged for various hardware- there will have to be flags to provide a fixed-function assembly method for Intel, etc.

DDS may not be the most efficient format, but I'd put a rule of thumb for 7-zip at saving you half the file size. That fraction isn't going to change when you make the texture bigger, and since existing maps are compressed your file size isn't improved that I can see, still a 50x increase.

And compared to the time to load from HDD you can probably just mix the textures in C fast enough.

Yeah, I know. My smallest map would be well over 60MB. That would suck, my current map folder is already far and away the largest single part of the upload of a new version of P.U.R.E.

That said, I could deal with it. I am not afraid of the prospect of a 400MB Demo again, for example, and I don't think (just doing some napkin-math) that any map for P.U.R.E. would go anywhere near 2GB when unpacked. That said, I think it'd be bad for everybody but me, so is therefore a bad idea.

For the moment, what is the potential for allowing a modified version of smf that simply doubles the texture resolution?

A smf upgrade that allows one to set the scale of the textures would seem like a better idea that uses more or less the same amount of effort. You could then have twice or four or even eight times the resolution if you wanted, or you could go backwards and have half or a quarter of the res.

However, could the map discussing be moved to a topic meant for map formats, and not meshes and animation?

Ya was just splitting it. Done now.

SM3 already determines maximum hardware texture units available and calculates the minimum number of passes required to render the map with this number of texture units.

In the debugging output I noticed even my 9300M already has 32 texture units available to OGL. Besides this, a quick glance at the code indicated it is using bump mapping, and not normal mapping, which means one splat can be handled entirely by one texture unit (RGBH). (Yes, I think a separate specularity texture per splat is over the top; note that there's no reason specular lighting can't be done without a specularity texture.)

Hence, a quick calculation indicates you can use 24 splats per pass. That is 24 texture units for RGBH texture, plus 6 4-channel textures for the blending values, and then there's even space left for the shadow texture and one special one (the infotex possibly).

Also, if I recall correctly, SM3 already divides the map into regions that use the same set of splats by analyzing the blendmaps, so you'd only hit this amount if you need 24 splats in a single (small) region of the map, in which case it seems to me you'd just get an ugly brownish blur since everything is mixed together

I can't imagine doing anything which would gain from more than eight.

Slightly related: Thanks for the split