Wild Idea. Splat-map concept.

[Argh]

I've just released a version of P.U.R.E. that's probably good for a minute, so I can finally afford to take a minute and explain this in detail. I've had this idea in my head for quite some time, but explaining how it would work requires visuals, so I've been refraining.

Basically, I have an idea for a splat-map format that would be considerably faster than SM3, and would also be editable in realtime. I know, cue laughter. But meh... look at the idea first, I swear I'm onto something here.

What I'd propose is this:

Step 1, Determine position and frustrum angles of the POV.

Step 2. Read the raw heightmap.

Now we have a mesh in space. No textures yet, no optimization done yet:



Step 3. To determine which small textures we want to perform projections with, we're going to need to get an interception of planes projected from the frustrum up to the fog distance (i.e., if past that, don't even bother because we'll never see it).

First, we get the points that we can intercept:


These points are all associated with a bitmap, a scale and a point x,z.

Now we have everything that's within the frustrum. We can drop those points and everything behind the frustrum or not within a wedge that's maybe 25% larger. Our next check is expensive.

And doing it this way allows for, among other things, the possibility of doing a depth-test and dropping points if they're hidden. But that probably needs to wait for the last step:



For anything in the wedge, we want to do a check against a "column". This would give us accurate detection of points outside the frustrum, and a more accurate depth-test check for stuff that's hidden. After all, some texture points may be on geometry we're going to cull, etc., and we want to make sure that the texture's projected properly onto the triangles that aren't.

Step 4. Now we know which points are going to be used, and where they are, x,z. Build a diffuse map, normalmap, etc.

Step 5. Reduce mesh polycount of the heightmap.

Step 6. Send the mesh and texture to the GPU, to be rendered by a shader to handle rendering the maps to the mesh.

I'm really pretty sure that this is the way to go. I've been thinking about this off and on for quite awhile now, and I think that this is the way to have big maps with layered textures that will be fast (and scaleable, too, because users can specify the size of the map that's generated, or even specify that only the base texture would get used, etc.). And it opens up the possibility of doing realtime changes, too, because we're no longer dealing with huge static maps or tilesets. Just points in space.

[lurker]

So your idea is basically to render the part of the map that's onscreen, with textures splatted.



And 'reducing the mesh polycount of the heightmap' somehow.



...Did I miss something that isn't part of that single sentence?

[Argh]

Um, yes. The whole part about using points, instead of a grayscale blendmap, for example. It's a very different concept about how projection and culling could be done, tbh.

[AF]

So basically instead of drawing tiled texture using blend map ad a type of blending specified, you instead want to draw lots and lots of decals

Calculate where they all go, put them in an array of primitives per decal, shunt to vbo, render each frame, done.

[Argh]

Except that I think that the decals should all be combined to one texture for the final rendering stage before being sent to the shader. That way, we can have user controls- maybe your card can't handle a 4096 texture, fine, use a 2048 final texture, etc.

Or maybe two- one for "near distance" and one for "far enough away that going down a mipmap won't suck".

The idea here is to reduce the search time by eliminating a lot of middleman steps that were used in SM3, basically. Get to the part where we're projecting the texture onto the primitives faster than SMF as well, because you'd get rid of the searches through the huge tilesets. Then use up the speed gains to put normalmaps / depthmaps in, as a secondary / tertiary stage.

[lurker]

"Render the part of the map that's onscreen, with textures placed at points."

Sorry, I didn't realize how specific the term splatting was.

Except that I think that the decals should all be combined to one texture

You want to combine textures on the cpu!?

The idea here is to reduce the search time by eliminating a lot of middleman steps that were used in SM3, basically.

And you want to do this by rebuilding textures, normal maps, mesh reduction every frame?

searches through the huge tilesets

There are no such searches. Argh, listen closely. You don't know how to design or evaluate an algorithm. You just don't. I'm sure you're capable of learning, but you don't have the skillset right now.

[Argh]

Well, JC referred to SM3 as "splatting", because it allowed for multiple tiling textures to be applied to the primitives.

I'm of the opinion that his shader approach was perfectly valid. I think where it went wrong was in the middleman areas. Too many places to go wrong- for example, culling the edges of the blendmaps, and there's the issue of the size of the maps required for each stage, as well as the size of the maps needed for a given "splat".

The way I see it, it'd be faster to have several hundred point objects used in any given POV (and generally a LOT lower number of intercepts, if looking downwards- this approach would only get into the hundreds of points on non-overhead POVs) than to have thousands and thousands of pixels of grayscale in the blendmap stages, basically.

I mean... just visualize, for a second. In SM3, if you're looking straight down at a typical distance, you're seeing maybe 128^2 pixels of blendmap... for every blendmap stage.

Compare that with doing it with points, where you're maybe seeing 30. Massive savings to be had there, imo. And even if mappers ended up using many more splats, it's still far better.

[lurker]

The way I see it, it'd be faster to have several hundred point objects used in any given POV (and generally a LOT lower number of intercepts, if looking downwards- this approach would only get into the hundreds of points on non-overhead POVs) than to have thousands and thousands of pixels of grayscale in the blendmap stages, basically.

Either method only puts textures in where you have a solid amount of alpha. Either method has thousands and thousands of pixels compared in the GPU where texture bits overlap.

[Argh]

Sure, you'd have texture bits overlap. That's why you build the bitmap in a buffer offscreen before projecting it onto the mesh. That's a middleman step that cannot be avoided, no matter how you go about this.

I mean... hell, try this: set up a viewport really quick, and do multiple alpha'd textures on top of each other (just on their own quads, I'm not saying build the entire projection, just a simple speed test). It's really not that bad, cost-wise.

[lurker]

Do you think it matters performance-wise to do it in a buffer? You can do it SM3-style in a buffer too, if it doesn't already.

[Argh]

See above. Seriously... test alpha blending on a quad, because that's what you'd be doing. That's not that bad. Where it gets bad is elsewhere.

And that's why I've been trying to solve the problem of "elsewhere", because you simply cannot avoid that alpha-blending stage, no matter what. I mean... SMF uses alpha-blended detail textures that simply tile. It's just part of building the diffuse stage (and it's done on the CPU, IIRC). What we want to avoid, if we can, is using tiling, which is damn slow because of culling issues (again IIRC, after reading a few things).

I mean... hello. There are lots of commercial engines doing this. Dawn of War's engine, old as it is, does lots and lots of decals with far more aplomb than Spring does. And... ooh, here's a thought- radial "lighting" could be performed on that quad, for quick fake realtime lightsources...

[lurker]

I never said anything against blending.

[Argh]

No, you said:

Either method only puts textures in where you have a solid amount of alpha. Either method has thousands and thousands of pixels compared in the GPU where texture bits overlap.

1. You're not using solid alpha, in my proposal, until the alpha blending is already done offscreen. You're building a diffuse, normal and depth stage by projecting them all to a quad somewhere to build a final texture.

2. You're not seeing overlap at all, that's already gone by the time you're projecting onto the error-corrected map mesh.

Basically... it's like having multiple layers in a paint program. Then flattening the layers to one diffuse texture without an alpha at all. So you'd have 3 big textures being used in the shader stage (four if we count the shadowmap).

Maybe I need to make more pictures. I thought that this was more clear when I made the first ones, and I'm not sure I can express it properly with language- and I'm not here to play verbal games, I've been thinking about this for months now.

[AF]

Rendering them to a texture beforehand would be wasteful regardless of wether its done on the gpu or cpu. It also means your post is an oxymoron, aka "lets cut out the middleman here, so lets add in a middleman to fix it"

Lets say we have a map with 5 decals ( odd I know)

We render each decal to a texture then render the texture to the map 6 renders, or we render each decal to the map 5 renders

Its a totally superfluous stage that adds more complexity and rendering work unnecessarily.

Put the decals in a vbo per decal type. Shunt it to the vbo, and each frame render. The whole process becomes gpu limited and cpu hit per frame is minimized immensely.

If you want the decals to be editable, then declare the vbos as modifiable, otherwise declare as read only so that we gain the speed up of moving everything over to gpu memory.

[Argh]

Put the decals in a vbo per decal type. Shunt it to the vbo, and each frame render. The whole process becomes gpu limited and cpu hit per frame is minimized immensely.

If you want the decals to be editable, then declare the vbos as modifiable, otherwise declare as read only so that we gain the speed up of moving everything over to gpu memory.

Fine and good. Really, all I'm trying to explain is the basic concept, and why it'd be fast, that's all.

Here's how I visualized that middleman stage, though.


Ok, so here are our points. We've taken the points and used them as the center of each projection to a final texture. The white is a base map that's probably just a tiling texture.

So, instead of having big blendmaps, we're using the points to determine where each splat is located. We're building a diffuse texture this way, that's unique to this frame.

The black is areas outside the POV, with a little bit of safety and a stop where the fog reaches 1.0. We don't need to fetch those textures, because we've already eliminated those points and columns from the middleman stage.

So, we end up with one map, instead of a lot of decals. We don't ever render one decal over another, except during this phase, which is cheap because we're doing it on a quad instead of multiple primitives. That's part of what I'm trying to get at, here- doing that part on as little geometry as possible. I think doing it all-decals won't work, basically. Instead, do one giant decal. Go through each triangle of the map mesh as few times as possible.

[Peet]

And He doth designed map renderer, with His Holy Knowledge. Wilt thy devs implement His Radiance?

[AF]

The aim of using as little geometry as possible and culling is usually to avoid sending things to the gpu. In this case everything is on the gpu, and we only have to send a single command 'draw vbo number x', which could probably be done by a shader.

See the gpu wants a tonne of data formatted exactly how it likes so it can start at array index 0 and munch its way all the way to the end of the array continuously and spit out what we want as it goes along, no seeking times, or waiting for the gpu<->cpu bridge or anything.

So while your algorithm is figuring out which decals can be seen and which cant and all these other things, it could be spitting out decals onto the map at breakneck speed with nothing slowing it down.

[Argh]

So, basically, the problem there is not that the GPU can't handle decals really fast, but telling it which ones to draw where?

Seems counter-intuitive to me, there's a lot of overhead associated per decal on complex primitives, due to depth-testing, etc. The more I think about it, the more convinced I am that that would just slow things down terrifically.

Because if it operated like I was saying, you wouldn't need to depth-test the splats- they'd just be put onto the final "decal" in their order of placement (I guess that's another variable that needs to be in this thing, I know I'm glossing over a lot of details here).

[AF]

Normally gpu activity is stop and start, involving lots of trips over the bridge to the cpu asking for things like textures or waiting for geometry to arrive. The gpu itself can churn through geometry shitfast if its handed to it on a silver platter.

For example in smf, the gpu drivers have to send textures from system memory over to the gpu. This was one of the major slowdowns on slow computer when panning the camera as new texture tiles would be pulled from main ram.

If however the whole thing in its entirety took the form of an array of integers indexing coordinates, all neatly ordered and interleaved with the colours uv coords normals everything for each point together and indexed, then the gpu can just munch through the array as fast as the hardware would allow without waiting. This is something that the gpu engineers have spend decades working on, optimizing.

When you see the statistics from nvidia and ATI, and the improvements, its this behaviour theyre talking about, and this is the ideal situation you want to have when rendering as fast as possible. Th gpu wants everything handed to it so it can munch through as fast as it can, no waiting times, no requests to other components in the computer, it wants to keep everything on the same chipset if it can.

Perhaps if you skip the texture and render only those decals showing onscreen and calculate which in a shader, but thats an optimization that shouldnt be necessary.

Ontop of this, rather than having a vbo per decal, you only need one per texture, so if all your decals fit on a single big texture, thats one vbo, thats even faster.

Now Im sure ontop of this crude simple design of shunting into vbo and rendering on gpu, there are more things that can be done, but simplicity is best, and the reasoning is sound. This design is already going to be orders of magnitude faster than smf. ESPECIALLY on hardware like 8800's and above.

[Argh]

Ok, I'm sold then. This might actually work.

Developing an editor should be possible using SME as the basis and using it to edit the coordinates of the splats then show you what it'll look like, using the same shader that'd be in Spring.

That might mean that SME's only slow spot would be heightmap changes, and make it almost totally equivalent to WiCed in power and speed.

Hell, here's another crazy idea. If it can be made to work (at all) and if it's really as fast as I think it might be... normalmap / depthmap splats could be seperated from the diffuse splats, to allow for a lot more gorgeous details and easier editing, too.