BUILD & DOOM technology comparison

[etko]

Hi,

I've been with DooM, DUKE3D and BLOOD for several years now .
I'm just investigating some concepts behind this two engines.

This is what I found out:

BOTH are 2.5D sector based engines, support slopes and got OpenGL, HiRes texture and MD2 support.

ZDOOM
- uses BSP tree to store sector/level information, thus levels are static
- moving map parts are possible only by using zdoom/hexen polyobj hack and aren't real sectors
- doesn't have "native" editor, mapper is unable to preview level realtime
- doesn't support sector over sector mapping
- zdoom has acquired powerfull ACS sripting language and sector capabilities

BUILD
- uses some diffren't algorithm for visibility calculation (which one) ?
- map is completely dynamic, any sector can be moved
- has "native" editor with online preview
- supports sector over sector scheme when certain conditions are met
- has quite obscure sripting system

My question is mainly, can you tell my what algorithm current OpenGL BUILD incarnation uses?

My second question is wheteher there are BUILD technology parts at charge in ZDOOM's core?
There has been screenshot with BLOOD level on zdoom site sometime, so I assume that current ZDOOM converts actual native DOOM maps into some intermediate form in memory much more similar to BUILD one's and uses BUILD's rendering techniques.

My third question is, are there any other differences?

Thank you

[Skunk]

My second question is wheteher there are BUILD technology parts at charge in ZDOOM's core?
There has been screenshot with BLOOD level on zdoom site sometime, so I assume that current ZDOOM converts actual native DOOM maps into some intermediate form in memory much more similar to BUILD one's and uses BUILD's rendering techniques.

If you are refering to City Of The Damned, which uses Blood textures, it's a simple ZDoom map and nothing more.

[Graf Zahl]

No that's not what he meant. ZDoom has some means to load BUILD levels (albeit very limited because ZDoom can't handle BUILD's extended features.)

[Nmn]

BUILD
- uses some diffren't algorithm for visibility calculation (which one) ?

Polygons? I'm not sure.

[etko]

Polygons? I'm not sure.

As ZDOOMGL, which I'm interested in, uses OpenGL, at some rendering state, map geometry must be converted into polys.

But there is some kind of optimization in game too and if I got it right, original DOOM propably split map into PVS "sectors leafs" in similiar manner like quake's CSG splits the 3D level and BSP tree is used to organize and parse this data. This BSP tree is used for visibility checking too, that is why doom maps must be recompiled every time the geometry changes... (on very slow old computers this could take some time (P120))

On the other side, in BUILD, you can add/change level geometry at any time in any way and engine's 3d view will reflect this change instantly without recalculation (there was no node calculation process on my vintage Pentium when editing Duke3D & BLOOD ).

So I assume that BUILD uses some other algorithm to get visible sectors. Is here someone who can tell how BUILD does this? Personally I think it's some portal thingy, but I don't understand the sources and so I'm not sure.

An finally I'm just curious wheter current ZDOOM, especially GL version, uses DOOM BSP aproach or the BUILD's one to get visibility DATA.

ZDoom has some means to load BUILD levels (albeit very limited because ZDoom can't handle BUILD's extended features.)

Because of that post I think that current ZDOOM core is currently an BUILD's one if you get what I mean.

[Nmn]

It gets updated automatically as You view it? hehe, now You know the name: Build. I presume You got the Build source code to view it? Myself can't, but I think my programmer (Praise him) would help You. I'll talk with him about that.

[randi]

Doom and Build use essentially identical rendering processes: Sort the walls from front to back and draw them in order until either you've covered every pixel on the screen or you run out of walls. Where they differ is how they sort the walls. Doom uses a precomputed BSP tree to do this. The BSP chops up the walls in the level so that no matter where you stand, you can just walk through the BSP tree and get perfectly sorted walls. Build sorts the walls on-the-fly as they're encountered, starting with the sector the player is in. Other differences between the two renderers are just nitpicky details such as how texture alignment works and how transparent textures are handled.

Because of that post I think that current ZDOOM core is currently an BUILD's one if you get what I mean.

I would love to replace the Doom renderer with a more Build-like one, but no. ZDoom can load Build levels because it has a built-in BSP generator, so it can create a BSP at load-time for levels that don't have one. There is a major organizational difference that makes using Build for Doom difficult: In Doom, sectors are just properties shared by a group of walls. In Build, sectors are real spaces with a definite area.

[etko]

Thank you,

now I got it. To conclude, for ZDOOM BSP is must, so you generate it on demand when not present, interesting.

So even when ZDOOM is much more powerful than in the past, and we can basicaly achieve same results as with BUILD, from the editing point of view, BUILD is much more user friendly as it is editable interactively. Being now capable of OpenGL and MD2 it seems like faster development solution then. Not having static world allows to any sector with any ceiling and floor height to move anywhere. Possibility of dynamic level manipulation and editing interactivity make it more suitable for level tweaking, isn't it true?

[killingblair]

This makes my brain hurt, im gonna lie down (walks away and says "build...moving sectors...wtf")

[HotWax]

You know, with the speed ZDoom computers the BSP tree for most computers and most maps, couldn't it theoretically be possible to implement a recalculate-on-demand feature to achieve some effects that would otherwise be impossible?

Discuss.

- doesn't have "native" editor, mapper is unable to preview level realtime

While Doom (and ZDoom) lacks an onboard-editor, the second half of this statement isn't true. DoomBuilder allows you to get a real-time view of the level using 3D rendering, and includes the ability to shift texture offsets, adjust ceiling and floor heights, and change textures and light levels all while viewing a 3D version of the map.

[qsrx3]

Doom Builder is nice, but not optimal. IMO for an engine with a built-in editor, you can't get much better than Cube.

[DaniJ]

You know, with the speed ZDoom computers the BSP tree for most computers and most maps, couldn't it theoretically be possible to implement a recalculate-on-demand feature to achieve some effects that would otherwise be impossible?

I'm not sure what effect you could possibly achieve by doing that. The only purpose I can think of would be for editing the level, not during gameplay.

If your plan was for moving walls then the BSP process is still far too slow. To be accurate enough during gameplay it would require recalculation at least every other frame while a vertex movement is happening. True an optimised BSP builder could be written that only recalculates what it HAS to do but is it really worth the effort? The time spent doing that would be much better spent switching to a BUILD style dynamic vis system.

[HotWax]

I was thinking more of instant changes to the geometry that only require one BSP rebuild, but hey, whatever...

[Killo Zapit]

There is a major organizational difference that makes using Build for Doom difficult: In Doom, sectors are just properties shared by a group of walls. In Build, sectors are real spaces with a definite area.

I always thought that sectors got split into unique sub-sectors anyway. Can't sub-sectors be used in a manner akin to build's sectors?