[WIP] Hovercrafts Sandbox Prototype (Postponed)

[Antypodish]

This is rather slower peace moving progress. But never the less progress.

Flood Algorithm WIP

I have revised few flood algorithm options.
The easiest near straight forward, as I already mentioned, is for 1x1x1 cubes.
Where getting neighbors is dead easy, with simple index offset.

I have discussed topic briefly in
** 3D flood mothods for variate 3D box sizes. Thoughts? **

That usually requires however, some predefined grid size (flood 2D example)

A* search algorithm

However, I expect that each row, column, depth lengths are of dynamic sizes and can change anytime, when construction changes. Plus, the fact, I am focusing on multidimensional scaled block sizes. Not 1x1x1 only, but 3x2x1, 2x7x4 etc. Which complicates the matter of such.

For simplicity, 2D representation of multidimensional blocks scales

But anyway, after hours of tinkering and testing, I got this working eventually.
Still got some bugs to resolve, but is getting nice I think. Not yet ready to showoff. But I will when ready

The other alternative I was considering, was to create chunks of 10x10x10, of 1000 1x1x1 cubic possible allocations, and then expand structure, by adding chunks accordingly. Or remove. This solution seams suitable as well, for many applications, where constructs are not too big. I may in fact, consider make such functionality at some point.
However, This works specially, for small cubes (boxes). Now if I consider for example structure, of lets say 100 blocks of 50x5x3, that is 100 x 750 = 75 000 required 1x1x1 cubic allocations in a grid. Which can easily reach 100k or more, with empty allocated spaces. With additional data, that may be few times bigger. If I run flood algorithm through that, that whole structures, that is at minimum 75k iterations. With my approach, I can reduce to few thousands, with side checks etc. So I hope, reduce memory and CPU use, specially for bigger constructs, of mixed sizes blocks.

However, I am aware, that for smaller constructs, typical 1x1x1 grid type with chunks, may be more convenient, or even more performant. Future test will show however, where through lies indeed.

Further on, I got splitting of construct partially working. Mainly much of debugging is to do now.
So for example I split, by removing diagonally all blocks, and smaller part of construct is discarded.

Barriers revision

I have revised Barriers along systems, “collapsing” into one. I had multiple, along systems.
Also, I removed EntityCommandBuffer SetComponent in most system that were still present and replaced with GetComponentFromEntity, or GetBufferFromEntity accordingly.
Plus other improvements.
But further, I want finally to rid off of last barrier injection, and replace with its none injection counterpart.

While this hasn’t been commented yet by Unity officials, since November 2018

@""

May I ask Unity devs (i.e. @Joachim_Ante_1 ) for comment upon that matter?

Is it best to stick with injection for now, or any of above proposed solutions are more appropriate?

I believe, I will follow @terlte comment

@""

        protected override void OnCreateManager()
        {
                this.barrier = this.World.GetOrCreateManager<EndFrameBarrier>();

        protected override JobHandle OnUpdate(JobHandle handle)
        {
                // queue jobs
                handle = default(Job).Schedule(this, handle);
                this.barrier.AddJobHandleForProducer(handle); // pass final handle to barrier to ensure dependency completion
                return handle;
        }

Which is inittially discussed in first quatation
Two questions about Barriers and EntityCommandBuffer

Other

Other than that, I have posted about my experience, when I did fall into a trap of floating point.
** Me falling into floating point error trap. **