Jump to content

Chunk complexity working wrong!


StarZet

Recommended Posts

In short: Percentage of complexity today depends on surface area, but must depend on amount of polygons.

 

(In polygon I mean 2trianles, so 1 cube have 6 polygons or 12 tris) https://en.wikipedia.org/wiki/Polygon_mesh

Yes modern GPU can handle millions of polygons but fps border closer then it looks.

So we have 2 variants of what Chunk complexity can depend on:

 1) amount of polygons

 2) storage on server side

But after some tests it find out that this system based on surface area count.

 

Have two solid cubes full of woxels 31x31x31, left of one material and second if full of chequerboard pattern. And they have the same 37%. (also I was ask NQ-Deckart about server storage of it, the ansver: "For example, the left cube will compress very easily. The one on the right, not so much.")

 

dualuniverse_2021-12-03_17h07m11s.thumb.png.7eb2641605fec6b28d38afcd6a963ea2.png

 

dualuniverse_2021-12-03_17h06m57s.thumb.png.fce440e23838e4786fd2ae779fc5a479.png

 

So it's no seen relative on server storage,

 

Next test on relation of surface area on different types of voxel structures.

Flats and Columns, when they have the same area surface, the polygon count is different. And what we see? When area is 2048m2 they have 267% for Flats and 320% for Columns.

That means chunk complexity is more complicated than it seems.

dualuniverse_2021-12-04_20h15m11s.thumb.png.947e641fd766270a4c317b4c671cc45c.png

 

Also some exel info shows as, that the percentage is decreasing with increasing surface area, but with more polygons it's decreasing less.

 

image.thumb.png.e0d2f4c8858e2fe3bd7379b4ff1aa6ef.png

 

And last test is about lags.

Here stable 60fps if look on 135 flat cubes x 6 sides = 810 polygons VS 135 flats of chequerboard x (64x96x2+(64+64+96+96)) = 1702080 polygons and 33fps.

(tested area is analog only of 3.24 L core areas)

1915615641_screen(959).thumb.png.ae7ec8fff6fde3c413408356efa9e76a.png

 

screen(964).thumb.png.c3785c1a5581bcf7553f2e61e65052e2.png

 

BUT the same 267% complexity.

 

unknown11.png.b9740b2e4ed38df850dcf98bb9309c7d.png

unknown12.png.cf8e2d563d45f3dfb3420280f1de9749.png

Link to comment
Share on other sites

Thanks for shedding some light on this black box constraint that has been snuck in.  What is probably being reported is some abstract measure such as the number of iterations over a block of code divided by some selected threshold. I imagine it would be hard to put that into guidance on what is ok and what should be avoided.
I'm curious if the market buildings could be built now within these constraints, or using the vertex editor under development (the voxel "grout" lines between wall/floor tiles look to be 1/16th wide).

Link to comment
Share on other sites

Hello everyone,

 

The complexity limitation is there primarily to protect our server infrastructure.
The protection of client side performance and framerates is secondary for this implementation.

 

There is also an aspect of compression and storage involved.

 

- Deckard

Link to comment
Share on other sites

Why was the chunk size set to 8 meters given that the smallest construct that a server deals with is 16 meters? As it is now, builders have to consider where chunk boundaries are so the complexity (whatever that is) can be shared across chunks.

Link to comment
Share on other sites

19 minutes ago, NQ-Deckard said:

As those are the sizes of the voxel chunks handled inside the game.

For example, and XS sized core, is made up out of 8 chunks.

 

- Deckard


@NQ-Deckard how much do dynamic core sizes impact server cost? Are static structures themselves an impact in server cost to NQ as well? 
Server cost being monthly cost in $$$ for NQ to run the servers.

Edited by Creator
Link to comment
Share on other sites

14 minutes ago, NQ-Deckard said:

As those are the sizes of the voxel chunks handled inside the game.

For example, and XS sized core, is made up out of 8 chunks.

 

- Deckard

You haven't told me anything I couldn't have (and in fact did) figure out for myself. Can you describe the parameters affecting the algorithm determining complexity measure? The number of vertices, the number vertices with an empty neighbour (or 2 or 3) etc?

Link to comment
Share on other sites

2 minutes ago, JayleBreak said:

You haven't told me anything I couldn't have (and in fact did) figure out for myself. Can you describe the parameters affecting the algorithm determining complexity measure? The number of vertices, the number vertices with an empty neighbour (or 2 or 3) etc?

 

Unfortunately that's a little beyond my own scope, however I can tell you it's related to how its converted for storage.

 

Perhaps, if there is a lot of demand for it. I can look into a more extensive devblog on the topic. However that will greatly depend on time available for the team members who's scope that does fall into. ?

 

8 minutes ago, Creator said:


@NQ-Deckard how much do dynamic core sizes impact server cost? Are static structures themselves an impact in server cost to NQ as well? 
Server cost being cost to NQ to run the servers.

 

Static and Dynamic constructs are pretty much the same from that perspective, although they do have some behavioural differences obviously as one supports movement and the other supports industry.

Link to comment
Share on other sites

10 minutes ago, NQ-Deckard said:

Static and Dynamic constructs are pretty much the same from that perspective, although they do have some behavioural differences obviously as one supports movement and the other supports industry.


@NQ-DeckardWasn't really the nature of my question, though I appreciate you responding.

The real meat of my question is: How much would it benefit NQ's bottom line(monthly server cost) by removing L-Core/M-Core constructs from the game world that are left lying around by inactive players? Would it be very little, quiet a lot, or something in between?

Does construct size matter in server costs to NQ or is it quantity of construct entities more important?
Approximately what % of the server workload is dictated by voxel complexity, or number of constructs in game vs. player activity (doing things)?

Edited by Creator
Link to comment
Share on other sites

Thank you for the information. At the moment it still does not help me how to improve the problems at my location in the game.
At the beginning it said that the enormous number of elements drags down the performance. In the meantime I have removed almost all machines and elements. No improvement. Another culprit was the enormous change in the ground due to terraforming. But with Demeter the ground is completely freed from this, again no improvement. As a third possibility, my typical Borg structure was blamed in the meantime, but here too, I have meanwhile removed almost 100 cores - no improvement.
Especially since with this structure the grid does not indicate any load.

 

Link to comment
Share on other sites

1 hour ago, Creator said:


@NQ-DeckardWasn't really the nature of my question, though I appreciate you responding.

The real meat of my question is: How much would it benefit NQ's bottom line(monthly server cost) by removing L-Core/M-Core constructs from the game world that are left lying around by inactive players? Would it be very little, quiet a lot, or something in between?

Does construct size matter in server costs to NQ or is it quantity of construct entities more important?
Approximately what % of the server workload is dictated by voxel complexity, or number of constructs in game vs. player activity (doing things)?

 

Sorry, but that is specific information I will not be disclosing. :)

What I can tell you is that systems are being developed to aid some of these aspects of the game. More on that will follow in later devblogs however.

Link to comment
Share on other sites

10 minutes ago, NQ-Deckard said:

 

Sorry, but that is specific information I will not be disclosing. :)

What I can tell you is that systems are being developed to aid some of these aspects of the game. More on that will follow in later devblogs however.


Based on the game changes direction NQ has done it seems like the impact of L-Cores & M-Cores is proportionally pretty large, and possibly the complexity of our constructs or/and number of them is significant even in comparison the active (vs. passive activities) actions of players on the server load. I feel the fact that you dodged even providing general answers confirms it.

Definitely explains the choking of progress and resources gains we see in Dementor that would allow players to commonly build out these large scale builds.

Edited by Creator
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...