Wild Idea. Splat-map concept.

[AF]

What I suggested should be very very easy to implement too. Load in decals, generate coordinates and indices, build vbo on startup, render each frame.

Should there be a humonguous number of splats, the vbo would need ot be modifiable, which means its likely the driver will shift the vbo from gpu memory to system memory incurring a performance penalty however. It may be wise to add a second rendering layer for additional splats at runtime to cut down on this effect, since a vbo thats readonly is going to go on the gpu else the driver is stupid.

[Argh]

What I suggested should be very very easy to implement too. Load in decals, generate coordinates and indices, build vbo on startup, render each frame.

LOL, great, now I "just" have to convince somebody who Knows How to do it. Otherwise, I'd probably just go ahead and pilot this in Lua right now.

I certainly don't. I still haven't had time to figure out FBOs or any of the high-end stuff, other than my fairly easy GLSL stuff where I was mainly modifying somebody else's code. And I won't have time to even try learning that stuff for awhile to come, tbh.

Should there be a humonguous number of splats, the vbo would need ot be modifiable, which means its likely the driver will shift the vbo from gpu memory to system memory incurring a performance penalty however. It may be wise to add a second rendering layer for additional splats at runtime to cut down on this effect, since a vbo thats readonly is going to go on the gpu else the driver is stupid.

I like that idea, it would mean, among other things, that decals generated by Units could be dynamic without requiring that the entire thing be rebuilt.

[lurker]

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.

I'm not talking about the map stage vs. the map stage, I'm talking about the stage where you combine textures vs. the stage where you combine textures. You're still merging a bunch of different things, and only doing it in areas where there is a nonzero alpha. I shouldn't have used the word solid. I was trying to reference the 5% thing. Sorry to be unclear.

[Argh]

Dude, it's fine, AF's basically saying that that part was stupid, anyhow. And I don't know enough to judge, I have to assume that he knows what he's talking about.

[AF]

Experiment with rendering it into an fbo texure and rendering that instead at a later date. What I suggested would have had to have been implemented beforehand anyway.

VBOs arent hard either, heres a basic VBO description of sorst, this may also be of use argh

[BaNa]

Argh, this seems to be a random texture splattering format. That would be bad (even a single layer splattering format would be bad). We want multi layered splattering with masks, not random plops. Believe me, fixing sm3 would be much more progress than this.

[Argh]

Random plops plus decals placed via World Builder or some Lua would pretty much make anything possible, though. Remember, the "plops" can be square, and could be pretty darn large, so creating specificity for a given area is entirely possible, and... heck, with an image slicer to dice up a big bitmap, you could have something like SM2 if you really wanted.

And none of this would replace SM2. I just want to have more options.

[jcnossen]

The idea of using points for splatting doesn't seem logical to me. At least not faster/better than blendmaps. I do agree (I think that's part of your idea) that conceptually, the map renderer should just render a bunch of decals in an optimized way. No difference between lua-generated decals or static decals.
That is also what I suggested to mikosz, but I don't really believe he'll actually produce something.

[Argh]

One other idea I should probably mention is that maybe we should steal a page from Wolfire's current engine, and use pre-computed shadows for the terrain (i.e., done at game-start, doesn't change).

Then Units and Features could cast to another shadowmap entirely, and it'd probably be a lot faster. And they also use it to generate fake AO for static stuff.

Oh, and they use detailmaps that have normal maps as well.

The idea of using points for splatting doesn't seem logical to me. At least not faster/better than blendmaps. I do agree (I think that's part of your idea) that conceptually, the map renderer should just render a bunch of decals in an optimized way. No difference between lua-generated decals or static decals.

Well, I always figured that using the points meant a faster evaluation time, because you're not having to use a way to cut / cull the blendmap, which you've gotta do (imo, at least) so that you're not drawing the entire map as decals off-screen. I figured it was faster to find the points / columns in a given POV than to do cutting of the blendmap, etc., so that the decals are being done on the least geometry possible.

But you're the expert, so maybe I'm just wildly off-track with that.

[Tobi]

It wouldn't really help since the terrain would still need to be rendered on the shadowmap for units and features.

Could as well use that shadowmap for terrain too then, I don't think the extra texture and depth compare is the bottleneck here.

[Argh]

Could as well use that shadowmap for terrain too then, I don't think the extra texture and depth compare is the bottleneck here.

That was what I was thinking.

But really, in terms of overall performance, shadows are a drop in the bucket at this point.