NativeSpline and Burst

[marsh jolt]

For anyone who has ever used the Spline package, there is a NativeSpline struct implementation included which allows you to use Burst compiled code to perform many operations on a Spline.

However, it seems creating a NativeSpline from bursted code is not supported for some reason, as the constructor requires a struct that implements the IReadOnlyList interface. This apparently causes boxing to occur and the Burst compiler is unable to deal with that.

Outside of editing NativeSpline to just accept a plain old NativeArray as a parameter instead, is there anyway to get an IReadOnlyList to not cause boxing?

[fleet turret]

interfaces are objects so no, i'm not familiar with the code of nativespline but there might be other ways around this

[marsh jolt]

Here's the full source of the file, to my eyes it appears not

https://pastebin.com/NJRMDdYq

[fleet turret]

you could do this without a fork

public struct NativeSplineCopy
{
    public NativeArray<BezierKnot> m_Knots;
    public NativeArray<BezierCurve> m_Curves;
    public NativeArray<DistanceToInterpolation> m_SegmentLengthsLookupTable;
    public NativeArray<float3> m_UpVectorsLookupTable;
    public bool m_Closed;
    public float m_Length;
}

var copy = new NativeSplineCopy() 
{
    m_Knots = blah,
    m_Curves = blah1,
    ...
};

// ref not really required here just habit
ref NativeSpline nativeSpline = ref UnsafeUtility.As<NativeSplineCopy, NativeSpline>(ref copy);```

just make a memory copy of the struct, write your own data, reinterpret to the actual NativeSpline

[marsh jolt]

ah, if the variables are the same order you can just do that, huh?

[fleet turret]

yes

memory layout just needs to match

[marsh jolt]

very clever, thanks

the bad news is, I think supplying the Knots is easy, but the other arrays are generated with internal code to NativeSpline in its big ole constructor

[quartz fox]

Just copy what the constructor is doing then

[marsh jolt]

yeah, it's just a little closer to having a fork, but I guess it's still not one

[quartz fox]

It's annoying but thats what you have to do to work within the limits of burst.

[fleet turret]

oh yeah i was going to suggest you implement the constructor as well

the point here is just not to have to fork

(this all said, super annoying they don't have a native array constructor...)

[marsh jolt]

yeah, I don't know why they went with an IReadOnlyList when they just turn it into a NativeArray inside

[amber perch]

with the office hours, id say this is a good time to ask

[marsh jolt]

Dang it, the BezierKnot struct is also using two interfaces, which is making it incompatible with Burst also

ISerializationCallbackReceiver, IEquatable<BezierKnot>

[stiff haven]

I have a bunch of structs implement at least IEquatable<T> since it's a requirement for TKey of NativeHashMap. Implementing interfaces doesn't make a struct incompatible with Burst.

However I notice that NativeSlice requires additional corrections before it is usable with Burst. Aside from issue with constructors as you've already mentioned. The GetEnumerator method must return a struct, not an interface. The nested type Slice<T> must also be corrected.

[stiff haven]

I think you should have a fork, but in the meantime you should file a bug report so they might be aware of the problem. Discord and forum might just be secondary channels when it comes to other packages not within the reach of DOTS team.

[marsh jolt]

I ended up making copies of BezierKnot and BezierCurve too and it seemed to work after that

[marsh jolt]

Nevermind, I didn't even have to make copies of BezierKnot and BezierCurve, I just thought I did because I stupidly declared my NativeSplineCopy as a class instead of a struct, lol