Dynamic Global Illumination

[klauss]

That's a decent polycount.
Nice... I was afraid it could rise quite higher.

With the soft limit at 5K, a 6K-ish model definitely qualifies as acceptable top-LOD (L0).

Important: whatever will be visible from space (inflight), must be a single material. With a 6K model, you are forced to have a single batch if you want performance. If you need a 2K x 2K texture atlas to achieve that, so be it.

Not so important, but I'd like it: the unwelded (simplified if necessary) as an L1 LOD. Depending on the polycount, a lesser LOD may not be needed. (like... 1-2K is OK as lower LOD, IMO).


Chuck... we have to decide right now whether we want dynamic global illumination on ships or not.
It's a shady issue.

a) it's rather expensive per-ship (requires at least one "state" texture per ship), so only a few ships can be selected for dynamic GI. The rest have to be static (environment) GI only. So, the question arises whether or not it is worth it. Why? because...

b) unwrapping has to be special for dynamic GI - UV coords must be unique. You can't use symmetries. You can't overlap polygons. That's an unhappy situation, ain't it? If it's worth it, it's not a big deal. But since dynamic GI can't be enabled for all ships (probably very few), makes me wonder if we want to waste half a texture for it (because of not being able to exploit symmetry).

c) however... the cockpit can and should have dynamic GI, because there's only 1. So unwrapping goes like that for the cockpit: unique UV coords.

d) But... I'm not sure I can do static GI without uniqu UV coords too. So that would limit us, if we use non-unique UV coords, to the simplest ambient occlusion only (not fun).

I guess you'll need a prototype to be able to decide, won't you?
Should I work like mad on a prototype? (it would be fun).

I think I could add a cockpit to the SystemExplorer and use it as prototype - doing dynamic/static GI on the cockpit, and you'll be able to see the effects as you move - (I'll need a semi-textured full cockpit for that) - or I could do a standalong demo.

[Privateer Ferrius]

Don't give me another texmap to make Klauss, for the sake of my sanity.

[klauss]

Klauss, I don't know what dynamic global illumination IS, exactly.

Radiosity... mostly.

[chuck_starchaser]

Ok, but what's the "dynamic" angle to this?

Dual, RE glass, for that we'll need our cockpit hatch to have an RGBA texture, as opposed to just RGB, which is another reason, IMO, for it being a sub-object... Don't worry about it. For rendering in Blender you can use transparency, with an alpha of, say, 0.1. But if you want the interior to be shadowed partially by the glass, you need to set the materials in the cockpit to "receive transparent shadows".

[klauss]

That it's not a static baking, it changes according to the situation.
If lighting changes, radiosity changes accordingly.
If the meshes change (or the scene), it also changes accordingly.

(It's kind of like saying that it is recomputed each frame or so).

[Privateer Ferrius]

I see potential for that to kill framerates dead

[chuck_starchaser]

That it's not a static baking, it changes according to the situation.
If lighting changes, radiosity changes accordingly.
If the meshes change (or the scene), it also changes accordingly.

(It's kind of like saying that it is recomputed each frame or so).

You're talking about self-radiosity, then. I mean, global illumination is global by definition; it doesn't change. Might change in color or intensity, but not direction.

[klauss]

Well... as all eyecandy techniques, it's an option users may disable.
But it won't be that bad. We'll see when I have a prototype.

[klauss]

You're talking about self-radiosity, then. I mean, global illumination is global by definition; it doesn't change. Might change in color or intensity, but not direction.

Nonono... global does not mean "static" - it means that it accounts for the interaction of all objects together (as opposed to just the object being lit and the light).

Imagine... if objects move around, their reflected light patterns also change, and so does the "global illumination" of the scene.

[chuck_starchaser]

Klauss, any self radiosity from global illumination can be baked in, in principle. The only "dynamic" issue here is with self radiosity from dynamic lights, IOW: second reflections.
If this is so, what you'd need to do is not to recompute the whole baking, but only compute secondary illumination from self-reflected light, like it was done in that paper you showed me from Nvidia.
To the algorithm presented there, we could add one further refinement:
We could statically determine which surfaces are worthy of secondary reflection analysis; --i.e.: Surfaces that are near some other surface partially facing them, to reduce the size of the problem.
And we could bake this info onto a separate texture, or use a different material for these self-radiation worthy areas...

EDIT: Sorry; I hadn't seen your last post. So, you mean radiosity from other ships as well as self-radiosity?
I think that dynamic illumination from missile and ship exhausts would make more of a difference and be simpler...

[klauss]

You're getting closer.
But I'm not using the paper, I'm using (going to) a less demanding technique, which does use precomputed stuff, very much similar to radiosity baking.

Basically, the technique works with static shapes (nVidia's paper worked with any kind of mesh, static or dynamic). Static shapes means that the vertex themselves don't move, except by affine transforms on the whole object (translation/rotation/scaling)

Such assumption allows me to precompute all the complex stuff, and all I need to do is store it in a little special format for the shader to finish off the computation.

Ideally, it would compute one further bounce per frame (so further bounces would lag in time). Really neat - on static scenes (which are the ones that give you enough time for scrutiny ), it would look almost perfect (if some simplifications I'm going to make to save memory don't kill the whole idea).

[chuck_starchaser]

Klauss, what if instead of killing symmetry exploits, we exploit symmetry?
By this I mean, could you use two channels in one texture to separate left and right procedurally? I would really like if we could standardize to exploit symmetry in a big way, like even at mesh level: have only half-ships in the bfxm, have the vertex shader mirror it at runtime, if that's possible...

[Privateer Ferrius]

I think that's taking it to too much of an extreme. No ship is going to be perfectly symetrical. And many arent even close, especially capships.

[klauss]

It would be possible with 3D texture coordinates.
You could store the "sign" of the mirror in the third coordinate.

But working with that would be a pain - no unwrapping tool will let you do that, so you're on your own, with commandline tools and stuff like that.

Let me think a bit - perhaps I can "derive" the required information using the normals and some heuristics. (normals would be able to tell apart one half from the other).

[chuck_starchaser]

No, what I mean is... Okay:

Ferrius, I don't mean ALL of the ship being mirrored; just most of it; with a way to flag geometry that needs mirroring or doesn't.

Klauss: I mean, if you need the full UV map, could you do with two half-maps? (In separate files or the same file, somehow?)

EDIT: I.e.: ignore self radiosity that crosses the median, yz plane?

[klauss]

The problem is not that I need the full coordinates. More like I need the full content - the precomputation on both halves wouldn't be the same.

[chuck_starchaser]

Okay, say we bake the two halfs of the ship separately Two textures. Same UV mapping, though; but the non-symetrical parts are present on only one texture, or both.

[Privateer Ferrius]

My job is hard enough as it is without having to stitch a ship texture together Frankenstien-style.

[klauss]

Let me think. It's tricky, but I think I can move the thing to tangentspace. Would make baking a helluva lot more difficult, but I think I can write tools for that later.

(tangentspace would allow mirroring)

Ferrius: don't worry - if it's done, you'll have carefully designed walkthroughs (made by chuck, probably, for blender-side)

In fact, you don't even need to do it. Any of us could do it just as well. The need to discuss it now is that depending on what we decide to do with it, unwrapping goes one way or the other.

[chuck_starchaser]

My job is hard enough as it is without having to stitch a ship texture together Frankenstien-style.

Your job would be easier: Only texture half the ship, plus anything asymmetrical.

What exactly IS tangent space, klauss? (If it can be explained easily.)

[Privateer Ferrius]

@Klauss: I don't think you get it fully.

Right now we have three textures for a ship, the diffuse texture, the PPL texture, and the GLO texture. For each faction that uses the ship, the textures increase dramatically. Take the Talon, that is used by the Militia, Confeds, Pirates, Retros, and Privateers. Thats 3*3*3*3*3*3 or 3^5 or 243 unique textures.

That's a lot of textures.

Adding more of them to do, increases that number dramatically.

As well, changing how coordinates are handled effectively trashes any and all work I've done to this point, and you're going to have to excuse me if that's something that I'm not going to be happy about.

[edit]: I must be the only one who thinks textures should NOT be symmetrical!

[chuck_starchaser]

Ferrius, we need to separate the current VS engine from the one Klauss is working on. In the new (upcoming) engine, with the Ogre back-end, there will be decals you can apply, so you can make one set of material textures for a ship, and then combine that, at run-time, with a faction-specific decal.
And the radiosity bakings we're talking about are generated in Blender; you wouldn't have to do them by hand.

[Privateer Ferrius]

I still think the textures should not be symmetrical. Just take a look at real-life fighters, such as the F-14 or F-18. The plates alone, let alone markings or details, are not symmetrical along any axis of the fighter.

[edit] Different factions still may need different textures outside of decals. I'm going out on a limb here, but I'm just guessing the Church of Man is using much less sophisticated construction processes and materials than other factions.

[chuck_starchaser]

The Church of Man don't have construction facilities, they buy their ships, through Menesche.

[Privateer Ferrius]

Really?

What's this doing in master_parts_list then?

The Retros, being by their nature not given to grand industrialization, rely on a small number of hidden facilities and sympathetic manufacturing plants to supply them with ships. The Salthi bears the distinction of being the only class of spacecraft officially sanctioned by the reverend Jones, who, when presented with its initial designs just over a year ago, said that prayer had revealed to her that that this was to be the 'shepherds crook' by which man's sins would be constrained. Inexpensive, even at the time of its introduction, the Salthi remains a utilitarian craft well suited to the production schedules of backwater worlds.

(Funny that the Church of Man is using a 'utilitarian' craft thats also a Kilrathi light fighter with some pretty high-end Kilrathi engine technology.)