SM3 (split from Mesh Deformation, Skeletal Animation, ...)

[jcnossen]

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

Just a quick note on this. Yes it does, but in practice this has no value because the mappers don't get feedback about where optimization works and where it fails, so they can't correct the mistakes (Like reducing the blendmap just a little in one area to make it use less texture units there).

Maybe if it allows you to enforce some texture unit maximum while designing the map, and give locations of the terrain sectors where this fails, then it could work (?)

[Tobi]

Hmm right.

Maybe another info map that overlays in grayscale the amount of texture units used everywhere, optionally turning map red where it's over some preconfigured threshold.

[Argh]

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.

[Master-Athmos]

I don't know if it's already in the SM3 format but wouldn't a chunked terrain solve many of the problems (just as increase performance in non top-down views)?

[Argh]

TBH, the geometry load produced by the current ROAM'd terrain algorithm is pretty reasonable, imo. If we use that, it's textures per pass, shader complexity and fillrate that kill performance.

[Master-Athmos]

Well from my experience a chunked terrain system always was a good thing when it was started to get used. I don't know though what the ROAM algorithm exactly does so they might at least partially do something on the same performance "bottleneck"...

[Argh]

Chunking it, if I'm understanding the term correctly, would mean exponential problems over long draw distances.

It'd probably work better than ROAM for top-down POV, but not for anything else. ROAM is a geometry-optimization algorithm applied in realtime, it's quite effective and the mesh density of Spring's maps has gone down by a huge amount since it was introduced. Basically, the bottleneck isn't geometry, per se- it's figuring out how to get all of the information we need for a next-gen map format that explicitly works with more than one texture to produce complex results via shaders, and has a dense enough resolution to look better than what we have now.

[Master-Athmos]

Actually afaik chunked terrains with a quadtree are a very nice solution especially for non top-down views. Maybe some vids I just found on Youtube:

http://www.youtube.com/watch?v=jDRbyG1IwrE
http://www.youtube.com/watch?v=zWIqMidNTAM
http://www.youtube.com/watch?v=9Pw1XQOL ... re=related

It's powerful, enables you to do LoD on both the geometry and texture side and should result in no problems for shaders...

[Tobi]

SM3 already divides the map into regions that use the same set of splats by analyzing the blendmaps,

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.

You could still have separate specularity value per splat that is blended like the diffuse color components. (e.g. so your metal splat has small sharp specular highlight and your grass splat has almost no specular highlight.)

Now since SM3 works again please make a map that doesn't work in it and that arguably can not be done with less splats to make your point

[Argh]

Took a look. I was having fewer problems than most people, so take my list with a huge grain of salt.

There were a few small bugs left:

1. The lighting angle used by the normalmap was clearly wrong.

2. It occasionally gives a false true to the logic that determines whether we can build. IE, turns green, but the build command fails.

3. It won't load RAW, at least not over here, so the heightmap looked distinctly pixelated in spots.

4. It needs to use ROAM, desperately- mesh density is insanely high.

Performance was not great. About 40FPS with a 3-blendmap map (vs. 200 or so for empty SMF), about the same as in previous tests, IIRC. I'll have to dig up Forb's old demo map, see whether that's still a slideshow.

[lurker]

Is it important to have specularity at the same texture density as RGBH? What about taking a blend map channel and storing it in there? You could calculate this at map creation time from actual specularity textures for each splat, that are then discarded.

[Argh]

No, I don't think that's a major obstacle.

I think it would be OK for specularity values to be set per blend level, as a constant- simply feed that to the GLSL, tell it to multiply the result of the normalmap X specular exponent X mapper-supplied constant, for a final value. IOW, if we want bright specular highlights for "stone", we'd give it a specular exponent value of, say, 16, and the "stone" layer would use a value of 1.0, whereas "dirt" might use 0.125.

That would probably be just fine, for most practical purposes.

And hell, we could supply a similar constant for reflectivity, kill two birds with one stone, since the two things are closely related and adding that much new math to the shader won't kill performance a lot. I know it may seem like weird / heretical to suggest that we need reflectivity, but trust me, it will make a giant difference in realism for some types of surfaces, such as snow, to have faint amounts of it... and we can do fake water (just surface "streams", obviously not deep water) with that as well, and wild stuff, like obsidian / crystal, etc. It's just one more constant to send to the shader, and sending over the reflectioncube at the start's not that big of a deal. It's one of the cheaper things that could be done to make it much prettier, frankly- a lot cheaper than glow, which pretty much does need its own channel.

I'd be in favor of having the blendmap be the alpha channel of the tile, so long as we have a genuine RGBA for the normalmap. I am really wanting to see depthmaps at the very least, I think that's going to result in a quantum leap in terms of quality, and depthmaps are still fairly cheap.

[lurker]

having the blendmap be the alpha channel of the tile

I do not understand this idea.



The current format already has depth maps, RGBH. I'm not sure where this 'leap' will come from. And with the knowledge that the current format is RGBH, I'm going to ask again.

Are you sure blending normal maps works? Can you provide reference?

[Argh]

Uh, why would blending normalmaps not work? Just average their RGBA values, weighted by blendmap value.

IOW:

Code: Select all

vec4 normalMapOne = texture2D(normalMapOneTex, tc);
vec4 normalMapTwo = texture2D(normalMapTwoTex, tc);
vec4 blendMapTwo = texture2D(blendMapTwoTex, tc);

vec4 normalMapValue = mix(normalMapOne,normalMapTwo,blendMapTwo);

Or, to be more explict... here's with the blendmap as the alpha channel of the tile:

Code: Select all

vec4 normalMapOne = texture2D(normalMapOneTex, tc);
vec4 normalMapTwo = texture2D(normalMapTwoTex, tc);
vec blendMapGrayValue = texture2D(diffuseTwoTex.a, tc);

vec4 normalMapValue = mix(normalMapOne,normalMapTwo,blendMapGrayValue);

[lurker]

Yes argh, I understand the math machine can do arithmetic. But just doing that is going to leave you with vectors that aren't normal. I would like some kind of reference that using such vectors, or renormalizing them, or using some other method, won't lead to poor results.

[Argh]

2D normalmaps are all using the same tangent space basis. It works just fine.

[lurker]

They may have the same alignment, but I'm not convinced you can simply mix them in all cases. But I suppose we'll see on that one, and it'll work well to a certain extent no matter what.

I still can't figure out what you're trying to do by putting blending data IN the tile, which is by definition used in more than one location.

[Argh]

Here, I figured you'd still quibble, so I'm still awake.



This resulted from this normalmap, which was two different normalmaps blended at 50% in Photoshop, with random bits erased with a soft brush.




Satisfied? It's fine, the operation in Photoshop is mathematically the same as what I just explained to you. Bedtime for me, I'm getting to the "Argh says stupid crap" point, my eyes are starting to cross. Oh, and the faint swirling's the diffuse texture, pay no attention to that.

And, imo at least, that shot's a pretty good advertisement for why specular control's important, amongst other things- it lets me make it feel like raw metal in that case. I think I'll keep the WB Editor Daemon that way for now, it's more impressive than that quickie "tech" texture, imo.

I still can't figure out what you're trying to do by putting blending data IN the tile, which is by definition used in more than one location.

That's just me being tired, tbh. I was thinking, "hey, if I have a 1024 tile, why not just stick the blendmap for that tile there, save a whole texture load operation", but I concede that that's just not going to make most people happy, I want to withdraw that. People will want to try to use small textures (btw, I already did, with SM3 as it currently operates, and there was zero real performance difference on this hardware), or they'll need huge blendmaps for their huge maps to be pixel-perfect (there's still that 2048 limit if you want it to run on most ATi tho), so nevermind, it'll annoy people who won't understand why I want to avoid that texture loading operation (if specularity / reflection was a constant, that'd get us down to two textures per operation, though, so maybe it's not totally stupid, if the blockiness can be blended out a bit in the shader, meh, tired).

[jK]

Code: Select all

vec4 normalMapOne = texture2D(normalMapOneTex, tc);
vec4 normalMapTwo = texture2D(normalMapTwoTex, tc);
vec blendMapGrayValue = texture2D(diffuseTwoTex.a, tc);

vec4 normalMapValue = mix(normalMapOne,normalMapTwo,blendMapGrayValue);

erm this is 100% incorrect.
A normal has always to be normalized and mixing two normalized vectors _do not_ give a normalized vector again.
also in the case of a layer system you want something like:

Code: Select all

normal += factorOne * texture2D(normalMapOneTex, tc).xyz;
normal += factorTwo * texture2D(normalMapTwoTex, tc).xyz;
normal = normalize(normal);

[Argh]

So, normalize it after you've done the blend operations. That's pretty much what we're seeing in that little visual demo, btw.

Anyhow, I'll go to bed now, too tired to contribute anything useful at this point, but basically, yeah, we can do that. The more I think about the blendmap-as-alpha, though, the more that makes sense, in terms of avoiding the the 16-texture ceiling.