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: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.
Suggest you do some reading! It uses opengl to run the ray tracing in using the shaders to handle the calculations.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)
No report of any bug was DELETED .. EVER....
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.
...
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:
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:
- 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.
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.
- 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
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.
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.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
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.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?
In theory it is partially true. In practice I think you will find it is less effective than you think.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.
>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.
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.
Pretty much what I said. Thanks for agreeing with me.If you accept a lower efficiency, and make many smaller block areas instead of one giant cube, you can better protect the system.
If you look at the images you can read the group block count.>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.
I generally design power systems around what I want the ships performance an weapons to work to.Pretty much what I said. Thanks for agreeing with me.
As i assumed it appears to be a client display bug[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]
i will keep that in mind.... So any emails coming in on it are auto deleted. I have far to many other ones I have to deal with. ...