Jump to content
  • Advertisement
Sign in to follow this  
dv

How to organize worlds/levels as seen in the new Doom

This topic is 849 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello,

 

I was very impressed with how large the levels in the new Doom are, and how fluid it all is.

This makes me wonder how levels are structured in 2016. The ancient methods like portals/cells and BSPs are clearly long gone. The last document I remember about how to do this was one from Leadwerks in 2009, where they described that levels are essentially made up of static meshes. One big crude static mesh as the foundation, and many detail meshes on top. Visibility determination - one of the holy 3D grails in the 90s and early 2000s - is reduced to frustum culling & predicated rendering (both based on bounding spheres, AABB, OBBs). And ... that's it.

 

Or is it? How are levels structured in 2016? How does visibility determination work in 2016? Is GPGPU involved, and if so, to what extent? How could Doom be doing it and allow such huge levels?

Share this post


Link to post
Share on other sites
Advertisement

I believe it's all the same.

If you think about it, size is just an illusion in video games.

A map represented by one big mesh is too much even for the new GPUs, so there's obviously some

visibility testing going on.

Objects are probably streamed in on demand, based on the player's position.

In order to overcome precision issues, the space is partitioned (octree, kdtree, bsp even quadtrees).

 

Basically, it's all the same, with the GPU taking some of the burden of the CPU where possible.

 

Read more about procedural planet renderers. They are the best large-world managers since they have to render

an enourmous amount of data.

 

Cheers!

Share this post


Link to post
Share on other sites

Some actual open world games create a depth only prepass with good occluders, eventually adding details by projecting depth buffer from last frame to actual time.

Than building a low res version and using it to cull the world hirarchy (test bounding box of a whole city behind a wall -> cull city in one step).

Big pro is such a system can handle dynamic scenes. It's possible to do it entirely on GPU.

 

This would work for indoor games too, but Potential Visible Set would be much faster - maybe Doom still uses PVS.

Building PVS by portal clipping still works if there is some low poly base geometry, but today i would prefer brute force aka trace from each point of cell A to each from cell B.

Coding a exact Quake like PVS compiler is pretty hard, error prone and time consuming.

Share this post


Link to post
Share on other sites

The new Doom uses Umbra, it says so right when you start up the game.

 

A lot of games still use some form of PVS, but probably not based on BSP's like in the Quake days. The games that I have worked on used manual camera volumes where the set of visible meshes/lights/particles/whatever was computed at build-time based on generated or hand-placed sample points. Other games compute visibility completely at runtime by rasterizing a coarse depth buffer on the CPU, and then testing bounding volumes for visibility. Some newer games are moving towards doing all occlusion culling and scene submission on the GPU.

Edited by MJP

Share this post


Link to post
Share on other sites

I once ran Doom's predecessor (Rage) through GLIntercept and determined that for a lot of it's visibility tests it just uses hardware occlusion queries.  Presumably with some optimization such as reading back the frame after a query is issued, and if a result is not ready yet use the last known good result instead.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!