Other [0.9.4] Latios Framework for ECS megathread

What would be the purpose of the int parameter in this case? The reason AnimationClipEvent in DMotion has it is to connect it to a SkeletonClipSetBlob, but if events were a BlobArray inside SkeletonClip, this wouldn't be necessary.

For the name, 64 bytes seems pretty good to me.

For context, this is DMotion that @DreamingImLatios mentioned: https://github.com/gamedev-pro/dmotion-runtime

The system has a plug and play animation State Machine, but if you are only interested in the events you can take a look at how they are implemented by reading

RaiseAnimationEventsJob

and the components it operates on.

 

It would allow the event name to act more like a "topic" and the parameter could provide extra details. For a simple example, you could have a "Footstep" event and have the parameter represent which foot. That might sound like overkill for a biped, but for a armored spider-mech, having to make a unique event name for each foot just to get the audio source and dust particles to spawn in the correct location would be annoying.

It is effectively a user value. The user can do whatever they want with it. It seems not that useful, but it is going to solve some creative person's problem at some point.

 

mmh that will help my greatly! inline with the system i'm currently working on^^

-For the name 64Bytes seems fine, i never use very long name in previous project.
-Will the utility be usable in jobs and BurstCompatible?

I need to try this!

 

The event data stored in the blob assets will be Burst-compatible, but the utility method to extract AnimationEvents from the UnityEngine API will not be Burst-compatible.

 

@Dechichi01 I pass all the day playing with your Dmotion and that's in fact pretty good!, just 1 question i'm searching for the "End Time transitions" feature who should be in the 0.2 according to the documentation, for now the scriptable object only allow boolean transition and setting no boolean transition switch directly to the next State without waiting for the end of the current animation and i couldn't find anything in the repository that seems to provide this behaviour, is it not released yet?


Some issue i encounter:

there is a strange bug where sometimes events are not catch, one reason is if the animation si too slow; when testing your sample, by setting the slider with a slow speed value, the footstep event is not caught at all.

Also when using boolean transition, the system have difficulties catching event for the very first animation(if play in loop), if i set to loop, the first time the animation is played, the event wont be catch, but all animations after are caught. after some testing it seems the first time the animation is played (using a boolean transition), it catches only events near the start of the clip(~0.3f normalized time on the AnimationClipAsset).

 

Hey @tassarho! Thanks a lot for trying the tool and for the bug reports. End Time transitions were (temporarily) removed at version 0.2.0, but they are coming back in version 0.3.0, which I'm releasing today(ish).

I believe I've also fixed the bugs with event raising, thanks a lot for catching those!

Btw, version 0.3.0 will come with custom editors for the entire tool

 

Latios Framework 0.5.4 is out!
Aside from Kinemation bugfixes, this release now supports Mac OS!

Special thanks to @cyriaca who was a huge help with this! And yes, it includes Apple Silicon support.

The next patch release will hopefully feature animation events and parameter clips (general purpose animation curves). But this weekend I will be doing a game jam, so that will happen later.

I still plan on making proper demos and videos next month, but with how crazy my calendar is getting, I may not finish within the month. But don't worry. They will come.

A friendly reminder, if you are stress testing optimized skeletons, make sure you use LODs. I usually put the LODGroup component on the same GameObject that has the Animator, with the Skinned Mesh Renderers as children.

Quick survey reminder. It is similar but different from the 0.4 survey I did last year.

And lastly, be sure to check this out: https://forum.unity.com/threads/0-3-0-dmotion-a-high-level-animation-framework-for-dots.1315593/

Enjoy the release!

 

Get ton of error in netcode project!

 

It looks like something in the main rendering system threw an exception, and all the other internal systems are freaking out because they needed that to complete without errors in order to function, hence the "X has detected that the previously updated Y did not finish its update procedure properly" spam.
If you find the first or second error that isn't that and can share the stack trace, that would be super helpful!

 

I'm trying to parent an object to a bone in an optimized skeleton. Is there a way to get the index of a particular bone at runtime (or conversion time, for later use)?

 

At conversion time, if you have an exported bone in your optimized GameObject hierarchy, an entity will be created for that bone which copies the transform from the optimized skeleton during the transform system. So you can parent to that entity. Is that sufficient for your use case?

 

Thanks for the quick reply. It looks like exported bones were the solution I'm looking for. I'll give it a try, thanks!

 

Hi,

Is there a workaround for myri audio source in subscenes? Can I instantiate entity prefabs with looped sounds?

Kind Regards

 

Nothing official. The bug report has been stuck in "In Review" since three weeks ago, whatever that means. It is possible this is environment-dependent, so it wouldn't hurt to try making a build yourself and reporting a crash. It hard crashes now in 2021 LTS.

If you are willing to modify the package, the issue comes from trying to read audio samples from an audio clip during the build process. That's the only time that fails. Reading clips in the editor, in play mode, and at runtime all seem to work fine. So if you were to serialize all the samples of the clip outside of the build process, and then read that data during build instead of the clip, it should work.

There's a couple of gotchas though which is why I never implemented one of these workarounds. If you serialize to a file, there's no stable ID for procedural audio clips. And if you serialize to a float[] inside a MonoBehaviour or ScriptableObject, you run the risk of duplicating the clip's samples multiple times which will chew up your RAM and bloat your authoring scene or project size.

Yes. For looped sources, they will start playing once instantiated. Where they start is based on the Play From Beginning At Spawn checkbox. If checked, they play from the beginning. Otherwise, they start playing from a random offset based on the number of Voices and the elapsed DSP clock time. The former is good for music. The latter is good for spatialized ambience.

 

For me myri audio source in subscenes is not even working in play mode although it does attached to GO with convert to entity checked, so I will try to go the spawn entity prefab route. Am using 2021 LTS and DOTS 0.51 packages.
Edit: Am not sure what I changed, but now audio source in subscenes works in playmode and in build.

 

Latios Framework 0.5.5 is out!
Aside from bug fixes, this release adds animation event baking in clips as well as general purpose scalar parameter clips. There's also a few other small additions.

I'm not aware of any more "low hanging fruit" features that I can add before 0.6. If you think of some that would help you out, let me know!

Demos and videos likely won't be this month. Hopefully next, but I am going to continue prioritizing supporting existing users and their higher level solutions.

Quick survey reminder. We're at 40% of the responses compared to the total the 0.4 survey received.

Enjoy the release!

 

Nice, I've been looking forward to this.

Do you have a sample of this working? I added an LOD group component to the entity with the animator component and the skinned mesh renderers as children, but I didn't see any noticeable change (in FPS or animation quality). I had a look in the pre-release Kinemation samples too, but AFAIK there's no LOD setup in those.

 

Unfortunately I cannot share any samples right now because I don't have a complete character model with good LODs and multiple animations that is unique and that I have the rights to distribute. And it has to be unique and not something widely distributed because otherwise users will get GUID conflicts when they add the sample to their project.

But what I can do is walk you through the exact steps I took and the thought process behind it.

I was investigating DMotion's 2.0 stress test to see if there were any severe Kinemation bottlenecks I needed to address. And when I ran the stress test and profiled it, I saw this:


That's a hard GPU bottleneck, and a bunch of CPU idling. That meant LODs would be useful.

At this point, it is important to note that LODs do not affect the skeleton or the quality of animation in any way. All they do is reduce the number of vertices the GPU has to apply bone weights for and the number of triangles the GPU has to draw. Animation is purely CPU-side and if fact LODs actually hurt CPU performance (although Kinemation is heavily optimized for this use case).

The character in the stress test has 30k vertices and 50k triangles which gets instanced over a thousand times. So to make proper LODs, I needed to drastically reduce the vertex and triangle count.

I happened to get MantisLOD in a bundle and wanted to try it out. There are other LOD tools for this, so use the one you are most comfortable with. I made a single LOD with 3k vertices and 3k triangles. Then I made a prefab variant of the stress test character. I duplicated the Armature_Mesh and then reassigned the Mesh in the Skinned Mesh Renderer with the generated LOD mesh. Then on the root, I added a LOD Group and made LOD 0 at 100% and LOD 1 at 10% all the way to 0%. Ignore the "Recalculate Bounds" button. Kinemation does its own thing.

And this is the performance result:


The main thread of the culling callbacks is now the bottleneck, which is something I would like to improve at some point. But this is also in the editor with safety checks. It is a lot better in builds.

One last tip, to verify LODs are working, it is a good idea to have different colors on the meshes for different LODs when experimenting. With large dense crowds like the stress test, you want to balance it such that when the camera is close, you have detailed LODs but more entities culled, and when the camera is far away, more entities are on screen but have less detailed LODs. If you do it right, the total vertex count in the game view stats should stay roughly static as you move the camera around.

Hopefully that helps!

 

Thanks for the in-depth response! I thought you might be recommending using LOD because Kinemation had some built in handling for it. I'll probably have a crack at reducing the pose sampling rate based on LOD later.

 

You are CPU-bound using optimized skeleton pose sampling?

That only happens when you have highly optimized assets and scenes, which means whatever you are building must be nothing short of impressive!

Out of curiosity, do you have a lot of entities off screen, or are you doing a bunch of pose blending, or do you just have a really tight CPU budget?

 

Latios Framework 0.5.6 is out!
Shoutout once again to @Dechichi01 for half the bug fixes in this release!

There isn't much noteworthy new in this release, but check the Kinemation changelog to see what did happen.

For those of you who are waiting for new demos and videos, would you mind sharing what kinds of examples you would like to see?

If any of you are trying or considering doing anything advanced with Kinemation, please reach out to me so that I can find more opportunities to make that process smoother. I'm still wrestling a bit with how to customize optimized skeleton definitions in authoring. For example, how to specify which optimized bones need ParentScaleInverse logic applied.

A friendly reminder, if you have feature requests, regardless if they are already planned or if someone else already said them or if you said them two months ago, be redundant and say it again. The more you make your desires known, the better I will feel knowing I am spending my time in ways that help others.

And lastly, while I plan to announce this more formally in a future video, I am planning another open project akin to LSSS but focused more on some of the newer developments of the framework. If you have hobby time and are interested, PM me.

Enjoy the release!

 

Latios Framework 0.5.7 is out!
This version bumps the minimum DOTS packages to 0.51.1. Besides applying the changes that would normally be applied via the Script Updater, there is nothing new in this release. If you are successfully using 0.5.6, you do not need to upgrade.

Due to some unexpected events, I will no longer be working on videos in the near future. If circumstances allow, I still plan to make demos in the form of package samples for Kinemation. But from this point forward I will be focusing my development on new feature releases.

There were a couple of things I was going to announce in the videos that I will be announcing here instead. So stay tuned for that.

Keep the feedback coming!

 

In my case, almost all of my entities are off-screen most of the time, and if they're all on screen they're very far away, so I'm relying a lot on culling and LOD. They pose-blend between animations, but that's a relatively small percentage of the time so it's not too much of an issue. I'd like to have around 10,000 NPCs active in the world at a time, but I'm not there yet. I bottleneck on updating transform hierarchies and pose-sampling almost exactly equally at the moment.

I still need to find some way around the maximum compute buffer size for poses, which kicks in at around 4,500 entities on-screen. I guess I'll have to switch to a completely non-skinned renderer at far distances to get past that. As an example, with 4000 NPCs in the world (most of which are off-screen/far away) pose-sampling (without blending) takes 2.18ms (after being split across 14 cores). That's not awful, but I might be able to eliminate most of it with LOD.

You've done great work optimizing Kinemation, etc. If you have any tips for optimizing for this use-case I'd love to hear them.

EDIT: I'd been planning a proper LOD system for animations with update rates based on distance, but this post reminded me to try the naive solution of adding:

if (math.lengthsq(translation.Value - cameraPosition) > 10000f) return;

to the start of my pose-sampling job and now it's down from over 30ms across 14 threads to 0.6ms on a single thread. I might need to fine-tune the distance, but at that range the NPCs are so small you really can't tell a difference.

Now I'm only bottlenecked by ImprovedLocalToParentSystem.UpdateHierarchy.

 

Myri question: I'm encountering some somewhat unwanted behaviour where a looping audiosource will "quiet" itself when another audiosource is played(instantiated), ie in the scenario of a weapon firing sound being played will temporarily dampen the currently looped audiosource. Is there a way to tweak the severity of this?

 

Apologies in advance if my math is off because I'm not 100% healthy atm.

Each bone is 48 bytes in size. There is an absolute maximum 341 bones per skinned mesh. The maximum compute buffer size before warnings are logged is 1 GB. Kinemation only reserves a buffer for the peak number of visible bones in any frame, which you state you have 4500 skeletons for. That means that you must have at least 14.5 skinned RenderMesh instances per skeleton (remember, there is a unique RenderMesh per material).

Or it means you are using Compute Deform skinning, in which case I suggest switching to Linear Blend Skinning for all but the most detailed LOD. Or reduce your vertex count more aggressively for other LODs. Like bones with Linear Blend skinning, Kinemation reserves a buffer for the peak number of visible vertices in any frame, with each vertex being 36 bytes in size.

It may be worth trying installing Extreme Transforms in the bootstrap instead of Improve Transforms. It has a heavier main thread cost, and is more susceptible performance-wise to structural changes as it caches hierarchy information. But it handles large numbers of hierarchies better on worker threads.

I can probably think of more ways to help your use case, but most likely I would need to see a profiler capture to better understand the bottlenecks.

I suspect that is the limiter kicking in. The limiter turns down the volume of the entire mix if after adding all the spatialized source signals together a sample exceeds the range of [-1f, 1f]. Try turning down the volume of your weapon fire sound. Or, if you still want to preserve the "loudness" ratio between the gun sound and the music, turn down the volume of the listener.

Remember volume controls are absolute, but hearing is "perceptive", which means an order of magnitude in the inspector is roughly half/double volume perceptually.

 

Thanks so much for the advice. I am indeed using compute deform skinning. I had some issues getting linear blend skinning working IIRC, but this was a few months ago so I can't remember the details. I'll have another crack at it some time this week. I'll grab a profiler capture for you then, too.

I'll try out Extreme Transforms too. Most hierarchy updates are for purely cosmetic purposes (multiple renderers for an entity each having their own transforms, for example), so I'll probably try some way of culling/reducing the frequency of transform updates that are far away/out of view. Just got to be careful not to cull game-logic dependent updates. Maybe a component on an entity marking it for hierarchy update culling would work. Does the transform hierarchy take LOD groups into account (not updating transforms that are hidden by LOD)? If not, I'll probably look into whether there's some free performance there, too.

 

Nope. Again, the only thing LOD groups are used for is rendering, and multiple can be active at once during a frame, which isn't known until the very end of the frame.

Honestly, I'm not sure what the best way is to reduce hierarchy updates further. It took me quite a few tries just to come up with Extreme Transforms in a way that offered advantages. I would likely need to experiment with several ideas in a real-world project before I would be comfortable providing any hard suggestions.

 

Forgot to report a Myri issue in Dots Build few weeks ago, till saw above(not sure related though).

All clips seem running fine and smooth at play mode in editor, but going lost or mute after project was build and run. The long playing BGMs and longer SFX are selectively no playbacks, like entirely mute. And the short playing sounds either run OK(ex. UI click) or snap at mid of playback(ex. footstep).

I'm still using Myri 0.4.4 on Unity 2020.3.37f1, plus dots build(com.unity.platforms.windows) 0.10.0-preview.10.


Build Configs(just one)

FYI, I managed to respectively declare those audio clip prefabs, frame by frame, to avoid all clips storing overhead at one frame.(not sure if this is the cause)

 

That's quite bizarre, and my first impression makes me suspect some weird DSP clock issue. But I would probably need a repro before I know more. Do you get any runtime errors when making a development build. Have you enabled logging in the Audio Settings component?

Seems unlikely the issue. Also seems overkill, as the issue as I remember was that you had multiple instances of the same clip being converted on separate GameObjects. And each GameObject was decompressing the clip into memory leading to an out-of-memory error. With prefabs, you reduce the number of GameObjects associated with a given audio clip dramatically. So unless you have a ton of different audio clips, converting them frame by frame seems unnecessary. Also in 0.5, decompression happens once per clip instead of once per game object, and you can convert clips independent of audio sources. I don't know what kind of clips your project uses. I know that with clips that span multiple hours, the decompression step can still be problematic. But with more conventional clips, I have never seen anyone encounter allocation issues in 0.5 even with a large number of clips.

 

Unfortunately, no errors or DSP buffer starved warnings printed, with all Debug Build, Development Build and Release Build.


The Profiler of Audio Module shows quite a lot memory using at Menu Scene where all sounds initializing at very first, increase from 0 to 0.88GB in seconds, as showed. But it doesn't make any difference between PlayMode in actually hearing things and Build in seemingly play mute, cause their analyzed info are exactly the same and you can't tell if a clip is playing or not(not sure that is correct for Audio CPU or DSP CPU are always occupied even with no playbacks from any clip at all).

Edit: Safety Audio Frames are risen to 72, if that's ok.

--------
Anyway, since Dots Build is deprecated and issue is not so far from bearable, I intend to give it a shot for new Myri & Entities1.0 & fancy new build integration, in the near future of course.

 

I was wondering if I could get some help. I know Unity ECS is still experimental and has lots of issues and I know Android is currently not supported with Latios but I built the ACL_Unity Library for Android. Then also built the apk with only Vulkan API and arm64-v8a. It crashes on startup with this error message:

Spoiler: Logcat Error

Code (CSharp):

1. Process: com.DMT.LifeofPiracy, PID: 614
2.     java.lang.Error: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
3.     Version '2021.3.9f1 (ad3870b89536)', Build type 'Development', Scripting Backend 'il2cpp', CPU 'arm64-v8a'
4.     Build fingerprint: 'motorola/kiev_t/kiev:11/RZKS31.Q3-45-16-3-3/d1c34:user/release-keys'
5.     Revision: 'pvt'
6.     ABI: 'arm64'
7.     Timestamp: 2022-09-05 12:03:15-0400
8.     pid: 614, tid: 4078, name: UnityMain  >>> com.DMT.LifeofPiracy <<<
9.     uid: 10567
10.     signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x78
11.     Cause: null pointer dereference
12.         x0  000000000000000d  x1  0000000002000108  x2  0000007538da0760  x3  0000007538da0764
13.         x4  0000000000000002  x5  0000007538da8b98  x6  0000000000000000  x7  0000000000000000
14.         x8  0000000000000032  x9  0000000080000000  x10 0000007491e3bcc0  x11 0000000000000032
15.         x12 0000000000000032  x13 0000007491e3bd58  x14 0000000000000032  x15 0000000080000000
16.         x16 0000000000000044  x17 0000000000000074  x18 00000075001aa0a8  x19 0000000000000000
17.         x20 0000007538da8ac0  x21 000000000000000a  x22 0000007538da8ac0  x23 0000007538da8b20
18.         x24 0000000000000030  x25 0000007491e38680  x26 0000007492f91540  x27 00000074502f8408
19.         x28 0000000000000000  x29 0000007492f915c0
20.         sp  0000007538da0720  lr  00000074208ddca4  pc  00000074208dd5c4
21.  
22.     backtrace:
23.           #00 pc 000000000010f5c4  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/lib_burst_generated.so (Unity.Entities.JobEntityBatchExtensions.JobEntityBatchProducer`1<Latios.Kinemation.Systems.UpdateChunkLinearBlendMetadataSystem.UpdateChunkVertexCountsJob>.ExecuteInternal(ref Unity.Entities.JobEntityBatchExtensions.JobEntityBatchWrapper`1<Latios.Kinemation.Systems.UpdateChunkLinearBlendMetadataSystem.UpdateChunkVertexCountsJob> jobWrapper, System.IntPtr bufferRangePatchData, ref Unity.Jobs.LowLevel.Unsafe.JobRanges ranges, int jobIndex) -> void_af0ee2df0b1e2158fa5c6d394d81afa0+1396) (BuildId: f058aad611487a2c48019b7ad79767eb6bfa8809)
24.           #01 pc 00000000000a3ce4  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/lib_burst_generated.so (8ddd5c52bcd4ec7960aa92b1c62a6306+4) (BuildId: f058aad611487a2c48019b7ad79767eb6bfa8809)
25.           #02 pc 0000000000298268  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/libunity.so (BuildId: 07dc86e9fe1d85ab329fd22dab5318f770a9f80f)
26.           #03 pc 0000000000298674  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/libunity.so (BuildId: 07dc86e9fe1d85ab329fd22dab5318f770a9f80f)
27.           #04 pc 0000000000298718  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/libunity.so (BuildId: 07dc86e9fe1d85ab329fd22dab5318f770a9f80f)
28.           #05 pc 0000000000299318  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/libunity.so (JobQueue::Exec(JobInfo*, long long, int, bool)+120) (BuildId: 07dc86e9fe1d85ab329fd22dab5318f770a9f80f)
29.           #06 pc 000000000029a8c0  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/libunity.so (JobQueue::WaitForJobGroupID(JobGroupID, JobQueue::JobQueueWorkStealMode)+632) (BuildId: 07dc86e9fe1d85ab329fd22dab5318f770a9f80f)
30.           #07 pc 0000000000293afc  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/libunity.so (CompleteFenceInternal(JobFence&, WorkStealMode)+28) (BuildId: 07dc86e9fe1d85ab329fd22dab5318f770a9f80f)
31.           #08 pc 000000000012bbc8  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/libunity.so (JobHandle_CUSTOM_ScheduleBatchedJobsAndComplete(JobFence&)+64) (BuildId: 07dc86e9fe1d85ab329fd22dab5318f770a9f80f)
32.           #09 pc 0000000000ff8174  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/libil2cpp.so (BuildId: 20aea0a72074670247688b8b2de02e05816a66)
33. 2022-09-05 12:03:16.077 614-4078/com.DMT.LifeofPiracy E/AndroidRuntime:       #10 pc 0000000000abba3c  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/libil2cpp.so (BuildId: 20aea0a72074670247688b8b2de02e05816a66)
34.           #11 pc 0000000000720568  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/libil2cpp.so (BuildId: 20aea0a72074670247688b8b2de02e05816a66)
35.           #12 pc 00000000009d89c8  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/libil2cpp.so (BuildId: 20aea0a72074670247688b8b2de02e05816a66)
36.           #13 pc 0000000000cb9c60  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/libil2cpp.so (BuildId: 20aea0a72074670247688b8b2de02e05816a66)
37.           #14 pc 0000000000c8dc9c  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/libil2cpp.so (BuildId: 20aea0a72074670247688b8b2de02e05816a66)
38.           #15 pc 00000000010a4534  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/libil2cpp.so (BuildId: 20aea0a72074670247688b8b2de02e05816a66)
39.           #16 pc 0000000000c8e6c8  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/libil2cpp.so (BuildId: 20aea0a72074670247688b8b2de02e05816a66)
40.           #17 pc 0000000000c8e950  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/libil2cpp.so (BuildId: 20aea0a72074670247688b8b2de02e05816a66)
41.           #18 pc 0000000000ff8ca0  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/libil2cpp.so (BuildId: 20aea0a72074670247688b8b2de02e05816a66)
42.           #19 pc 0000000000ccdfe0  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/libil2cpp.so (BuildId: 20aea0a72074670247688b8b2de02e05816a66)
43.           #20 pc 000000000153b05c  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/libil2cpp.so (BuildId: 20aea0a72074670247688b8b2de02e05816a66)
44.           #21 pc 00000000008dd250  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/libil2cpp.so (BuildId: 20aea0a72074670247688b8b2de02e05816a66)
45.           #22 pc 00000000008dd0b0  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/libil2cpp.so (BuildId: 20aea0a72074670247688b8b2de02e05816a66)
46.           #23 pc 000000000040e7f8  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/libunity.so (scripting_method_invoke(ScriptingMethodPtr, ScriptingObjectPtr, ScriptingArguments&, ScriptingExceptionPtr*, bool)+164) (BuildId: 07dc86e9fe1d85ab329fd22dab5318f770a9f80f)
47.           #24 pc 000000000041f77c  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/libunity.so (ScriptingInvocation::Invoke(ScriptingExceptionPtr*, bool)+156) (BuildId: 07dc86e9fe1d85ab329fd22dab5318f770a9f80f)
48.           #25 pc 00000000004fa838  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/libunity.so (Scripting::UnityEngine::Rendering::BatchRendererGroupProxy::InvokeOnPerformCulling(ScriptingObjectPtr, void const*, void const*, ScriptingExceptionPtr*)+120) (BuildId: 07dc86e9fe1d85ab329fd22dab5318f770a9f80f)
49.           #26 pc 0000000000744890  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/libunity.so (BatchRendererGroup::OnBeforeCulling(int, Plane const*, LODParameters const&, unsigned long, Matrix4x4f const&, float)+576) (BuildId: 07dc86e9fe1d85ab329fd22dab5318f770a9f80f)
50.           #27 pc 00000000007a0c70  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/libunity.so (CullScene(CullResults&)+208) (BuildId: 07dc86e9fe1d85ab329fd22dab5318f770a9f80f)
51. 2022-09-05 12:03:16.077 614-4078/com.DMT.LifeofPiracy E/AndroidRuntime:       #28 pc 0000000000268558  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/libunity.so (CullScriptable(ScriptableRenderContext const&, ScriptableCullingParameters const&)+948) (BuildId: 07dc86e9fe1d85ab329fd22dab5318f770a9f80f)
52.           #29 pc 000000000015d4b4  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/libunity.so (ScriptableRenderContext_CUSTOM_Internal_Cull_Injected(ScriptableCullingParameters&, ScriptableRenderContextManaged const&, void*)+68) (BuildId: 07dc86e9fe1d85ab329fd22dab5318f770a9f80f)
53.           #30 pc 000000000153599c  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/libil2cpp.so (BuildId: 20aea0a72074670247688b8b2de02e05816a66)
54.           #31 pc 0000000001535904  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/libil2cpp.so (BuildId: 20aea0a72074670247688b8b2de02e05816a66)
55.           #32 pc 00000000013e46d4  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/libil2cpp.so (BuildId: 20aea0a72074670247688b8b2de02e05816a66)
56.           #33 pc 00000000013e2ff4  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/libil2cpp.so (BuildId: 20aea0a72074670247688b8b2de02e05816a66)
57.           #34 pc 00000000013e1a4c  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/libil2cpp.so (BuildId: 20aea0a72074670247688b8b2de02e05816a66)
58.           #35 pc 000000000152f3a0  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/libil2cpp.so (BuildId: 20aea0a72074670247688b8b2de02e05816a66)
59.           #36 pc 00000000008dd250  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/libil2cpp.so (BuildId: 20aea0a72074670247688b8b2de02e05816a66)
60.           #37 pc 00000000008dd0b0  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/libil2cpp.so (BuildId: 20aea0a72074670247688b8b2de02e05816a66)
61.           #38 pc 000000000040e7f8  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/libunity.so (scripting_method_invoke(ScriptingMethodPtr, ScriptingObjectPtr, ScriptingArguments&, ScriptingExceptionPtr*, bool)+164) (BuildId: 07dc86e9fe1d85ab329fd22dab5318f770a9f80f)
62.           #39 pc 000000000041f77c  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/libunity.so (ScriptingInvocation::Invoke(ScriptingExceptionPtr*, bool)+156) (BuildId: 07dc86e9fe1d85ab329fd22dab5318f770a9f80f)
63.           #40 pc 0000000000272aac  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/libunity.so (ScriptableRenderContext::ExtractAndExecuteRenderPipeline(dynamic_array<Camera*, 0ul> const&, void (*)(SceneNode const*, AABB const*, IndexList&, SceneCullingParameters const*), void*, ScriptingObjectPtr)+328) (BuildId: 07dc86e9fe1d85ab329fd22dab5318f770a9f80f)
64.           #41 pc 0000000000790880  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/libunity.so (RenderManager::RenderCamerasWithScriptableRenderLoop(int)+808) (BuildId: 07dc86e9fe1d85ab329fd22dab5318f770a9f80f)
65.           #42 pc 00000000007909fc  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/libunity.so (RenderManager::RenderCameras(int, void (*)(), void (*)())+56) (BuildId: 07dc86e9fe1d85ab329fd22dab5318f770a9f80f)
66.           #43 pc 00000000002b2d34  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/libunity.so (PlayerRender(bool)+708) (BuildId: 07dc86e9fe1d85ab329fd22dab5318f770a9f80f)
67.           #44 pc 00000000002b3e2c  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/libunity.so (BuildId: 07dc86e9fe1d85ab329fd22dab5318f770a9f80f)
68. 2022-09-05 12:03:16.077 614-4078/com.DMT.LifeofPiracy E/AndroidRuntime:       #45 pc 00000000002b50ec  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/libunity.so (ExecutePlayerLoop(NativePlayerLoopSystem*)+92) (BuildId: 07dc86e9fe1d85ab329fd22dab5318f770a9f80f)
69.           #46 pc 00000000002b512c  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/libunity.so (ExecutePlayerLoop(NativePlayerLoopSystem*)+156) (BuildId: 07dc86e9fe1d85ab329fd22dab5318f770a9f80f)
70.           #47 pc 00000000002b53cc  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/libunity.so (PlayerLoop()+312) (BuildId: 07dc86e9fe1d85ab329fd22dab5318f770a9f80f)
71.           #48 pc 00000000004b2ae0  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/libunity.so (UnityPlayerLoop()+824) (BuildId: 07dc86e9fe1d85ab329fd22dab5318f770a9f80f)
72.           #49 pc 00000000004e5830  /data/app/~~CD6uhAT9_3DDEojXFoUBdQ==/com.DMT.LifeofPiracy-_0wIS3gNHyrSlMqBF4bB3g==/lib/arm64/libunity.so (nativeRender(_JNIEnv*, _jobject*)+72) (BuildId: 07dc86e9fe1d85ab329fd22dab5318f770a9f80f)
73.           #50 pc 000000000013ced4  /apex/com.android.art/lib64/libart.so (art_quick_generic_jni_trampoline+148) (BuildId: 5a57bef0c3bc3adef9f99a7e80bfa5)
74.           #51 pc 0000000000133564  /apex/com.android.art/lib64/libart.so (art_quick_invoke_stub+548) (BuildId: 5a57bef0c3bc3adef9f99a7e80bfa5)
75.           #52 pc 00000000001a8a78  /apex/com.android.art/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+200) (BuildId: 5a57bef0c3bc3adef9f99a7e80bfa5)
76.           #53 pc 0000000000319da4  /apex/com.android.art/lib64/libart.so (art::interpreter::ArtInterpreterToCompiledCodeBridge(art::Thread*, art::ArtMethod*, art::ShadowFrame*, unsigned short, art::JValue*)+376) (BuildId: 5a57bef0c3bc3adef9f99a7e80bfa5)
77.           #54 pc 00000000003100d0  /apex/com.android.art/lib64/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+996) (BuildId: 5a57bef0c3bc3adef9f99a7e80bfa5)
78.           #55 pc 0000000000681228  /apex/com.android.art/lib64/libart.so (MterpInvokeDirect+576) (BuildId: 5a57bef0c3bc3adef9f99a7e80bfa5)
79.           #56 pc 000000000012d914  /apex/com.android.art/lib64/libart.so (mterp_op_invoke_direct+20) (BuildId: 5a57bef0c3bc3adef9f99a7e80bfa5)
80.           #57 pc 0000000000681da8  /apex/com.android.art/lib64/libart.so (MterpInvokeStatic+1224) (BuildId: 5a57bef0c3bc3adef9f99a7e80bfa5)
81.           #58 pc 000000000012d994  /apex/com.android.art/lib64/libart.so (mterp_op_invoke_static+20) (BuildId: 5a57bef0c3bc3adef9f99a7e80bfa5)
82.           #59 pc 0000000000680884  /apex/com.android.art/lib64/libart.so (MterpInvokeInterface+1808) (BuildId: 5a57bef0c3bc3adef9f99a7e80bfa5)
83.           #60 pc 000000000012da14  /apex/com.android.art/lib64/libart.so (mterp_op_invoke_interface+20) (BuildId: 5a57bef0c3bc3adef9f99a7e80bfa5)
84.           #61 pc 000000000067ee4c  /apex/com.android.art/lib64/libart.so (MterpInvokeVirtual+1520) (BuildId: 5a57bef0c3bc3adef9f99a7e80bfa5)
85.           #62 pc 000000000012d814  /apex/com.android.art/lib64/libart.so (mterp_op_invoke_virtual+20) (BuildId: 5a57bef0c3bc3adef9f99a7e80bfa5)
86.           #63 pc 0000000000681da8  /apex/com.android.art/lib64/libart.so (MterpInvokeStatic+1224) (BuildId: 5a57bef0c3bc3adef9f99a7e80bfa5)
87.           #64 pc 000000000012d994  /apex/com.android.art/lib64/libart.so (mterp_op_invoke_static+20) (BuildId: 5a57bef0c3bc3adef9f99a7e80bfa5)
88.           #65 pc 00000000003076cc  /apex/com.android.art/lib64/libart.so (art::interpreter::Execute(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame&, art::JValue, bool, bool) (.llvm.13239354378677934218)+268) (BuildId: 5a57bef0c3bc3adef9f99a7e80bfa5)
89.           #66 pc 000000000066d8b4  /apex/com.android.art/lib64/libart.so (artQuickToInterpreterBridge+780) (BuildId: 5a57bef0c3bc3adef9f99a7e80bfa5)
90. 2022-09-05 12:03:16.077 614-4078/com.DMT.LifeofPiracy E/AndroidRuntime:       #67 pc 000000000013cff8  /apex/com.android.art/lib64/libart.so (art_quick_to_interpreter_bridge+88) (BuildId: 5a57bef0c3bc3adef9f99a7e80bfa5)
91.           #68 pc 0000000000133564  /apex/com.android.art/lib64/libart.so (art_quick_invoke_stub+548) (BuildId: 5a57bef0c3bc3adef9f99a7e80bfa5)
92.           #69 pc 00000000001a8a78  /apex/com.android.art/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+200) (BuildId: 5a57bef0c3bc3adef9f99a7e80bfa5)
93.           #70 pc 000000000055729c  /apex/com.android.art/lib64/libart.so (art::JValue art::InvokeVirtualOrInterfaceWithJValues<art::ArtMethod*>(art::ScopedObjectAccessAlreadyRunnable const&, _jobject*, art::ArtMethod*, jvalue const*)+460) (BuildId: 5a57bef0c3bc3adef9f99a7e80bfa5)
94.           #71 pc 00000000005a66c0  /apex/com.android.art/lib64/libart.so (art::Thread::CreateCallback(void*)+1308) (BuildId: 5a57bef0c3bc3adef9f99a7e80bfa5)
95.           #72 pc 00000000000afc6c  /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+64) (BuildId: 1fdafb7d457cc367eb58ced21a4fa8ac)
96.           #73 pc 00000000000502c8  /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64) (BuildId: 1fdafb7d457cc367eb58ced21a4fa8ac)
97.  
98.         at lib_burst_generated.Unity.Entities.JobEntityBatchExtensions.JobEntityBatchProducer`1<Latios.Kinemation.Systems.UpdateChunkLinearBlendMetadataSystem.UpdateChunkVertexCountsJob>.ExecuteInternal(ref Unity.Entities.JobEntityBatchExtensions.JobEntityBatchWrapper`1<Latios.Kinemation.Systems.UpdateChunkLinearBlendMetadataSystem.UpdateChunkVertexCountsJob> jobWrapper, System.IntPtr bufferRangePatchData, ref Unity.Jobs.LowLevel.Unsafe.JobRanges ranges, int jobIndex) -> void_af0ee2df0b1e2158fa5c6d394d81afa0(Unity.Entities.JobEntityBatchExtensions.JobEntityBatchProducer`1<Latios.Kinemation.Systems.UpdateChunkLinearBlendMetadataSystem.UpdateChunkVertexCountsJob>.ExecuteInternal:1396)
99.         at lib_burst_generated.8ddd5c52bcd4ec7960aa92b1c62a6306(8ddd5c52bcd4ec7960aa92b1c62a6306:4)
100.         at libunity.0x298268(Native Method)
101.         at libunity.0x298674(Native Method)
102.         at libunity.0x298718(Native Method)
103.         at libunity.JobQueue::Exec(JobInfo*, long long, int, bool)(Exec:120)
104.         at libunity.JobQueue::WaitForJobGroupID(JobGroupID, JobQueue::JobQueueWorkStealMode)(WaitForJobGroupID:632)
105.         at libunity.CompleteFenceInternal(JobFence&, WorkStealMode)(CompleteFenceInternal:28)
106.         at libunity.JobHandle_CUSTOM_ScheduleBatchedJobsAndComplete(JobFence&)(JobHandle_CUSTOM_ScheduleBatchedJobsAndComplete:64)
107.         at libil2cpp.0xff8174(Native Method)
108.         at libil2cpp.0xabba3c(Native Method)
109.         at libil2cpp.0x720568(Native Method)
110.         at libil2cpp.0x9d89c8(Native Method)
111.         at libil2cpp.0xcb9c60(Native Method)
112.         at libil2cpp.0xc8dc9c(Native Method)
113.         at libil2cpp.0x10a4534(Native Method)
114.         at libil2cpp.0xc8e6c8(Native Method)
115.         at libil2cpp.0xc8e950(Native Method)
116.         at libil2cpp.0xff8ca0(Native Method)
117.         at libil2cpp.0xccdfe0(Native Method)
118.         at libil2cpp.0x153b05c(Native Method)
119.         at libil2cpp.0x8dd250(Native Method)
120.         at libil2cpp.0x8dd0b0(Native Method)
121.         at libunity.scripting_method_invoke(ScriptingMethodPtr, ScriptingObjectPtr, ScriptingArguments&, ScriptingExceptionPtr*, bool)(scripting_method_invoke:164)
122.         at libunity.ScriptingInvocation::Invoke(ScriptingExceptionPtr*, bool)(Invoke:156)
123.         at libunity.Scripting::UnityEngine::Rendering::BatchRendererGroupProxy::InvokeOnPerformCulling(ScriptingObjectPtr, void const*, void const*, ScriptingExceptionPtr*)(InvokeOnPerformCulling:120)
124.         at libunity.BatchRendererGroup::OnBeforeCulling(int, Plane const*, LODParameters const&, unsigned long, Matrix4x4f const&, float)(OnBeforeCulling:576)
125.         at libunity.CullScene(CullResults&)(CullScene:208)
126.         at libunity.CullScriptable(ScriptableRenderContext const&, ScriptableCullingParameters const&)(CullScriptable:948)
127.         at libunity.ScriptableRenderContext_CUSTOM_Internal_Cull_Injected(ScriptableCullingParameters&, ScriptableRenderContextManaged const&, void*)(ScriptableRenderContext_CUSTOM_Internal_Cull_Injected:68)

 

My guess is if you were to unload unused resources after the audio clips are converted, that number would drop back down. As for DSP usage, that amount is exclusively dependent on the number of audio listeners, the complexity of the listener profiles, and the brickwall limiter.

That's way too many. Set that to 2, and then most likely you'll get some logs about buffers being starved. It is okay if buffers get starved on loading frames. If it is persistent, then we need to adjust settings appropriately.

When profiling, there's two things to look at in the Timeline view. First, there's the chain of jobs scheduled from Myri from the main thread, usually at the start of the frame. The biggest ones are usually named "Sample Looped" or "Sample OneShots". Second, on the audio thread, you will see periodically an update in which you might see some "Kernel" operations including the brickwall limiter. Every time that happens, that is a single "audio frame", and it is very decoupled from the game framerate. Now how often those audio frames happen relative to the worker threads processing the audio jobs scheduled from the main thread, that's what dictates how to correctly tune the audio settings.

Honestly, I'm surprised you even were able to run with 72 safety frames. That means the jobs scheduled from the main thread are computing 72 extra audio frames worth of samples every update. My computer would not be able to keep up with that workload.

I unfortunately cannot make promises. Whether or not this works in the future requires either QA to understand what is going on (they are clueless either due to incompetency, bad processes, or both), or the DOTS team to look into it (which they seem to have refused to do until QA processes it).

At the very least it may be worth upgrading to the latest DOTS and framework version. I don't think it will be possible to upgrade your project to 1.0 without going through that stepping stone first.

 

Sorry, I missed this somehow. It is a little difficult to deduce without the Burst generated symbols, but I'm guessing this line is the culprit: https://github.com/Dreaming381/Lati...g/UpdateChunkLinearBlendMetadataSystem.cs#L57

Before that line, you can check if the blob asset is valid, and if not, log a warning and continue? See if that removes the crash? Or at the very least, it may move the crash to a different job.

Other than maybe some bug on Android with subscenes, this doesn't seem like an Android-specific bug. So maybe try making a desktop build?

 

No worries I haven't posted much so my posts are still moderated. You're indeed correct it crashes on the PC standalone build as well. I also did a check on the var blobs and it still gave the same error. When played through the editor it runs fine. BUT I noticed if I keep the editor open long enough then play through editor the fps gets down to 20 fps. Maybe there's a memory leak? Also I am building the DMotion Stress Test scene and the crash doesn't happen on an empty scene.

I'm currently running:
- Unity 2021.3.9f1
- Burst 1.7.4
- Entities & Hybrid Renderer 0.51.1-preview.21
- Jobs 0.70.0-preview.7
- Latios 0.5.7
- Dmotion 0.3.1

 

I made a new test project with DMotion 0.3.2 in 2021.3.9f1 and the latest public Latios Framework version. Aside from having to delete a LatiosBootstrap in DMotion's Tests directory, I was able to run the stress test scene in both the editor and a mono build without issues.

Unfortunately, I'm going to need something else in order to troubleshoot your issue. Here's some options:
A) Send me a repro project.
B) Undo any local changes to the Latios Framework, then capture a crash log in a build, and send them to me along with the lib_burst_generated.txt file.
C) Undo any local changes to the Latios Framework. Then comment out the [BurstCompile] line for the failing job (make sure to only comment it out so that respective line numbers don't change). Get a crash log with that and ensure that it spits out the actual line number of the error and send the full error message to me.

Please get profiler captures when the FPS is good and when the FPS is bad and send them to me. There's a save button in the profiler in the top right. You can send it to me via PM. Do not Deep Profile.

 

I'm testing your framework with DMotion and I just can't load a scene with a subscene in a IL2CPP build with Latios installed. It just crashes with this messages in the debugger:

Code (CSharp):

1. Unhandled exception thrown: read access violation.
2. **__this** was 0x20A5011AA98.

Even when the scene is just a empty scene with a camera and the subscene is completely empty.

I suspect it has to do something with deserializing dots data of the subscene

The debugger catches the exception in the function below at this line (line 35 in the code block below)
int32_t L_3 = (int32_t)__this->___m_OffsetPtr_0;

Code (CSharp):

1.  
2. // System.Void* Unity.Entities.BlobArray`1<System.Byte>::GetUnsafePtr()
3. IL2CPP_EXTERN_C IL2CPP_METHOD_ATTR void* BlobArray_1_GetUnsafePtr_m1C36E9770A33F35255BFCC18D7FA21E4863771FE_gshared (BlobArray_1_t112C49ADFEB7465DC55221B4D8E6C721002D4D16* __this, const RuntimeMethod* method)
4. {
5.     static bool s_Il2CppMethodInitialized;
6.     if (!s_Il2CppMethodInitialized)
7.     {
8.         il2cpp_codegen_initialize_runtime_metadata((uintptr_t*)&BlobArray_1_GetUnsafePtr_m1C36E9770A33F35255BFCC18D7FA21E4863771FE_RuntimeMethod_var);
9.         il2cpp_codegen_initialize_runtime_metadata((uintptr_t*)&BlobArray_1_tFC768C3058FC84BF0876F0A08FB2FA04F83C5E7C_0_0_0_var);
10.         il2cpp_codegen_initialize_runtime_metadata((uintptr_t*)&Int32U2A_t49A648948B5A176D1945F61EB07A64274F3A9D47_0_0_0_var);
11.         il2cpp_codegen_initialize_runtime_metadata((uintptr_t*)&Int32_t680FF22E76F6EFAD4375103CBBFFA0421349384C_0_0_0_var);
12.         il2cpp_codegen_initialize_runtime_metadata((uintptr_t*)&VoidU2A_t104EAEFBD2D237A8C29618913DA9B4D99355E965_0_0_0_var);
13.         s_Il2CppMethodInitialized = true;
14.     }
15.     int32_t* V_0 = NULL;
16.     int32_t* V_1 = NULL;
17.     void* V_2 = NULL;
18.     DECLARE_METHOD_THIS(methodExecutionContextThis, (&__this));
19.     DECLARE_METHOD_LOCALS(methodExecutionContextLocals, (&V_0));
20.     DECLARE_METHOD_EXEC_CTX(methodExecutionContext, BlobArray_1_GetUnsafePtr_m1C36E9770A33F35255BFCC18D7FA21E4863771FE_RuntimeMethod_var, methodExecutionContextThis, NULL, methodExecutionContextLocals);
21.     CHECK_METHOD_ENTRY_SEQ_POINT(methodExecutionContext, (g_sequencePointsUnity_Entities + 1642));
22.     CHECK_METHOD_EXIT_SEQ_POINT(methodExitChecker, methodExecutionContext, (g_sequencePointsUnity_Entities + 1643));
23.     {
24.         CHECK_SEQ_POINT(methodExecutionContext, (g_sequencePointsUnity_Entities + 1644));
25.         int32_t* L_0 = (int32_t*)(&__this->___m_OffsetPtr_0);
26.         V_1 = L_0;
27.         // fixed (int* thisPtr = &m_OffsetPtr)
28.         CHECK_SEQ_POINT(methodExecutionContext, (g_sequencePointsUnity_Entities + 1645));
29.         int32_t* L_1 = V_1;
30.         V_0 = (int32_t*)((uintptr_t)L_1);
31.         CHECK_SEQ_POINT(methodExecutionContext, (g_sequencePointsUnity_Entities + 1646));
32.         // return (byte*) thisPtr + m_OffsetPtr;
33.         CHECK_SEQ_POINT(methodExecutionContext, (g_sequencePointsUnity_Entities + 1647));
34.         int32_t* L_2 = V_0;
35.         int32_t L_3 = (int32_t)__this->___m_OffsetPtr_0;
36.         V_2 = (void*)((int32_t*)il2cpp_codegen_add((intptr_t)L_2, L_3));
37.         goto IL_0017;
38.     }
39. IL_0017:
40.     {
41.         // }
42.         CHECK_SEQ_POINT(methodExecutionContext, (g_sequencePointsUnity_Entities + 1648));
43.         void* L_4 = V_2;
44.         return L_4;
45.     }
46. }
47.  

and this is the call stack:

Code (CSharp):

1. >    GameAssembly.dll!BlobArray_1_GetUnsafePtr_m1C36E9770A33F35255BFCC18D7FA21E4863771FE_gshared(BlobArray_1_t112C49ADFEB7465DC55221B4D8E6C721002D4D16 * __this, const MethodInfo * method) Line 26264    C++
2.      GameAssembly.dll!BlobArray_1_GetUnsafePtr_m1C36E9770A33F35255BFCC18D7FA21E4863771FE(BlobArray_1_t112C49ADFEB7465DC55221B4D8E6C721002D4D16 * __this, const MethodInfo * method) Line 8971    C++
3.      GameAssembly.dll!DotsSerializationReader__ctor_m315258F39B2C56305ECFFEE3EF95561BDC5CD4DA(DotsSerializationReader_t01E6CC40A126BDFFC10693CDE3B06F8361B433DF * __this, BlobHeader_tCE133EA8852A67AF9C9F3E380D6288A120A34953 * ___blobHeader0, const MethodInfo * method) Line 33832    C++
4.      GameAssembly.dll!DotsSerialization_CreateReader_mD449775FCAA012FBD6CF131CB7C488037D473745(BlobHeader_tCE133EA8852A67AF9C9F3E380D6288A120A34953 * ___header0, const MethodInfo * method) Line 30842    C++
5.      GameAssembly.dll!AsyncLoadSceneOperation_UpdateAsync_m25C4533BE332945DB9ACFCF80AB913B132653253(AsyncLoadSceneOperation_t21BFB9CC923FF96B9F40F8AFFE880CABDA139D5D * __this, const MethodInfo * method) Line 14771    C++
6.      GameAssembly.dll!AsyncLoadSceneOperation_Update_m07545C9F8CDA2DC5FB6D4450C59924B66BEBC6BD(AsyncLoadSceneOperation_t21BFB9CC923FF96B9F40F8AFFE880CABDA139D5D * __this, const MethodInfo * method) Line 15487    C++
7.      GameAssembly.dll!SceneSectionStreamingSystem_UpdateLoadOperation_m808052F10FF4966DB2C5563A77A366953377AD5A(SceneSectionStreamingSystem_t1263FB3EB08E30F8336B4B470F1E8FD52014067B * __this, AsyncLoadSceneOperation_t21BFB9CC923FF96B9F40F8AFFE880CABDA139D5D * ___operation0, World_t55FCE40A4C47400A27AE7BF5A0FED66B34C8726A * ___streamingWorld1, Entity_t56176FC78C475061A82383D9E0CEE352C6C52ABD ___sectionEntity2, bool ___moveEntities3, const MethodInfo * method) Line 36049    C++
8.      GameAssembly.dll!SceneSectionStreamingSystem_ProcessActiveStreams_m6300856C6B8532C6B75E14029910E8D17B39135E(SceneSectionStreamingSystem_t1263FB3EB08E30F8336B4B470F1E8FD52014067B * __this, const MethodInfo * method) Line 35673    C++
9.      GameAssembly.dll!SceneSectionStreamingSystem_OnUpdate_m48E550F61E3B9720FA4CBC7B99BE33FD55750A85(SceneSectionStreamingSystem_t1263FB3EB08E30F8336B4B470F1E8FD52014067B * __this, const MethodInfo * method) Line 37503    C++
10.      GameAssembly.dll!VirtualActionInvoker0::Invoke(unsigned short slot, Il2CppObject * obj) Line 22    C++
11.      GameAssembly.dll!SystemBase_Update_m795994EE60C054DFA78C313A60ED025B2668C9B4(SystemBase_tF1D148F181415A7A0A38555F7FAD20D5D33C0F0D * __this, const MethodInfo * method) Line 15157    C++
12.      GameAssembly.dll!VirtualActionInvoker0::Invoke(unsigned short slot, Il2CppObject * obj) Line 22    C++
13.      GameAssembly.dll!ComponentSystemGroup_UpdateAllSystems_m78B1AA9EAF07133497E9BA556B592AC93935441C(ComponentSystemGroup_t0D346A735463F650D032D4386FA23D62BB24D24D * __this, const MethodInfo * method) Line 36516    C++
14.      GameAssembly.dll!ComponentSystemGroup_OnUpdate_m83128938DF97469E0D1CB883E5C9000C0C2DA9A7(ComponentSystemGroup_t0D346A735463F650D032D4386FA23D62BB24D24D * __this, const MethodInfo * method) Line 36148    C++
15.      GameAssembly.dll!VirtualActionInvoker0::Invoke(unsigned short slot, Il2CppObject * obj) Line 22    C++
16.      GameAssembly.dll!ComponentSystem_Update_mC7F35C2595C5D67B4A4724A65C1D0CBFFAB56C3C(ComponentSystem_t0357452663010AC3459AFD9496555C9D0CD7B6AA * __this, const MethodInfo * method) Line 29729    C++
17.      GameAssembly.dll!VirtualActionInvoker0::Invoke(unsigned short slot, Il2CppObject * obj) Line 22    C++
18.      GameAssembly.dll!SuperSystem_UpdateManagedSystem_mB713FAAB83E71F83463C5A0F15EAC2597108EBDF(ComponentSystemBase_tE64F7524784FF1281BE7E48E7EEACA6BDCE15625 * ___system0, bool ___propagateError1, const MethodInfo * method) Line 28214    C++
19.      GameAssembly.dll!SuperSystem_UpdateAllSystems_m925B52801E549E51A38A6EE15E50AB25A873D04F(ComponentSystemGroup_t0D346A735463F650D032D4386FA23D62BB24D24D * ___group0, SystemSortingTracker_t4E3B0008B1B5190C95666B2ABE93B7BE2B224934 * ___tracker1, const MethodInfo * method) Line 28476    C++
20.      GameAssembly.dll!SuperSystem_DoSuperSystemUpdate_m4F77E6C94FB39D60EC8251C1A19715F3B4757C49(ComponentSystemGroup_t0D346A735463F650D032D4386FA23D62BB24D24D * ___group0, SystemSortingTracker_t4E3B0008B1B5190C95666B2ABE93B7BE2B224934 * ___tracker1, const MethodInfo * method) Line 28675    C++
21.      GameAssembly.dll!LatiosInitializationSystemGroup_OnUpdate_mD7A56B5300E915674AB179212065A169F6F6C94A(LatiosInitializationSystemGroup_t78AC9A7D5BEB77052161211255BDA744BF061E2B * __this, const MethodInfo * method) Line 34187    C++
22.      GameAssembly.dll!VirtualActionInvoker0::Invoke(unsigned short slot, Il2CppObject * obj) Line 22    C++
23.      GameAssembly.dll!ComponentSystem_Update_mC7F35C2595C5D67B4A4724A65C1D0CBFFAB56C3C(ComponentSystem_t0357452663010AC3459AFD9496555C9D0CD7B6AA * __this, const MethodInfo * method) Line 29729    C++
24.      GameAssembly.dll!VirtualActionInvoker0::Invoke(unsigned short slot, Il2CppObject * obj) Line 22    C++
25.      GameAssembly.dll!DummyDelegateWrapper_TriggerUpdate_m2C37F16899DE9C87FE35B065E0FF7E410E463FE7(DummyDelegateWrapper_tC361ADC5E6F97CA0B11FF154F02DD5813751E553 * __this, const MethodInfo * method) Line 35854    C++
26.      GameAssembly.dll!UpdateFunction_Invoke_m9BCEE4E5BEE924EB804DA64314B78D0E831C179B(UpdateFunction_t1C48B7EECBE47AC123A9D9D7D9D2A9EE951C56C4 * __this, const MethodInfo * method) Line 38252    C++
27.      GameAssembly.dll!RuntimeInvoker_TrueVoid_t4861ACF8F4594C3437BB48B6E56783494B843915(void(*)() methodPointer, const MethodInfo * methodMetadata, void * obj, void * * args, void * returnAddress) Line 292233    C++
28.      GameAssembly.dll!il2cpp::vm::Runtime::InvokeWithThrow(const MethodInfo * method, void * obj, void * * params) Line 577    C++
29.      GameAssembly.dll!il2cpp::vm::Runtime::Invoke(const MethodInfo * method, void * obj, void * * params, Il2CppException * * exc) Line 562    C++
30.      GameAssembly.dll!il2cpp_runtime_invoke(const MethodInfo * method, void * obj, void * * params, Il2CppException * * exc) Line 1122    C++
31.      [External Code]
32.  

It works in a Mono build and a IL2CPP build without subscenes also work.

 

Someone else has the same crash callstack as you (for that matter, so do I)
https://forum.unity.com/threads/exe...tequality-compareimpl-1.1296462/#post-8410533
Not specific to LF/DM, really, just the Subscenes. Supposedly 2021.3.8f1 with IL2CPP set to "Faster (smaller) builds" still works.

 

Unity QA has been closing my crash bug reports as not reproducible. So everyone who encounters crashes with IL2CPP builds but not Mono builds on the latest 2021 LTS, please report a bug. Same goes for crashes using Myri audio sources in subscenes (or simply calling UnityEngine.AudioSource.ReadData() inside of an IConvertGameObjectToEntity).

After that, use this:

This may not resolve all issues, and you may be stuck with Mono builds until Unity gets their IL2CPP build system back in order. If you are getting crashes within a Kinemation job and are trying to ship soon, PM me. It will definitely take some experimentation (and unlikely to be resolved in a single day), but I have a couple of ideas for how the crashing code could be altered that might avoid whatever magic death path causes Unity to fall flat on its face.

 

Version 0.6 Status and Announcements

Hey everyone.

In my last patch release announcement post, I mentioned that due to an unfortunate combination of events, I had to cancel a couple of videos and would make some planned announcements here instead. This post contains those announcements.

First, 0.6 is under active development.

Versions 0.1 and 0.2 were focused on architecture. Version 0.3 through 0.5 were focused on enabling essential technologies like audio and animation. However, as I reminded myself in a game jam a couple months ago, having these technologies doesn’t necessarily mean DOTS game dev is easy or straightforward.

The next phase begins with 0.6, and focuses on providing higher-level gameplay features and making developing gameplay with the Latios Framework easier and more straightforward. That includes overhauling Psyshock, developing MachAxle, and adding IK functionality to Kinemation. A good portion of the Psyshock rework has already been done and exists in the open projects in an experimental state.

Once this phase of development is completed, Latios Framework will reach its own 1.0 status.

Second, there’s now an official Discord server for the Latios Framework.

Admittedly, I’m not really a “people” person and don’t have a lot of experience with this sort of thing, so please be patient with me as I learn. Regardless, this server is meant to be a space for you. A space where you can ask questions, regularly remind me of features you want, discuss API designs, show off demos, be involved in Open Projects, ect.

DOTS 1.0 will likely require some significant redesigns of a few key features in the Latios Framework, and I hope we can have good discussions on how to move forward there.

I’ll still be involved in the forums, GitHub, and other communication channels.

Edit: Link should be permanent now.

Third, I am officially starting Open Project #2: ATAR.

Open projects are my primary way of developing new features and technologies. The first open project was the Latios Space Shooter Sample, or LSSS. It served for developing the basic functions of Core, Psyshock, and Myri up to Latios Framework 0.4 and was specifically scoped for that development.

While I still periodically update LSSS to the latest Latios Framework versions and incorporate applicable improvements, the Latios Framework has expanded beyond the scope of LSSS, especially with Kinemation.

I have private projects in early development, but Kinemation is still a long ways from meeting their animation needs; and consequently, I haven’t integrated Kinemation into those projects yet. That means Kinemation was primarily developed using small test projects and experiments, which is why there were 7 bugfix releases over the last few months (more than any previous feature version). Many of you have done more with Kinemation than I have, which is awesome! But I need to do something better than what I have been doing.

ATAR, which stands for an Atypical Team with Atypical Responsibilities is a combination of tower defense and first-person shooter where a team of magical girls and their robot army defend castle towers in the sky. Gameplay alternates between fortification and combat phases. If any magical girl dies, player or not, it is game over.

The game concept is specifically designed to cover a wide range of future Latios Framework features, while only requiring a small subset to be a playable (and hopefully fun) experience.

Here’s the link to the repo. If you would like to be a part of the development process, join the Discord.

Fourth, there’s still a survey.

The 0.5 survey is still open.

But I wanted to share some interesting facts from the now closed 0.4 survey as well as the current trends in the 0.5 submissions.

Spoiler: Survey Results

The 0.4 survey was released well into the quiet period of DOTS, so I asked how people felt about it. Most were either “impatient” or “worried”. A smaller subset liked the stability which made it easier to learn. My personal view was not very popular.

In the 0.5 survey, I instead ask how comfortable people are with the technicalities of DOTS. So far, most people rely on Unity, the DOTS architecture, and other packages to deliver performance rather than try to optimize things themselves using the Burst inspector and browsing package sources.

Questions for users

Originally in the 0.4 release, people wanted the Latios Framework to stay compatible with the oldest versions of the engine and Burst DOTS was compatible with. But by the time the survey closed, that opinion shifted towards updating to the latest. In 0.5, more users want the Latios Framework to quickly migrate to 1.0 when it comes out.

In 0.4, more people used Psyshock than Myri. That trend is currently flipped in 0.5, but now people use Kinemation the most.

Of the main Core features, Blackboard Entities, Collection Components, Custom Command Buffers, and Fluent Queries were the most popular in 0.4. The current trend in 0.5 sees a dramatic decrease in collection components, but an increase in bootstrap tools. The latter is likely due to the new installer workflows of 0.5.

In 0.4, the most popular Psyshock feature was the simple primitive query operations. But the current trend in 0.5 leans more towards character controllers and simulation utilities.

The current trend in 0.5 shows more people using Myri’s Audio Settings component compared to 0.4.

The current trend in 0.5 shows that Optimized Skeletons are much more popular than Exposed Skeletons.

In 0.4, most found videos and the mini samples most helpful. The current trend in 0.5 shows that the markdown documentation is the most helpful. That is probably because there currently is no video on Kinemation yet, but there is a walkthrough of Kinemation basics in the markdown docs.

Questions for non-users

In both surveys, I asked why non-users were not using the framework. I provided multiple answers, and they could check which ones applied, or write their own. I classified all the answers as either “technical limitations” or “uncomfortableness/misunderstanding”. Zero respondents specified a technical limitation. In 0.4, most specified they haven’t “bothered to try it” followed by not wanting to “risk using something that may not be supported in the future”. In 0.5, the trend is similar, although more users admit they are new to DOTS. This time, platform support is a real technical concern (due to Kinemation), although it still has relatively few respondents.

Questions for all respondents

In 0.4, most people were excited about Kinemation. The first wave of respondents who were mostly users had a 100% “HYPED” rating for Kinemation. Behind Kinemation were Psyshock, then Myri. Currently in 0.5, Kinemation popularity has pulled even further ahead. And now Myri is more popular than Psyshock.

For Core features, 0.4 respondents most wanted safer blob asset tools. The current trend in 0.5 has now shifted towards hierarchy traversal tools. I suspect Smart Blobbers may have solved most people’s blob asset problems.

For Psyshock features, 0.4 respondents most wanted CollisionLayer improvements. In 0.5, character controller utilities are now the most desired. I suspect people want to see Psyshock driving Kinemation characters.

For Myri features, 0.4 respondents were mostly not interested in new features. However, in 0.5, layers have become a popular ask, as well as performance improvements. Unfortunately, there is little room to address performance improvements, because newer versions of Burst started doing the optimizations for me. Please make sure your audio sources match your project’s sample rate if you want good performance.

Currently in 0.5, people most want Kinemation to have IK utilities, followed closely by Blend Shapes support. Also, state machines, graphs, and motion matching are magically in a 3-way tie for preferred high-level animation tool.

In 0.4, people were torn if I should focus more on new features or videos. In 0.5, videos are now the clear winner. But people also want embedded package samples. I think that is the Kinemation crowd speaking. Unfortunately, it will be impossible for me to make a video until 2023 at the earliest. Samples may still come, but there are still two more things that need to happen to make those possible.

My current situation is a little confusing, but I expect things to eventually resolve themselves and in the meantime I will continue to improve and support the Latios Framework in the ways I am able to.

Keep the questions, feedback, and discussion coming!

 

I am curious, is this framework supports Inverse Kinematics bones, with constraints?

 

There's no built-in solver today, but one is definitely planned.

However, the API should allow for anyone to implement such. Exposed skeletons have bones as entities, which you can manipulate however you want. And for optimized skeletons, not only do you have direct access to the pose buffer, but after sampling using a BufferPoseBlender, there are utility functions for computing partial hierarchy matrices which you could use to write a solver. I've experimented with this for shoulder IK for a 3rd-person shooter prototype. In a future release (likely 0.7), such utility functions will no longer be necessary as the buffer will use a new transform hierarchy similar to Transforms V2.

 

Thx @DreamingImLatios for quick reply.

 

Latios Framework 0.5.8 is out!
Given that 2022.2 beta is still very unstable at this point, I decided to backport some bugfixes I discovered while working on 0.6.

I have a fully functional version of Latios Framework for Entities 1.0 exp and am currently working on documentation. I plan to release that next week.

Enjoy the release!

 

Latios Framework currently only supports Windows, Mac OS, and Linux desktop
platforms. This is because the Kinemation module ships with a native plugin
which is currently only built for those platforms.
But ACL support Android (NDK 21) ARMv7-A and ARM64,
Why Latios Framework not support Android?

 

It is purely a DevOps problem. Android supports lots of different hardware with different levels of NEON support. So to properly support it, I need a GitHub Actions job to compile the plugin for all the different instruction sets. What is required is detailed in the README in the AclUnity repo: https://github.com/Dreaming381/AclUnity

If you are targeting a specific device like a Quest headset, you may find it easier to build the plugin locally for your specific hardware and load that into Unity. I know couple of people have done that already.

There's also the issue of most mobile GPUs being especially bad at GPU skinning. Many of them require all constants to be packed in a small cache with compile-time offsets. And that works horribly with skin matrices. While I do plan to get into more VR development at some point, its a fairly low priority for me for the next year or so, and I have no interest in mobile. That is to say, I'm not going to do all the work myself to support Android in the near future.

But if you get something working and make a pull request, even for a limited set of platforms, I can probably clean up some things and include it in a future release.

 

Latios Framework 0.6 is Officially Here!
Link​

This is a feature release targeting Entities 1.0.0 experimental. Feature releases contain breaking changes, so please read the Upgrade Guide if you are using [0.5.8].

This is a transitional release that still uses Transforms V1. Use this release if you need a stepping stone on your migration to Entities 1.0 or if you want to prototype. Do not start new long-term projects with this release. 0.5.8 is a much more stable environment currently.

Overall Highlights
I had two goals for this release:

1. Support for Entities 1.0
2. Eliminate non-transform related performance problems inaccessible prior to Unity 2022.2

Core Highlights
Baking is supported. Subscenes are supported. Live view modes are supported. It is all supported.

In addition, there are custom bootstrappers for both baking and the Editor World, providing granular control. These are used by the installers introduced in 0.5.

Smart Blobbers have been redesigned from the ground up to work with baking. The new design is admittedly a little trickier to get started, but significantly more flexible.

Collection Components and Sync Point and all the automatic dependency features of those now work natively with all systems, including Burst-compiled ISystems.

Psyshock Physics Highlights
Layer queries are finally here! You can now Raycast an entire CollisionLayer, or ColliderCast it, or do distance queries with it. You can even query AABBs with custom processors via the new FindObjects algorithm. All of this is accelerated by a new complementary data structure in CollisionLayer, while still preserving O(n) memory and time complexity for construction.

Also, multiple colliders on a Game Object will now bake into a Compound Collider by default. Disabling a collider authoring component will stop it from being baked.

Myri Audio Highlights
Myri has a new Smart Blobber that allows baking procedural audio. The runtime system is also Burst-compiled now, saving about 0.1 milliseconds.

Kinemation Highlights
Kinemation didn't really see any new custom features, but it did get quite a few boosts from the new baking system and runtime.

For starters, the new baking workflow allows for the baking of skeletons to be much more precise in which bones it selects. You can now have a full skeleton parented to another skeleton's bone. And you can have dynamic children of exported bones.

Skinned meshes also got some boosts. There are new inspectors for the binding data to help troubleshoot binding issues. You can also bake meshes with their binding information without baking the skeleton via GetEntity() inside a baker. And many different skinned meshes can all be packed inside the same chunk, so go nuts with a whole bunch of different skinned meshes.

The renderer also saw some major improvements. Kinemation rendering now works in the Editor World, so you can see entity previews of your skinned meshes and even pick them with highlighting. Culling got significantly faster, especially with shadow maps.

What's Next?
For the next few weeks, I will be making minor improvements in functionality and adding low-risk features that didn't quite make it in the 0.6.0 release. As always, bug reports and feedback are welcome!

But there's something I need to tell you about 0.7.

A major requirement of Kinemation in the medium and long term is that it support stretch bones. These are bones that have non-uniform scaling that only affects the offset positions of children, but does not affect children bone scales. Unfortunately, Unity Transforms V2 does not support this. I plan to write an alternative Latios Transforms to recover this functionality.

This means Latios Framework 0.7 will break compatibility with Unity Physics and NetCode.

I'm not sure what the best option will be moving forward. Latios Transforms will be a functional superset of Unity Transforms V2 as they stand today. It may be possible for someone to create modified versions of those packages that work with Latios Transforms.

I've proposed the necessary transforms modification to Unity via multiple channels. If they choose to adopt the changes, then compatibility will no longer be a concern. But in the meantime, I hope this will spark some discussion amongst all of you. You can discuss here on the forums, or via the Latios Framework Discord.

Regardless, the new Transforms in 0.7, while being a breaking API change, will drastically improve both the performance and learning curve of Latios Framework, as the new system will drastically simplify Psyshock's and Kinemation's runtime APIs.

Latios Transforms, Bootstrap profiles, and new samples are my only planned features for the 0.7 development cycle.

Enjoy the new release!

 

Been trying to build my DOTS project, but keeps crashing on load. This is a Mac Release Build with IL2CPP. The full crash log is attached and all the settings. I've tried everything that I know, but still no luck. I see the Unity Logo when I opened the build and that's it.

Debug Crash Log: (Full Log is attached)
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x000000315e65e718
Exception Codes: 0x0000000000000001, 0x000000315e65e718
Exception Note: EXC_CORPSE_NOTIFY
Termination Reason: Namespace SIGNAL, Code 11 Segmentation fault: 11
Terminating Process: exc handler [17906]
VM Region Info: 0x315e65e718 is not in any region. Bytes after previous region: 206045308697 Bytes before following region: 105341079132392
REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL
VM_ALLOCATE 165201000-165240000 [ 252K] ---/rwx SM=NUL
---> GAP OF 0x5ffe9adc0000 BYTES
MALLOC_NANO 600000000000-600008000000 [128.0M] rw-/rwx SM=PRV
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 GameAssembly.dylib 0x13dbbb81c BlobArray_1_GetUnsafePtr_mFF5B95F44D1DA647D85710F4F943530974FE71FF_gshared + 428 (Generics2.cpp:18792)
1 GameAssembly.dylib 0x13dc87eed BlobArray_1_GetUnsafePtr_m1C36E9770A33F35255BFCC18D7FA21E4863771FE(BlobArray_1_t112C49ADFEB7465DC55221B4D8E6C721002D4D16*, MethodInfo const*) + 29 (Unity.Entities.cpp:5177)
2 GameAssembly.dylib 0x13ec48188 DotsSerializationReader__ctor_m315258F39B2C56305ECFFEE3EF95561BDC5CD4DA + 440 (Unity.Entities9.cpp:31573)
3 GameAssembly.dylib 0x13ec47eed DotsSerialization_CreateReader_mD449775FCAA012FBD6CF131CB7C488037D473745 + 365 (Unity.Entities9.cpp:28582)
4 GameAssembly.dylib 0x1497ac073 AsyncLoadSceneOperation_UpdateAsync_m25C4533BE332945DB9ACFCF80AB913B132653253 + 3987 (Unity.Scenes.cpp:14767)
5 GameAssembly.dylib 0x1497aed02 AsyncLoadSceneOperation_Update_m07545C9F8CDA2DC5FB6D4450C59924B66BEBC6BD + 706 (Unity.Scenes.cpp:15482)
6 GameAssembly.dylib 0x14980a1e7 SceneSectionStreamingSystem_UpdateLoadOperation_m808052F10FF4966DB2C5563A77A366953377AD5A + 967 (Unity.Scenes.cpp:36044)
7 GameAssembly.dylib 0x149808fc2 SceneSectionStreamingSystem_ProcessActiveStreams_m6300856C6B8532C6B75E14029910E8D17B39135E + 1426 (Unity.Scenes.cpp:35669)
8 GameAssembly.dylib 0x14980fef7 SceneSectionStreamingSystem_OnUpdate_m48E550F61E3B9720FA4CBC7B99BE33FD55750A85 + 10455 (Unity.Scenes.cpp:37499)
9 GameAssembly.dylib 0x13bf8e294 VirtualActionInvoker0::Invoke(unsigned short, Il2CppObject*) + 180 (mscorlib9.cpp:21)
10 GameAssembly.dylib 0x13ed98a96 SystemBase_Update_m795994EE60C054DFA78C313A60ED025B2668C9B4 + 4294 (Unity.Entities8.cpp:18917)
11 GameAssembly.dylib 0x13bf8e294 VirtualActionInvoker0::Invoke(unsigned short, Il2CppObject*) + 180 (mscorlib9.cpp:21)
12 GameAssembly.dylib 0x13dcf65bf ComponentSystemGroup_UpdateAllSystems_m78B1AA9EAF07133497E9BA556B592AC93935441C + 4095 (Unity.Entities.cpp:39399)
13 GameAssembly.dylib 0x13dcf5162 ComponentSystemGroup_OnUpdate_m83128938DF97469E0D1CB883E5C9000C0C2DA9A7 + 1154 (Unity.Entities.cpp:39031)
14 GameAssembly.dylib 0x13bf8e294 VirtualActionInvoker0::Invoke(unsigned short, Il2CppObject*) + 180 (mscorlib9.cpp:21)
15 GameAssembly.dylib 0x13dcda63b ComponentSystem_Update_mC7F35C2595C5D67B4A4724A65C1D0CBFFAB56C3C + 4267 (Unity.Entities.cpp:32612)
16 GameAssembly.dylib 0x13bf8e294 VirtualActionInvoker0::Invoke(unsigned short, Il2CppObject*) + 180 (mscorlib9.cpp:21)
17 GameAssembly.dylib 0x14778562d SuperSystem_UpdateManagedSystem_mB713FAAB83E71F83463C5A0F15EAC2597108EBDF + 2397 (Latios.Core.cpp:28233)
18 GameAssembly.dylib 0x147786d4e SuperSystem_UpdateAllSystems_m925B52801E549E51A38A6EE15E50AB25A873D04F + 4798 (Latios.Core.cpp:28495)
19 GameAssembly.dylib 0x1477827ec SuperSystem_DoSuperSystemUpdate_m4F77E6C94FB39D60EC8251C1A19715F3B4757C49 + 2252 (Latios.Core.cpp:28694)
20 GameAssembly.dylib 0x13e7fdeb7 LatiosInitializationSystemGroup_OnUpdate_mD7A56B5300E915674AB179212065A169F6F6C94A + 615 (Latios.Core1.cpp:34115)
21 GameAssembly.dylib 0x13bf8e294 VirtualActionInvoker0::Invoke(unsigned short, Il2CppObject*) + 180 (mscorlib9.cpp:21)
22 GameAssembly.dylib 0x13dcda63b ComponentSystem_Update_mC7F35C2595C5D67B4A4724A65C1D0CBFFAB56C3C + 4267 (Unity.Entities.cpp:32612)
23 GameAssembly.dylib 0x13bf8e294 VirtualActionInvoker0::Invoke(unsigned short, Il2CppObject*) + 180 (mscorlib9.cpp:21)
24 GameAssembly.dylib 0x1452f08a7 DummyDelegateWrapper_TriggerUpdate_m2C37F16899DE9C87FE35B065E0FF7E410E463FE7 + 535 (Unity.Entities7.cpp:40118)
25 GameAssembly.dylib 0x14884eeaa UpdateFunction_Invoke_m9BCEE4E5BEE924EB804DA64314B78D0E831C179B + 42 (UnityEngine.CoreModule2.cpp:23235)
26 GameAssembly.dylib 0x14708890a RuntimeInvoker_TrueVoid_t4861ACF8F4594C3437BB48B6E56783494B843915(void (*)(), MethodInfo const*, void*, void**, void*) + 42 (Il2CppInvokerTable.cpp:86117)
27 GameAssembly.dylib 0x14a5db58e il2cpp::vm::Runtime::InvokeWithThrow(MethodInfo const*, void*, void**) + 94 (Runtime.cpp:576)
28 GameAssembly.dylib 0x14a5db35a il2cpp::vm::Runtime::Invoke(MethodInfo const*, void*, void**, Il2CppException**) + 218 (Runtime.cpp:562)
29 GameAssembly.dylib 0x14a58f6ed il2cpp_runtime_invoke + 45 (il2cpp-api.cpp:1121)
30 UnityPlayer.dylib 0x117cc7afc scripting_method_invoke(ScriptingMethodPtr, ScriptingObjectPtr, ScriptingArguments&, ScriptingExceptionPtr*, bool) + 140
31 UnityPlayer.dylib 0x117ccf846 ScriptingInvocation::Invoke(ScriptingExceptionPtr*, bool) + 166
32 UnityPlayer.dylib 0x117818cdd ExecutePlayerLoop(NativePlayerLoopSystem*) + 157
33 UnityPlayer.dylib 0x117818d5a ExecutePlayerLoop(NativePlayerLoopSystem*) + 282
34 UnityPlayer.dylib 0x117819063 PlayerLoop() + 307
35 UnityPlayer.dylib 0x11899f02a -[PlayerAppDelegate UpdatePlayer] + 410
36 Foundation 0x7ff81ae1ff21 __NSFireTimer + 67
37 CoreFoundation 0x7ff819f9af69 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 20
38 CoreFoundation 0x7ff819f9aa58 __CFRunLoopDoTimer + 923
39 CoreFoundation 0x7ff819f9a5c8 __CFRunLoopDoTimers + 307
40 CoreFoundation 0x7ff819f80cd6 __CFRunLoopRun + 2010
41 CoreFoundation 0x7ff819f7fe3c CFRunLoopRunSpecific + 562
42 HIToolbox 0x7ff822c2f5e6 RunCurrentEventLoopInMode + 292
43 HIToolbox 0x7ff822c2f34a ReceiveNextEventCommon + 594
44 HIToolbox 0x7ff822c2f0e5 _BlockUntilNextEventMatchingListInModeWithFilter + 70
45 AppKit 0x7ff81c9b9fad _DPSNextEvent + 927
46 AppKit 0x7ff81c9b866a -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1394
47 AppKit 0x7ff81c9aad19 -[NSApplication run] + 586
48 AppKit 0x7ff81c97ec97 NSApplicationMain + 817
49 UnityPlayer.dylib 0x1189a2966 PlayerMain(int, char const**) + 1206
50 dyld 0x116efe52e start + 462

 

Can you outline the use cases for stretch bones?

Breaking compatibility with Unity Physics and Netcode is not an option for me, but I want to decide whether I'll go the route of forking Kinemation (and make it not use stretch bones), or forking Unity Physics/Netcode and make them use Latios Transforms.

 

Unfortunately, my best example I have isn't something I am ready to share yet. But I'll try and walk through an example.

In Blender, with the Rigify addon enabled, I created a humanoid rig (and generated the actual rig) and then parented two meshes to two bones, the upper arm, and the hand.


Next, in top-down view and in Pose mode, I have enabled the ARM IK controls and selected the hand IK bone. I've also set the bones to render in front of everything to make it easier to see what happens.



Notice the bones stretch non-uniformly, and the box stretches with it. The hand moves with the IK control, but the sphere retains its shape.

This behavior is very desirable for animators, as it achieves a "squash and stretch" of individual limbs without shearing fingers or held weapons. While it is especially useful for more cartoonish animation, this type of stretching happens in real life too, though it is usually much more subtle.

If you tried to import this configuration as FBX into classical Unity with GameObjects, the sphere would deform and stretch.

Game engines have been notoriously bad at supporting this behavior, which is why anyone using a game engine for cinematics will typically use alembic for transfer and bake their animations into a mesh cache.

Typically for games, animators might choose to not scale bones at all, resulting in stiff animations. Or they might flatten the bone hierarchy and make all bones parented directly to the root, which isn't useful when you want runtime IK. Or they might introduce a bunch of intermediate bones that get displaced relative to each other and clever bone weights to fake the effect of stretching. That hurts performance and is more prone to texturing artifacts.

In Transforms V2 today, the animation with the non-uniform scaling isn't even possible to represent. And if you tried to recreate it with PostTransformMatrix, the hand bone would be in the wrong spot.

In Transforms V1, you can recreate what is in Blender using ParentScaleInverse.

With Latios Transforms, scale is split into uniform inherited scale and non-uniform non-inherited scale. Which means what is in Blender will work out-of-the-box without any additional setup.

The non-uniform scaling has other use cases in games as well. Think anything that has physical properties similar to a bungee cord.

Does this clarify things sufficiently?

 

You might not need to create a fork for NonUniform scale support: Just scrolling through the changelog for Entities 1.0.0-pre.15 and found this: “This path is slightly slower, but supports additional features like PostTransformMatrix (for non-uniform scale)”