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.
Without specific specularity control, we'd either have maps that looked like plastic all over, or that had it dimmed to the point of being "natural" all over. That's a pretty major issue, tbh, if it's going to use bumpmaps or normalmaps, as I found out when tweaking Kloot's work on Unit shaders.
I think that what Lurker proposed- a self-assembling SM3-like design that creates final optimized output per sector- is really the way to go, tbh. Then there's a one-time cost to assemble the map and save the textures, like building the path-map, and when it's done, maps could load very quickly indeed.
With that solution, we literally could allow for unlimited
layers, blend textures could be any power-of-two we wanted to use, and the result could be as low as 1 texture per map sector up to 3 or 4 layers- i.e., it'd be a pretty flexible way to go about stuff.
That would give us enough data to produce the random look that's necessary to approach or exceed what we see on a well-painted SMF.
The process of assembling the map sectors would be pretty easy:
For each sector, XZ:
For each blender defined, in order:
For each output layer defined:
Load the blender and the texture.
Load the previous layer's assembled texture / normalmap, if any, from a FBO.
Now it's just a simple GLSL operation- from the texture coordinates XZ cooresponding to the map XZ, we're using that texture coordinate offset for the blend texture and the tile.
Output goes back to the FBO, it's just like P.O.P.S. or the Volcano Gadget, only at the end we've assembled a lot more FBOs.
Repeat until done, then save each FBO as DDS.
At runtime, for each sector, read the relevant texture chunks into PBO. Obviously, it needs to know whether there's enough memory at that point- the memory load could get quite high and large maps by today's standards would probably not be possible.
But one of the big advantages of this is that we could force it to discard mip0 or even mip1, for people with low RAM, when it got assembled. People could move a slider in SpringSettings, and voila, the next time they play on a given map, the mips are discarded, the final assembled texture is smaller by half, a quarter, an eighth. IOW, we can have our cake and eat it too.