Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

nothings.org

Post reply on HN
Print view View original

31–37 of 37 posts

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

#31

Post by kencausey »

causality0 wrote: post #8
FooHentai wrote: post #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 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

I don't think Banjo Kazooie is a good comparison because the camera is entirely on a track by intention so that they could fully pre-process visibility.

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

#32

Post by IMSAI8080 »

The trick he mentions he used where he issues a floating-point divide for perspective correction followed by integer instructions allegedly killed Cyrix. Carmack figured out for Quake that the original Intel Pentium could execute a floating point divide in parallel with integer instructions and exploited it. Without that trick Quake produced a disappointing frame rate. The Cyrix 686 CPU was generally faster than the Pentium but the FPU didn't work like that which meant it couldn't play Quake very well.

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

#33

Post by causality0 »

kencausey wrote: post #31
causality0 wrote: post #8

Earlier quoted context omitted.

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

I don't think Banjo Kazooie is a good comparison because the camera is entirely on a track by intention so that they could fully pre-process visibility.

What? You can rotate the camera freely in Banjo-Kazooie.

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

#34

Post by CliffyA »

causality0 wrote: post #33
kencausey wrote: post #31

Earlier quoted context omitted.

I don't think Banjo Kazooie is a good comparison because the camera is entirely on a track by intention so that they could fully pre-process visibility.

What? You can rotate the camera freely in Banjo-Kazooie.

Ya i think OP may be mixing up crash bandicoot and banjo kazooie

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

#35

Post by qcumberqr »

brobinson wrote: post #4
pkphilip wrote: 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.

The Dark Engine source has been leaked and can be found in couple of GH repositories. The code really is an amalgamation of all kinds of past projects and architectures, without a really strong architectural design, I’m not surprised it would result in “strange” programs.

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

#37

Post by FooHentai »

causality0 wrote: post #8
FooHentai wrote: post #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 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

The Quake engine BSP format precompiled visibility and lighting elements into the level file data. So at runtime you had a precomputed 'potentially visible set' (PVS) for any position a player could be within the playable area, and rendering was then performed based on that set only. Walking that tree was stunningly fast compared to runtime occlusion culling techniques. Likewise lighting info was pre-baked into the level as a layer of texture, and computed based on point-in-space light objects raycast against the PVS calculated in the previous step. All of this meant you were processing on less textures and polygons for any given position during the game, and that provided a speed edge at a time when absolute reduction in overdraw was key to performance.

This let you do stuff like (and I'm working from memory here) have a 15k triangle budget from which you could easily develop a 300k triangle environment, as long as you were VIS-ing well enough that a player never saw more than 5% of the environment from any common position. Non-visible areas were essentially completely free, because they weren't even considered at runtime. This was a significant edge over culling approaches such as the one you mentioned, at a time when that kind of edge mattered a lot.

That said, IMO this approach was tuned for extracting maximum performance from the hardware available at the time (~Mid 1996- late 98). It showed it's age heavily from Quake 3 onward and was quickly overtaken by engines adopting somewhat different approaches (e.g. Unreal) quite quickly.

Post reply on HN