Schwaa2 on 5/8/2011 at 18:57

---

Well, there are several things to consider.

Real time lighting IS an improvement over lightmaps of T2. It's one of the major upgrades to a game like this. Moving shadows.
So I don't think anyone would want to see it replaced with lightmaps. Rather just find a solution to soften the existing shadows so they look better.

However, baked lightmaps can have a big effect on the overall looks of a map. And having lightmaps added to the game would be a great thing imo. They just add a bit of shadow in corners and help add some depth to normally 'flat' textures. This is probably the largest drawback to visuals in TDM imo. Not that I can't live with how it looks now, I'm perfectly fine with that.
It's just that the added shadow pass would really make it shine.

The issue then becomes file size. T2 maps and Hammer maps (Halflife, TF2, L4D2) can double or triple in size when full lighting is compiled. Depending on engine/settings. That's because every surface in the game is given an addition greyscale blend textures to add shadows to flat tiling textured walls.
Right now missions are 15-50 MB which is decent. Pushing them up to 100+ could be bad.

It also adds an extra stage to each material. So that can reduce performance.

Plus maps will take at least twice as long to compile for the light bounce.

And t2 baked 2 lightmaps per usuable light. Any light that had an on/off possibility had to have the materials baked for when it was on or off. For best looks this would need to be used in TDM.
And since almost all lights start off as useable (torches, candle, etc..) lightmap sizes/baking time would be large.

I'm not opposed to it but there are as many drawbacks as benefits imo.

Then there's also the issue of AO maps, which is a lesser issue but pertains to the same idea. If the terrain has baked ao, then all the objects without (almost all of them) will look more odd than they do no without ao on anything.
Many of them were made with optimization of texture useage in mind. So most would need to be re-uved (the worst part of modelling imo) AND baked with ao (easy but time consuming). This would require a lot of work and in some cases source files that aren't available due to import formats.
It would also require more object specific textures (a lot just reuse terrain textures), thus increasing load times and memory usage on top of mod size and bandwidth use.

AND... Some objects like doors that would need baked wouldn't look right in old missions, because the skins they use are tiling world textures so we'd need an additional 100 some skins to make all the door combos we currently have...

Albert on 6/8/2011 at 04:46

---

Alright, so I'm factoring aesthetics as well as size requirements into my next small question: Given all that, would all these additions to the ID4 source code be efficient enough to run on something a bit older. In fact, just like how Doom 3 would run vanilla on the recommended systems of its time?

I mean, it's selfish of me to assume this would be a mere feat to accomplish, but I guess I'm stubborn enough to be a rooter of software efficiency over hardware efficiency. There's so many things holding me back, as well as a bunch of other people I know, in keeping with the times...

Depressing really. But It's dumb to imagine our technical advancements to be fully ball-and-chain free. Finances just don't allow for me getting my new system finished anytime soon...

Just pitiful, if I do say so myself...

*sighs*

However, I am just complaining a tad on this slight matter. I'll get this game running smooth on a new system someday, but as for now, I'm a bit jaded by alot of these new games coming out that really demand a good system. It's no wonder the PC gaming market is on a thinning lifeline.

Schwaa2 on 6/8/2011 at 05:27

---

I think what we're really hoping for is that TDM will be able to run as fast after some optimizing as Doom3 runs now.

We really did push a lot of stuff quite a bit more than Doom3, so that's why it's not as fast. Doom3 models were really quite low poly (6 sided cylinder pop can for example). I went with 10+ sides on most stuff. Their ai were probably 1500 tris, ours are 2500 +.

We have the ambient lighting (which adds an extra pass to all surfaces), the lightgem calculator was a 'hack-a-round' which takes a lot of power.

I think someone was thinking we might be able to save several fps on better light gem technique alone. Maybe a few more on fixes to the renderer... All that helps.

Of course, if we could get better performance AND add some ao it would be even better. Unfortunately programmers are thin atm. But there are always Doom3 guys that will probably jump into some of this, and it's possible we can leech that from them.

jtr7 on 6/8/2011 at 06:37

---

I'm seriously confused. Is there a global economic crisis, or not? :mad:

I sure as hell ain't gettin' any $300.00 to spend on fun. There's a guy at the Eidos forums who claims he has Internet just flippin' his computer on as if that's all it takes these days. All my friends 'round the world who don't even get enough of a signal to read the forums most days, let alone post, and I, would like to know where all this excess money is freely flowing from.






But yeah, I'm hopin' someone can step up and replace the Doom 3 assets so TDM can become a standalone.

New Horizon on 6/8/2011 at 12:03

---

It can go even deeper than that. :)

The vanilla ambient lights in D3 had broken shading, so everything had incorrect shadows. Rebb introduced a fix to his enhanced interaction shader that made the shading directionless, but still made the textures have depth, based on player view I believe. Unfortunately, since doom 3 uses a single interaction shader for all lights...the calculations to fix id's broken ambient lights had to be performed on every light. That's why older systems really choke when players use the 'enhanced' interaction shader. On my old system though, I was able to run the mod relatively well with the standard interaction shader, along with 'simple' ambient lighting technique.

With the source code, we should be able to branch different types of lights into their own interaction file...just like they did with the game Prey. That will ensure that ambient lighting calculations are only done on the single ambient_world light. Should make a decent improvement.