Doom 3 source code to be released. What does this mean for TDM?

Renzatic on 8/8/2011 at 06:39

The first thing I would do after the source gets released, and the TDM team twiddles with a few performance enhancing tweaks (which I agree with NH in that it's the first thing that should be done), would be to contact the guys at Splash Damage, and ask what all they did to get Brink looking as good as it does.

I've only recently heard about this game, and was doubly surprised when I heard it ran on the good old Doom 3 engine. (http://deadendthrills.com/collections/brink/) It looks nothing like what you'd expect a D3 game to look like. You've got soft shadows, SSAO, actual honest-to-god tasteful HDR. The works. Considering how soft the lighting is, I wouldn't be surprised if they added a prerendered radiosity baker somewhere in there. The game looks absolutely stunning in general, not just as a D3 engine game.

TDM could one day look as good as that.

edit: just now saw a link to (http://charles.hollemeersch.net/node/58) this at the bottom of the page. It does use prebaked lighting in lieu of the total realtime approach, and also uses IdTech 4s implementation of megatextures, which I don't think they're gonna be releasing with the source.

demagogue on 8/8/2011 at 13:39

There were guys from D3W working on megatextures in vanilla Doom3. They got a version working and I understood they were waiting for it to go open source so they could optimize it. It looked good but they were massive filesizes, so they need compression. I don't know if they can code something as good as the implementation in later id4 games, but if there's progress on that I think it's going to come from those guys. It would be a nice addition.

nbohr1more on 8/8/2011 at 18:21

While I hope it's possible, it's not at all certain whether Megatexture can be implemented without the underlying code. The folks who reverse engineered the shader took educated guesses on how the Megatexture component would feed the renderer and they never fully worked-out all of the pipeline (thus none of the megatexture images in the mod could be light reactive).

Megatexture is actually an implementation of an old SGI technique called "ClipMapping":

(http://www.doom3world.org/phpbb2/viewtopic.php?t=10673)

If someone in the community can workout an alternate Clipmapping method, then we'd have our own Megatexture.

I understand that the core of this magic is that John Carmack found a way to trick the drivers and swap-in pages dynamically. It could take some time to find that exploit... though a GL intercept could probably capture it... If the Open Source community used the same exploit would they be liable with regard to software patents? Can you patent a hack\exploit?

Renzatic on 8/8/2011 at 19:20

I'm taking a huge meh stance on megatextures in TDM. If it does end up being available in the source, then yeah, go ahead and implement it....eventually. It'd be a nice bonus, readily available to those who want to use it. If not, well, a good 99% of fanmissions don't necessarily need unique UV space for every single surface in their map, so it's not worth bother trying to get a hacky workaround in.

For those who do need it, they've already got access to tons of tools and options they can use to achieve a similar effect (albeit with a much higher cost of vram). Most everyone else is gonna stick to placeables and good ole fashioned tileable textures on BSP. For them, improving the quality of lighting and shadows would be much more immediate and beneficial to their maps than megatextures ever would.

Schwaa2 on 12/8/2011 at 16:44

Quote Posted by Renzatic

Brink LOOKS good. But the performance is HORRIBLE. I pre-ordered because it looked so beautiful and the movement was supposed to be next to godly (according to the devs bragging).
But I have a pretty decent system and run most games on highest possible.
I run Brink on super low and it chugs.
And the movement is abysmal.
Great art, horrible game.

I think the same can be said for TDM already. Most people that see screens don't think it looks like Doom3 at all.

And realtime lighting is our biggest issue dealing with performance, and yet TDM still performs better than Brink which uses prebaked.

demagogue on 12/8/2011 at 17:10

Quote Posted by Renzatic

I'm taking a huge meh stance on megatextures in TDM. ... so it's not worth bother trying to get a hacky workaround in.

The point I think I was trying to make in my last point is that work on megatextures is anyway probably going to be done by other Doom3 teams for their own reasons. Then once they do the heavy lifting, there's not much more to do to get their work into TDM... Just the capability, which mappers can then take or leave. Most mappers may still not want to use it; but a really committed mapper might be able to use it to make some really stunning outdoor or urban scene... where every building is really hand painted and unique. (Not sure if it translates to buildings or not; old versions don't but newer versions seem to.) But the point is no one on the TDM team needs to lose time working on it. It's something that would come for practically free, if it comes at all.

lost_soul on 12/8/2011 at 18:17

Wasn't Carmack saying that megatextures are the primary reason modders won't be able to do as much with RAGE? Supposedly it would be almost impossible for the average Joe to produce good ones or something.

demagogue on 12/8/2011 at 18:59

RAGE has them at crazy high resolution and massive in size (filesize & acreage). He said it'd take like a render farm to compress & bake them which most modders wouldn't have access to (edit: I wonder if fans would consider organizing to set up their own background render farm across 100s of systems, a la Seti), and a lot of power just to manage the files generally. I don't think he meant they couldn't learn how to do it; just that it takes powerful resources. But the megatex tech for id4 has them at smaller resolution & filesize. It's like for having a rough, less-than-photo-real landscape with rolling hills & canyons & streets that at least looks much better than a repeating texture. Cf Enemy Territory: Quake Wars for what to expect. It still looks good; just Rage goes the next step.

Edit: I mean modders have already made megatextures for id4 for Doom3 & Enemy Territory. So that's not an issue. The only thing missing for vanilla Doom3 AFAIK, that the sourcecode opens up (that ET:QW has) is compressing the megatex so the filesize isn't crazy.

New Horizon on 13/8/2011 at 02:38

Quote Posted by demagogue

The mega textures in Rage are handled much differently than the hacked in version in Doom 3. That was essentially Carmack's proof of concept. The megatextures in rage are broken into pages containing smaller tiles of all the textures...so parts of that larger texture can be called when it is needed. The D3 equivalent loads the full texture.

Serpentine on 15/8/2011 at 17:45

Quote Posted by Shadowhide

he talking about entities like player starting point and movers and other doom3 stuff being used in darkmod missions.If darkmod be standalone and those assets won't be replaced,all fm's created so far will go to the trashcan
textures is most easy part

Entities such as player starts, AI nodes and the rest of it will be included in the release, those are very basic defs and are extremely unlikely to be removed. Even if they were removed, DarkRadiant already has the functionality to 'fix maps', replacing entities with newer versions while preserving/fixing the values, however these cases are best avoided anyway. Assets are the important bit, Textures are easy to replace with placeholders - tho we are in pretty good shape in regards to textures. Sounds, models and animation however I'm not so sure about.

Quote Posted by lost_soul

How portable is TDM though. In three years when some guy has Doom 3 running on an ARM device that fits in the pocket, how hard will it be to make TDM run on that?

Considering it's compiling on Win/GNU/Lixux and OSX, the portability is fairly good I'd say. There are few external dependencies and all of them are extremely portable. Supporting other archs should not be a huge hurdle since most of the changes will need to be done in piecemeal and porting is usually something done by interested parties rather than core members. That said, it's unlikely anyone will be interested in porting it in the near future other than amd64 or w/e you want to call it these days.

Lightmaps, baking random stuff in is all a matter of theorycrafting and armchair debate. Simply put : If you want them, you know what to do. Personally I feel that they're extremely likely to be too static and result in crappy scenes. That said, it's likely you could actually do that stuff atm via the undocumented ambientmap stuff.

But I feel that we'll be looking at a fair gain in performance, specially for people with low mem. There are also some areas that tech3-based engines have improved and perhaps would be a nice fit for replacement. But until it's out and there are hands to help, it's not worth getting hopes up. Code doesnt mean everything is going to be rainbows and lollypops.

At the end of the day, the TDM team is small tho the community mappers are strong :) Code monkeys and content contributers are always in demand, even if its once off; good patches and content are appreciated and thanks to the ttlg guys that have taken that up so far! :)