BUILD & DOOM technology comparison

Discuss anything ZDoom-related that doesn't fall into one of the other categories.

BUILD & DOOM technology comparison

Postby etko » Fri Feb 04, 2005 6:38 am

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
User avatar
etko
 
Joined: 04 Feb 2005
Location: Slovakia, Zvolen

Re: BUILD & DOOM technology comparison

Postby Skunk » Fri Feb 04, 2005 7:29 am

etko wrote: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.
User avatar
Skunk
 
Joined: 18 Jan 2005

Postby Graf Zahl » Fri Feb 04, 2005 8:56 am

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.)
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: BUILD & DOOM technology comparison

Postby Nmn » Fri Feb 04, 2005 8:58 am

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

Polygons? I'm not sure.
User avatar
Nmn
##ERROR - Can not process Custom Title ##
 
Joined: 16 Apr 2004

Postby etko » Fri Feb 04, 2005 10:55 am

Nmn wrote wrote: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.

Graf Zahl wrote wrote: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.
User avatar
etko
 
Joined: 04 Feb 2005
Location: Slovakia, Zvolen

Postby Nmn » Fri Feb 04, 2005 11:02 am

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.
User avatar
Nmn
##ERROR - Can not process Custom Title ##
 
Joined: 16 Apr 2004

Postby randi » Fri Feb 04, 2005 5:05 pm

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.

Elmo wrote: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.
User avatar
randi
Site Admin
 
Joined: 09 Jul 2003

Postby etko » Fri Feb 04, 2005 8:41 pm

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?
User avatar
etko
 
Joined: 04 Feb 2005
Location: Slovakia, Zvolen

Postby killingblair » Fri Feb 04, 2005 8:52 pm

This makes my brain hurt, im gonna lie down (walks away and says "build...moving sectors...wtf")
killingblair
 
Joined: 04 Oct 2004

Postby HotWax » Fri Feb 04, 2005 8:55 pm

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.

etko wrote:- 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.
Last edited by HotWax on Fri Feb 04, 2005 8:57 pm, edited 1 time in total.
User avatar
HotWax
Do what you must, and pay the price later.
 
Joined: 18 Jul 2003
Location: Idaho Falls, ID

Postby qsrx3 » Fri Feb 04, 2005 9:48 pm

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

Postby DaniJ » Sat Feb 05, 2005 12:05 am

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.
DaniJ
 
Joined: 30 Jan 2005

Postby HotWax » Sat Feb 05, 2005 1:04 am

I was thinking more of instant changes to the geometry that only require one BSP rebuild, but hey, whatever... :P
User avatar
HotWax
Do what you must, and pay the price later.
 
Joined: 18 Jul 2003
Location: Idaho Falls, ID

Postby Killo Zapit » Sat Feb 05, 2005 10:58 pm

randy wrote: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?
User avatar
Killo Zapit
PIGBUTT LIVES AGAIN!
 
Joined: 16 Jul 2003
Location: Most likely sleeping.


Return to General

Who is online

Users browsing this forum: No registered users and 1 guest