Dev Blog : July 28th 2016

[Valck]

View attachment 29893

Makes me wonder about blueprints-stations (and templates, if it exists). In your example, there appears to be no change; possibly because they were from a fresh install and didn't need converting.

But what if you happen to upgrade, and/or have custom stations? And how about templates and sector exports, they have a different format (judging from the extension at least, no idea of the internal structure), will they get converted, or do they even need to be?

 

[AndyP]

I have all my blueprint backed up in a separate folder. Would it be possible to choose which folders to convert?

Not directly, but all blueprints the game has available in the /blueprints folder will be converted.
So if you pull them out of it, the game cant see them and wont convert them, however it will convert them, once they are put back in.

Makes me wonder about blueprints-stations (and templates, if it exists). In your example, there appears to be no change; possibly because they were from a fresh install and didn't need converting.

But what if you happen to upgrade, and/or have custom stations? And how about templates and sector exports, they have a different format (judging from the extension at least, no idea of the internal structure), will they get converted, or do they even need to be?

Good question, they are currently converted like all other blueprints, so I see no reason for them to be an exception.
They will be treated as all other assets shipped with the game.

- Andy

 

[<SCRIPTKITTY>]

With a 1km long ship as well as a 3.14*500m^2 station in the works. Performance improvement es bueno

 

[Gonzalo]

I dont understand...how the heck does increasing chunk size make better performance?

 

[nightrune]

I dont understand...how the heck does increasing chunk size make better performance?

I am not a dev for the game. Some things maybe wrong since I don't have access to their code. I've just been a developer for the last 10 years, and professional for the last 5.

There are a couple things:
In-game fps is coupled to a few things, but the one we care about right now is how many objects are on the screen. In many voxel games each chunk/segment is rendered separately. Specifically that its one OpenGL draw call, and by increasing the chunk size there are less draw calls every frame. Therefore, speeding up rendering.

New block format:
The current smd2 file type has a smal header for every chunk and then up to N( Like 5000 ish?) number of bytes after the 16x16x16x3 number of bytes has been compressed. Compressing the data on disk has two obvious benefits. One that disks are slow and you need less data from it, but you trade it off with processor time. Two its less disk space, but one thing to know about compression algorithms is that they tend to work better on large data. So when you increase the chunk size we now have 32x32x32x3 bytes you actually end up reducing disk size and increasing the effective chunk loading speed.

Possible advantage:
Combat damage may take less time since you need to update fewer chunks based on the damage you receive.

Disadvantages of Chunk increase:
- For physics it means you have to likely search through 32x32x32 blocks to find the one/ones you are colliding with. We've seen this so far.
- Chunk updates may take longer since you have to touch each block and there are more blocks, but since you are likely in a tighter loop this may stay the same or be close to the original if you did 2x2x2 chunks together.

 

[Edymnion]

I dont understand...how the heck does increasing chunk size make better performance?

Shortest explanation is that each chunk is counted as a distinct object in the code. So when the engine has to draw your ship, its not going "Okay, this is one ship with 4 turrets, thats 5 things to draw", its going "Okay, this ship is 4 turrets at 2 chunks each, thats 8 chunks. The ship itself is 20 chunks, so thats 28 things I need to draw separately and then make them all match up to look like one solid object".

Then each "pass" the engine makes is it doing something to a single chunk. A draw pass to actually put the polygons and textures on the screen, a lighting pass to make them look pretty, etc. So it may be doing say a half dozen different passes per chunk to make it look pretty for us.

Doubling the dimensions of the chunk is letting it do 8x as many blocks per pass, which means it can do the same amount of work in less time, which means higher FPS.

So say it takes 1/10th of a second to do X number of passes to render your ship, it would then be able to do 10 of those passes per second, giving you 10 FPS. Increasing the chunk size means it'll take a little bit longer per pass to render everything, but it will have to do a lot less passes in total, so it might take 0.05 seconds to do all the passes instead of 0.1, meaning you're now getting 20 FPS.

 

[Gonzalo]

Shortest explanation is that each chunk is counted as a distinct object in the code. So when the engine has to draw your ship, its not going "Okay, this is one ship with 4 turrets, thats 5 things to draw", its going "Okay, this ship is 4 turrets at 2 chunks each, thats 8 chunks. The ship itself is 20 chunks, so thats 28 things I need to draw separately and then make them all match up to look like one solid object".

Then each "pass" the engine makes is it doing something to a single chunk. A draw pass to actually put the polygons and textures on the screen, a lighting pass to make them look pretty, etc. So it may be doing say a half dozen different passes per chunk to make it look pretty for us.

Doubling the dimensions of the chunk is letting it do 8x as many blocks per pass, which means it can do the same amount of work in less time, which means higher FPS.

So say it takes 1/10th of a second to do X number of passes to render your ship, it would then be able to do 10 of those passes per second, giving you 10 FPS. Increasing the chunk size means it'll take a little bit longer per pass to render everything, but it will have to do a lot less passes in total, so it might take 0.05 seconds to do all the passes instead of 0.1, meaning you're now getting 20 FPS.

So why not have 1000x1000x1000 chunk sizes?

 

[Edymnion]

So why not have 1000x1000x1000 chunk sizes?

Because the bigger the chunks, the bigger the file size, and the more difficult it is to handle.

Think of it like bringing in bags of groceries. Assume you have a car full of food you just bought, and you can only take one bag into the house at a time. If you have small bags that can only hold 2 items at a time, you're going to spend forever going back and forth to the car, those are small chunks. If you put all the groceries into one bag, its too heavy for you to carry and it takes you forever to drag the bag into the house. But there is a sweet spot where the bag is just the right size to hold lots of stuff at once without getting too heavy.

 

[kiddan]

So why not have 1000x1000x1000 chunk sizes?

Erth Paradine said it quite well in this very thread:

A system of 16x16x16 = 4096 blocks (voxels) per chunk, which consumes 12,288 bytes per chunk (assuming SM still uses 3 byte voxels). On a 10Mbps connection this requires 10.1ms to transfer. For the desktop/GPU, smaller chunks also pose a significant rendering overhead. There's also AABB (e.g. collision) checks: a collision typically interacts with more chunks when they're smaller, and therefore more calculation work is required when there's more/smaller chunks.

Upcoming system using 32x32x32 = 32678 blocks per chunk, consumes 98,034 bytes per chunk. This requires 80.3ms of time to transfer, and should help improve mesh generation for the desktop/GPU, while also reducing the quantity of chunks involved in many types of collisions (therefore making AABB checks less painful).

A jump to 64x64x64 = 262,144 bytes/chunk, requires 214.7ms to transfer...from a server perspective, that's a point of diminishing returns. Primarily because anytime a single block is changed, the entire chunk (+ any colliding/interacting chunks) must be recomputed/resent. That would require a lot of bandwidth, and I assume would introduce too much lag.

 

[Chichus]

Ever since the update, my game became incredibly sluggish and now it is impossible to play. I can't look at an asteroid without the game freezing up, even though before I could run asteroids at a solid 30 fps. Is there a solution to this? Many people on the starmade brierie server are experiencing the same issue too.

 

[nightrune]

Ever since the update, my game became incredibly sluggish and now it is impossible to play. I can't look at an asteroid without the game freezing up, even though before I could run asteroids at a solid 30 fps. Is there a solution to this? Many people on the starmade brierie server are experiencing the same issue too.

Can you post your logs here or start a thread in support and post them there?

 

[Chichus]

Can you post your logs here or start a thread in support and post them there?

yeah, here are my logs:
[doublepost=1470378749,1470378719][/doublepost]

yeah, here are my logs:

it doesnt want to upload the logs
[doublepost=1470378923][/doublepost]ah, okay,finally it worked

 

[Valck]

Ever since the update, my game became incredibly sluggish and now it is impossible to play. I can't look at an asteroid without the game freezing up, even though before I could run asteroids at a solid 30 fps. Is there a solution to this? Many people on the starmade brierie server are experiencing the same issue too.

If you haven't already, try reducing the value of "segments drawn", in graphics options; go low initially and work your way up.
That's what fixed it for me, after schema pointed out that with larger chunks, the same number of chunks (i.e. "segments") drawn means an overall increase in blocks to render.

 

[nightrune]

yeah, here are my logs:
[doublepost=1470378749,1470378719][/doublepost]
it doesnt want to upload the logs
[doublepost=1470378923][/doublepost]ah, okay,finally it worked

I really need to see log.txt.0