You just got to love the chunk system used on vehicles.

[takethispie]

schema as a Developer myself, your answer is just:

keep the good work, the game is awesome !!

 

[TBterra]

Edit: looks like schema has already replied, this just goes more into how the proposed system would suck at collision detection

Lets take a weapons hit and look at it.
Both systems would determine direction and point of impact. There is no difference there.
The current system would look at what block is there and get its data.
The discussed system is under a much lower load. It has a minor amount of work to do that is one time generate a list of the blocks in the group. It is essentially for or while loop. Then both systems calculate damage against the block and if there is any punch through and if any other blocks are damage. At the end the discussed system would rewrite the blocks storing the new shape.
The difference comes in the discussed system doesn't have millions of continuous checks to do on all the other stuff and other blocks and any issue handling them for movement because it only needs to deal with the much smaller data of the representative model. So it has plenty of time to do those small fast tasks need to expand the data and restore it.

Based on your response I assume you have never made a collision detection algorithm, mostly as you assume that finding the point of collision is trivial, when in fact it can often be the most complex part of the system. ill run you through the basics and how the different systems would have to handle it:

the incoming projectile is modeled for collision purposes as a line from its last position to the position it will end at if it doesn't hit anything.

Initially you will do a line/BB collision test with all entities in the local area. (one check per ship) (same for both algorithms)

If you get a collision then you will need to generate a list of all block locations that the line passes through ordered in the order they are passed through, this is not too hard to do with an adapted line rasterization algorithm. (same for both algorithms)

You then need to traverse the list until you find the first block that is not empty, and that becomes the initial point of impact. This is where the algorithms differ, and its a big diference:

in the current algorithm, if you know what the block location in, then you know what chunk the block in in, you then lookup in the chunk index where that chunk is in memory then you can lookup the block in that chunk, total cost : 3 array lookups regardless of the ships size.

in the proposed system , there is no direct relation between a block position and its groups position in memory, therefore to work out what type the block is, you must traverse the group list until you find a group that contains the block, or reach the end of the list, this could mean traversing a multiple thousand element list. using a R*-tree could cut down the number of checks to about 1+log2(list length) but then you have an extremely complex and memory inefficient data structure.


In short the current data structure is used not because it is memory efficient (3bytes per block,96kbytes per chunk), but because it is fast for the most commonly used operations.

If you wish to continue with your idea I would recommend you test it out before claiming that is better

 

[GRHayes]

The preview window(s) does not/do not use raytracing, It uses openGL, and this was with backface culling enabled, face display set to solid (not rendered, textured, material or x-ray)

Suggest you do some reading! It uses opengl to run the ray tracing in using the shaders to handle the calculations.
In fact it wasn't till rather recent ATI cards could make use of it. Nvidia has been able to do it for some time. That had to do with ATI's drivers sucking.

 

[Crusade]

the 'preview' raycount is strictly for when you have 3d view set to 'rendered' When you DON'T have it set to that, it uses basic openGL rendering, NOT raycasting.

 

[Gasboy]

So Schema answered you, OP.

Also, you missed the hint so I'll say it bluntly.

If you go for maximum efficiency, you risk the catastrohpic destruction of the aux power system.

If you accept a lower efficicency, and make many smaller block areas instead of one giant cube, you can better protect the system.

Your choice.

 

[SmilingDemon]

...
You know what I didn't do a bug report on them. Why because in general I am sick of the attitude around dealing with bugs.
One report was simply deleted. The bug still exists 100% repeatable.
...

No report of any bug was DELETED .. EVER.
are you able to give me a Report number for that bug so that i can look it up, or its Titel?

 

[GRHayes]

Hey, I usually don't do this, but I have to clarify some things.

There are some things assumed in this thread that are simply not true. The chunk system is just one part of the engine and there are a lot of other systems (including group systems) layered for the game to work.

First of all: The chunk system. Why is it a good system and why do 90% of voxel games use some form of it:

• Clear Segmentation of data: A chunk is a clear part of memory. That makes for a lot faster access because you can reference it with static indices in an array. You can make assumptions to it's size and apply several data structures to it for optimization I'll mention below.
• Fast and memory efficient region systems by just indexing empty chunks, and not actually give them any real data.
• Fast referencing of single blocks needed by several physics systems as well as damage and state changing systems like logic.
• It allows for a unit of requesting and sending so that networking can be throttled to not stall.
• It is necessary for drawing, i.e. frustum culling. Else you end up iterating through stuff that is not in camera view. That is one of the biggest pitfalls in draw performance
• Lighting functions can be calculated threaded per chunk, which would be impossible with a group system.
• Fast generation and modification of octrees for rendering and physics.
• Saving and loading can be done per changed chunk.
• Physics: without the chunk system, several optimizations would be impossible. The engine makes use of octrees and Axis sweeps to minimize the problem of comparing millions of cubes to each other in milliseconds.

I'm not entirely sure which alternative is proposed in this thread, but from what I read, it's some kind of grouping system where you would combine equal blocks with equal orientation into groups. If that is the case there would be several game breaking problems with that:

• Logic: activation states change for individual blocks, and it happens often. That would trigger a group change and would need major CPU load to recalculate those groups.
• Ship battles: Again, groups are only changing when blocks are added/removed. In ship battles that happens thousands of times of a longer time period. Keep in mind that a damaged block already counts as a changed state and would invoke a group update.
• Building Style / Generation / Ship Battles: A grouping system's advantage would depend on a player's style to build. It would be strongest when doing big boxes of the same blocks. While some players do that for their system, others prefer other shapes rendering a possible grouping system slower and more convoluted. Worst case would be small system blocks of a few cubes that would be speckled across a ship. Ship battles will generate these kind of worst cases very very quickly. And using a group system would also affect the generation, because it too can generate worst case patterns.
• Comparing the rendering system to an engine that doesn't have complete editable voxels is a fallacy. Add back all the thousands of light sources of a ship into such an engine and then we will see how well that performs. The lighting is stored in the vertices and if you actually removed the vertices for rendering all lighting information in the vertices is lost. It can be solved by deferred lighting but that also has a limit of 50-100 lights which isn't enough. Deferred lighting will be added on top of the current rendering system for the closest lights to the camera in the future

If you can convince me of a better alternative that would have major performance boosts, I will use it no doubt. But I can tell you already, that it will be hard since you would probably need to know all requirements that are needed to process the game, and that is kind of impossible without looking at the code. There are a lot of things at work in this game you wouldn't assume are necessary, and all of this has to work for several situations.

But now to what it seems is being talked about: Connections (C+V) and Logic:

First of all, if a chunk isn't drawn because some kind of bug it doesn't mean it isn't loaded. It could be loaded on server and still function perfectly fine. It could be that just the lighting engine had problems processing it, so it would be on client as well as server. It's im possible for me to tell without looking at the ship itself reproducing the error.

Now, it is assumed that connections are tied into the chunk system. That is actually NOT the case. Connections is a separate data structure which actually uses a grouping system in some respect! Reason being, because it makes sense here, since there is only one state per connected block.
Logic not working can have different causes, but I'm working on improving it. I could just wait for all connected blocks to be loaded. Then you have the same effect as any other system which would ensure logic to fully work. The grouping also comes in handy when sending the C+V data to clients. The grouping system here also has several modes to minimize any worst case by also for example being able identify lots of long "sticks" and optimizing for those. There can still be some things done to decrease their size in memory, but they actually don't consume almost any processing power as is.

There is also a misconception on how power/weapons/shield/etc works. Believe it or not, but this system ALSO uses a group system. The nice thing about this system is that it can have any algorithm for calculating data. The most common one is just detecting touching groups, there are complex ones that have several requirements like shipyard, but there are also simple ones that just count the connected blocks, which goes extremely fast obviously.

It also only changes when a block gets added/removed. The process is being done by multiple threads, so you hardly notice it. It can still be notices when two capital ships with huge blocks of systems destroy each other for the reason I mentioned above on why I use the chunk
system for the "basic" data of blocks.

Basically when you add or remove a system block that has any meta-value like power, an update is scheduled for the worker threads to pick up. Then the groups for the power system are changed according to that. The only thing that could be done to speed that up in the beginning is to actually flat save those groups, and load them as is, instead of doing a full reconstruction of all groups at load time.

The downside would be larger file size, and problems when unloading/saving a ship that still has ongoing threads that would have to finish first (but that's solvable). The real reason why I don't do that already is because I want the base system to be as fast as efficient as possible, so I kind of want it to do a lot to identify bottlenecks, and over the years I found plenty and made the systems at least a thousand times faster already. These problems wouldn't be obvious if I would save and load it.

There is no "iteration over every block" per tick when processing any system. After having the groups the system just accumulates and calculates all the values like power, powercap, shield-regen, weapon power, combinations, etc. These values are then used for the updates per tick making the time taken for it O(1) or in other terms, constant!
Iterating over each block of a system per frame would be insane and end up in a slideshow with not even one frame per second, so I'm not sure why anyone that played the game would assume that I would do that...

The bugs of this system are still present when sometimes a signal gets fired while these groups are still in the process for first generating, it is possible for it to be "eaten". This was the case for the rail speed controller for example, where even if you put a rail to 0 speed, loading the structure up would move the docked ship that was placed on that 0 speed rail. This is because when checking for that rail's speed, the attached group would not be done calculating and report that the rail actually had speed (the default). This bug is however solved in the last version by just waiting for the group before making any decision.

There may still be similar bugs left, but those are solvable in the same way.

By they way, the reasons why planets are currently loaded slow is because of some missing optimizations on it, but I can't get into detail too much about it, because that would reveal too much about planned stuff in progress.

The reason why shift+v looks like it does is purely to calculate the touching blocks, and it is done on client. It has no impact whatsoever on how the game works.

If you have a bug, please report it. I'm not sure why your previous report was deleted, but usually there is a reason behind it.




I hope this clears up things a little bit.

First, Schema Not trying to rag on your work. And thank you for the effort and replying.

Second you have a few misconception about what is proposed or more how it works.
Of those voxel based game very few use a chunk system on vehicles. I only seen a minecraft mod besides this game that uses voxels on a moving object. From what I remember space engineers uses chunks on astroids and planets but not the ships.

I doubt you will say that star citizen graphics or games with such graphic are that terrible in performance. They manage to handle dealing with off screen displays and so on using BSP trees and so on. I pose that question because what I am suggesting is to basically turn the ship into such a structure.

As for different states and damage. If a group is hit which is easy to determine no different than what you do now to tell if a block is hit. Then you determine which block position is hit and run your damage calculations as you do now. Then run an oct-tree and or BSP tree and divide the orignal group into new groups. Very much like LOD. You put different state blocks into a different group.

Have you looked at realtime simulation for particle physics? They don't run a chunk system even when handling made structures.
The complexity of what they are looking at can be vastly more complex than the structures we see in this game.

I do realize you use groups and how.
In fact if you look above I put a number of images showing the group count changing simply because I moved or changed view angle.
That tells me it is reevaluating the group even though it has had no reason to change. My view and position angle should have no bearing on what is in a group.

You also bring up another point. When it comes to power you are saving meta data per block. Consider that the amount of power generated by a group is determined by the number of blocks connect and so on. So why save per block the amount a block makes a second is determined after the calculation. So simply save the group values. It only needs to be recalculated as you said when it changes. Thus who cares what the individual blocks create because in truth that is determined by the group. That would save on storing all that meta data as well.

The issue with Shift-V was an issue after it had finished calculating.
I hit shift-V the group calculated the number of missile tubes in group and that was visible in the groups menu.
Then I moved forward about 1 meter. Opened the menu again and it changed. I then turned at it changed again.
So I tested it over several times. Created the group. checked it and it showed right.Waited then checked again. Still fine.
Moved or changed angle and it changed. Fired missile and that caused it to change. Of course that could be because switching to the flight view itself initiated the recalculation.

My suggested system is just that. There are other systems out there.
There are a number of ways of getting more complex voxel structures displayed here are a few things you might look into. Some of these are in a way related to each other. Euclideon supposedly use a point cloud search routine.
Atomontage Engine
Atomontage Engine - Dev Blog
Atomontage Engine - Photos | Facebook
Euclideon by unlimited detail
Euclideon - Wikipedia, the free encyclopedia
SVO (Sparse Voxel Octree)
Point clouds
https://www.hds.utc.fr/~vfremont/fichiers_pdf/pub_IEEE_CCIS04.pdf
http://www.cs.ubc.ca/~lowe/papers/brown05.pdf
Pointcloud software that creates point clouds to create 3D models from 2D photos.
insight3d - opensource image based 3d modeling software

 

[StormWing0]

Well this is going to end badly Programming Cat God vs a person that only accepts their own reality.

 

[GRHayes]

Edit: looks like schema has already replied, this just goes more into how the proposed system would suck at collision detection



Based on your response I assume you have never made a collision detection algorithm, mostly as you assume that finding the point of collision is trivial, when in fact it can often be the most complex part of the system. ill run you through the basics and how the different systems would have to handle it:

the incoming projectile is modeled for collision purposes as a line from its last position to the position it will end at if it doesn't hit anything.

Initially you will do a line/BB collision test with all entities in the local area. (one check per ship) (same for both algorithms)

If you get a collision then you will need to generate a list of all block locations that the line passes through ordered in the order they are passed through, this is not too hard to do with an adapted line rasterization algorithm. (same for both algorithms)

You then need to traverse the list until you find the first block that is not empty, and that becomes the initial point of impact. This is where the algorithms differ, and its a big diference:

in the current algorithm, if you know what the block location in, then you know what chunk the block in in, you then lookup in the chunk index where that chunk is in memory then you can lookup the block in that chunk, total cost : 3 array lookups regardless of the ships size.

in the proposed system , there is no direct relation between a block position and its groups position in memory, therefore to work out what type the block is, you must traverse the group list until you find a group that contains the block, or reach the end of the list, this could mean traversing a multiple thousand element list. using a R*-tree could cut down the number of checks to about 1+log2(list length) but then you have an extremely complex and memory inefficient data structure.


In short the current data structure is used not because it is memory efficient (3bytes per block,96kbytes per chunk), but because it is fast for the most commonly used operations.

If you wish to continue with your idea I would recommend you test it out before claiming that is better

I wrote my first collision detection system in 1986. I was in 11th grade and it ran on an atari 800xl. It was a very basic living room setup the user could move around and view the room from different positions. It was all of 4 colors and dogged slow. But it worked.
The fact you think it is difficult says something about you not me.
[doublepost=1474555097,1474554669][/doublepost]

No report of any bug was DELETED .. EVER.
are you able to give me a Report number for that bug so that i can look it up, or its Titel?

Fine Find the report from GRHayes that has this in it. Because it was there for several days. I even wrote a message and got a reply from an admin on that I hadn't seen any activity on it.
After that it was gone. I figure once I hand it over its there problem. So any emails coming in on it are auto deleted. I have far to many other ones I have to deal with. The reason I know it was there a couple days is because I filed those pictures as an update to it.
Either way not my problem any more.

 

[schema]

>I doubt you will say that star citizen graphics or games with such graphic are that terrible in performance. They manage to handle dealing with off screen displays and so on using BSP trees and so on. I pose that question because what I am suggesting is to basically turn the ship into such a structure.

That's because they don't have fully voxel editable terrain/structures. You can do so much optimization with things that have a fixed shape or a limited amount of mutations. Voxel games do not have a lot of these options, because there is and there will be a worst case. They use deferred rendering/lighting which is nice for a limited amount of lights. But for example you can't just place 1000 light sources on your ship in games like these. It's a different game with different requirements.



>Then you determine which block position is hit and run your damage calculations as you do now. Then run an oct-tree and or BSP tree and divide the orignal group into new groups. Very much like LOD. You put different state blocks into a different group.

But what would be the gain of that system except saving on memory in only the best case scenario? You would have to do extra calculations for every single block operation, instead of like it is now, which is not having to do them.
I can do raycasting in O (linear time) already, with grouping that would introduce extra steps to determine the result. The goal of having values by group is already implemented and fully in use. The chunk system is just the block data structure. The power values etc are actually stored and calculated by group.



>In fact if you look above I put a number of images showing the group count changing simply because I moved or changed view angle.
That tells me it is reevaluating the group even though it has had no reason to change. My view and position angle should have no bearing on what is in a group.

I have no idea what brought you to think that is how the game works. The view of the client has absolutely NO impact on grouping whatsoever. Why would you believe I would do such a thing? Your view and position angle doesn't have any bearing on what is in the group. It never has and never will have. I couldn't even do that if I wanted without making huge changes to do that (but why would I).



>When it comes to power you are saving meta data per block. Consider that the amount of power generated by a group is determined by the number of blocks connect and so on.

I did not say this, and that also isn't the case. I do not save any metadata per block unless it is absolutely necessary, i.e. for inventories. Power is calculated per group. Power blocks, weapons, shields, etc do not have any meta data saved with or in memory whatsoever. Only groups of them do.


>The issue with Shift-V was an issue after it had finished calculating.
>I hit shift-V the group calculated the number of missile tubes in group and that was visible in the groups menu.
>Then I moved forward about 1 meter. Opened the menu again and it changed. I then turned at it changed again.

What you saw is not how the game works. On shift+V the client does a distributed check that runs threaded to not stall the client (it was done at once before causing the client to freeze).
That means that the client is doing connection requests of thousands of blocks distributed over time. Now to prevent servers from receiving huge data from clients in a short amount of time, my netcode subdivides requests so they are sent in smaller chunks over time. This has the effect that unfinished group (part of the huge cube you want to connect) is calculated until it stops changing.

This means that even if you see it finish graphically (which is also hard to see on a big cube since it will reach the closest 3 faces sooner than the opposite vertex) it doesn't mean that the calculations finished, since they are running in the background.

In no way is a finished group changing without actually adding/removing a block from that group.


Yes there are other attempts of using voxels, but none of them have yet produced a fully playable game. There are advantages and disadvantages to each, and for me, using a chunk based system fits best to what the requirements are for this game.

 

[GRHayes]

So Schema answered you, OP.

Also, you missed the hint so I'll say it bluntly.

If you go for maximum efficiency, you risk the catastrohpic destruction of the aux power system.

If you accept a lower efficicency, and make many smaller block areas instead of one giant cube, you can better protect the system.

Your choice.

In theory it is partially true. In practice I think you will find it is less effective than you think.
Consider you are going to need to make many more of those things to get an equal amount of power. That will mean a much larger block count increase thus a far greater chance of being hit. It also means a larger portion of your ship will be converted to Aux power. Than using the efficient system.

Think of it this way a 9900 group produces 1910060.1 power you can fit that in a block 20x20x25 effectively. granted that is actually 10,000 That gives you two side 20x20 and 4 sides 20x25 800+2000=2800 surface area.

However if you use 1000 block groups (38715.6)instead to make the same power it will take 49 such groups. that is 49,000 blocks. The least amount of surface area would be 49*600 = 29,400 which is a far larger area to hit than 2800.

That said it does provide some benefits. Being broken into groups like that means it won't all fail at once.
A down side is a greater portion of the structure is volatile.
Another down side is that it will require more blocks of free space around such groups to protect your other ship structures and other groups.
You will be using more than 5.4 times the space just in block plus all the added space around each group. The size of explosion from a 1000 group vs a 9000 group is only about 1 block radial difference. So instead of needing 4 blocks clearance you will need 3.

if you go to 3000 block groups it will take 8 of those. 4000 will take 4.7, 5000 will take 3 groups, 6000 will take 2.2

If you are talking about protecting smaller groups with armor it will take much more because the surface area is that much greater.

So the only real way going smaller works is if you intend to actually give up power and not achieve the same amount of power.

 

[Captain_Stripes]

>I doubt you will say that star citizen graphics or games with such graphic are that terrible in performance. They manage to handle dealing with off screen displays and so on using BSP trees and so on. I pose that question because what I am suggesting is to basically turn the ship into such a structure.

That's because they don't have fully voxel editable terrain/structures. You can do so much optimization with things that have a fixed shape or a limited amount of mutations. Voxel games do not have a lot of these options, because there is and there will be a worst case. They use deferred rendering/lighting which is nice for a limited amount of lights. But for example you can't just place 1000 light sources on your ship in games like these. It's a different game with different requirements.



>Then you determine which block position is hit and run your damage calculations as you do now. Then run an oct-tree and or BSP tree and divide the orignal group into new groups. Very much like LOD. You put different state blocks into a different group.

But what would be the gain of that system except saving on memory in only the best case scenario? You would have to do extra calculations for every single block operation, instead of like it is now, which is not having to do them.
I can do raycasting in O (linear time) already, with grouping that would introduce extra steps to determine the result. The goal of having values by group is already implemented and fully in use. The chunk system is just the block data structure. The power values etc are actually stored and calculated by group.



>In fact if you look above I put a number of images showing the group count changing simply because I moved or changed view angle.
That tells me it is reevaluating the group even though it has had no reason to change. My view and position angle should have no bearing on what is in a group.

I have no idea what brought you to think that is how the game works. The view of the client has absolutely NO impact on grouping whatsoever. Why would you believe I would do such a thing? Your view and position angle doesn't have any bearing on what is in the group. It never has and never will have. I couldn't even do that if I wanted without making huge changes to do that (but why would I).



>When it comes to power you are saving meta data per block. Consider that the amount of power generated by a group is determined by the number of blocks connect and so on.

I did not say this, and that also isn't the case. I do not save any metadata per block unless it is absolutely necessary, i.e. for inventories. Power is calculated per group. Power blocks, weapons, shields, etc do not have any meta data saved with or in memory whatsoever. Only groups of them do.


>The issue with Shift-V was an issue after it had finished calculating.
>I hit shift-V the group calculated the number of missile tubes in group and that was visible in the groups menu.
>Then I moved forward about 1 meter. Opened the menu again and it changed. I then turned at it changed again.

What you saw is not how the game works. On shift+V the client does a distributed check that runs threaded to not stall the client (it was done at once before causing the client to freeze).
That means that the client is doing connection requests of thousands of blocks distributed over time. Now to prevent servers from receiving huge data from clients in a short amount of time, my netcode subdivides requests so they are sent in smaller chunks over time. This has the effect that unfinished group (part of the huge cube you want to connect) is calculated until it stops changing.

This means that even if you see it finish graphically (which is also hard to see on a big cube since it will reach the closest 3 faces sooner than the opposite vertex) it doesn't mean that the calculations finished, since they are running in the background.

In no way is a finished group changing without actually adding/removing a block from that group.


Yes there are other attempts of using voxels, but none of them have yet produced a fully playable game. There are advantages and disadvantages to each, and for me, using a chunk based system fits best to what the requirements are for this game.

 

[Gasboy]

So the only real way going smaller works is if you intend to actually give up power and not achieve the same amount of power.

If you accept a lower efficiency, and make many smaller block areas instead of one giant cube, you can better protect the system.

Pretty much what I said. Thanks for agreeing with me.

 

[GRHayes]

>I doubt you will say that star citizen graphics or games with such graphic are that terrible in performance. They manage to handle dealing with off screen displays and so on using BSP trees and so on. I pose that question because what I am suggesting is to basically turn the ship into such a structure.

That's because they don't have fully voxel editable terrain/structures. You can do so much optimization with things that have a fixed shape or a limited amount of mutations. Voxel games do not have a lot of these options, because there is and there will be a worst case. They use deferred rendering/lighting which is nice for a limited amount of lights. But for example you can't just place 1000 light sources on your ship in games like these. It's a different game with different requirements.



>Then you determine which block position is hit and run your damage calculations as you do now. Then run an oct-tree and or BSP tree and divide the orignal group into new groups. Very much like LOD. You put different state blocks into a different group.

But what would be the gain of that system except saving on memory in only the best case scenario? You would have to do extra calculations for every single block operation, instead of like it is now, which is not having to do them.
I can do raycasting in O (linear time) already, with grouping that would introduce extra steps to determine the result. The goal of having values by group is already implemented and fully in use. The chunk system is just the block data structure. The power values etc are actually stored and calculated by group.



>In fact if you look above I put a number of images showing the group count changing simply because I moved or changed view angle.
That tells me it is reevaluating the group even though it has had no reason to change. My view and position angle should have no bearing on what is in a group.

I have no idea what brought you to think that is how the game works. The view of the client has absolutely NO impact on grouping whatsoever. Why would you believe I would do such a thing? Your view and position angle doesn't have any bearing on what is in the group. It never has and never will have. I couldn't even do that if I wanted without making huge changes to do that (but why would I).



>When it comes to power you are saving meta data per block. Consider that the amount of power generated by a group is determined by the number of blocks connect and so on.

I did not say this, and that also isn't the case. I do not save any metadata per block unless it is absolutely necessary, i.e. for inventories. Power is calculated per group. Power blocks, weapons, shields, etc do not have any meta data saved with or in memory whatsoever. Only groups of them do.


>The issue with Shift-V was an issue after it had finished calculating.
>I hit shift-V the group calculated the number of missile tubes in group and that was visible in the groups menu.
>Then I moved forward about 1 meter. Opened the menu again and it changed. I then turned at it changed again.

What you saw is not how the game works. On shift+V the client does a distributed check that runs threaded to not stall the client (it was done at once before causing the client to freeze).
That means that the client is doing connection requests of thousands of blocks distributed over time. Now to prevent servers from receiving huge data from clients in a short amount of time, my netcode subdivides requests so they are sent in smaller chunks over time. This has the effect that unfinished group (part of the huge cube you want to connect) is calculated until it stops changing.

This means that even if you see it finish graphically (which is also hard to see on a big cube since it will reach the closest 3 faces sooner than the opposite vertex) it doesn't mean that the calculations finished, since they are running in the background.

In no way is a finished group changing without actually adding/removing a block from that group.


Yes there are other attempts of using voxels, but none of them have yet produced a fully playable game. There are advantages and disadvantages to each, and for me, using a chunk based system fits best to what the requirements are for this game.

If you look at the images you can read the group block count.
You can read it yourself in the image block count starts at 76,800 then drops to 73673 then 28380 and finally 21555.
That 76800 as I said was stable for over 30 seconds. 76,800 is also the right block count.
There is no one else on the server and the only events what-so-ever that happens around that ship is me moving. No re-clicking of Control V or anything of the sort.
Lets say it wasn't me moving as you said. Why would the block count be stable then change and go down? I could understand it going up as more chunks are calculated in and it is laggy(which it isn't). But that isn't the case it is going down?
Lets also assume you are right on the aspect that the system must have not been finished totaling the blocks.
For that matter why would it go down at all even if the group wasn't done accumulating it should be going up not down?
And why when it clearly reached the correct value would it change at all?
The pictures are in order and clearly show it does go down from the correct value. I would offer to video tape it but as of this comment I removed the game.


Best case scenario.
Consider this a chunk based voxel system as the maximum data store system ignoring the potential of using compression because so can any other system.
If the chunk system is the max then a system that starts of at a minimal data storage requirement and only adds to it as things change such as states of blocks and damage it will never reach the memory requirements of the chunk system because before that can happen the ship will no longer exist.
That said someone could intentionally build a ship that makes this bad. They would need to very simply not put similar or related blocks close together. think alternating checkerboard. the system could create runs of the blocks and would be making a group for each individual block.
How many ships do you see built that way?

What other gains. Well if it was me I would be transferring only the representation of the ship to clients. The server should be doing the hit calculations and damage. The ships 3d model representation with this is vastly smaller. Transferring and updating sections of it would be much smaller to send over a network.
Are you having clients also runs stuff like power calculations and so on or missile damage?
If not why do they need to know every single block of the ship?
If you are again why? Why not make that the servers task and just provide the representation of the ship to be displayed?
The only thing the client needs to really know when damage happens is where the explosion should be renedered. What blocks need to be replaced with damage blocks and which blocks are broke blocks and where to generate particles and what geometry to replace with what. That should be coming from the server.

 

[AndyP]

Just checked something:


(All Reports our bug tracker knows that you authored)

One has been worked on and fixed.
One is waiting on being fixed.
One was rejected as it was a valid report, but a cross influence of two other bugs that got fixed while investigating the details.

The one T1822 is there and still "hidden from public" as we had no time yet to review it.
The report contains a lot of infomation that needs to be sorted first to find out what may have cause it. (Its basically the lost weapons issue described here)

Is there any report missing you sent?
Its in theory impossible, but IF someone messed up view permissions on processing it, it would be possible to make a report visible to only the author, or one person. If you remember a title/topic in it, and a rough estimate when you reported it, I can check the database directly if this was the case. (But its unlikely as I do this from time to time to see if all is in shape.)

- Andy

[EDIT]

While reading the description that the number was correct and then decreases looks like a sync issue.
Like your client cache is seeing and calculating the blocks, but the server then reverts them.
However this should not happen more than once.
I'll make sure someone checks the report.
(I'll do that myself tomorrow after work.)
Validated and Picked up T1822 now.

[/EDIT]

 

[GRHayes]

Pretty much what I said. Thanks for agreeing with me.

I generally design power systems around what I want the ships performance an weapons to work to.
So if I need 4 million power in a ship. I would use the 2 million on the primary power system then add 2 million of he aux system.

If I need that 2 million going to a smaller group size actually makes it much more dangerous. Because will require a much larger number of blocks and create a much larger surface area that can be hit.

What you just effectively said was I have a ship that is designed for 4 million power but I should run it with only 3 million because the Aux power is to dangerous.

If you are going to say that well then we should just cut the aux system out entirely because that would be safer still. I mean if we aren't going to run our ship with the required power that it needs why run it at all?

 

[schema]

>If you look at the images you can read the group block count.
You can read it yourself in the image block count starts at 76,800 then drops to 73673 then 28380 and finally 21555.
That 76800 as I said was stable for over 30 seconds. 76,800 is also the right block count.
There is no one else on the server and the only events what-so-ever that happens around that ship is me moving. No re-clicking of Control V or anything of the sort.

This is still not how the game works. You can try it in singleplayer which eliminates network lag and it will always almost instantly display the right amount. I know my code, and I know that there is not even a connection between the camera or player position with that system. It's code wise not even close to each other. What you have seen is either client bug (which i couldn't reproduce with 125000 missile tubes), or it is still catching up from that huge amount of data. Keep in mind that you are sending requests AND getting back answers from the server client finishing doesn't mean the server finished.

Do you actually think I would lie about my own code? I can give you a version where you can watch the server reporting it's collection processing if you don't believe me. I have no reason to lie about this, because what you are saying is happening would actually take more work to implement, because as said, there is no such system in place to even remotely touch that number from the view system, as it should be.


>Well if it was me I would be transferring only the representation of the ship to clients. The server should be doing the hit calculations and damage. The ships 3d model representation with this is vastly smaller. Transferring and updating sections of it would be much smaller to send over a network.

Because you can actually compress chunks very well. And the worst case is is reached a lot faster than you think in a battle. Since damaged block pretty much counts as a different block that cannot belong to the same group.


>Are you having clients also runs stuff like power calculations and so on or missile damage?

Any damage is actually done server side ONLY and then sent to relevant clients. The raytracing is done on the client too, so beams etc will actually stop when you hit something and display damage, do appropriate effects, etc obviously, as it#s done with pretty much any multiplayer game.
Physics is also done on client and server. Doing that server side only would be horrible. Any movement would be completely lag/RTT dependent.

Power calculations are cheap because the groups calculation gives me single values for ships. No block is being looked at when doing the per update power calculation. With network sending a bunch of floating point values per update would be incredibly bad. The worst bottleneck for bandwidth are positional data, which is just 9 floats sent when a ship moves. It is a big advantage to have the same group representation on clients because of not only debugging but also future features like system scanning.


>If not why do they need to know every single block of the ship?

For physics, for rendering, for other calculations. Not only that, but the client actually needs to check blocks for their state a lot of times before sending out requests. And the connection info has to be there anyways. Sending Chunks is not equal to sending every single block individually. That's because they are compressed, and they compress very well, and in a sense it's no different than putting the blocks into a data structure that groups them. The size on average isn't much different as I actually did some tests on it in the past.


So if the data sent to the client is as big, the only difference again is its representation in memory vs performance loss through doing grouping when referencing blocks. Block writing is completely on the server already.

I still don't see a gain in your system, except being smaller in memory in best case.

• No real physics gain since the outer surface of ships is rarely a rectangle made of the same cubes. It would lose an optimization by not being able to do a faster low level calculation on cube v cube.
• No render gain since light information would be lost.
• Referencing performance if any block is referenced.
• Need to do a full group change operation on every single block change, be it damage, activation state, or adding/removing.

[doublepost=1474564270,1474563825][/doublepost]I'm uploading a version to dev (0.199.226) in which you can enable the server.cfg option DISPLAY_GROUPING_DEBUG_INFORMATION.
This will display the server group calculation when they are scheduled and when they finished executing. In singleplayer it will also do the same for the client
[doublepost=1474564409][/doublepost]

[EDIT]

While reading the description that the number was correct and then decreases looks like a sync issue.
Like your client cache is seeing and calculating the blocks, but the server then reverts them.
However this should not happen more than once.
I'll make sure someone checks the report.
(I'll do that myself tomorrow after work.)
Validated and Picked up T1822 now.

[/EDIT]

As i assumed it appears to be a client display bug

 

[StormWing0]

GRHayes it's quite obvious you have this "My Way or the Highway" thing going on and Schema has given you the correct information twice. It seems you won't change your ways and won't stop until he agrees with you like some mindless pet. So how about we end this and lock this topic so this nonsense doesn't continue further?

 

[SmilingDemon]

... So any emails coming in on it are auto deleted. I have far to many other ones I have to deal with. ...

i will keep that in mind.
have a nice day.

 

[FlyingDebris]

Quit pissing off the cat, Hayes.