How big will lvls be

[Flyingdebris]

so i take it hl2 maps can be large enough to support fast moving aircraft?

i'd love to have a dogfight in jet in the hl2 engine, not that crappy BF engine that treats planes like crap

 

[Stigmata]

so i take it hl2 maps can be large enough to support fast moving aircraft?

Yep. And with the unit scaling option I already talked about, you can scale the maps to 32 times regular size, and that's only if you want physics collisions guaranteed to be accurate. You could definitely scale it even more, and have maps roughly 64km^3 in size... or even larger! :E

 

[The Dark Elf]

so i take it hl2 maps can be large enough to support fast moving aircraft?

i'd love to have a dogfight in jet in the hl2 engine, not that crappy BF engine that treats planes like crap

Basically no.

Another problem that comes into play with .bsp and large maps is occlusion, or the lack of. If you create a vast landscape, or have aircraft flying around in the air or space. Everything in your view needs to be calculated. Which slows it now. You could use fog to cut the distance the engine 'sees' but that ends up defeating the point of large maps.

Valve make maps that appear larger than they are through tricks. City17 maps will likely appear bigger than they are because I imagine you wont be going from A to Z on a map, but rather A to B to C to D and so on, zigzagging across the map, with obstacles in the way that make it appear bigger, but also help with occlusion (since the engine, like before wont draw anything that exists behind a standard brush) I wouldn't be surprised if the larger appearing maps work on a large loop method around the map. So you appear to be going a long distance, but were you to noclip to your right instead of going the proper route, you'd probably be at the end of the map in a few seconds.

Also models don't block objects behind them like brushes do. So filling a map of props thinking that will do the job of brushes, will just slow it down even more. The engine see's through anything but standard world brushes. I can't see them having been able to change that as other .bsp type engines have the same drawbacks IIRC.

 

[Stigmata]

Basically no.

Another problem that comes into play with .bsp and large maps is occlusion, or the lack of. If you create a vast landscape, or have aircraft flying around in the air or space. Everything in your view needs to be calculated. Which slows it now. You could use fog to cut the distance the engine 'sees' but that ends up defeating the point of large maps.

Valve make maps that appear larger than they are through tricks. City17 maps will likely appear bigger than they are because I imagine you wont be going from A to Z on a map, but rather A to B to C to D and so on, zigzagging across the map, with obstacles in the way that make it appear bigger, but also help with occlusion (since the engine, like before wont draw anything that exists behind a standard brush) I wouldn't be surprised if the larger appearing maps work on a large loop method around the map. So you appear to be going a long distance, but were you to noclip to your right instead of going the proper route, you'd probably be at the end of the map in a few seconds.

Also models don't block objects behind them like brushes do. So filling a map of props thinking that will do the job of brushes, will just slow it down even more. The engine see's through anything but standard world brushes. I can't see them having been able to change that as other .bsp type engines have the same drawbacks IIRC.

You bring up some good points, but I still stand by the fact that you will be able to make absolutely huge, yet still playable, maps.

With the whole occlusion thing that would end up causing lag, there is one solution that stands out particularly in my mind: Make a max render distance for models, and use brushes instead of props for the major structures. Buildings made of brushes rather than props would occlude each other, cutting down render time, as would the max render distance for models (cutting down render time, not occluding ). Of course, you wouldn't have a max render distance for the super-important models i.e. missiles and enemy planes.

Of course, there is the case of terrain. I take it that displacement maps will be converted to a prop rather than a collection of brushes, which would not occlude each other from what we know. But, Valve could have coded the possibility for model-based occlusions. So in conclusion, nobody knows for sure how it will work, but it will end up being possible, one way or another. I hope

 

[The Dark Elf]

But... how do you intend to get around the problem of limitations hard coded in the engine? The larger the map, the sparser it becomes. ie: 200 entities in a small space, nicely detailed, 200 entities across a large space. Sparsely populated. Same applied to Brushes.

 

[Foxtrot]

Would it be possible to make a huge barren map, with almost nothing on it?

 

[Stigmata]

But... how do you intend to get around the problem of limitations hard coded in the engine? The larger the map, the sparser it becomes. ie: 200 entities in a small space, nicely detailed, 200 entities across a large space. Sparsely populated. Same applied to Brushes.

That's true, but again we don't know the limitations of Source yet. We'll have to wait and see about that.

 

[The Dark Elf]

Would it be possible to make a huge barren map, with almost nothing on it?

Yeah, but.. maps like that take ages to compile, and often wont because of some issue with light and bounces, there's something that doesn't appear to take into account having nothing atall to bounce on, yet continues to try.. Or something like that, I don't know the reasons behind it but there are problems, i think its just something to do with the bsp structure so will probably have the same problem across the board and not just Source based.. There are ways around it, lower height and/or none flat terrain for example. But its still going to have problems.

And it would likely be a bit boring after the first go on it.. I suppose you could mimic one of those old Amiga racing games, with the sparse scenery, but the players would probably expect more.

In theory you probably could, in practice you probably wouldn't want to

That's true, but again we don't know the limitations of Source yet. We'll have to wait and see about that.

True.. though the more I hear the less convinced I am that Source is as cutting edge as Valve would like us to believe.. I'm not saying its crap, far from it. I just think in an effort to keep it compatible with HL1 resources. Valve have had to retain certain things which will limit some of the more far thinking idea's.. Wont mean its a bad engine, just means its geared to a certain type of game and probably isn't the best idea to use it on massive open maps as its more optimised for complex maps split into smaller sections and tied together in the same way they were in HL1.

 

[nc17]

Compile times in source are drasticly reduced, something like 25% of what hl1 compile times were

CSG has been removed and source does not do bsp cuts using texture luxels anymore so no scaling textures to lower WPolys, wooohoooo

This has been comfirmed by rick ellis