Author Topic: How come larger cubes are so much slower than smaller ones? (Read 1435 times)

TheBlackParrot · November 20, 2015, 01:53:09 AM

I'm noticing on servers with a heavy amount of cubescape (e.g. Reverie Fortwars and something I'm working on for a freebuild), the game will lag to stuff while the larger cubes ghost.
Creating them through a new fxDTSBrick object manually too is also quite slow, especially in terrain generation.

Why are they so much slower?

Ad Bot · Advertisement

Zeblote · November 20, 2015, 02:00:23 AM

Does it use 32x cubes? Figuring out the coverage for those takes a long time because they're so big.

TheBlackParrot · November 20, 2015, 02:03:03 AM

Quote from: Zeblote on November 20, 2015, 02:00:23 AM

Does it use 32x cubes? Figuring out the coverage for those takes a long time because they're so big.

64x
I might tone it down to 32, but I wanted an expansive area

Planr · November 20, 2015, 03:24:09 AM

donald Annoying Orange would build a wall out of 64x cubes and then he'd lag america as a result.

Lord Tony� · November 20, 2015, 03:45:06 AM

Because 64x cubes take much larger render space. If it takes like 5 second to remove a 16x16 cube then a 64x64 cube requires 4x that amount of time.

250k 1x1 bricks will clear faster than 50k 64x64 cubes.

Kyuande · November 20, 2015, 11:52:30 AM

Modter is worse

Lord Tony� · November 20, 2015, 01:22:13 PM

Quote from: Kyuande on November 20, 2015, 11:52:30 AM

Modter is worse

It's because it's a water cube and it's a print cube.

Kyuande · November 20, 2015, 01:31:37 PM

I don't think water bricks matter

A_TEE · November 20, 2015, 02:25:29 PM

I've never noticed that.

Refticus · November 20, 2015, 05:10:12 PM

Quote from: Planr on November 20, 2015, 03:24:09 AM

donald Annoying Orange would build a wall out of 64x cubes and then he'd lag america as a result.

make america great again

Scout31 · November 20, 2015, 05:17:38 PM

I believe it relates to the octotree, not rendering. Rendering a polygon 4x as large will only have a negligible effect on render time, and it wouldn't impact load times.

An octotree works by splitting a cubes in to smaller cubes essentially. By placing a 64x cube, you're intersecting much more of the octotree cubes (divisions? I'm only familiar with the concept, not terminology) than placing a 32x cube. The game has to do a lot of work to divide up the block. Imagine a trench war server, where you randomly split a x64 cube in to dozens of bricks by mining out a single hole in the middle.

Zeblote · November 20, 2015, 06:26:56 PM

Quote from: Kyuande on November 20, 2015, 01:31:37 PM

I don't think water bricks matter

Water bricks make it worse because of the second brick layer.

Honno · November 20, 2015, 06:38:06 PM

Quote from: Scout31 on November 20, 2015, 05:17:38 PM

I believe it relates to the octotree, not rendering. Rendering a polygon 4x as large will only have a negligible effect on render time, and it wouldn't impact load times.

An octotree works by splitting a cubes in to smaller cubes essentially. By placing a 64x cube, you're intersecting much more of the octotree cubes (divisions? I'm only familiar with the concept, not terminology) than placing a 32x cube. The game has to do a lot of work to divide up the block. Imagine a trench war server, where you randomly split a x64 cube in to dozens of bricks by mining out a single hole in the middle.

also its called an octree. heres some clarification on it:

Quote from: Klarck on October 24, 2015, 02:58:34 PM

Ok so let me put things stright.
Blockland isn't a voxel rendering engine however it could be categorized as a voxel game, due to the limitations of bricks to the grid.
An octree is the 3d version of a binary tree.
A binary tree is a tree where each node has 2 children.
Example:

An octree is the same thing, except each node has 8 children and each corresponds to each of the 8 octants of the cube

Here's how a typical octree would look like:

~~The leftmost cube represents the root node. The rightmost tree has one of the leaf nodes marked in red.~~ << ignore that i replaced the image so it doesnt apply anymore
In blockland, the most likely scenario is that all bricks are stored in the octree.
The octree is used to optimize the removal of invisible faces. In principal, the octree would be used to efficiently find the adjacent node in the tree and check whether it contains a brick. If it does it removes the face of the brick there.
The problem is when bricks can contain other bricks. The algorithm doesn't take into account that case, and that is why you can see through bricks sometimes when they are partially inside modter bricks.
If you had a cube of size 8 made entirely of 8x8x8 bricks, using the na�ve method you would would have to render each face of the cube, which would result in (number of faces per brick)*(number of bricks) = 6 * 8^3 = 3072 faces.
Using the octree, you would only have to render the outer faces, because the inner faces would be removed using the algorithm (in the optimal case), which would result in drawing only (number of large faces)*(number of faces per large face) = 6 * 8^2 = 384 faces.
What i speculate that goes inside blockland is, The algorithm runs over the octree of bricks and removes all hidden faces. After that, it adds in all the faces of all the non-brick objects suck as vehicles, players, projectiles, emitters, and all the like.
After that, it sends all of the data about polygons into the GPU which handles all the rendering, shading, and such.
The reason why I don't consider blockland as a true voxel rendering engine, is because a true voxel rendering engine usually is a raytracing engine, which means that instead of sending data to the GPU it casts rays into the scene and calculates collisions of the ray with the octree.

EDIT: the thing with static shapes is that they don't use the octree because they are not fixed to the grid, and that's why they are slower