hexarith on 15/4/2006 at 12:30

---

No, it proofes, that it can be done. Using an optimized engine and a clever approach on storing levels and data.

Physics surely is the CPU hog. Rendering is done completely by the GPU nowadays, and the setup of objects and geometry is done once (actually it's loaded into the Gfx card's own memory) and then only the parameters are changed.

Sound propagation can share parts of the data with the pathfinding algorithm, which shares a lot of the data with the BSP code (if a BSP engine is used, which is the case for TDS).

Managing AI is not that complicated and the state machine needs not to be updated every frame. Also the AI behaviour in TDS looked rather simple to me.

In a BSP map line of sight checking is not complex. Actually it's the most simple thing to do, just locate the BSP nodes in which opponents are. If they're on a line of sight the BSP nodes are direct neighbours. Actually this is the whole idea of a BSP: To _exactly_ know what is visible and what's not from a certain point without large computations. Building a BSP is a computationly intensive operation, though, but it needs to be done only once, namely when the map is written into the file by the map editor.

The brightness computation isn't hard, too, since it's just a bit notched up visibility check. Just perform a visibility check of the player model from the light's position. The larger the area it occludes in the BSP seen from the light and the closer it is to the light in a 1/r^2 relation the brighter it is. It's really that simple. To know which lights to use for calculation, a check which lights the player can see is performed in the first place.

Of course, but you don't have to compute them in full fashion. e.g. if you can't see them it's not neccesary to calculate the full animations. It's enough to update the state machine for each NPC. And even if all animations are calculated: Since there is no IK system all animations are in fact looked up in some file. Computational complexity: About the same as a pointer dereference. And like it or not, every NPC is just a state machine with a few bytes, and sometimes it meets another NPC which makes the state of both change. Takes about 5% CPU


That's not what I was saying: What I meant was, that running on game console doesn't means, that is must be limited. And if you look back into the good old times you'll see, that coders have spent a lot of looong nights into optimizing. This is something that only few people do today. Tim Sweeny, John Carmack, me ;-). The problem is just, that 3D engines like every piece of software are very fragile, put something into it, which was not foreseen and you break it all. But while you can fix e.g. a word processor wasting a few Megs of RAM or 10000 CPU Cycles w/o the User noticing it, a game is very sensitve to it. Everything has to happen in realtime.

And Halo shows us, that storing, processing and rendering of large scale maps is feasible on the XBox. And believe me: Visibility checks, illumination calculation and AI bahaviour inclusive path finding are not really compuatationly and memory intensive. The most complex is IMHO still sound propagation, but there's probably a lot of precomputed either.

I'm developing a game engine myself, and instead the Unreal1.5/TDS engine mine will allow for completely dynamic sourroundings: Map geometry can be altered, paths may change by this and all lighting is completely dynamic (in TDS only the torch equpped NPCs and the green glowing orbs in Pagan territory are really dynamic, the torches on the wall are precomputed, you can recognize this in the way the light attenuates). Now the one big difference is, that my engine does not use BSP! This means that line of sight and illumination computations are a lot of harder, but the benefit is, that I can change geometry. My approach is similair to the DarkEngines way of modelling: A map can contain one or more Scenes. Every Scene starts with a so called Root Node. This is either an infinitely filled or void space (the DarkEngine always starts from a filled space). Into this space geometry is added by boolean operations. Now the big difference to other engines is, that there are not only planar shapes avaliable, but also curved primitives (cylinder, sphere, ellipsoids, NURBS and Bezier patches) and volumetric implicit surface primitives (great for modelling caves) that are dynamically tesselated. And except the implicit surfaces primitives, all of them can be described with only a few numbers, so that even the largest maps store in a few MB. Detail geometry is applied by so called meta materials, that add geometry on the fly in a procedural way; so not every single brick in a wall has to be stored, but yet it is accessible to the whole in game world as an independent object if requested. This works not only for bricks, but also for plants on meadows, tiles on a floor etc.

Or in a few words: I explicitly designed my engine for large scale, high detailed, dynamic environments to be squeezed into a minimum of memory at the cost of a bit higher computational complexity. And since the maps can be described by only a few MB of data, avaerage sized map loading times for geometry are below 1 second (loading textures is still the bottleneck, but I'm going to solve this, too).

I'm positive, that it should be possible with my engine (once it's up and running stable) to put whole TDS into one single large map (separate missions with no physical connection to the citiy would be placed in different scenes, still being part of the same map), yet meeting the memory constraints of a modern PC system (but surely not the XBox), i.e. 256MB RAM, 128MB texture memory.

Sorry, I didn't want to go off topic, but my point is: It can be done.:thumb:

BTW: In the last days playing Thief I got such a Fan of the series, that once the engine is done I'll donate a licence of the engine to the TTLG comunity to use it for Thiefish FMs and eventually a remake of TDP and TMA ;)

Screenshots of the current engine state are avaliable on request.

Domarius on 15/4/2006 at 14:51

---

I understand your technical explanations; yes finite state machines aren't very intensive, BSP line checks are relatively quick, and so on, but Halo is no example that Thief 3 could have run better on the XBox. It probably could have, but Halo is just a standard FPS with not much going on. They're too different. To me its like the "Doom 3 can do large levels!" demo map, a huge map full of oblong buildings. Yes, it was physically huge, but when you actually put AI into it, it ran horribly slow, even with just a handful of them.

Anyway I'm more interested in your engine. My brother and I were actually talking about this sort of thing (if I get your meaning) - instead of incessantly scaling up the graphical complexity to burn up the new processing power, why not leave it at a certain older standard, and scale up the rest of the game, so you can do more with it, for example, exactly what you said, real-time terrain destruction.

I read about an engine in another game (Red Faction... can't remember the name, Red something...) that had real time terrain destruction. The graphics weren't on par with the other latest games, but you could blow holes in any wall etc.
The way it works sounds like how yours might work - you have the initial level geometry, but when you blow a hole in a wall, that's (for example) a sphere that is a boolean subtraction out of the wall. The reason the graphics couldn't be as complex is this is kind of intensive. To render this every frame, the game starts with the original level geometry, then subtracts all your modifications (holes), and then draws the final result to the screen. So naturaly, the more modifications visible at once, the slower the frame rate.

How do meta materials work?
And how do you cull out the unessecary, out of view geometry?

Also, I "request" pictures :)

I think you should start a new thread about it.

ZylonBane on 15/4/2006 at 19:58

---

Sure it is. The TDS version of Flesh (ugh) runs a lot more smoothly than the DX:IW version. I actually think it's quite an acceptable engine from a framerate standpoint. The Dark Engine was never a speed demon either.

It's just all the other design decisions/X-Box limitations/lack of polish/general incompetence that bring TDS down.

tiger@sound.net on 16/4/2006 at 00:43

---

(Hexarith, please excuse my partial-quote of your very informative message.)

But such great news bears repeating, imho.
Also it touched me, as I am sure that it has inspired others, I hope?

And it was something about the image of a almost buried T3 rising and flying upwards, from its "ashes", to become a new burning bright "Thief Flame", that kind of brought a child-like smile of "wonder" to my very old face.
(Thanks, Hexarith!)

And please start your messages, around here, so that we can find you.
(And always try to remember that a lot of us can only be visitors, within your highly technical "arena of discussions", with just our bright and shiney smiles, to simply "be there" to cheer you, onwards, mate!) :thumb:
(http://games.groups.yahoo.com/group/silenthillforever/)

OrbWeaver on 16/4/2006 at 09:29

---

I guess you haven't played Doom 3 then?

[email]tiger@sound.net[/email]: I wouldn't get too excited about hexarith's "engine" at the moment - theory means nothing without actual, hard performance data to back it up. And an engine with no apparent means of calculating occlusion is going to have very poor performance indeed.