Level size?

[Retardinator]

Hi guys. I've been tracking the Leadwerks engine for a while now and I like the direction it's currently going in.

I have experience with the Hammer editor and I know that you can't build a big wide open world in it. I was wondering if Leadwerks 3 has/will have such a capability, either via the editor directly or by some method of map streaming.

 

Basically, the question is: What is the current supported level size, will it change and can/will users alter the way the levels are loaded via code?

[YouGroove]

BSP is not for as big worlds as some terrain systems.

Even Valve with HL2 game use level sections loading , this is the way with BSP.

I would say make your game first, see if it works, take decisions after

[AggrorJorn]

Terrain streaming is being build as we speak. Levels can be enormous although it also would require a longer loading time. You can divide your level in to chunks and load them in when you reach a certain area.

[zumwalt]

Actually LE can already handle unlmited level size, my generic term for this is called cube loading, for lack of any other term, basically you setup an array 3x3x3 each segment is set to 1/9 kilometer in size, although this depends on the type of game your making but back to the design, so each 1/9'th only knows about its neighbors, so when you travel into one of the segments you replace the objects in the outer most segments with the needed objects, rinse and repeat, the depth of field keeps the player from seeing nothing beyond the horizon anyway and the camera has a limited viewing depth. Your skybox then creates the additional illusion of infinity. Memory is handled very nicely in this model because each segment has a maximum amount of memory it will use by the largest fillable data set in that segment, this is basically your assets. You can reduce load time by caching objects that are nearest to the adjacent segment. While the player is playing your current quadrant of segments, you then continue to cache in chunks. Being mindful that you don't want your game to eat up more than about 1 and 1/2 gig of ram since 32 bit machines are limited to max of 4 gig of ram period and about 2 gig of that is eaten by the OS if they are on Windows 7/8 so you don't want to blow up there machine.

 

Physics is the challenge, not the rest of the stuff, because it is the physics that can make or break your game. Set all physics to be calculated from position of dynamic objects that are in motion, when they are not in motion anchor them and disable their physics. The player / actor has or should have a limited enactment of physics by nearest sets of polygons, and immediate polygons, but this takes practice with ray casting and determining polygons that the player model will possibly intersect with in an immediate radius. You can cheat with this by creating a sphere that is invisible, anything inside the sphere should have physics enabled, anything outside the sphere disabled, you attach such spheres to players and also to dynamic objects, when the sphere touches an object or contains an object, that object should have physics enabled only where the polygons are within the sphere.

 

Long of the story in any given game engine, you only can have about 32,768 worth of objects with physics enabled before you barf, each object only containing 12 polygons, (so basically a single cube was my test), however if you remove the physics from those cubes, your good until you run out of ram or the GPU pukes.

[Retardinator]

Thanks for the replies, it's exactly what i wanted to know (and hear ).