What if you had a row of cubes take the shape of the ground as they move acrossed the scene.You would store the shape of the ground in a notepad file and python would read it.There is nothing in the scene except the
cubes that the player is standing on and that row of cubes.I think you could have a framerate of
60 with that.You like or not?
Congratz, you just invented paging. 50 years too late…
A more successful method — and even less sophisticated — method is to use paging or “virtual memory” to expand the size of the flat array. To do this one breaks down the flat 3D array into a collection of pages or “chunks”, and then uses a hash table to sparsely store only a subset of the pages which are currently required by the game:
Pages/chunks are typically assigned in the same way as any virtual memory system: by reserving the upper-bits of the coordinate for the chunk ID. Using a virtual memory system has the additional advantage that chunks can be lazily initialized, which is great for games with procedural content. The same concept also allows chunks to be mapped back to disk when they are not needed (that is when there are no players nearby). Using a hash map to store the chunks allows one to maintain constant time random access, while simultaneously taking advantage of sparsity as in an octree.
First problem, why do you ened to store in txt file and not in memory?
(you have enough memory probably for a trillion voxels)
Second, for example by god awful demo you love already does this if you haven’t noticed.
LOOK, I even have the Dynamic loading gif I originally posted to show this.
Finally, you have not addressed the issue!
You are limiting the amount of cubes visible not making them perform better.
its like saying: ‘To stop being hungry is easy, just expect that there is no food’
Also structure you post please, and give images at least because you don’t even consider that ‘a row of cubes’ is cryptic as sht.
You probably meant the cubes visible in the camera, ie line of sight.
I meant moving a row of cubes from one side to the other.While making them take the shape of the terrain as they move from one side to the other.Ten thousands cubes in a straight line you get a framerate 60.I would rather do what can be done in the bge right now.But in your demo the framerate goes down if you dig and the tunnels are not smooth.What i am trying to do is prevent the framerate from dropping from that.
How fast can you load and unload a line of terrain from side to side with the method you used in
block easy demo?Because if you can do it fast enough it would give the illusion of continuous ground while keeping the framerate 60.
If you can’t figure out why digging lowers the framerate, then I have bad news…
It has nothing to do with the arrangement or lines.
If you dig into something, the surface increases.
And what the voxel demo does is to display the surface of voxel volumes/chunks.
(its a form of culling)
More surface == more cubes.
Even if the tunnels are underground, they still can be in the camera frustum, which means processing.
Digging increases the count of cubes that can be in the camera fustrum.
(meaning it creates hot spots, with over the average amount of cubes)
Why would drawing cubes in a line give more performance anyways? :spin::spin::spin:
In short, digging creates more cubes. Your line theory is dumb.
I do not understand that “row of cubes” idea.
Too me it sounds like I see a row. But I want to see a wide surface. A sketch might help to visualize what you mean.
Add a row then end that row.Then add a row next to that row then end that row.Then add a row next to that row then end that row etc.These no collision cubes.They are just for display only.I want them to add fast and end fast as possible. Etc. means over and over again until it displays the whole terrain.What did i say.Having a line of 10,000 cubes for the terrain in a row gives a framerate of 60.
So finally it is like VegetableJuiceF wrote in post#2 with fine granularity (he mentioned a method to add more than just a row).
The complete idea is (similar to LOD and object culling) to see all (possible visible) objects, but remove all objects that can’t be seen.
The BGE does such things already via camera frustum culling. This is for rendering only. The objects are still handled by the other parts of the BGE (logic, physics, scene management …). Therefore adding object culling can be a good way to avoid performance loss.
On large scenes (open world) it is a must have, otherwise the engine manages itself to death. You can’t have a whole city in memory and expect it is realtime.
Rule number 1: Culling should never ever visible to the user!
Rule number 2: It is very important to keep an eye on the costs of the culling operation. It has to be much less costs than the costs without it.
So coming back to “rows” vs. “chunks”. Rows are a special form of chunks. While rows allow to have less objects in the scene, the culling can be more expensive than with larger chunks. This needs to be measured within the specific situation.
How expensive is it?What is the framerate?I like my idea.I really don’t care if culling is visible.Why should anyone else?If they can see the scene.What make rows more expensive than chunks?Is there a way to optimize it?
What makes rows more expensive than chunks the adding and ending of the rows of terrain.
What about if i make a row of terrain cubes take the shape of the terrain as they move from left
to right.Here is a more detailed explanation.
You have a row of terrain cubes.Then they move to the next row taking the shape of the terrain from python.The rows are in python.Then they move to the next row taking the shape of the terrain from python. etc.These are no collision cubes.They are just for display only.
Chunks are easily defined, contained and easy to use.
Your rows would require math and expensive random lookups because they are volatile.
Better question is: have you even done any rudimentary testing?
How many cubes can you spawn before hitting 16 ms?
How many cubes can you move before hitting 16 ms?
How many complex lookups can you do in 16 ms?
By saying complex lookups I am thinking about querying all the surface voxels for given fustrum ie your ‘rows’.
The first two you should be able to produce in 2 min.
EDIT:
Tested, and WOW. You are off by 10 times…
Even my i7 cant do that many :eek:
I have not tested that?Have you tested that before?The ten thousand blocks were not individual blocks.They were all joined together.
I think lostscience proposes a “scanning” line of cubes, that scans fast enough to appear solid. This won’t offer any better performance, and it very much based on non rendering ideas.
How do you know?Did you try it?
Because it’s just the same problem re-arranged. Rendering one line in different places extra fast is the same as rendering N times as many lines N times less often (ish)
I won’t believe that until i am shown proof.
Fab, then try it!
what about using a tree of trees to store a grid, and as objects are inside a range they get spawned and added toa ‘active’ tree, so one can manage what is in a scene by using a xyz and the two trees? (active vs inactive?)
That’s typically how a large world is handled. Regions are stored spatially, and the minimum subset of elements loaded around the player to give the illusion of a larger world. We cannot, and have never been able to, render a world of infinite size without ignoring most of it at any given time.
The optimising of open world video games is a job title in itself. There is a lot of theory behind these techniques, which is why it can be relatively simple to determine whether a particular naive technique will work or not, without testing it.
I know one way that could make the world appear to load more at once, would be static cube maps that were the horizon so distant objects could be seen even though they are not loaded, but that sounds like some serious amount of ram 
(and would not represent changes to the scene*)