Hello, I have a large problem with my game.
I'm making a city building game. All buildings are built with cubes, these are models with a size of 32x32x32 quants. I don't use WED, 'cause I want to build the game area with my own editor ingame (it's a lot easier due to the big amount of cubes). So, here comes the problem. Because of the cube-building system, there are many entities in my game, and it uses an EXTREME amount of memory (the more cubes I put down, the more memory it uses, even more than 600 MB). When it reaches a certain value, the game crashes. And, on top of that, it is also slow because of the many entities.
So, my question is, how can I reduce the amount of memory the game uses? And how can I make it run faster? With segments, loading models only in a certain area around the player? I also noticed that textures with bigger resolution also takes a lot of memory, but I cannot reduce the texture resolution enough. My options are more limited because I don't make my maps in WED, but ingame with my own editor.
Thanks for the answers in advance.

I'll take Minecraft as example: Performance wise it's impossible to use one entity per cube.

Minecraft solves this problem by using chunks (1 chunk = 1 entity = (afaik) 16³ blocks). Also they only create the faces that you can actually see, which is another must-have in order to make the game fast enough to be playable.

But how should I make these chunks?
And how can I render only the faces I can actually see?

This was just an example and an explanation why your approach doesn't work. You'll need some experience and you have to figure out how you can achieve what you want to do.
Combining multiple blocks to a single entity is just a rough guideline.

Also you're not just hiding polygons that cannot be seen, you actually don't even create them.

the idea with chunking is more or less this :

by having a world with a lot of models/entities your
rendering time to render each separate model/entity
increases dramatically .

to try and reduce the rendering calls , you split your
world up in to volumes containing each a certain
amount of data , in this case that data would represent models/ entities , each volume can now
be referred to as a chunk ,if you ever looked at the gs
chunked terrain ,it works on the same principles those chunks store triangles of the large terrain
splitted up into separate pieces ,well its kind off the same concept. .

you need to create single meshes and entitys from a bunch of meshes and entitys , so that in total you reduce
the amount of entities while still having the required mesh geometry , your meshes could be procedural/ dynamic meshes wich you could remove /add faces to, based upon what faces is seen ..

These merged meshes /entities are then stored in chunks wich is a data array ,wich refers to these volumes of entities. .

then you can, based upon a view distance ,load and
unload these chunks of entities/models so that
enough is visible at a time to still keep your rendering time small enough while not looking to cheap .

basicly chunking reduces the amount of rendering calls by physically reducing the amount of entities and models ..

chunk sizes go a bit deeper because you cannot make your chunks to large or to small ..

you would have to research on it or you can take a look at the tust library for kubus wich is basically what I have described in bad english constructed sentences here..

chunking=joining splitting/slicing into chunks

edit: oh and by the way ,there is alot of memory management that goes into chunking a large area ,you need to unload data from memory you dont need
on screen and only load what you need ,usually you load a little a head of time so chunks dont just pop
up into view but seem to be there by the time you can view them , this loading is usually a backround threaded routine so you do not suddenly cause to much overhead on the main application thread .

jb

there is always the alternative that you could use models of larger areas like city blocks instead of single models for each building or you could make
the editor such that the single buildings are added together by the user
on a grid surface with the appropriate limits , and then joined into one piece and plugged into the world grid as larger single meshes ...chunks ,wich you could manage

then there's instancing also ..

here is a theoretical idea for you wich you could try
out and if it works okay it could possibly make things
simpler...

if you are placing these buildings on top of terrain
you could determine the chunk of terrain your entity
are placed upon , then you could alter that chunk
of terrain by merging the entity mesh with the terrain
chunk's mesh ,then get rid of the entity and only
keep track of where that entity is (what terrain chunk it is on)

this way the terrain chunks should manage the added
geometry on it's own ..

The only problem with this idea is ,I dont know how
you would keep your skins correct and you would
actually add more geometry to the terrain chunk
than was initially planned for each chunk upon
creation ..

enough from me ..

jb

I have to add that Acknex capabilities are pretty limited in this area, mainly due to the huge memory footprint of geometry. I already asked, looks like there's no way around this since you cannot modify the per-vertex data in Acknex.

Here's a little example:


8x8x5 chunks with 200 blocks per chunk added. Acknex can't take any more than this. If I add more blocks, random crashes appear, I'll get an oom exception or I end up with bugs that cause so much CPU usage that the framerate drops below 1fps.

welcome to acknex ;(

there is a 64k of indices or vertices limit per entity mesh ,think I read that somewhere in the manual. .

jb

I know but that's not the issue because I'm using chunks ;P

It's simply the used memory which goes up to ~1.8gb until acknex crashes.

Edit: and if my calculation is right, the worst case scenario, if the meshing is done properly, is 24576 vertices per chunk. The index limit cannot be the problem.