Splat-map idea.

[Argh]

Had a thought about how to achieve fast splat-mapping, based on what I've seen elsewhere.

1. Use RGB images, where each channel stands for a strength value. Areas that have a combined strength of less than 1.0 for all channels are less than totally opaque, and are given an alpha value of the difference.

2. For each RGB image, send three splat textures (tiling, repeat on) and the display list of the map geometry. If normalmaps are desired, then send that as well. Specular boost of normals after the normalmap has been applied could be constants for each channel.

3. Render the geometry to a framebuffer. Render the alpha level to another RGB bitmap as grayscale.

4. Repeat as many times as is necessary to build up the splats.

5. If dynamic events are desired that are effected by shadows, render them to a framebuffer with alpha now.

6. Render the shadowmap to the geometry in a seperate pass, white on black.

6. Combine all framebuffers in the same order that they were rendered, using the grayscale to blend them together. Interpolate the shadow values according to the value set for shadows in terms of opacity and color.

I am fairly certain that this is how it's being done in most engines atm. The main performance limit is the geometry of the map- running multiple passes with shaders that don't contain any branching statements should run very fast, presuming that the bitmaps are all stored on the GPU.

I know that all of this is "obvious" and whatever, but I am fairly certain that that is all there is to it, and the key is the geometry load and the number of splat passes (because they are massive eaters-of-fillrate). As you can see, this does not involve alpha channels built and sent ala SM3, and it can be done in multipass, which is apparently faster than a single-pass shader, and does not (potentially) have a limitation on the number of splats, since each render operation involves four textures, max, seven if normalmapped, and no branching at all.

[Beherith]

SM3 style splatting (meaning no underlying custom image, try making heightlines with splatting) has proven its ugg and uselessness to me. SSMF is the way to go imo.

[Argh]

I understand what you mean, from the beauty perspective.

But this technique offers some performance benefits over SMT, especially regarding CPU use... and unlike SSMF won't have to include a lot of branching statements to cover all sorts of eventualities.

And I've seen that, with some other solutions, the "specialness" of areas can be done in other ways. But that's another topic.

[Beherith]

SSMF does not branch. It compiles segments on demand.

[Argh]

Yes it does:

Code: Select all

		if (vertexHeight < 0.0) {
			int vertexStepHeight = min(1023, int(-vertexHeight));
			float waterLightInt = min((cosAngleDiffuse + 0.2) * 2.0, 1.0);
			vec4 waterHeightColor = vec4(
				max(waterMinColor.r, waterBaseColor.r - (waterAbsorbColor.r * vertexStepHeight)) * SMF_INTENSITY_MUL,
				max(waterMinColor.g, waterBaseColor.g - (waterAbsorbColor.g * vertexStepHeight)) * SMF_INTENSITY_MUL,
				max(waterMinColor.b, waterBaseColor.b - (waterAbsorbColor.b * vertexStepHeight)) * SMF_INTENSITY_MUL,
				max(0.0, (255.0 + int(10.0 * vertexHeight)) / 255.0)
			);

			if (vertexHeight > -10.0) {
				shadeInt.xyz =
					(diffuseInt.xyz * (1.0 - (-vertexHeight * 0.1))) +
					(waterHeightColor.xyz * (0.0 + (-vertexHeight * 0.1)) * waterLightInt);
			} else {
				shadeInt.xyz = (waterHeightColor.xyz * waterLightInt);
			}

			shadeInt.a = waterHeightColor.a;
			shadeInt *= shadowInt.x;
		}

But that's not really the issue, anyhow. The issue is the shader complexity and CPU costs of SMF, which are fairly considerable. And lastly, the last time I tested, SSMF wasn't working correctly on ATi, whereas this doesn't use any methods that aren't working (it's just about as simple and bullet-proof as it can be).

Moreover, what I'm talking about could use a collision mesh that differed from the map mesh (voila, we'd have support for hidden heightmaps, finally), and be very flexible in terms of mesh complexity.

I.E., it could be set by a game to fit performance requirements, or even set by the mapper, to optimize the geometry for maps that were flat or just gentle hills, instead of the one-size-fits-all way it's done now, or taken to the opposite extreme if you really wanted to see what a 2X mesh density looked like, etc. (this I've seen done, btw, and it makes a giant difference... just like I've always said it would).

And it would still be able to be deformed, etc., by moving the mesh verts, instead of messing with a heightmap.

And it wouldn't be distorted on cliffs.

We can't do any of that with SMF, aside from the hidden collision / physics mesh, which imo at least is a must-have item for the engine now that I've seen how it gets used.

And we can make "specialness" without a hand-painted texture. There are other ways, and they're much less limiting, look better, and are very efficient.

[Beherith]

But that's not really the issue, anyhow. The issue is the shader complexity and CPU costs of SMF, which are fairly considerable. And lastly, the last time I tested, SSMF wasn't working correctly on ATi, whereas this doesn't use any methods that aren't working (it's just about as simple and bullet-proof as it can be).

As far as I see, this doesnt use a single method at all. How is that proof it will work on ati?

Moreover, what I'm talking about could use a collision mesh that differed from the map mesh (voila, we'd have support for hidden heightmaps, finally), and be very flexible in terms of mesh complexity.

Yes I would like 2 sep. heightmaps.

I.E., it could be set by a game to fit performance requirements, or even set by the mapper, to optimize the geometry for maps that were flat or just gentle hills, instead of the one-size-fits-all way it's done now, or taken to the opposite extreme if you really wanted to see what a 2X mesh density looked like, etc.

And it would still be able to be deformed, etc., by moving the mesh verts, instead of messing with a heightmap.

And are you taking into account the deformation happening in a low mesh density area? If so, then mesh cant be static, and we are more or less back to another heightmap (which isnt bad) or you can use my ROAM.

And we can make "specialness" without a hand-painted texture. There are other ways, and they're much less limiting, look better, and are very efficient.

I feel this is a blatant lie. Enlighten me on how you think topo lines and m spots and geo spots can be done.

[Argh]

As far as I see, this doesnt use a single method at all. How is that proof it will work on ati?

Because I've already written all these things before on code that I know works. Most of the methods are in P.O.P.S.

FBO works fine; the blend operations are simple, and the final combination is just a combination. Nothing about that is complicated, it's all fast, and the main upper limit is fillrate and not trying to cram too many textures into the passes.

I also know it works because the engine I'm playing around with right now uses it. They also add a final RGBA pass, so that mappers can "paint" colors directly on to areas, if the splats aren't quite what they wanted.

In terms of the specifics:

1. Topo lines are just a function of the resolution of the RGB images you feed the shader. So you can go up to the limits of current-gen cards, if you want, and probably have enough resolution, and older cards can be stepped down and fed a lower-resolution texture.

There's a definite tradeoff there, in terms of speed- larger textures would eat a lot more GPU operations, and it gets ugly if you go huge on everything. But doing topo lines / special details as the last operation, after using lower-resolution bitmaps for the previous passes, could probably be done at a reasonable tradeoff.

I know that's not an entirely satisfactory answer, but there isn't one for that particular issue, where this method is concerned. It simply wouldn't have the same capabilities of SMF, in both the good and bad senses.

2. M spots and geo spots can be done as the first pass of rendering decals. If decals support a normalmap, it's pretty much the same thing, and would look fine.

3. Static decals could be part of the "specialness", if we finally lost the sacred-cow aspect of being able to deform map geometry. We could store decals in static display lists, sectioned so that we're not rendering much geometry off-screen, and they could use an atlas.

4. You all know that I don't regard being able to deform the map to be a sacred cow. It makes all sorts of speedups impossible, and if we ever consider a new map format, it needs to be something that isn't sacred, or I might as well not even bother talking about this stuff. Most game engines don't allow for that feature; there's a reason for that, and it's not something we can't lose in exchange for something else, in a new, optional format that doesn't suddenly take it away from people wanting to play BA/DSD.


And lastly, I'm not calling for SMF to be abolished or whatever. It's stable, it's going to be prettier, and that's great. This isn't meant as a slam or anything. This is an idea for the future, since there isn't much else we can do with SMF, now that we can use a shader and manipulate it in various ways.

Well, that, and frankly, I've seen what is being done elsewhere on my break from Spring, and they aren't doing anything like SMF anywhere else.

We might be wise to pay attention to that, and realize why, instead of pretending that it's irrelevant, and that the other people who are studying these problems made those choices because they're stupid.

It doesn't matter what modern engine I've looked at. None of them are using anything like SMF. It's a dead end, taken to the nth degree, and even SSMF doesn't look as nice as Starcraft II, because we're spending CPU that we could be spending on, say, instanced geometry, decals and dynamic props on rendering a static bitmap on a shifting terrain built from interpolating a heightmap constantly and doing complex bitmap fetches.

I know that won't be taken well, but... meh, it has to be said.

[AF]

If you think it will work, and you claim to have already written the stuff that it would use in P.O.P.S and the like, then there's nothing stopping you producing a small tech demo on an SMF map with the terrain rendering turned off. This would also provide a reference implementation, and still be faster than SMF if your claims are correct despite being in lua.

Until then, this is all speculation and what ifs, arguing against a rock solid physical implementation living in the real world. You never argue something is better if your arguing from theory against real world examples unless you can provide a rock solid mathematical and logical breakdown, and have every intention of actually proving with a prototype or experiment of your own, else nobody will ever take you seriously.

Since this particular idea of your has already been discussed and outlined numerous times before, I suggest we stop wasting our effort arguing for or against it, and spend our time actually being productive.

Nobodies going to just take a leap of faith and implement your idea Argh, thats not how it works here, your going to have to take a real world step towards an implementation if you want a fully formed version to appear in the engine.

[KaiserJ]

i tried making a little flash program to splat a texture onto a map procedurally in the way of bryce texturing... looked like ballz i gave up

ideally i would want to be able to create a map-as-a-model; using uvwrap to dictate texture locations

not a bad idea argh, i dont understand some of the code but i understand the basic concept; the problem here i think is that most advanced mappers (and if im wrong, i hope they will post their opinions here) require more manual control over how their maps look, rather than an option to generate a texture procedurally.

i personally, on event of another format, would want something optimized like ROAM combined with a quake style map.

however, i realize that my maps are generally quite a bit different than other peoples, and this would probably be useless to them.

and hell, like AF said, if you can show us, and its awesome, then people will use it, me included. im just after more control, rather than a more refined procedure

edit : oh and i'd love 2x resolution heightmap. that would be the peewees knees

[Argh]

I may write a demo for this one, the code's not that hard and the shader can be a modification of Kloot's normalmapper. Not right this second, though, I'm still tied down elsewhere.

[Forboding Angel]

not a bad idea argh, i dont understand some of the code but i understand the basic concept; the problem here i think is that most advanced mappers (and if im wrong, i hope they will post their opinions here) require more manual control over how their maps look, rather than an option to generate a texture procedurally.

Tbh I can do either, if you do some lookign you can find old screens of some epicly pretty stuff that I did with sm3, but it's a lot harder to create a beautiful map using jsut splatting, but if you splat like a texturing program does, it can be pulled off without too much pain.

So imo, smf is easier to use but epic filesizes, whereas splatting is harder but the performance is much much better.

[jK]

So imo, smf is easier to use but epic filesizes, whereas splatting is harder but the performance is much much better.

Splatting doesn't perform better, it even does the opposite cause you need multiple splatmaps to get similar results compared to `megatextures`.

The only advantage of splatting is the varying resolution frequencies, so you can get much more detail in close distance, on the other hand you normally >lose< detail in far distance. So the best way is what Behe did (adding detailtexture splatting to SSMF) to get the pros of both methods.

[Forboding Angel]

Yeah, that makes sense. I was under the impression that splatting was inherently cheaper.

Edit: From what I've seen tho, ssmf is pretty much sex on a stick.

[KaiserJ]

sweet