Anti lag idea

I thought a little bit about Spaceships and space in the mod and
thought that it would lag like hell here's why:

1.Problem:
One cow (or any other mob)= Zero Lag
One zeppelin from zeppelin mod 10x10x10 blocks= A little lag
1000 cows= Hard lag
1000 10x10x10 block zeppelins= 1 frame per minute (massive lag)

And if you have a spaceship like Laserbillys Reckoning class fleet carrier,
that is massive it would also lag as hell.

2. Solution: Make everything 8x smaller so that a player is only half a block big and our example zeppelin is
2,5x2,5x2,5 blocks big.
What do you think?

Julo wrote:

I thought a little bit about Spaceships and space in the mod and
thought that it would lag like hell here's why:

1.Problem:
One cow (or any other mob)= Zero Lag
One zeppelin from zeppelin mod 10x10x10 blocks= A little lag
1000 cows= Hard lag
1000 10x10x10 block zeppelins= 1 frame per minute (massive lag)

And if you have a spaceship like Laserbillys Reckoning class fleet carrier,
that is massive it would also lag as hell.

2. Solution: Make everything 8x smaller so that a player is only half a block big and our example zeppelin is
2,5x2,5x2,5 blocks big.
What do you think?

I doesn´t matter how big stuff is, it only matters how much stuff there is.
Zeppelin mod lags because it converts every single block into an entity, Futurecreft will either turn all into a single entity or leave it being blocks and just change the direction they´re facing. (I actually don´t know what of that is the case anymore, ask Fr0stbyte)

That's silly. Sorry. The most obvious side effect would be that all ships would be eight times less detailed. To fix that, we could include smaller blocks, so we could have the same level of detail. But then the ship has the original number of blocks in it. In any case, we're not doing it the same way Zeppelin does, and even that is only a small part of the total framerate problem. Fr0st's new graphics engine should take care of at least some of this without having to do anything strange.

Last_Jedi_Standing wrote:

Fr0st's new graphics engine should take care of at least some of this without having to do anything strange.

Last_Jedi_Standing wrote:

without having to do anything strange

Last_Jedi_Standing wrote:

anything strange

I thought Fr0st is already doing strange stuff?

Surp. Grm. Ivan Kintobor wrote:

Last_Jedi_Standing wrote:

Fr0st's new graphics engine should take care of at least some of this without having to do anything strange.

Last_Jedi_Standing wrote:

without having to do anything strange

Last_Jedi_Standing wrote:

anything strange

I thought Fr0st is already doing strange stuff?

Stranger.

Ships don't have significant lag. It's been optimized pretty heavily.

That looked like Troll physics to me.

hyperlite wrote:

That looked like Troll physics to me.

That's it exactly. This is an interesting idea, but it's a troll idea.

What he is saying is similar to the concept of octree segmentation, which allows you to work with increasingly coarse resolution models to knock out preliminary collision detection much more efficiently.
Normally it's a good idea, and has a lot of useful traits not only to efficient searching, but also also data storage, but I don't use it in the case of ship collisions because I've got a model which can take full advantage of the uniform shape and displacement of blocks in terrain and on ships. It's the sort of advantage you aren't normally afforded in most games, which is why this is a custom solution.

fr0stbyte124 wrote:

What he is saying is similar to the concept of octree segmentation, which allows you to work with increasingly coarse resolution models to knock out preliminary collision detection much more efficiently.
Normally it's a good idea, and has a lot of useful traits not only to efficient searching, but also also data storage, but I don't use it in the case of ship collisions because I've got a model which can take full advantage of the uniform shape and displacement of blocks in terrain and on ships. It's the sort of advantage you aren't normally afforded in most games, which is why this is a custom solution.

It is my belief that custom problems present custom solutions, or that necessity is the mother of invention.

fr0stbyte124 wrote:

What he is saying is similar to the concept of octree segmentation, which allows you to work with increasingly coarse resolution models to knock out preliminary collision detection much more efficiently.
Normally it's a good idea, and has a lot of useful traits not only to efficient searching, but also also data storage, but I don't use it in the case of ship collisions because I've got a model which can take full advantage of the uniform shape and displacement of blocks in terrain and on ships. It's the sort of advantage you aren't normally afforded in most games, which is why this is a custom solution.

After the first line I lost track of your technical terms.

Yeah, pretty much.

Surp. Grm. Ivan Kintobor wrote:

fr0stbyte124 wrote:

What he is saying is similar to the concept of octree segmentation, which allows you to work with increasingly coarse resolution models to knock out preliminary collision detection much more efficiently.
Normally it's a good idea, and has a lot of useful traits not only to efficient searching, but also also data storage, but I don't use it in the case of ship collisions because I've got a model which can take full advantage of the uniform shape and displacement of blocks in terrain and on ships. It's the sort of advantage you aren't normally afforded in most games, which is why this is a custom solution.

After the first line I lost track of your technical terms.

An octtree is a cube that is divided into 8 pieces. Each piece can be subdivided into 8 more pieces. You keep going like this until it is the smallest unit you care about. This structure is efficient for a lot of sciencey reasons,.

fr0stbyte124 wrote:

Surp. Grm. Ivan Kintobor wrote:

fr0stbyte124 wrote:

What he is saying is similar to the concept of octree segmentation, which allows you to work with increasingly coarse resolution models to knock out preliminary collision detection much more efficiently.
Normally it's a good idea, and has a lot of useful traits not only to efficient searching, but also also data storage, but I don't use it in the case of ship collisions because I've got a model which can take full advantage of the uniform shape and displacement of blocks in terrain and on ships. It's the sort of advantage you aren't normally afforded in most games, which is why this is a custom solution.

After the first line I lost track of your technical terms.

An octtree is a cube that is divided into 8 pieces. Each piece can be subdivided into 8 more pieces. You keep going like this until it is the smallest unit you care about. This structure is efficient for a lot of sciencey reasons,.

Is it of any use for Minecraft framerates?

Minecraft doesn't use octtrees. But most real voxel apps do.

fr0stbyte124 wrote:

most real voxel apps do.

You mean to say there are games like Minecraft that aren't crap performance-wise?

English, please, put it in layman terms then I can comment meaningfully

Prototype wrote:

English, please, put it in layman terms then I can comment meaningfully

Oh, oh, Fr0stbyte-time...

Surp. Grm. Ivan Kintobor wrote:

Prototype wrote:

English, please, put it in layman terms then I can comment meaningfully

Oh, oh, Fr0stbyte-time...

STFU, it's learning time!

In the strictest sense, Minecraft does have a voxel engine; terrain blocks are stored according to relative positions, rather than explicit coordinates, like a pixel map only 3D. However, each of those blocks is then converted 1:1 into a set of polygon faces for rendering. There are other voxel engines which convert voxel data into polygons before rendering, because modern GPUs are very good at drawing polygons. The difference here is the 1:1 correlation between blocks and faces. While necessary to maintain the blocky nature of the game, you could view the voxel data simply as a compressed version of listing out each polygon by coordinate. In this respect, it is not so terribly different from any polygon-based model. I would consider it a hybrid.

In a fully realized voxel engine, you are often dealing with a massive scale between your largest objects and your smallest voxel units. Because of this, the engines usually employ specialized drawing techniques, like the marching cubes algorithm, which converts voxel data into polygon surfaces, but which can be used at varying levels of resolution so that you have control over your end poly-count. Different storage structures, such as octtrees, are often an efficient way of storing large amounts of uniform data by using voxels of varying scales.

Basically he means minecraft ha a voxel engine ... (?)

I'm saying Minecraft is only superficially a voxel engine. The sort of things you would normally expect to see in most voxel systems which distinguish them from polygon-based systems are not present here.

fr0stbyte124 wrote:

Surp. Grm. Ivan Kintobor wrote:

Prototype wrote:

English, please, put it in layman terms then I can comment meaningfully

Oh, oh, Fr0stbyte-time...

STFU, it's learning time!

In the strictest sense, Minecraft does have a voxel engine; terrain blocks are stored according to relative positions, rather than explicit coordinates, like a pixel map only 3D. However, each of those blocks is then converted 1:1 into a set of polygon faces for rendering. There are other voxel engines which convert voxel data into polygons before rendering, because modern GPUs are very good at drawing polygons. The difference here is the 1:1 correlation between blocks and faces. While necessary to maintain the blocky nature of the game, you could view the voxel data simply as a compressed version of listing out each polygon by coordinate. In this respect, it is not so terribly different from any bolygon-based model. I would consider it a hybrid.

In a fully realized voxel engine, you are often dealing with a massive scale between your largest objects and your smallest voxel units. Because of this, the engines usually employ specialized drawing techniques, like the marching cubes algorithm, which converts voxel data into polygon surfaces, but which can be used at varying levels of resolution so that you have control over your end poly-count. Different storage structures, such as octtrees, are often an efficient way of storing large amounts of uniform data by using voxels of varying scales.

Did you mean to say "bolygon"? Because that ain't a word as far as I know.

The Schmetterling wrote:

fr0stbyte124 wrote:

Surp. Grm. Ivan Kintobor wrote:

Prototype wrote:

English, please, put it in layman terms then I can comment meaningfully

Oh, oh, Fr0stbyte-time...

STFU, it's learning time!

In the strictest sense, Minecraft does have a voxel engine; terrain blocks are stored according to relative positions, rather than explicit coordinates, like a pixel map only 3D. However, each of those blocks is then converted 1:1 into a set of polygon faces for rendering. There are other voxel engines which convert voxel data into polygons before rendering, because modern GPUs are very good at drawing polygons. The difference here is the 1:1 correlation between blocks and faces. While necessary to maintain the blocky nature of the game, you could view the voxel data simply as a compressed version of listing out each polygon by coordinate. In this respect, it is not so terribly different from any bolygon-based model. I would consider it a hybrid.

In a fully realized voxel engine, you are often dealing with a massive scale between your largest objects and your smallest voxel units. Because of this, the engines usually employ specialized drawing techniques, like the marching cubes algorithm, which converts voxel data into polygon surfaces, but which can be used at varying levels of resolution so that you have control over your end poly-count. Different storage structures, such as octtrees, are often an efficient way of storing large amounts of uniform data by using voxels of varying scales.

Did you mean to say "bolygon"? Because that ain't a word as far as I know.

I think polygon is a pokemon so that might be it?

kokonus wrote:

The Schmetterling wrote:

fr0stbyte124 wrote:

Surp. Grm. Ivan Kintobor wrote:

Prototype wrote:

English, please, put it in layman terms then I can comment meaningfully

Oh, oh, Fr0stbyte-time...

STFU, it's learning time!

In the strictest sense, Minecraft does have a voxel engine; terrain blocks are stored according to relative positions, rather than explicit coordinates, like a pixel map only 3D. However, each of those blocks is then converted 1:1 into a set of polygon faces for rendering. There are other voxel engines which convert voxel data into polygons before rendering, because modern GPUs are very good at drawing polygons. The difference here is the 1:1 correlation between blocks and faces. While necessary to maintain the blocky nature of the game, you could view the voxel data simply as a compressed version of listing out each polygon by coordinate. In this respect, it is not so terribly different from any bolygon-based model. I would consider it a hybrid.

In a fully realized voxel engine, you are often dealing with a massive scale between your largest objects and your smallest voxel units. Because of this, the engines usually employ specialized drawing techniques, like the marching cubes algorithm, which converts voxel data into polygon surfaces, but which can be used at varying levels of resolution so that you have control over your end poly-count. Different storage structures, such as octtrees, are often an efficient way of storing large amounts of uniform data by using voxels of varying scales.

Did you mean to say "bolygon"? Because that ain't a word as far as I know.

I think polygon is a pokemon so that might be it?

...

OK, if you don't speak English, you don't speak English. But commenting on English grammar discussions is probably not the most productive use of your time.

Polygons ... are they triangles in minecraft ?