Blender and "open world"

Game Engine Game Engine Support and Discussion
1

More than anything, this is a theoretical question. I found myself wondering today how the Blender Game engine would or could (be made to) handle “open world” game environments. For those not acquainted with the term, I will refer to Wikipedia (http://en.wikipedia.org/wiki/Open_world ):

An open world is a type of video game level design concept where a player can freely roam a virtual world.

The term is sometimes used interchangeably with “sandbox” and “free-roaming”; however, the terms open world and free-roaming describe the game environment itself and allude more to the absence of artificial barriers, in contrast to the invisible wallsloading screens that are common in linear level designs.

Apart still from setting up the game logic for such a type of game, I am wondering specifically about the graphical implementation of the idea. Obviously building something larger than a relatively small self-contained “level” within a single Blender scene (say, for example, Yo Frankie’s levels) would be inefficient. I reckon level editing in Blender would become very slow if not impossible with so much material to load in a single scene. I don’t even have a clue how all that would be handled when the game engine is running, but I imagine it may be extremely taxing on the frame rate. Are these assumptions correct? Opinions?

What would be solutions to the problem? Would it be possible to create a Python “grid system”, that could divide a landscape into (interdependent) squares with coördinates? Any ideas or wild theories on this?

2

Would it be possible to create a Python “grid system”, that could divide a landscape into (interdependent) squares with coordinates? Any ideas or wild theories on this?

Are you referring to an octree? (link). Octrees are very common in modern day graphics and physics.

“open world” game environments

An “open world environment” is an extremely general term. Exactly, how large do you want the scene to be? Also, there are dozens of different ways in which you could simulate a large environment (but some methods may require knowledge in C++).

I reckon level editing in Blender would become very slow if not impossible with so much material to load in a single scene.

Again, it depends on the size of the scene that you want to make.

3

You can use C++ with Blender? :eek:

4

You can use C++ with Blender? :eek:
The BGE is written in C++ (and is open source), therefore you can modify the source code in C++.

5

Is it possible to tell the BGE to only render a set radius of the surroundings from the player?
Like how the GTA games work, even if it means some pop in.

6

Is it possible to tell the BGE to only render a set radius of the surroundings from the player?
Like how the GTA games work, even if it means some pop in.
Yes. Select a camera, then go to the button panel and press “F9”. In there, change the “End” clipping distance.

Attachments

image.png916×367 18.7 KB

7

Ah… I meant more like using C++ instead of Python for the scripts in the BGE… hehe But still, nice to know. I might actually check that out someday. :slight_smile:

8

I’ll admit that I’m not an expert on game coding, so the concept of an octree is rather alien to me. Allow me to attempt to explain what I mean in embarrassing layman terms.

The concept I am thinking is that the entirety of the game is continuous and does not consist of various areas linked by loading points. Instead, the game “world” is theoretically infinite (though the size can of course also be limited) and in its most basic form consists of nothing more than a flat landscape mesh. This landscape mesh can later be manipulated at will.

The way the system works is that the entire landscape mesh is divided into square cells of a set size on a grid. Every of these cells has unique coordinates. When the player finds himself in a particular cell on the grid, the game loads a number of cells adjacent to it (and, I assume, unloads overly distant ones). If the player for examples finds themselves in cell (0,0) in bold below, the game will also load all of the adjacent cells in italics. The radius could of course be set larger than one adjacent cell. More remote cells can be displayed by means of low-poly long-distance meshes, or be obscured by mist.

(-1,1) | (0,1) | (1,1)

(-1,0) | (0,0) | (0,1)

(-1,-1)| (0,-1)| (1,-1)

For those familiar with those games, I believe a system like this was used by in games such as Morrowind, Oblivion and Fallout 3. Which, for the record, does not mean I have any intentions of creating anything close to that. The conceptual aim so far is to create a small modern day European-style city. While that wouldn’t make for an enormous area, it would more than likely be impractical as a single scene. At the same time, though, we would prefer that the player is not forced to pass through particular “teleport” points just to get to a different area.

9

You could probably do that just using python. If you have an empty at each grid location, with the grid pieces on a hidden layer, you could add and remove the pieces using the empties, depending on the player’s coordinates. you could also have further empties add low res textures and sprites to save framerate.

10

I believe showing/hiding pieces of the world based on such a system (possibly using layers or whatever) would be quite easy. However, you’d also have to de-spawn (delete, or even just deactivate somehow) any instances of characters and objects with complicated logic or physics in those hidden areas.

Basically, hiding things based on a grid like that is easy. But, then you’d also have to basically “turn off” the game engine’s processing of objects in those hidden areas as well, otherwise you’ll still have that slowdown.

There are also several things about the engine’s internal functioning that might hinder such a system. It depends on whether hidden objects are truly optimized out of the game’s processing while they’re hidden. In other words, does the engine still process the graphics, but not draw them, or does it skip them entirely. Also, does it keep them loaded in memory, or would it load them back up from a file when they’re brought to visibility? Large game worlds (like Oblivion, Fallout 3, etc) are constantly dumping and loading data based on what it needs as you wander around, but as far as I know, Blender always has everything in the file loaded, whether it’s visible or not (except for large movie textures and sounds perhaps?). I really don’t know enough about the inner workings of the engine to know how efficient all of that could be.

11

Some one please correct me if I am wrong here, but I think you can run c++ in the script blocks, but it might only be for custom shaders. I know I’ve looked at Martinish’s .blends and soem of the custom shaders he’s written and it looked like c or c++ in the blocks.

12

naw, dude. custom shaders are written in glsl, or OpenGL Shading Language.

13

Go ahead and think outside of the “(x,y) coordinates” box. The virtual-world that you “inhabit” does not need to be square. It could consist of arbitrarily-connected “places.” Your underlying data-structure therefore becomes a graph, not merely a grid.

14

The type of automatic procedural loading you describe can be considered an extension of level-of-detail which adds another level below the minimum called ‘not even loaded in memory’.

That’s how I’d think of it, and also how I’d implement it. Bits of land would be divisioned with regards to size/visibility, and from there an arbitrary method (whether it be calculated distance, collision detection, heuristics etc) can be used to load/unload them and select detail level.

Bullet can play a very useful part in these sorts of things, seeing as how it has everything split up into an acceleration structure to begin with…

15

Dynamic loading will be essential for this, which Campbell fortunately added in 2.5. This will allow you to actually load and unload data that is out of range, saving resources. For this to work you will have to already have everything divided up. You could also use dynamic loading to adjust level of detail at varying distances.

–Kupoman

16

Heres a quick proof of concept: http://www.box.net/shared/z0n19ytijl

The landscape is divided into 16 parts. The pieces don’t add until the player is pretty close, just so you can see it happening. That can be changed just by increasing the range of the near sensors on each empty. I used a short python script to add and remove each piece, but this could easily be done using only logic bricks.

17

I’ve done quite a bit of research into this in the past and I’ve come up with a few points which may or may not be of interest to you.

1. Level Design.You say you are worried about the cost of such a huge scene in the editing process. A valid worry but ask yourself this; Why edit it all in the one scene? For each area that your world is divided up into make a separate blend file. Group the entire map together as a single blender group and link the group into your final file. Now arrange these objects in your final file to make your world and you can edit each section separately in their own file. The results will be automatically transfered to the final blend file.

2. LOD. There are many prototypes for LOD (Level of detail) in Blender. It can be done with python and even with logic bricks. You want to carefully map out how to run your LOD system for each section and for the map as a whole. Remember also to use the lowest LOD level as the object seen when editing the map. Since in the 3D viewport all the objects will be giving their impact you want to be using the versions with the lowest polycount to avoid editing impact.

3. Heavy use of occluders. Occluders are a relatively new feature in the BGE that, if active, will prevent anything hidden behind an occluder being rendered. For instance if you have a big building and a park behind it full of trees by making the building an occluder you prevent having to render all those trees and save yourself FPS. Just remember never use your detailed game model as the occluder. They should be as simple as possible. It can be handy to just use the same parts as your collision map for your occluders but remember to think in simple shapes. If your detailed building is in essence a tall cuboid tower then have an invisible cuboid with only 6 faces the same size in the same place. Have it act as your occluder.

4. Collision map. This is something to bare in mind for every game you make. You want a nice detailed environment but these details will cost you in terms of speed when it comes to collisions. You want the detailed environment to be a ghost and to have an invisible map with the most basic geometry possible while maintaining the approximate layout as the map that the objects actually collide with. This is a method that has been used in practically every game since the PS2 era began so it is an important factor in speeding up your games performance. The extra polys are well worth the save in collision calculation time.

5. Keep your game clean. What this means is avoid having the game slow down over time. If you are doing a GTA-like with lots of cars and pedestrians being generated all the time make sure to impose limitations on the numbers generated. Also, when a dynamic object such as a pedestrian or a car has been out of view for five to ten seconds end that object and get rid of it entirely. This will enable the game to generate a new pedestrian at a more suitable location and it will make sure that they don’t “fall through the cracks” as it were, leading to a build up in pedestrians over time making the game slow down more and more as time goes on. One way of testing for this is to start your game at night and check the frame-rate. Leave it running overnight and check framerate again in the morning. If the game has slowed to a snails crawl or crashed then you have leaks and or bugs that need fixing.

6. Dynamic Loading and Freeing. This is a feature that is available in some builds of 2.49 but is officially coming in with 2.5. Dynamically loading and Freeing objects and even entire sections of scenes will remove them entirely. Rather than only removing the calculations pertaining to the objects rendering they are removed from calculation entirely greatly saving your frame-rate.

7. Extensive use of Grouping. Grouping objects is one of the best features when it comes to design of objects and even areas in the BGE. You can have all your objects set aside in their own files where you set them up with their Graphics, Dynamics and Logic. All this in it’s on safe, external file that enables easy editing without having to bother with the rest of the game getting in the way. Make extensive use of grouping in every game project you do. Its very important for creating a strong flexible workflow which will allow for easy correction of problems at any stage of the game.

18

In a massive level, another thing to worry about that doesn’t come up in smaller ones so much is ram. without dynamic loading/freeing you can still make things invisible and pause physics and whatnot, but your entire blend file sits in ram even if you’re only using a tiny part of it, and if you have more texture space than your vram can handle, and your level forces your computer to start paging, you’re going to start hitting some serious lag regardless of what’s actually on screen, or even added into a visible layer.

19

I’m planning to make a more in-depth post tomorrow, but I just wanted to take the opportunity to already thank all of you for some of the great advice and ideas in this thread.

20

Unforeseen circumstances prevented me from returning to this topic for a while as I had promised, but here’s take two. I’m sure people won’t mind if I do not edit my previous post and instead make a new one.

1. Level Design.You say you are worried about the cost of such a huge scene in the editing process. A valid worry but ask yourself this; Why edit it all in the one scene? For each area that your world is divided up into make a separate blend file. Group the entire map together as a single blender group and link the group into your final file. Now arrange these objects in your final file to make your world and you can edit each section separately in their own file. The results will be automatically transfered to the final blend file.

A good point, but from the way you describe it, I still wonder if the method wouldn’t make have a few major setbacks. I will try to describe them here.

Imagine, for example, that we want a river to criss-cross through the landscape of a hypothetical game application. That landscape is divided into a number of “plots” of a shape and configuration that are of no importance right now. (Plots is the catch-all term I use here to denote one particular blend file that constitutes the final scene.)

Imagine that each of those plots corresponds to a separate blend file, the way you describe above. Obviously, we want to be able to sculpt this river in a scene that combines all of the individual plots (scenes), so that any changes to the landscape at the edge of one particular plot also propagate to the adjacent plot, so as to make a smooth, continuous landscape. The only problem here is that the scene that links all the individual plots together cannot directly be edited.

Instead, we’d have to edit the blend file of every plot individually and painstakingly try to make its edges line up with the rest. Otherwise, the landscape in the final file will look like it is “falling apart at the seams”. To use a metaphor, it would be like trying to draw a picture on a blank jigsaw puzzle, without being allowed to put the puzzle pieces together first.

In a related vein, you could probably see land textures end abruptly at the end of one plot. You’d constantly need to consult the “jigsaw puzzle” scene to make sure any buildings or objects you place in one plot do not bleed into something from an other plot etc.

2. LOD. There are many prototypes for LOD (Level of detail) in Blender. It can be done with python and even with logic bricks. You want to carefully map out how to run your LOD system for each section and for the map as a whole. Remember also to use the lowest LOD level as the object seen when editing the map. Since in the 3D viewport all the objects will be giving their impact you want to be using the versions with the lowest polycount to avoid editing impact.

Very good point, thanks.

3. Heavy use of occluders. Occluders are a relatively new feature in the BGE that, if active, will prevent anything hidden behind an occluder being rendered. For instance if you have a big building and a park behind it full of trees by making the building an occluder you prevent having to render all those trees and save yourself FPS. Just remember never use your detailed game model as the occluder. They should be as simple as possible. It can be handy to just use the same parts as your collision map for your occluders but remember to think in simple shapes. If your detailed building is in essence a tall cuboid tower then have an invisible cuboid with only 6 faces the same size in the same place. Have it act as your occluder.

I wasn’t aware of the existence of occluders, but I had certainly hoped something like it would exist. They could be a lifesaver.

4. Collision map. This is something to bare in mind for every game you make. You want a nice detailed environment but these details will cost you in terms of speed when it comes to collisions. You want the detailed environment to be a ghost and to have an invisible map with the most basic geometry possible while maintaining the approximate layout as the map that the objects actually collide with. This is a method that has been used in practically every game since the PS2 era began so it is an important factor in speeding up your games performance. The extra polys are well worth the save in collision calculation time.

This was already the method I had in mind. Like you say, I figure that the collision mesh can often double as an occluder, especially for geometrically simple, opaque objects.

6. Dynamic Loading and Freeing. This is a feature that is available in some builds of 2.49 but is officially coming in with 2.5. Dynamically loading and Freeing objects and even entire sections of scenes will remove them entirely. Rather than only removing the calculations pertaining to the objects rendering they are removed from calculation entirely greatly saving your frame-rate.

Joy. I will be reading into this. Thank you.

Magnum Opus: That proof of concept works remarkably well. Obviously the mechanics would have to be edited quite extensively to work on a larger scale, but it’s a start. Thanks.