Other [0.9.4] Latios Framework for ECS megathread

Unfortunately, that feature completely fails to cover the use case.
1) PostTransformScale is completely ignored by TransformAspect, meaning any positioning between local space and world space will get out of sync. In my example, the hand will never be positioned in the correct location.
2) The propagation tag doesn't help either because it makes the child inherit the scale, which would cause the hand to deform in ugly ways.
3) While Unity has acknowledged that they have heard my feedback, they have chosen to completely ignore it, because LocalToWorldSystem still has the change version race condition bug I called them out on.

The TransformAspect doing the wrong thing is the main reason I am writing my own transform system rather than extending Unity's. But even so, there's some really cool things I can do if I ensure that non-uniform scale is only a float3. The biggest being that I will be able to remove 64 bytes per render entity from the archetype when using the Kinemation renderer, which will drastically improve chunk occupancy, memory usage, and performance.

 

On 1), what if you don't support TransformAspect, but just the Transform System V2 components? (I personally don't get the benefit of Aspects)

Or, in other words, would PostTransformScale conceptually be a solution for stretch bones? Perhaps requiring small divergence vs a complete overhall?

I understand LatiosTransform may still be preferrable to you. But breaking compatibility with Unity Transforms would make Latios an "all or nothing" framework, which would drastically diminish it's benefit to the community. For instance, I won't be able to continue using/developing DMotion unless I fork Kinemation now.

 

All the learning resources on DOTS are focusing on aspects. Not supporting TransformAspect would be super bug prone. Plus any third party asset that used it would just straight up break everything silently. The mixed approach creates too much confusion. It is much easier for me to make an API that strongly resembles Transforms V2, but also does the things I need it to do.

If it was accounted for correctly, it would work, but would also lose all the performance advantages a QVVS system has over a matrix system.

I don't like breaking compatibility. I would much rather Unity do something smart and support the use case that has been in nearly every DCC application for the last 10 years. But Unity Transforms do not support my use case. I can't use it. So if I want to use DOTS, I have no choice but to roll my own solution. Making it compatible just to help the community but to make it useless for myself? For as much as I try to help the community, even I have my limits.

As for DMotion, based on our other conversation, I don't believe that changes my situation in any way. EDIT: Just saw your most recent reply. I will follow up there.

Forks aren't the only option though. I could see a route where you or others could contribute a different mode to the framework that disables exposed skeletons and uses Unity Transforms for everything else. I'm willing to guide that process. I just can't justify doing the work entirely myself, especially with how many other features I still need to develop. It may also be that compatibility could be added for Unity Physics without a fork and just a couple custom systems for the acquire and write-back stages.

But I'll be honest, if you want to fork Kinemation, I suggest forking ACLUnity to make it exclude scale animation from the clips, and to make BoneTransform not have scale values.

 

Honestly my preference is towards the solution with minimal divergence from Kinemation. Good to know that a different mode is an option, I'd be happy to implement it. I'll reach out in the future, after version 0.7, to discuss how I can help with this.

 

Latios Framework 0.6.1 is out!
This is a compatibility release for the latest Entities 1.0.0-pre.15 and associated packages.

Besides compatibility and bugfixes, there's two new features to try out!

The first is a new SystemRng. The new Rng workflow makes use of system entity components and IJobEntityChunkBeginEnd to provide optimal performance for use with ISystem and IJobEntity.

The second is a new API for overriding MeshRenderer baking when Kinemation is installed. This allows you to make procedural meshes in a baker and have them be baked properly as if you had assigned the mesh right before baking. Same goes for materials. I suspect someone could extend this to make it automatically work with ProBuilder or other tools.

I know quite a few of you have been watching closely to the state of Transforms recently. The good news is that Unity doesn't appear to have fully locked down on the API yet (I had believed they had prior to today). There's still hope for incredible intuitive high-performance transforms that will allow animation to reach a new level in Unity!

But, even if that doesn't happen, it isn't the end of the world. I had a lot of time to think through what it would take to make the framework work with Unity Transforms if such an effort was community-driven. As it turns out, it might be easier than I initially estimated. Most of the framework just wants to read the world-space transform. In fact, that is all Psyshock and Myri care about today. Kinemation has a couple of trickier situations though:

1) The bakers will need to somehow decide which transform components to add, probably by reading some project config variable or something. I don't know what that would look like or how intuitive it could be.
2) Exported bones will require writing to the correct transform components.
3) I have no idea what the future has in store for IK and dynamics.

If you want to see what the new Latios Transforms may look like data-wise, I've pushed some code here: https://github.com/Dreaming381/lsss...ckages/com.latios.latios-framework/Transforms

I have at least one more patch release planned for 0.6.x addressing a GPU battery life issue and a LOD performance issue. After that, I plan to start on 0.7 development. I may bring other things into the scope of 0.7 if Unity takes their time with the next prerelease (which I hope they do).

Enjoy the release!

 

Newcomer here. I just read through this thread. I’m very interested in Kinemation! But not supporting Unity Physics or Netcode would be a deal breaker for me. Any news on compatibility there? Either way this is a really cool project. Major respect!

 

Actually yes. I finally have some answers after the DOTS Dev Blitz Day.

I will be moving forward with Latios Transforms. Latios Transforms have several significant advantages:

• Single component world-space transform for everything
• Non-uniform scaling support that works with the TransformAspect
• Support for larger worlds
• Tight integration with other modules (including significant rendering optimizations)

However, this does pose challenges with compatibility.

Physics:
There are three options:

• Extend Unity Physics to support Latios Transforms (may or may not require package modifications)
• Extend Kinemation to support Unity Transforms for Physics
• Achieve feature parity in Psyshock

I'm personally going to be working towards the third option (though don't expect anything to be ready until 2024). It will be up to the community to implement the other two. However, I will do my best to be supportive and helpful in that process! If any of you decide to take on this work, do not hesitate to reach out to me!

NetCode
My current plan is to do a NetCode deep-dive after the Latios Framework 0.7 release with Latios Transforms. Assuming I don't hit a wall, you can expect that I will provide some feature-parity solution for NetCode (minus predicted physics simulation initially). Whether that be extensions or a fork, I don't know yet. But I have high hopes!

Asset Store Packages
I don't have a great answer to this. Actually, the Asset Store has become my greatest enemy as of late. People who want to create free assets for the community are heavily incentivized to put there assets there. But what most people don't realize is that the Asset Store EULA disallows using "free" assets in sample projects or demos. So for me to create such learning resources, I have to create everything from scratch.

There's 50+ people at Unity working on DOTS, and only one of me. I have to be savvy with my time and pick my battles, and sometimes I will have no choice but to make unpopular decisions, as the popular decision is not practical for me alone. But the moment it becomes more than just me, that all changes and anything is possible!

 

Latios Framework 0.6.2 is out!
This is a small bugfix release which should help battery life performance on mobile devices by replacing the GPU buffer recycling method from async readback to a fixed frame count.

I have decided to postpone the LOD performance issue to a later release when I will be reworking the relevant code for other reasons. In practice, it is pretty rare that it has much of an impact on performance.

Speaking of performance, I know most of you are waiting for 0.7, but I would appreciate if you took the time to go through the Kinemation Getting Started Guide for 0.6 and tested out the performance for yourself. Now that the BRG regression is resolved, I'm very curious what kinds of performance you see. I've noticed a pretty significant boost over 0.5 with a larger variety of skinned meshes.

Anyways, I'm starting 0.7 development now. One thing I've been struggling with has been deciding how much time to spend on learning resources rather than features. The last survey hasn't been as effective as I would have liked, so I am going to try a new policy.

If 10 people ask for a sample on a specific topic within a month's time-frame, I will prioritize that sample. If 25 people ask for a video on a specific topic within a month's time-frame, I will prioritize that video. And lastly, should anyone provide help with these resources, I will slash those requirement numbers.

Otherwise, I'm going to focus on features, documentation, and open projects. Feel free to make requests regarding any of those things as usual.

For anyone who is just discovering me now that these forums are more public, welcome! Do not hesitate to PM me if you like. Or if you prefer Discord, I have a Latios Framework Discord here.

Enjoy the release!

Edit: 0.6.3 is out and is another small bugfix release, but for Psyshock.

 

Latios Framework 0.6.4 is out!
This is a bugfix release addressing a variety of issues brought to my attention over the last few days, and addresses issues in Core, Psyshock, and Kinemation.

Special shoutout to Dechichi01 for the Core and Kinemation reports, which helped me identify some very "interesting" Unity baking behavior!

Just a reminder that GameObjects that are direct children of an Animator with an optimized hierarchy will be treated as exported bones and will have corresponding optimized bones in the skeleton's buffer. There's no Unity API to figure out whether a Transform is driven by an Animator with an optimized hierarchy, so I don't believe I can improve this automatically. I've considered adding a special authoring component to exclude a GameObject from becoming an exported bone, but I'm not sure I want to go down that route yet. Let me know your thoughts.

2022 Has Been A Crazy Year
The first half of the year, I started heavily teasing Kinemation. People were genuinely interested in the potential, even moreso after 0.50 dropped and Unity.Animation was excluded. Several months later, I finally released 0.5.0 with Kinemation. It was a little buggy to begin with, and at the time it only supported Windows. But several of you jumped onboard anyway and helped guide it through the next 8 patch releases to become something powerful. I got to watch people make giant battles, or use Rival to control a character driving a DMotion state machine. Compatibility was excellent. It started to feel like classical Unity again, and it felt amazing to be a big part of it!

Then Entities 1.0 experimental came in hot and messy. Ignoring the number of breaking changes it made to the low-level APIs which took me several weeks to fix (though to be fair, my "fixes" involved fixing a lot of Core's own tech debt), the new release came with a challenging tradeoff. On one hand, the performance ceiling increased substantially. Kinemation is faster than ever, especially on the main thread. It is now possible to have hundreds of unique characters in large worlds without fragmenting chunks. But the downside is that "compatibility" was a short-lived luxury.

By the time Unity released 1.0, they had already committed to their designs along with all their flaws. They treat these designs as "defaults", with the expectation that people will modify the packages as needed. It is the same philosophy that drove Scriptable Render Pipelines, but just like SRPs, this is shaping up to become a compatibility and extensibility nightmare.

When those flawed designs no longer met my use cases and future plans, I panicked. I said a lot of things I now regret. I was short with people. And my words may have come off as threatening and manipulative. I'm sorry to everyone who had to deal with this. I didn't want compatibility to die. I still want to be part of a DOTS ecosystem, but given the direction of Unity no longer fully aligns with my goals, that is much more difficult.

What To Expect In 2023
This next year is going to be different. The days of trying to be compatible with everything are over. Rather, it seems my only way forward is to build the best tech stack that I can, and hope that it leaves a big enough impression that a community and ecosystem evolves around it. It is going to become increasingly difficult. With Entities out of experimental status, assets on the asset store which do small parts of what the Latios Framework does are bound to pop up, each with their own tradeoffs, and surely with out-of-the-box compatibility with Unity's flawed defaults. I've already spotted some promotional videos of such.

So what does the future of the Latios Framework look like?

For starters, Latios Transforms are going to take over and make a bigger impact. Psyshock and Kinemation will work out-of-the-box with dynamically scaled and stretched entities, allowing for all sorts of stylized gameplay and effects. Kinemation's renderer will become even more aggressive at omitting unnecessary work and keeping archetypes smaller so that more entities can fit into chunks. Psyshock and Myri will be more tolerant of transform manipulations anywhere in the frame, and better respect transform hierarchies. And Transforms themselves will have simple rules that you can rely on even for advanced use cases.

But there is more. NetCode, IK, physics simulations, character controllers, audio mixing controls, world-space ECS text, improved authoring experiences, more samples, more videos; these are all things that I would love to take on in 2023. But without help, I won't be able to even cover a quarter of these things.

I also want to focus on stability, making this framework rock-solid so that bugs like the ones addressed in today's release don't ever make it into a release in the first place. But that requires real-world projects, which is why I develop LSSS and ATAR. But there's a chicken-and-egg problem here. Art is challenging. With enough iteration and feedback, I can eventually create a 3D art piece I am happy with, but it takes me a looooong time to get there. One of the projects I plan to use Latios Framework for is a tool that will drastically accelerate this process. However, that requires I have the features of the framework working, which requires that I have it tested with art made without such a tool. Without help, progress in this area will also be quite slow.

All of this is to say that much more than previous years, how much value the Latios Framework provides for the DOTS community in 2023 is going to depend on how much love the community pours into the Latios Framework.

What Is Next?
Latios Framework 0.7 is in active development, and is on track for a February release. It will come with Latios Transforms, a change to how bootstraps work to allow for "profiles", and lots of changes to the various APIs.

Core will ditch the Improved Transforms and Extreme Transforms features, as alternatives will be present in Latios Transforms. But apart from bootstraps, most of the required changes have already been made in 0.6.

Psyshock will see a big change in its static API. Currently, overloads of all the static APIs exist for all combinations of collider types. I plan to remove all of these, and only expose the generic Collider versions of these APIs. This will come with a performance hit if you were using the specialized variants, as everything will have to go through the dispatcher tables. But this will help simplify Psyshock's API footprint and allow me to better identify and target hot paths in the code. If you are ever wanting more performance out of Psyshock's APIs, I encourage you to reach out to me. Aside from FindPairs broadphase algorithm, I have spent very little time optimizing Psyshock.

Myri will likely see the least amount of changes in 0.7. It will switch to using Latios Transforms, but apart from that, it will continue to work as it has been. I do have big plans for Myri in the future, but it has been difficult to prioritize them.

Kinemation will see some pretty big changes. Latios Transforms will make squash-and-stretch bones the default behavior, while still preserving root scaling to keep your characters sized correctly in the world. Motion vectors will be fully supported, which means exposed skeletons will have transform histories. This will also allow for inertial blending. Optimized skeletons will use an IAspect for managing the bones. While the underlying components will still be accessible, direct usage will not be recommended. The aspect will handling blending, synchronization of local and world spaces, motion vector and inertial blending transform history and memory rotation, and perhaps a few other features. I also plan to rework a few things to use enableable components. And lastly, expect new versions of ACLUnity.

Latios Transforms will be new, but also quite familiar to those who have worked with Transforms V2. It will follow the same paradigm where you either want to read from WorldTransform or you want to write using TransformAspect. Unlike Unity Transforms, LocalTransform is only present when a Parent is around, and the ParentSystem enforces the archetype. In addition, there are no write groups nor a LocalToWorld. There is a PostProcessMatrix if you need shearing or offset-scaling for rendering. And there is an IdentityLocalToParentTransformTag for locking down the local-space transform (and shrinking the archetype). While the LocalTransform and WorldTransform components are different than Unity, you will find a comprehensive set of APIs similar to Unity either in TransformAspect or the static qvvs class.

All of this in two months. I hope you are hyped!

How To Help Before 0.7
In the meantime, aside from continuing to find bugs in 0.6, you can help out by bringing ACLUnity to mobile platforms. Mobile performance with Entities Graphics is a lot better now.

Otherwise, you can help out with the art and design of ATAR. Don't hesitate to reach out to me if you are interested in that.

And lastly, if you have any character models which have traditionally been problematic in Unity, either due to some weird import you don't know how to fix, or animations not working correctly due to scaling causing weird shearing artifacts in Unity, or objects getting detached, or whatever anything; send them to me so that I can add them to my test cases. I fully intend that Kinemation will be able to handle models that classical Unity cannot.

Enjoy the release, and have a happy new year!

 

After installing version 0.6.4 many errors appeared

Library\PackageCache\com.latios.latiosframework@65ad140350\Core\Systems\Transforms\ExtremeHierarchy\ExtremeParentSystem.cs(69,20): error CS0246: The type or namespace name 'NativeMultiHashMap<,>' could not be found (are you missing a using directive or an assembly reference?)

Library\PackageCache\com.latios.latiosframework@65ad140350\Core\Systems\Transforms\ImprovedTransforms\ImprovedParentSystem.cs(68,20): error CS0246: The type or namespace name 'NativeMultiHashMap<,>' could not be found (are you missing a using directive or an assembly reference?)

(8 errors)

Editor 2022.2.7f1
Entities 1.0.0-pre.44 +
ENABLE_TRANSFORM_V1 +
IL2CPP +
Faster (Smaller) Builds +

What could be the problem? what am i missing?

 

Problem solved, these errors were due to the newest version Entities 1.0.0-pre.44, need to roll back to version Entities 1.0.0-pre.15...

 

On that subject, it was just a change of the name NativeMultiHashMap to NativeParallelMultiHashMap. Functionally, you could embed the LF package and rename references yourself if you were so inclined.

 

Other way is: enable C#10 using csc.rsp and use Global Usings with *.asmref to map new names to old ones
not tried this myself actually

 

Latios Framework 0.6.5 is out!

This is NOT compatible with the latest prerelease 44 of Entities. While I do have a changeset that should theoretically work with that release, there are major stability issues and silently failing bugs that Unity needs to work out. I may post an experimental branch with that changeset for anyone who wants to try and track the issues down.

Instead, this release is a bugfix release, with contributions from both @Dechichi01 and canmom on the Latios Framework Discord. It contains mostly build fixes and Psyshock improvements.

As for 0.7, there’s been some updates. If you follow the Discord, you already know about this, but for everyone else, I will summarize here:

0.7 has been heavily delayed due to technical reasons with regards to the skinned mesh rendering system that resulted in a major scope change. Consequently, larger skeletons, blend shapes, dynamic meshes, dual quaternion skinning, custom shader graph nodes, and several other features will all be included in 0.7. I plan to have alpha versions available next month, with a release goal around May.

If you want to be involved to help speed up the process, don’t hesitate to reach out! Discord is typically the fastest way to reach me, but other channels work as well. There’s a ton of work to do to make this release mind-blowingly awesome!

Enjoy the release!

 

That’s… quite the first post from someone with the “Unity Technologies” badge on this thread.

Regardless, your statement does not change the situation that prompted me to write those words, nor is this the place to argue about that. I’ve sent you a PM. I hope that there we can have a real technical conversation about the challenges that led to this mess in the first place, and solutions to those challenges that can result in us being better aligned moving forward.

 

Latios Framework 0.6.6 is out!

This is just a small bugfix release for Kinemation.

But perhaps more interestingly...

Latios Framework 0.7.0-alpha.1 is out!

This release is infested with creepy crawlies, and you should not attempt to “upgrade” to it. Only experiment with throw-away projects and get a feel for the new design and APIs (inline XML documentation is up-to-date). APIs are not finalized.

Included is Latios Transforms, or perhaps better named Transforms QVVS? Similar to Unity Transforms V2, this is a vector-based transform system in which a TransformAspect keeps the local and world positions roughly in sync. However, Latios Transforms has a few key advantages that set it apart.

Stretch


It might seem a little unintuitive at first, as unlike normal scale values which fully scale children, stretch only scales the positional offsets of the children relative to their stretched parent. Stretch is always local-space axis-aligned, meaning shearing is impossible. Shear is a presentation-only concept and can be realized with special rendering PostProcessMatrix components.

WorldTransform is WorldTransform

LocalToWorld is nowhere to be found. You never have to wonder whether WorldTransform or LocalToWorld is the most accurate world transform. The answer is always WorldTransform.

Smaller Archetypes

With LocalToWorld gone, archetypes get much smaller. A single world-space entity only requires 48 bytes of transform data compared to the 128 bytes in Transforms V2. All transform archetypes in Latios Transforms are at least the same size if not smaller.

Smarter Parent System

The Parent System in Latios Transforms has been completely redesigned algorithmically to be significantly more robust to edge cases. Entity.Null Parent components will simply be removed rather than crash. And any invalid transform archetype will automatically be fixed to one of the correct archetypes. The child buffer order is fully deterministic as well as change versions on said buffer. On top of this, the system is significantly more parallelized, and even manages to schedule work on the worker threads while performing structural changes.

Transform History

There is built-in support for tracking the previous world transform and the transform before that. You can always figure out how a kinematic object is moving with just these components. They are optional.

Rendering Optimizations

Latios Transforms is paired with the Kinemation renderer, which on top of the material property optimizations in 0.6 comes with some additional improvements. Triangle winding calculations are significantly cheaper, as a determinant is replaced by simple sign checks. In addition, the matrices used by shaders are now computed in the upload compute shader. The CPU never has to convert the WorldTransform to matrices. Plus, unlike with LocalToWorld which needed to perform four 12-byte memcpy operations for each matrix during upload, the new uploader can raw memcpy the WorldTransform component array directly to GPU-accessible memory, which better utilizes the CPU’s SIMD hardware.

There's lots of other changes, but they are heavily under-tested, so I will save those highlights for the official release.

What’s Next?

Feel free to try out the alpha, submit bug reports and pull requests, ask questions, ect.

Besides exterminating bugs, there are a few features planned that aren’t in this alpha. Core will likely see a new Bootstrap workflow which will allow switching bootstraps in the editor. Psyshock may see some debugging improvements. Myri will get audio layer support and better mixing controls. And Kinemation will continue to receive more IAspect types and extra skeleton baking utilities. There may be more in store depending on what comes up.

I won’t be updating this thread with every alpha and beta release. So follow GitHub or Discord if you want to keep up with the latest updates!

Enjoy the releases!

 

L Transforms
L is for "House of L" and so:

 

Hallelujah!!!! OMG. Transforms which work. I was very surprised that Unity's default Transforms are not working properly... Can't use WorldTransform at all. Hopefully there will be a LocalPosition/WorldPosition access through the IAspect which actually does what it says on the tin in yours.

And a custom bootstrap - Amen! Written that one myself before, but seems you've done the hard bit. Saves my take - hopefully :fingers-crossed:

Shall try your framework a bit deeper later.

Thanks for what you do good job!

 

I'm curious about QVVS, what does it mean actually?

 

[Q]uaternion - rotation
[V]ector - position
[V]ector - stretch
[S.]calar - uniform scale

 

I saw your other thread, and unfortunately it is not going to work quite the way you expect. Just like Transforms V2, child entities keep a cached version of their parent transforms, and this is only updated once per frame (or however often you update the Transform Systems). I do plan on having fully synchronous modes in the future, but these will take some time to figure out how to make performant. I could go into a lot of detail on the nuances involved.

There are LocalPosition/WorldPosition properties on TransformAspect. The TransformAspect API is fairly comprehensive, though I will gladly accept PRs for additional utilities you might want added!

 

Update once per frame would be enough. But it seems it never gets updated in my case, when using Unity's TransformAspect WorldPosition/WorldTransform. I mean it gets updated on baking, but that's about it. Later I can move the parent as much as I want, but the children WorldTransforms stay the same they were when they got baked.

I assumed that calling TransformAspect.WorldPosition -> it would calculate the world position or it would get the position from the world transform, which got updated during the TransformSystem run. However, WorldTransform never updates - not this frame, not ever.

EDIT:

Though LocalToWorld gets updated, so I'm a bit lost on why there are two transforms storing the same information. If I get LocalToWorld.Position it returns the right position. But if I call TransformAspect.WorldPosition - it returns WorldTransform.Position, instead of LocalToWorld.Position. Everything would work, if WorldTransform ever got updated.

Unless I'm misunderstanding the meaning of WorldPosition, and WorldPosition is not a world position, and the documentation doesn't explain it properly.

 

The issue you are encountering is likely due to something using WriteGroups to bypass WorldTransform and write directly to LocalToWorld. I've heard rumors of this being a problem in Physics and/or NetCode. Haven't investigated personally.

But yeah. This sort of confusing behavior is impossible to have with Latios Transforms. If you encounter confusing behavior, report a bug.

 

Yeah, I have noticed a couple of people mentioning Unity.Physics messing it up. Maybe that's the case, cuz I use PhysicsVelocity.Linear to move items. Maybe that's some kind of optimization for physics? "Like" this kind of behaviour... pulling the rug from under you... :facepalm:

 

Ok, time for me to join this wonderful train of goodness. I'm beyond impressed by the breadth of features and clean code, as well as many of the abstractions (some I don't understand but maybe this will change )

But before I get ahead of myself - do I get this right from the github page - 0.6.6 does not work with Entities 1.0.0-pre47?

 

Unfortunately no. I only officially support Pre.15. When I tried creating the patch, I encountered this issue: https://forum.unity.com/threads/pre-47-closed-subscenes-wont-load-with-zero-errors.1406512/

However, I've shared the version used to submit that bug here: https://github.com/Dreaming381/Latios-Framework/issues/28

You might have better luck than me. If you try it, definitely share your results!

 

Hey everyone.

The latest Entities release definitely shakes things up. I’m still trying to figure out how to best approach things, and I would love all of your feedback on the situation!

First off, Latios Framework 0.6.X is dead. You can still submit bug reports, but there won’t be any more patch releases. I will only be supporting the 0.7.X series moving forward.

Second, I plan to make a pretty big change to the documentation. Currently, documentation is synchronized with releases in the same repo. I plan to split that into a separate repo and update that more frequently with guides and such. Initially, I also wanted to generate API documentation via DocFx, but I have struggled to make that work and have exhausted my patience trying to get that working on my own. If this is something you want to see and have expertise in, let me know!

Third, I am heavily considering dropping Myri and Bootstrap changes for 0.7 to get the 0.7 official release out faster.

And now what you are all probably wondering about, what about Transforms?

The good news is that the new Unity Transform System (which I will refer to as Transforms V3) can be extended to support my “must have” use-cases. However, Latios Transforms still have a lot of advantages. Let me break it down:

First, what is the same:

1) Both transform systems have an end-all-be-all world transform component. In Latios Transforms, this is WorldTransform. In Transforms V3, this is LocalToWorld.

2) Both transform systems are able to represent stretch. In Transforms V3, this can be done with extra components and WriteGroups.

3) Both transform systems have predictable and well-defined archetypes. This is one of the major ways that Transforms V3 improved over Transforms V2. While Latios Transforms has a superior ParentChangeSystem, it is now possible to make a version of that system that works with Transforms V3.

And now what is different:

1) Latios Transforms has a TransformAspect. And unlike Transforms V2, it accomplishes its design goals 100% of the time. This means that you can get or set an approximate world transform at any time. Transforms V3 does not have TransformAspect.

2) Latios Transforms have different memory requirements. For root entities, Latios Transforms uses half the memory of Transforms V3 (48 vs 96 bytes). For child entities, Transforms V3 uses 112 bytes, whereas Latios Transforms uses 144. However, adding stretch to Transforms V3 would require an additional 64 bytes putting the total at 176 bytes.

3) Latios Transforms have hyper-fast root entities. Matrices do not get computed on the CPU. Roots don’t need to be updated by a transform system at all. The Kinemation renderer is able to consume QVVS directly and compute the float3x4 matrix on the GPU in a compute shader, which is essentially free.

4) Latios Transforms have fast access to world-space rotation. You can just ask for it directly. Whereas with Transforms V3, we are back to Transforms V1 techniques where we need to extract it from matrices. The scaling extraction bug seems to still exist, so you can’t rely on the Rotation property to get it.

5) Latios Transforms have faster rendering support. Triangle winding is much cheaper to compute per frame. Transform uploads have better SIMD support.

6) Latios Transforms are required for Dual Quaternion Skinning. Dual quaternion Skinning in Kinemation breaks when shear is present. Latios Transforms not only enforces this, but also presents the data in a friendly format to convert into dual quaternions. If Transforms V3 was used, dual quaternion support would have to be dropped for exposed skeletons. Optimized skeletons would remain unaffected as they could continue to use the TransformQvvs type.

7) Latios Transforms will always support stretch, no matter what abstractions Unity adds to Transforms V3 in the future. Latios Transforms is stable design-wise.

8) Transforms V3 will likely have compatibility with other assets. Latios Transforms do not yet.

Right now, my mindset is to continue working with Latios Transforms, as it solves my use cases better. I have it working with LSSS, and the next step is to iron out issues with animation that remain. I’ll likely be doing that first, cut a new alpha release, and then after that attempt to upgrade packages.

But several of you have volunteered to try and make this tech work with Unity Transforms. And if you are willing to get involved, I will support this effort!

Anyways, that’s it for this update. Join the Discord if you want to be a part of the community discussion there. Otherwise you can PM me if you want to share your thoughts that way.

And shout-outs to Unity for cleaning up Transforms! Had Transforms V3 happened 4 months ago, things would be a lot different!

 

What the problems with docfx you’re experiencing? Unity docs based on that, and we also used then in Diplomacy, with just a couple of tweaks and attributes for excluding some stuff we don’t want to put in API.

 

I'm trying to use the SingulinkFx theme with the memberpages plugin, because that has a functioning navigation bar on mobile. Unfortunately, member pages don't show up, and links don't work. I've also had other weird issues with getting the top-level TOC to render correctly, getting the homepage to be styled, and getting method parameters to read the XML comments (they seem to not parse correctly for some reason). It is just stupid bizarre things that wear at my patience pretty fast.

 

Isn’t they’re deprecating memberpages? As far as I remember DocFX wanted to merge it’s functionality in to a core and there is no need with plugin from some of the 2.x versions (can’t remember which one)?

 

If you know how to turn it on, I'd appreciate it. But please PM me if you want to try debugging all the weird stuff I'm facing. We don't need to pollute this thread any further.

 

Hey @DreamingImLatios,
I would like to ask, what is the functional current state of Myri audio library?
Does it works with DOTS 0.51?
I had some errors after importing packages, but haven't had oo much time, to investigate the problem.
Something related to Native collection, if I recall.
Chances are, I had incompatible packages installed.
Are there any specific incompatibilities between various of packages? I.e. collections, burst etc.?

 

Aside from the AudioSource.GetData crashes with subscenes that only some people encounter on the engine side, I would expect an appropriate version of Myri (0.5.8) would be working. There was a moment during the 0.50 and 0.51 lifecycle where hashmaps got renamed, and Myri was a little slow to switch to the new version and naming due to other bugs, but it did eventually switch over in 0.5.7.

 

As I can see Unity Transforms now way more similar to Latios ones

For main transformation routine they both use simple transform LocalTransform vs WorldTransform but difference only in name both represent WorldTransform for root entities and local transform for others

Unitys LocalTransform contains position scale and rotation only
Latios WorldTransform contains position scale rotation stretch and worldindex

May be it have sense to make Latios WorldTransform based on Unitys LocalTransform.

Create LatiosStretchAndIndex component and together with Unitys LocalTransform it will have same data as Qvvs
Make TransformAspect work with those 2 components instead of one WorldComponent

Then just supersede all or almost all UnityTransform systems with LatiosOnes on player loop and we ready to go

This at least will make LatiosTransform to work on top of UnityTransforms and also work with all other framework that know only Unitys LocalTransform.


As you already sow I love some small hacks over the system so I can propose somewhat better solution I guess

Write small editor util that will patch Unity Entities Transforms right in the PckageCache to make Unitys LocalTransform have Qvvs field with [field offset 0] and other small tweeks (may be add properties).
Then for proof of Concept add: global using WorldTransform = Unity.....LocalTransform

This way there will be exactly same data structure as your framework want and all other frameworks like DMotion can just work with it further

OK all other structs like parent will be different but main one Local/WorldTransform will be same so systems that dont touch/rely upon hierarchy structures will work as expected

 

I'm not sure I quite agree with the similarities or the practicalities of building Latios Transforms on top of Unity Transforms. But I do agree that it is possible to extent Unity Transforms Pre.65 to support Stretch.

You can read up on the differences of the various approaches here: https://github.com/Dreaming381/Lati...sforms/Choosing the Right Transform System.md

I don't plan on doing all the work to implement the Unity Transforms myself. I have a lot of other features I need to implement. But the latest alpha version is in a state where such an effort could be started without interfering with the work I'm doing. If you want to get involved, please reach out to me via PM or join the Discord and make yourself known there. The work required isn't trivial for one person, but I think that a small team could make it happen pretty quick!

And for everyone else wondering what the state of things are, I recently got some source generator experiments working, and they are a lot easier to use than I expected! They are going to solve several infrastructural problems with the framework (generics), which will hopefully reduce maintenance time sinks in the future so that I can focus more on features again. Also, I've been told that a fix for the subscene serialization bug that prevented me from releasing an official version of 0.6.x with Pre.47 is likely coming in the next release. So I am moving the alpha versions forward. LSSS already has a version with Pre.47, and once I get the source generator stuff in, I'll be moving it to Pre.65.

 

Latios Framework 0.7.0-beta.1 is out!

This version uses Unity 2022.2.19 and Entities 1.0.8 and can be found on this branch.

What Does Beta Mean?

Beta means that I am performing final validation testing (mostly builds) and updating the documentation. This process typically takes two weeks. During that time, I will be looking for feedback with regards to bug reports and documentation. Speaking of documentation, it has been moved to a separate repo here.

What’s In the Beta?

This is the complete version of 0.7. It includes significant updates to Core, the new QVVS Transform System, and a vastly improved Kinemation with lots of new rendering features as well as an overhauled Optimized Skeleton API using IAspect. Also, this version ships with source generators.

I want to thank all of you for being patient on this journey, and a special thank you to everyone who has been active on the Discord and helped me get through this roller coaster of Entities 1.0. This beta is the most stable the Latios Framework has felt since Entities 0.51. I’m very excited to see what you all do with it!

What About Unity Transforms?

Currently, they are not supported. However, I have already designated the LATIOS_TRANSFORMS_UNITY scripting define for future compatibility and added guards throughout the codebase. Ignoring performance, there are two issues with compatibility that I need your help deciding how to handle, if compatibility were to happen.

1) QVVS Transforms interpret the scene hierarchy during baking differently from Unity Transforms when GameObjects have non-uniform scale. Should compatibility mode use this new interpretation, or should it disable Stretch support?

2) Kinemation requires that bones are able to represent their transform as a pure TRS in root space. What happens when a bone has a PostTransformMatrix and no longer can meet this requirement?

That doesn’t mean that if decisions are reached that I will implement compatibility mode all by myself. QVVS Transforms are faster in all of my tests, and if I needed a package that relied on Unity Transforms, I’d be more inclined to modify it to work with QVVS Transforms. With that said, I am willing to contribute to any effort made and provide guidance along the way, especially regarding fixing determinism and other performance tweaks.

What’s After 0.7?

Lots of exciting things!

NetCode support will be my primary objective. But there are a few other really cool things planned or already in the works:

• bootstrap profiles
• IJobEntityHierarchy
• mesh colliders
• Myri Effect Stacks (user programmable)
• dual quaternion skinning (the feature is present but disabled due to a bug I still haven’t tracked down)
• advanced animation utilities (2D blend tree analysis, foot strike analysis, ect)
• world-space text (pure ECS)
• LifeFX VFX Graph job spawners
• MachAxle AI
• And probably much more!

Until then, I’m looking forward to the discussion and feedback!

 

Latios Framework 0.7 is Officially Here
Link​

This is a feature release targeting Entities 1.0.10. Feature releases contain breaking changes. If you would like to upgrade from [0.6.6], please read the Upgrade Guide. But be warned, the breaking changes are significant this time around.

Major revisions to the API are not anticipated in the near future, which makes this release one of the safer releases to start a new project.

Overall Highlights

I had three goals for this release:

1. QVVS Transforms

2. Kinemation feature overhaul

3. Core stability

Core Highlights

Collection Components and Managed Struct Components now use source generators. This results in less boilerplate, less runtime reflection, and more code that runs with Burst. There are no longer any generic systems at runtime. Instead of an AssociatedComponentType, there is now an ExistComponent that is automatically defined as a nested type, which you can reference in your own code, including bakers. No more TypeManager hacks.

Additionally, a bunch of memory leaks got stomped out since 0.6. The leaks were rare, at the frequency of a few kilobytes per LatiosWorld instance, but now they are all gone.

New Module: QVVS Transforms

This new module offers faster transform updates, smaller archetypes, better determinism for hierarchies, and lots of special features and improvements across the entire framework.

You can use the Motion History components for tracking movement of kinematic objects, or you can use CopyParentWorldTransformTag to save chunk space for submeshes or other linked entities.

Then there’s stretch, a non-uniform scale with unique hierarchy properties that prevent shearing, making it incredibly useful for squash-n-stretch feels.

Psyshock Physics Highlights

With QVVS Transforms, Psyshock can now automatically scale and stretch all colliders. For round shapes like spheres and capsules, you can choose the rules for how they stretch, but the defaults are typically sufficient for most use cases.

Psyshock’s internal query code saw a major refactor. The goal of this was to better organize the code based on the collider types and operations involved in a query, allowing for more vertical optimizations and making it easier for others to contribute new collider types partially or completely.

Myri Audio Highlights

The DSPGraph node leak warning is gone. The leak has finally been tracked down thanks to TrackedMalloc.

Kinemation Highlights

Kinemation saw a massive set of new features. The bone limit per skeleton has been increased from 341 to 32767. Blend shapes are supported. Dynamic Meshes let you animate a mesh’s vertices in a Burst job. There’s a flag component that lets you enable or disable a renderer in a Burst job. Optimized skeletons got a new API that keeps local, root, and world space transforms of a skeleton in sync to make custom game logic interactions easy. Inertial blending components make transitions smooth even between wildly different animation clips.

Performance also improved significantly. The new QVVS Transforms simplify triangle winding analysis and transform uploads. Better system responsibility distribution and caching reduce the pressure on memory bandwidth. A new round-robin culling loop keeps the worker threads busy in spite of the inevitable graphics buffer sync points. And light probes have a fully rewritten updater that utilizes jobs and Burst, so that thousands of entities can receive proper environment lighting.

Kinemation offers the best performance you can find in Unity for the amount of flexibility it offers (beaten only by GPU animation techniques).

What’s Next?

Along with bugfixes and low-hanging fruits you all bring to my attention, I plan to spend the next few months of development focused on collaboration. Which features I work on will be largely driven by the needs of those who are willing to work with me. If you want to collaborate, don’t hesitate to reach out!

Alongside that, now that I’ve finally caught up to the ECS packages with a stable release to go alongside the long-term supported Entities 1.0, I can focus hard on new features again. It is going to be a lot of fun!

If you want to help influence the near-term future of this framework, you can provide your opinions with this new 0.7 survey.

But as always you are welcome to also discuss here, on GitHub, and on Discord. And never hesitate to ask questions. I look forward to seeing what you all create with this!

Enjoy the new release!

 

Latios Framework 0.7.1 is out!

This is a small bugfix release. It contains a bugfix for Kinemation shaders, some small API additions to Core (plus docs), and bugfixes across packages to ensure modules at least compile (but not necessarily function) with LATIOS_TRANSFORMS_UNITY defined.

In addition, this release bumps the minimum version of the Editor to 2022.3.0f1. This is because the new LTS Editor has a bugfix that was plaguing some Myri users.

I missed these timely bugfix releases. It feels nice to be back on track again.

Enjoy the release!

Edit: Hotfix 0.7.2 is out to patch a .7.1 compilation regression.

 

Latios Framework 0.7.3 is out!

This release contains some bugfixes to custom command buffers as well as some minor API additions to Psyshock.

Please complete the survey if you haven't already. It really does help me prioritize things that are the most likely to benefit you.

Also, keep your eye out for the first 0.8 alpha in the next few days.

And lastly, feel free to ask any question or leave comments about this tech. I recognize that this stuff can be intimidating and that some of you are probably skeptical. I'm happy to ease your concerns and provide clarity and guidance to whatever you may be deliberating.

Enjoy the release!

 

Latios Framework 0.7.4 is out!

This release contains bugfixes for Kinemation.

But also:

Latios Framework 0.8.0-alpha.2 is out!

Why the announcement? Well, because this version has Kinemation using Unity Transforms!

There are still some issues, and I will be relying on the community to help navigate future changes. So make sure you try it out if this is what you were waiting for!

Enjoy the releases!

 

Latios Framework 0.7.5 is out!

This release officially bumps up the Entities dependency to 1.0.11 (not that it didn't work already). Besides that, this release fixes many blend shape bugs. Blend shapes should work a lot better now.

And I also have to share:

This is a new Mecanim (Animator Controller) state machine runtime compatible with both Unity Transforms and QVVS Transforms. There's still a big feature parity gap between this and other solutions, but this one is free, and I dare say it is also the fastest for large dynamic worlds by a longshot!

This has been a collaborative effort, so we'd really appreciate any feedback and help to make this a rich set of tools for everyone. We have a few more features also nearing the point to debut in an alpha release. Stay tuned!

Enjoy the release!

 

If you make so that external objects can force an entity into a specific animation clip without using weird stuff like

Animator Override Controllers

then it is already better than Mechanim IMO.

How I wish I had the time to just upgrade my whole project to the newest version...

 

I can think of two ways to do this:
1) If you have the specific clip as a state in the state machine, you can command the aspect to transition directly to that state. We diverge a little bit from Unity's implementation on this and always use inertial blending for these types of transitions.
2) If the clip comes from outside the state machine (you'd still need to bake it for the specific character), you can disable the state machine through the aspect, and then use the Kinemation low-level APIs to do your animation. Then when you are done, enable the state machine and use (1) to transition into a valid state again.

I will admit that these more advanced use cases aren't very well tested yet and there are probably some usability gaps. But we have pretty fast turnaround time!

 

Not sure what this means, but I am thinking of a system like The Sims (not sure which), one of the things they did to make developing interactable things (TV, wardrobe, freezer) quickly and be able to churn them for DLC was making the thing tells the sims how to animate, arbitrarily.
To me this is an incredible idea that should just be used on 99% of the games, hence why I want to be able to just arbitrarily play animation clips on characters.

Specifically runtime loaded animation clips gotten from mods on steam workshop that just retargets to the Mecanim avatar that is also something you got from a steam mod (imo the best feature of Unity, despite how much I hate using it, is Mecanim). If your animation framework lets me do that effortlessly it is an automatic 10/10 to me.

 

If the skeleton that the animation clip was authored with is different than the target you want to play the animation on, and you only know about this at runtime, then you will need to define your own runtime muscle space to do something like this. But all the other pieces are there. And if you only need retargeting in the Editor at bake time, that's supported out-of-the-box.

So probably not quite what you are looking for. But if the alternative is building something from scratch, you would save yourself a lot of time by building what you want on top of this framework instead, since one of its goals is to provide fundamental building blocks for custom solutions.

 

Latios Framework 0.7.6 is out!

This is a small bugfix that patches a memory leak in SyncPointPlaybackSystem (the system responsible for playing custom command buffers). The fix is included in 0.8.0-alpha.3 which was released last week. That alpha version is the version with all the new Mecanim stuff and also includes a highly experimental version of LifeFX.

There's two more big features that should be out in the next week or two, so stay tuned!

Enjoy the release!

 

Latios Framework 0.7.7 is out!

This is a compatibility release for Entities 1.0.14. Additionally, several bugfixes and features were added to Core and Psyshock, including the ability to use NativeStream in FindPairs via the new BeginBucket() and EndBucket() callbacks thanks to Burst 1.8.8 bringing default interface method support.

As for 0.8, the features are coming along, and I am transitioning towards stabilization for beta. Despite only being a couple of months, 0.8 is packed full of new features!

Actually, there’s so many new features, it has become an accessibility problem. Features don’t mean anything if you don’t know how to use them, or are even aware of their existence. To help address these issues and provide an entryway for you all to help collaborate, I have started a new Open Project called Free Parking. It is still early days for this project, so I would really appreciate any help giving the project the momentum it needs!

Otherwise, stay tuned for the beta in a few weeks.

Enjoy the release!

 

I just thought I'd share my rather simple solution for the Myri audio GetData bug (that I don't think will ever be fixed at the rate of things), after seeing on your latest feedback that its still an issue.

I basically use a ScriptableObject to store the audio samples from GetData so its done as a step prior to baking. This does introduce an extra step to the workflow, managing another asset on top of the audioclip. I've made some basic tooling to include a button for the audioclip/audioimporter(this was surprisingly difficult to track down) to simplify this, though the asset paths are coded for my own use(can obviously be changed inside the scripts).

It's based on an older version(0.4.5), and works standalone from the latios framework, keeping it up to date with the current ECS packages. I've also stripped out the smartblobbers baking, so that feature isn't there if anyone is expecting that.

https://github.com/thelebaron/myri-audio

 

Until further notice, all Latios Framework announcements will be made exclusively on the Latios Framework Discord.

If you have questions or concerns, feel free to PM me on these forums or DM me via the Latios Framework Discord or the official Unity Discord (same username as here).

If you need to blink twice because of the overlords, like the first 0.7.x patch release post.