Brute Force Rectangle:
124ms (0ms build, 124ms find)
AABRectangle:
24ms (12ms build. 12ms find)
Brute Force Circle (Circumscribed of same rectangle)"
67ms (0ms build, 67ms find)
AABCircle:
41ms(19ms build, 22ms find)
All tests are bursted. Rectangle shows more than 5x improvement over brute, in case tree is re-used that would be 10x.
As expected circle is not showing that much of the win compared to brute force, not even 2x. It is mostly, because union and overlap functions more expensive. Also in case you wonder why brute force circle is faster, it just circle and line test is much cheaper.
For version 1.5 plan to add MeshSurface and VertexData for very fast mesh reading/writing/processing.
Plan to release dots mesh slicer that will use dots plus, to also show the advantages of this package.
Here is demo of mesh slicer in dots that is powered by DelaunayTriangulation and upcoming MeshSurface from dots plus. As example full sphere mesh slice takes somewhere 0.1ms on my *machine.
Purchased this package yesterday, and while I still haven’t had a chance to check out absolutely everything, it’s looking great!
I did notice an issue during building though where the struct Node in UnsafeAABBTree.cs has a variable
#if ENABLE_UNITY_COLLECTIONS_CHECKS
public bool IsFree;
#endif
Other places in the script there is logic which uses IsFree without the same wrappers which causes builds to terminate. I just wrapped that other logic with the same preprocessor logic and it worked fine.
Going to make short break on this package to finish my local avoidance new version (In case anyone is interested Local Avoidance 3.0.0 ). Feel free to put requests here or in discord.
I recently played around with fixed point type, basically the same as float just that point is fixed.
The main two advantages of fixed type over float type:
Deterministic as it uses integer types behind the hood. Will be familiar for those who attempted lock step networking model.
There is possibility for some mathematically functions to be faster. For example, sin and cos could use lookup maps on lower precisions (Not confirmed yet).
Made small test with this new type.
// See https://aka.ms/new-console-template for more information
using System.Diagnostics;
using ProjectDawn.Mathematics;
using ProjectDawn.Assertion;
// Int
Assert.AssertEqual(new fixe(5), 5);
Assert.AssertEqual(new fixe(39), 39);
Assert.AssertEqual(new fixe(625), 625);
// Float
Assert.AssertEqual(new fixe(1.5f), 1.5f);
Assert.AssertEqual(new fixe(2.25f), 2.25f);
Assert.AssertEqual(new fixe(0.625f), 0.625f);
// Add
Assert.AssertEqual(new fixe(1.5f) + new fixe(1.25f), 2.75f);
Assert.AssertEqual(new fixe(10.5f) + new fixe(6.5f), 17f);
// Sub
Assert.AssertEqual(new fixe(1.5f) - new fixe(1.25f), 0.25f);
Assert.AssertEqual(new fixe(10.5f) - new fixe(6.5f), 4f);
// Mul
Assert.AssertEqual(new fixe(1.5f) * new fixe(1.25f), 1.875f);
Assert.AssertEqual(new fixe(10.5f) * new fixe(6.5f), 68.25f);
// Div
Assert.AssertEqual(new fixe(1.5f) / new fixe(2f), 0.75f);
Assert.AssertEqual(new fixe(10.5f) / new fixe(4), 2.625f);
// ToString
fixe number = 5.625f;
Console.WriteLine($"number = {number}");
// Mul performance
float[] floats = new float[]
{
0.5f,
1.5f,
2.5f,
0.25f,
1.45f,
};
{
float result = 1;
var sw = new Stopwatch();
sw.Start();
for (int i = 0; i < 200; ++i)
{
result = result * floats[i % floats.Length];
}
sw.Stop();
Console.WriteLine($"Float result:{result} time:{sw.Elapsed.TotalMilliseconds}");
}
{
float result = 1;
var sw = new Stopwatch();
sw.Start();
for (int i = 0; i < 200; ++i)
{
result = result * floats[i % floats.Length];
}
sw.Stop();
Console.WriteLine($"Float result:{result} time:{sw.Elapsed.TotalMilliseconds}");
}
{
fixe[] fixes = new fixe[floats.Length];
for (int i = 0; i < floats.Length; ++i)
fixes[i] = floats[i];
fixe result = 1;
var sw = new Stopwatch();
sw.Start();
for (int i = 0; i < 200; ++i)
{
result = result * fixes[i % fixes.Length];
}
sw.Stop();
Console.WriteLine($"Fixe result:{(float)result} time:{sw.Elapsed.TotalMilliseconds}");
}
Performance is almost same, result differs, because in this test there is only 8bits after the point.
I am curious if anyone would found this useful if it was in the package? Of course, it would also have vectorized variations too, with all same math functions.
100%. I would have purchased the asset just for the fixed math xD and I know us DOTS Devs working on Sanctuary have been curious about exploring fixed math for a while.
I would love to see some more benchmarks – especially inside bursted jobs!
One of the users complained that NativePriorityQueue is quite slow in big data, which is true as it uses linked list behind the hood. For this reason, I created additional NativePriorityQueue that is heap based. Also, added suffix to clarify each queue backend and heap one uses key instead of comparer for simplicity.
struct AscendingOrder : IComparer<int>
{
public int Compare(int x, int y) => x.CompareTo(y);
}
var queue = new NativeLinkedPriorityQueue<int, AscendingOrder>(Allocator.Temp, new AscendingOrder());
queue.Enqueue(2);
queue.Enqueue(1);
Assert.AreEqual(1, queue.Dequeue());
Assert.AreEqual(2, queue.Dequeue());
queue.Dispose();
var queue = new NativeHeapPriorityQueue<int, int>(Allocator.Temp);
queue.Enqueue(2, 2);
queue.Enqueue(1, 1);
Assert.AreEqual(1, queue.Dequeue());
Assert.AreEqual(2, queue.Dequeue());
queue.Dispose();
[1.7.0] - 2022-12-21
Added NativeHeapPriorityQueue that uses heap
Added NativeLinkedPriorityQueue that uses linked list
Deprecated NativePriorityQueue should use now either NativeHeapPriorityQueue or NativeLinkedPriorityQueue
Not really for an use case, but rather it seems that the EntityEditor (plus UI Toolkit binding) is using this? So if left unimplemented, there will be nonstop errors in the console if you click on an entity that has an compdata that’s using Rectangle for example.
