Dromed limits 2014 - TTLG Forums

Dale_ on 12/5/2014 at 03:48

Oh I see, so I guess building 15,000 26-side cylinders wouldn't work then, eh? :D

So the first limit usually encountered would be 32760 cells. One more question, the 8000 objects, does it also matter how many polygons those have?

Thanks again everyone!

Xorak on 12/5/2014 at 05:03

You'd actually be able to build 15,000 26-sided cylinders, but they'd all have to remain separately detached from one another, so that you end up with 15,000 separate cylinder-shaped rooms.

As long as Dromed accepts the complexity of the objects you can have as many as within the limit, though there might be a problem of having too many (1000+) on screen.

PinkDot on 12/5/2014 at 12:30

Quote:

I ask this with just a hint of facetiousness, but why not then build every object with the AI bin program? When importing the AI object into Dromed, it can easily then be turned into a lifeless AI.

Some static objects can be done as 'lifeless AI'. I remember people making statues out of re-textured AI models.
But when it comes to physics and player interaction it might be slightly more difficult.

Quote:

One more question, the 8000 objects, does it also matter how many polygons those have?

Note, it's not just the polygonal objects - it includes particles, sound markers, patrol points and other gameplay related stuff.

Quote:

Although, for the fidelity of Dark's environments, the current object polygon limit is more than sufficient.

"More than sufficient" it had been at the time of the game release. Nowadays you'd like to see trees, statues, some architectural details that have more than 1K polys.

ZylonBane on 12/5/2014 at 18:53

Quote Posted by Xorak

I ask this with just a hint of facetiousness, but why not then build every object with the AI bin program?

Because AI models are no doubt enormously more expensive to render than regular 3D models. It's also possible that AI models are more limited in how they can be animated and used as physics objects.

Yandros on 13/5/2014 at 01:00

The main reason not to use complex meshes for terrain, as is done in more modern editors, is because Dark's physics collision models are limited to cubes and spheres/sphere hats.

PinkDot on 18/5/2014 at 17:00

Quote:

- Increased cell limit from 28672 to 32760

Does anyone know if the above limit is the Dromed limit or the game engine limit? When you exceed it, is it the CSG Merge that spits out the error, or does it compile OK, but when you go into a game mode then it crashes?

fibanocci on 18/5/2014 at 18:29

First of all, it's the DromEd limit. You can't go ingame without compiling the map.

PinkDot on 18/5/2014 at 20:52

Thanks. Now, the question is, if this limit is removed (somehow, someday...), would the engine accept higher number of cells? Something makes me wonder that there must have been a reason why NewDark did not go above it. While polycount had been raised around 20 times, the cell count limit got increased by 15% or so only...

LarryG on 18/5/2014 at 21:23

32760 is very close to 32767, the largest value for a 2-byte integer. Coincidence? Or is the cell limit based on the data type of the internal storage used? I would bet on the latter. Which means that the cell limit is not likely to increase again any time soon, as it could requiring tracking down all related places in the code and changing the data types of the storage arrays involved.

nemyax on 28/5/2014 at 07:19

Quote Posted by PinkDot

The limit lies within the BIN format itself. Here's what nemyax wrote to me once:

I just reread that, and a couple of corrections are in order:

Quote:

The polycount limit is due to the way faces are referenced by nodes. You only get a two-byte unsigned integer to specify the offset of a face's data within a node, so you can't have a face chunk exceeding 65535 bytes plus one face entry. At that size, you can have, for example, a maximum of 2114 UV-mapped triangles. If they are not triangles, you get even fewer.
Unless the NewDark guys come up with a revised format spec, it's going to stay that way.

Interestingly, you can up the maximum polycount without changing the file format, by parsing the file differently in the engine. There's nothing illegal about storing up to 65536 polygon entries. It's just that only a small portion of that array can be referenced by nodes. If you ignore the node chunk altogether and process the polygon array directly, all those polygons are your bitches. The tradeoff would be that your pretend node can only be of the "raw" type. Which is fine.