Implementing hub levels a la Hexen, Dishonored, etc.

Started by motorsep, November 28, 2014, 02:19:22 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

motorsep

In the light of recent events unveiled while testing LOD system, it seems that after all, having massive open levels in not possible with neither idTech 4 nor modified BFG engine. It could be some limits set in some tricky manner or ultimate flaw in the rendering engine design (even Darkplaces engine can draw so many triangles over massive outdoor levels without having artifacts).

I still do need "big open" level for the game. So I was thinking that having hub structured levels would be a good solution. That would allow me to split my "open world" into smaller hubs, and player would be crossing over (that's to short map loading times in BFG engine it shouldn't be too horrible).

Is it easy to implement hub structure with idTech 4 ? How would I go about implementing it ?

Thanks!

BloodRayne

#1
Hub gameplay is extremely easy in Idtech4. Just use persistentSpawnArgs.

void setPersistentSpawnArg("variable","value")
void getPersistentSpawnArg("variable")

That's all there is to it for basic hub gameplay.

But you'll want to extend that, probably. Depending on how far you want the Hubs to integrate and maintain level states. For instance if you want broken barrels to stay broken, then you'll need to add persistent variables that maintain their state between levels. I remember that Zeroth (the coder back then for Hexen) implemented this in the base code of entities, basically maintaining states for all entities across hubs (that had a hub key set)... (or something like that it really was a long time ago).

When you start a new hub (that doesn't backtrack to other hubs) you can clear all persistent args with a clearPersistentArgs command.

It was all a long time ago for me, best thing you can do is check the doom_events.script file for the exact persistent args commands.

motorsep

#2
Sounds easy, except there are no such script functions in doom_events.script.

Edit: Apparently someone who implemented script functions had C in English - I was searching for "persistent", yet the word used is "persistAnt"  ::)

BloodRayne

Quote from: motorsep on November 29, 2014, 02:18:01 PM
Sounds easy, except there are no such script functions in doom_events.script.

Edit: Apparently someone who implemented script functions had C in English - I was searching for "persistent", yet the word used is "persistAnt"  ::)
Yeah I kept writing it wrong and then fixing it in the post, now I know why, lol.
There's many more typos in both the decals and the code.

The Happy Friar

I noticed in either Q2 or D3 GPL code, id occasionally has a comment that says things are misspelled for ease of search. 

However, it's in the Oxford dictionary!  So I guesss it doesn't really matter how it's spelled.  Could be an older way of spelling it too.

BloodRayne

Quote from: The Happy Friar on November 30, 2014, 08:24:45 AM
I noticed in either Q2 or D3 GPL code, id occasionally has a comment that says things are misspelled for ease of search. 

However, it's in the Oxford dictionary!  So I guesss it doesn't really matter how it's spelled.  Could be an older way of spelling it too.

I think that's the French word. (At least your link says French > English) :P

oneofthe8devilz

Speaking of HUGE intro outdoor maps...

... back in 2004 I wanted to push the engine to its limits regarding size and came up with this:



... I ended up with an outdoor landscape that is multiple square miles in scale and adds up to a total of around 4 million polygons.

I got six little friends and they all run faster than you ;)


Check out our mods at
moddb or the SPS Homepage

motorsep

Multiple square miles? How many units is that?

The reason I am asking is that A. VertexCache has hard wired limit on how many verts/tris can be in the scene and if exceeded, engine crashes (maybe 4M fit just right into it, but I doubt that; 13M tris certainly crashed it); B. The world is limited to 131072 x 131072 x 131072 volume, so unless several square miles fits in it, it probably not possible (especially that Radiant doesn't draw anything if it extends beyond the grid).

Also, if the world is that massive, why use fog at such a short distance?

And the last question - is it Megatexures ?

oneofthe8devilz

#8
Quote from: motorsep on November 30, 2014, 06:58:55 PM

Also, if the world is that massive, why use fog at such a short distance?

And the last question - is it Megatexures ?

The fog was just a game design decision back then and wouldn't help in any way of speeding up performance (the visibility is about 300-400 meters)... And since I did this showcase back in 2004 mega textures weren't even invented back then (at last not that I would know of)... so no, it was done with traditional texturing...
I got six little friends and they all run faster than you ;)


Check out our mods at
moddb or the SPS Homepage

motorsep

Quote from: oneofthe8devilz on November 30, 2014, 07:08:57 PM
The fog was just a game design decision back then and wouldn't help in any way of speeding up performance (the visibility is about 300-400 meters)... And since I did this showcase back in 2004 mega textures weren't even invented back then (at last not that I would know of)... so no, it was done with traditional texturing...

Do you still have that map by chance? I'd really like to test it and see 4M polys, traditionally textured, in action.

Btw, there is no issues with lighting when it's just one big level, with only one parallel light.

Sir Blackington

That's a pretty cool showcase there, especially from 2004. Seen some custom etqw maps get pretty big but thinking about it I really doubt there was ever over 200k polys on screen at once. Would the pcf shadowmapping in rbbfg perform better then stencil since u would only need he 1 shadowcasting light? From what I understand a lot of the performance drop seen has to do with the sheer number of lights in most doom levels.

motorsep

Quote from: Sir Blackington on December 01, 2014, 12:48:09 AM
Would the pcf shadowmapping in rbbfg perform better then stencil since u would only need he 1 shadowcasting light? From what I understand a lot of the performance drop seen has to do with the sheer number of lights in most doom levels.

RBDoom3 BFG has unoptimized (and improper for point lights) shadow mapping implementation. It's _slow_. Even after optimizing it, it's still slightly slower than shadow volumes for Doom 3 polycounts. Where shadow mapping wins is when it comes to high polycounts, since it's pretty much decoupled from polycount, unlike shadow volumes.

There is no performance drop in Doom 3 :) Without RB's shadow mapping, fps is always 60 for me. It's more about light/surface interactions than just light count. From what I understand, if you have 10 lights lighting one surface, engine will have to redraw that surface 10 times (one per light). Add shader effects, different materials and textures on top of that and it's going to be quite a number of draw calls.

motorsep

Btw, it seems that there can only be 1 parallel light per map, and it parallel light doesn't like visportals :/

argoon

I saw a idtech 4 mapping editing tut some time ago, that add two parallel lights working well in a single map, but i think only one of them casted shadows, will see if i can find that tut.

Here it is.

http://www.katsbits.com/tutorials/idtech/dynamic-outdoor-lighting-techniques.php

motorsep

Quote from: argoon on December 01, 2014, 12:10:47 PM
I saw a idtech 4 mapping editing tut some time ago, that add two parallel lights working well in a single map, but i think only one of them casted shadows, will see if i can find that tut.

Here it is.

http://www.katsbits.com/tutorials/idtech/dynamic-outdoor-lighting-techniques.php

Right, and that works, because he uses only one area. The problem arises when you have 2 areas, connected with a tunnel, and each has to have sunlight.

One thing I haven't tried yet is having 2 disconnected areas. That's next on my to-test list.