Is it even possible to make a open world game in blender game engine??
I mean in a open world structurs, character and props must disapear after a specific range ootherwise it will lagg shit, yes?
And that not har at all to do, just make the object get invisible after a specific range. very simple
But what when i am in “non game” mode in blender, you know where i model and such. no script or anything work there so then i have see all objects, witch no personal computer cant handle in a really big map…
So is open world impossible in blender game engine??
I mean yes sure, i can set so the render distance is short as hell. but thats it right? i mean thats gonna be hard to work with
The short answer is yes, you can create an open world. The main difference with other engines is the lack of a dedicated terrain management module, the rest works exactly the same. And the biggest problem is the sheer amount of stuff you have to design and model to make the open world actually interesting.
I was wondering how exacly will it work, on other engines models disapear when they are to far away from camera even in non game mode, here they doesnt. so how do i make them disapear even out of game? like can i set render distance to 1 layer, and have a longer distance on another layer or something?
Open worlds are usually managed by recursively dividing the world into different levels of importance. There are structures that benefit distance culling, like quadtrees, BVH trees and Octrees (for 3D worlds like Minecraft, whereas a more 2D constrained game like Call Of Duty, Last Of Us, Skyrim etc) would likely use a 2D structure because the difference in height is very little).
The purpose of these algorithms is to quickly work out what to show to the player based on the player’s proximity. It does so by started with very course grained regions (e.g Chunks, in minecraft) which are quick to test near the player, and if the player is not near enough (or, in some implementations, inside of) to the chunk, it’s unloaded / not loaded. As you create a larger world, it’s useful to have larger base regions, and divide them again, so that you maintain performance. The greater the number of divisions (or resolution of the tree), the more accurately regions can be loaded/unloaded (which may improve performance), but at a cost to the search time (to find nearby valid regions).
LOD is then useful within the loaded regions to ensure that we don’t waste time rendering high-detailed models which are too distant to be noticeable.
i know all this allready, but im talkign about OUT OF GAME you know, NOT In-game not when you have pressed “P” befour, no scrips or logicbricks or snything works there, and LOD doesnt work out there since its a script and nothing that blender has built in to it
Actually, LOD works out of the game. But, it won’t cull models. If you read my post above, the reason I mentioned regions is that you don’t design the entire level in one file. You design per-region (for the assets), and design the terrain according to some system that can support regions. Typically handling terrain and assets with different systems. Terrain might use the regions, or rather a shader with its own region system (as terrain might be more visible than assets far away), etc. The point is you need something scalable. Some people use heightmaps per-region, so the terrain data is defined by several images, which can be loaded with the region information.
To implement this, and make it scalable, some people might have regions stored in folders in a regions folder, with each folder containing the metadata for that region, and any nested regions as folders of the same structure.
To edit these regions, it depends how you design. You might be best producing the terrain heightmaps first, splitting them into regions, then devising a system of displacing a terrain mesh with the region heightmap. Then, placing the assets, remove the terrain and save the assets file, save the other maps for the region etc.
It’s a time consuming process, but it’s a big task. Alternatively, you could bake the heightmaps from a pre-modelled terrain.
It makes the most sense to design tools to do these tasks, which requires Python.
The Novus Terra project started working on things like this, though it was abandoned after a redesign to move to UDK
I’m exporting the code to GitHub, because the Google Code page will soon disappear - https://github.com/agoose77/novus-terra-code
You can easily organize your scene objects by moving them to different layers.
For example, say I have a scene with an island, covered in Trees, Rocks, and a large Building.
I would have the base terrain mesh on its own layer.
On another layer, I put the Trees. On another, Rocks.
I dedicated a seperate layer just to the large Building.
On yet another layer, I put my sunlamp and ambient lamps.
Then, you only need to make visible the layers you’re working on.
There is no need to have every object in your scene being drawn in the editor all at once, if you don’t want it to.
In addition to the previous suggestions, you could use simple proxy objects to represent different, more complex objects if you need them to (i.e. a plane with the word “tree” on it to represent your actual tree, or a simple cube that gets swapped out with an actual building).
yghtim - They are answering questions - no offense, -you don’t know to ask yet. These guys are VERY good at Blender and the GE. They get it. They know what you are asking. Yes, you can get rid of objects you don’t want to see when you are modeling several different ways. Layers, scenes etc. They are just recommending a more over-arching strategy. Again no offense.
