Live data from Hacker News

3D Software Rendering Technology of 1998's Thief: The Dark Project (2011)

nothings.org

1–10 of 37 posts

Re: 3D Software Rendering Technology of 1998's Thief: The Dark Project (2011)

#2
>This result could be less tight; for example, if you had a long corridor with many side rooms, and that long corridor was a single cell, then in Quake it would always try to render all the side rooms, whereas Thief would only try to render the entry cell to each of the side rooms (since those cells would always be adjacent to the corridor and visible), but Thief could cull the rooms themselves if they weren't currently visible.

Big if. You had screwed up if you left such a setup as one long vis chunk. Level designers would place vis boundaries strategically along a corridor to control this behavior. It was a bit of an art form but not exactly hidden knowledge, even the levels that shipped with quake SW had this kind of tuning built in.

Weird that at no point in this article is the engine overall referred to as what I and presumably most level/mod designers referred to it as - 'The Dark Engine'. Still, she's a classic. Tuned beautifully for the sneak/rpg gameplay of Thief and System Shock. Not at all suitable for the high speed multiplayer FPS gameplay of Quake. A comparison between the two is always interesting to see.

Re: 3D Software Rendering Technology of 1998's Thief: The Dark Project (2011)

#4
post #3

Thief was a brilliant game for the era. The rendering of shadows etc was very well done and so also I believe it used 3D positional audio better than the contemporary games

First game to use ECS (or an ECS-like system), too, if I recall correctly. DromEd is one of the strangest programs I've used.

Re: 3D Software Rendering Technology of 1998's Thief: The Dark Project (2011)

#5
post #3

Thief was a brilliant game for the era. The rendering of shadows etc was very well done and so also I believe it used 3D positional audio better than the contemporary games

We're the shadows actually rendered in real time or were they prerendered and baked into the textures along with the environment lighting? Genuinely curious.

I could be wrong but, AFAIK, Doom 3 was the first game with real time shadows and dinamic lighting and every game before that employed various tricks that simulated those instead.

Re: 3D Software Rendering Technology of 1998's Thief: The Dark Project (2011)

#6
post #3

Thief was a brilliant game for the era. The rendering of shadows etc was very well done and so also I believe it used 3D positional audio better than the contemporary games

We're the shadows actually rendered in real time or were they prerendered and baked into the textures along with the environment lighting? Genuinely curious. I could be wrong but, AFAIK, Doom 3 was the first game with real time shadows and dinamic lighting and every game before that employed various tricks that simulated those instead.

The article doesn't make it completely clear but it infers the shadows were not dynamic because it affected the gameplay in that the player needed some certainty about where stealth was effective, and the level designs hinged on that.

Great game. Thief and Descent were pretty challenging compared to quake.

Re: 3D Software Rendering Technology of 1998's Thief: The Dark Project (2011)

#7
post #3

Thief was a brilliant game for the era. The rendering of shadows etc was very well done and so also I believe it used 3D positional audio better than the contemporary games

We're the shadows actually rendered in real time or were they prerendered and baked into the textures along with the environment lighting? Genuinely curious. I could be wrong but, AFAIK, Doom 3 was the first game with real time shadows and dinamic lighting and every game before that employed various tricks that simulated those instead.

Blade AKA Severance AKA Blade of Darkness was the first engine I ever saw doing "real" realtime lighting and shadows (they started in 1995 and by 1996 they had pretty strong level geometry dynamic shadows). The game itself came out in early 2001. There's even a re-release from late last year!

Re: 3D Software Rendering Technology of 1998's Thief: The Dark Project (2011)

#8

>This result could be less tight; for example, if you had a long corridor with many side rooms, and that long corridor was a single cell, then in Quake it would always try to render all the side rooms, whereas Thief would only try to render the entry cell to each of the side rooms (since those cells would always be adjacent to the corridor and visible), but Thief could cull the rooms themselves if they weren't curren…

That's quite interesting. I wonder why visual culling on PC appears to have been much more primitive than culling on, say, the Nintendo 64. Some games there seem to dynamically cull every single polygon not in sight. For example, Banjo Kazooie: https://m.youtube.com/watch?v=se6y5we3p2I

Re: 3D Software Rendering Technology of 1998's Thief: The Dark Project (2011)

#10

>This result could be less tight; for example, if you had a long corridor with many side rooms, and that long corridor was a single cell, then in Quake it would always try to render all the side rooms, whereas Thief would only try to render the entry cell to each of the side rooms (since those cells would always be adjacent to the corridor and visible), but Thief could cull the rooms themselves if they weren't curren…

That's quite interesting. I wonder why visual culling on PC appears to have been much more primitive than culling on, say, the Nintendo 64. Some games there seem to dynamically cull every single polygon not in sight. For example, Banjo Kazooie: https://m.youtube.com/watch?v=se6y5we3p2I

because you cut out relevant lighting from off-screen / occluded sources, it only works with prebaked lighting.
Post reply on HN