This is a new restriction in 2018.2. Was it intentional? Animation curves are used for a lot more then just animation and not being able to use them in jobs kind of sucks. My case I was using it for utility ai and now i have to go back to using a more complex process of exporting the data and using my own evaluate method on it.
Could you give us more info on this?
I looked at the code, and there don’t seem to be any explicit main thread checks in the AnimationCurve.
That said, the AnimationCurve has never been thread safe, as its evaluation uses a cache. If you evaluate the curve on two threads at the same time, you are not going to get the right results
2 Likes
I had to go back to 2018.1 for other reasons but there were two error lines. The first simply said Evaluate can only be called from the main thread. The second one was sort of odd it gave the message I think you get if you try to create a monobehaviour via new.
The code path is a class referenced from a shared dll. Basically there is a ScriptableObject that contains that class, which has a field for an AnimationCurve. The field name is AnimationCurve if that matters at all.
The job was an IJob, only one running at any given time.
That’s fine and no real reason to disbar it from threading accessibility (and not implying you meant that). I did like the extra information though - had no idea it was actually cached. Would be useful to put in manual as well, now jobs are the new normal.
We looked at it a bit more, and this seems to be a side effect of migrating to a new C# to C++ binding system. The new binding code generator seems to be defaulting to non-thread safe by default.
We’re going to force it back to what it was before, because barring non-main thread access just in case is pretty sad. Just be aware that modifying a curve on one thread and accessing it on another is dicey. It’s not limited to evaluation.
2 Likes
If anyone has wants to file a bug with a repro scene, it’s always appeciated.
Yep can totally understand that 
But I am fairly sure the docs team will need to become jobs-aware as people will probably be excited by the whole “oh threading is perfectly safe now” thing and file bug reports on various parts of Unity, but this is just a general Unity problem.
I hit another case where access is being blocked that I wonder if it’s related. It throws an error trying to set keys saying SetKeys can’t be called in serialization callbacks. MapMagic is effected by this, it can’t save/load it’s node editor data.
You can track this issue here:
The fix is on its way to 2018.2
2 Likes
@snacktime I am not 100% certain, but this is probably the same issue. It should affect all methods on animation curve.
@DavidGeoffroy issue tracker indicated that this is fixed in future release. Do you have more specific target version for the fix? Like, is it planned to be fixed in 2018.2 release or later? I still get this on 2018.2.0b8.
Hmm I know they fixed at least part of this as I have a test project with some third party assets that were affected. And in beta 8 they started working. Guessing since the issue didn’t mention all the api’s affected that they missed some stuff?
Could be. Asset affected by this is Particle Playground. It’s already deprecated so the original author is not going to update it anymore, just noticed that it still worked on 2018.1 but fails on 2018.2 with following error message:
Oh, my bad, the part where I get this error is Unity - Scripting API: Gradient.Evaluate instead (I think the AnimationCurve.Evaluate works now as I didn’t get errors from it). Any chance this will be fixed too?
I’ve opened a bug for the gradient. We will get it fixed. Thanks for reporting it!
1 Like
Thank you, the issue tracker for this: Unity Issue Tracker - [Scripting/Particles] Gradient Scripting API thread checks have changed after bindings upgrade.