Latios Framework 0.9.2 is out!
This is a bugfix release with Kinemation and Mimic fixes.
I’ve received enough questions the last few days regarding QVVS Transforms that I have added an FAQ page to the documentation. Hopefully that answers most questions, but if not, feel free to ask!
Enjoy the release!
Latios Framework 0.9.3 is out!
This is a bugfix release for Kinemation covering a variety of areas.
0.10 development has been progressing, but unfortunately a combination of factors have put two projects of mine on pause. These two projects were the primary drivers of features for 0.10. Without them, framework development is currently without any sort of direction. If I have seen frustrated here as of late, that’s partly the reason.
What I would like to ask you all is to throw stuff my way. Questions, requests, assets you want me to play with, profile captures of your projects, Jams, collab invites, whatever you can think of. Most of it won’t stick, but whatever does will help drive the direction of the framework until the other issues sort themselves out.
Thanks in advance, and enjoy the release!
Latios Framework 0.9.4 is out!
This is a small bugfix release for Psyshock and Myri.
The two feature-driving projects are still blocked. While I wait for the blockers to be resolved, I am currently developing features I will need in the future. However, I do not plan to validate each of those features and debug them before moving on to another. The rationale for this is that when my main projects are unblocked, I will only have to do the debugging part of feature development. It also opens an opportunity for anyone in the community who wants the feature early to help with debugging and validation. But as of right now, I suspect the development cycle for 0.10 will be a longer one.
Currently, I am porting the Unity Physics solver (sans architecture and scheduling) to Psyshock. I’m getting close to having something people can start playing with, and I plan to release the first 0.10 alpha when that happens. Psyshock’s design is intended to provide various algorithms from various physics engines that you can mix and match to build your own physics solution. If you are a physics engine enthusiast and would like to help bring in physics algorithms that aren’t included in Unity Physics, feel free to reach out!
Enjoy the release!
well, latios is an ECS extension and a fps saver? what is ECS and DOTS? (… lol)
Hey everyone.
I don’t anticipate releasing a new 0.9.x release in the near future, if at all, and a lot has happened over the last couple of weeks. So I am making this update post to keep everyone in the loop.
0.10.0-alpha.3
The third alpha is out, and it contains a bunch of new features. Kinemation now has masked animation sampling and dual quaternion skinning (I finally found the bugs). Calligraphics got a huge update with the help of Fribur. I’ve finally committed to a design for MachAxle that I have started developing in public. And Psyshock has received three major updates.
Psyshock’s CollisionLayer type used to be backed by NativeArrays. They are now backed by NativeLists, meaning the number of colliders does not have to be known at schedule time anymore. Along with this change, FindPairs received a big improvement both in compile times and in performance.
But the biggest milestone is this:
Major Milestone
This is the Unity Physics contact rigid body algorithms, extracted as simple body-wise and pair-wise static methods, and made compatible with QVVS transforms. This combined with the new PairStream type and Physics.ForEachPair() allow you to effectively assemble your own physics engine, where you can swap out any piece with whatever custom logic you like. A very simple example engine can be found here: Free-Parking/Assets/Dev Dungeons/DreamingImLatios/PsyshockRigidBodies/_Code at main · Dreaming381/Free-Parking · GitHub
There is still more work to be done. Specifically, stabilization, constraints, joints, motors, and performance improvements. But right now, I’m looking for feedback on the API design. Psyshock still retains its identity of being systemless and inside-out, but I am concerned the new APIs may be too low-level that they become inaccessible to the average ECS developer.
Entities 1.2 Situation (Rant)
For those completely unfamiliar, Latios Framework is currently at Entities 1.1.0-pre.3 for both 0.9.x and the 0.10.0 alpha releases. And the reason I’ve not pushed forward is due to the unresolved entity ID determinism issue introduced in Entities 1.2.
Technically, none of the main features of the Latios Framework actually care about determinism at all. In a normal project, animation, rendering, audio, physics, they all will work just fine. So why is this such a deal-breaker?
Imagine you were using the framework, and after making some code changes to your spawning logic, some of your skinned meshes stopped rendering. It could be a bug in the framework. It could also be a mistake you made. Both have happened plenty of times on the Latios Framework discord. You decide to report the issue to me, and then send me a sample project where you experience the issue.
What would happen if I then told you that I opened the project, and everything seemed to be working? You’d be tear-your-hair-out frustrated, right?
In Entities 1.1, this is nearly impossible to happen.
In Entities 1.2, this becomes a likely event.
The reason for this is that Kinemation relies heavily on chunk caching. And with chunk caching, the perceived presence and behavior of bugs are dependent on the order of entities in a chunk. The Latios Framework relies on deterministic entity IDs to keep the order of entities in each chunk deterministic. Entities 1.2 breaks this. Correct code will still have correct behavior, but incorrect code could result in anything, even changing from run to run.
There might be ways to preserve chunk-order determinism without deterministic entity IDs, but doing so would almost certainly result in performance regressions. In 1.2, do I sacrifice debugging and support quality, or sacrifice performance?
And Unity has only given mixed signals on this. I’ve heard some say that chunk-order determinism is a lost cause due to subscene streaming (I’d argue synchronous streaming is fine for debugging). I’ve heard some say that chunk-order determinism is still a supported feature and is what Unity Physics relies upon. I’ve heard some say that non-deterministic IDs are so entities can be moved quickly between worlds, because apparently that’s a use case they want to support? And I’ve also heard that they still plan to support lockstep determinism networking. These are all in conflict with each other. I can’t align with Unity’s philosophies even if I wanted to.
So regarding upgrading to 1.2, I’m not opposed to it, but I’m also not going to do it alone. It is not fair that I be expected to release and be judge by a worse experience due to factors outside of my control. It is not fair that I’m the only one who understands the situation, and be the only one who goes through the mess Unity made to make something work. It is not fair that I be judged for Unity pulling the rug out from under me by changing what their solution promises, proposing a remedy to quiet me, and then never delivering on that remedy.
If you really, really want me to upgrade the framework, then get involved. The three places that first require attention due to the determinism issues are Core’s custom command buffers, QVVS Transforms’ parenting system, and Kinemation’s binding system.
Otherwise, I’m going to stay on 1.1 until Unity exhibits some kind of “unity” in what they want to promise out of their ECS.
Enjoy the alpha, and feel free to stop by the Discord if you have any comments or questions. That’s where all the support discussion for the framework happens nowadays. But you are always welcome to post here or PM me too.
[mention|jHGV85e+IFLkrONZ9ccj5Q==], [mention|GbHrv5YO6MbWuJTViMER4w==]: sorry for the ping. In the Nov 2023 dots status thread one of the most heavily debated topic was determinism of entity IDs broken in 1.2.
You asked for specific use cases relying on entity ID determinism. Post above is one. And it’s starting to affect the growing list of users of Latio’s framework (count me in since 2 weeks ago): a quick update if you are going to follow through with your plan to introduce a 64bit deterministic entity ID (/counter) in entities 1.3 or 2.0 (or if you abandoned that plan) would be great for planning purposes. Much obliged!
Hi,Thank for you effort.I found this by accident. Now i want use this framwork for my game.I really want to konw What problem was solved by this framework.In other word,what you do In the underlying technology make it perform better than unity origin So i can know whether my game can switch to this and preserve all func. Judge how much work should do for change.If you dont have time. In you project you said:Many of its tools and solutions are inspired by GDC presentations, technical blogs, and research papers.can i get the list,So i can find the answer by myself,Thank you~
I’m glad your interested!
If you haven’t read through this document yet, take some time to read it: https://github.com/Dreaming381/Latios-Framework-Documentation/blob/main/What%20Parts%20of%20ECS%20Does%20the%20Latios%20Framework%20Change.md
Also, you may find the “Optimization Adventure” articles and just the documentation in general may answer a lot of your questions. But if something isn’t clear, don’t be afraid to ask!
I’ll briefly discuss the underlying changes performance-wise. You should refer to that other document to see if these changes impact you negatively.
The change that probably has the biggest impact, and fortunately is a change that even works in Unity Transforms mode, would be the culling loop rework of Kinemation. In vanilla Entities Graphics, deformations are dispatched first, then material properties (including transforms) are uploaded to the GPU, and then culling happens for each camera. I figured out how to flip the order of these so that deformations and material properties can use culling information and update incrementally by camera within a frame. That eliminates a ton of unnecessary work for both the CPU and the GPU, as long as you have things moving every frame. It may have ~500 microsecond overhead for fully static scenes.
The second change is the QVVS Transform system. This one is the hardest to switch to, which is why there’s a Unity Transforms mode. But if you can commit to this, it enables lots of little optimizations all over the place. And sometimes those optimizations can have a big effect, such as making some expensive jobs obsolete. That was the case for the million spinning cubes example, where the conversion from local transform to LocalToWorld disappeared entirely. Kinemation does the conversion on the GPU instead, using GPU resources that would otherwise be idling while waiting on a memory transfer.
The third change is the physics with Psyshock. Unity Physics has fast algorithms, but is architected to calculate everything unless told not to (and telling it not to calculate things is not always trivial). Psyshock is designed inside-out compared to a normal physics engine, and will only calculate what you ask it to. It is a bit friendlier to the ECS query system, but also a bit more manual. It can be tricky to get the most out of it, but when leveraged correctly, it removes a lot of overhead.
There’s a lot of other things as well, mostly just native ECS implementations of things where there were none before. Though I do have to call out ACL for animation, as even when Unity releases their solution, I suspect ACL is still going to beat them out. It changes the algorithmic complexity of animation sampling from O( log(m) * n) to simply O(n).
I hope that all helps!
Thank you very much for your answer, yesterday I read part of the project documents, QVVS is a good idea, in the memory and computation are partly improved. I personally feel that existing matrix-based library may not be worth the cost if runtime processing requires additional intermediate processes. If the editing state is processed in advance, it needs to maintain excess code. So at this stage, if you’re not considering using someone else’s library, and it’s a new project, I think it’s a good idea. But I will try your animation scheme, I think it is very good. I hope to be able to use all of your functions one day
PS:I just glance over"Optimization Adventures".yes,It is exactly what I want ,Thank you again
"
Latios Framework 0.10 is Officially Here
Link
This is a feature release targeting Entities 1.2.1 using ENTITY_STORE_V1. Feature releases contain breaking changes. If you would like to upgrade from [0.9.4], please read the Upgrade Guide. There are only a small number of breaking changes in this release, and most projects will be unaffected.
Wait! 1.2.1?
After reassessing the current state of things, I realized that switching to this version using ENTITY_STORE_V1 was a very low risk to me personally, and only a high risk to the community and official support efforts. I decided to give the Latios Framework Discord community a choice, I could either stay on 1.1.0-pre.3, or I could upgrade, and if anything on Unity’s end broke, I would not provide any official support or remedies. The decision was unanimous. So far, the editor seems to be stable. Builds? Good luck!
Overall Highlights
I had three goals for this release:
Core Highlights
Core got a new AddComponentsCommandBuffer. The main motivation for this was to handle cleanup components more elegantly.
Scene management now supports loading some subscenes asynchronously. You can choose this on a per-subscene basis.
Core also saw a few additional low-level changes and improvements to its collections, which the rest of the framework can leverage to great effect. If you used UnsafeParallelBlockList in the past, you can find new alignment guarantees and a new indexed variant. There’s also a new ThreadStackAllocator which can recycle per-thread temporary allocations made multiple times within a job.
QVVS Transforms Highlights
GameObjectEntity should support Unity Transforms now. It is not installed by default, but the new Unity Transforms bootstraps allow you to enable it by uncommenting a couple lines.
Psyshock Physics Highlights
Psyshock saw major updates.
First, FindPairs got a new optimization that can result in up to 5X improvements! You may need to retune your CollisionLayerSettings to have more subdivisions as a result.
Second, CollisionLayer has been changed to be backed by NativeLists instead of NativeArrays. This removes a sync point when using enabled components in EntityQueries, and also allows you to build layers from body lists populated in jobs.
Third, Psyshock has a new sibling to FindPairs named ForEachPair, which can leverage the new PairStream native container to cache arbitrary data with found pairs and iterate over them multiple times later. The mechanism is extremely flexible, cache friendly, parallel, and safer than NativeStream.
Lastly, I have extracted many of the core rigid body algorithms from Unity Physics and made them available in the UnitySim class. When combined with Psyshock’s existing tools, it is now possible to build your own rigid body simulation tailored to your project’s needs. Psyshock has finally delivered on this promise! And if you don’t need simulation, there’s no performance penalty.
Myri Audio Highlights
I have made progress on effect stacks, but they are not ready yet.
Kinemation Highlights
Kinemation got a bunch of small, but exciting additions.
Dual quaternion skinning is here! You can choose whether to use it or linear blend skinning on a per-mesh basis.
There’s a new LOD algorithm with LOD Crossfade support! The algorithm is also much faster than the previous algorithm. This is a breaking change if you do anything with LODs in code. However, if you just used the LOD Group in authoring, it should all just work.
Animation sampling masks are here. AclUnity will now automatically accumulate weights per bone, and the weights no longer need to add up to 1 anymore. You can implement both additive and override layers.
In baking, you can now request bone names for optimized skeleton to help bake bone indices for faster runtime bone manipulation.
There’s now a runtime skeleton animation clip blob generation API. More APIs like this can be added upon request.
Calligraphics Highlights
Thanks to Fribur, Calligraphics received a major update. Many of these improvements can also be found in TextMeshDOTS on Fribur’s GitHub, if you just want text rendering compatible with Entities Graphics.
Fribur’s big contribution was overhauling the glyph generator to support a plethora of rich text tags. You can perform all kinds of inline manipulations now.
Fribur also improved the shader. Bold fonts and other features should work now!
The vertical layouter has been upgraded to support dynamic line heights and allows for anchoring against any of the font lines.
Multi-font support is here. You can change fonts using rich text tags.
There’s a new rendering mode called GPU-Resident Text which caches the generated glyphs on the GPU. There are tradeoffs between this and the default rendering mode, but you can pick on a per-entity basis.
What’s Next?
I have yet to decide what will be included in 0.11 development. Despite being the most-requested feature, I think IK is unlikely, given the lack of community involvement in that area. But there are a few areas I am heavily considering.
NetCode is back on the table. There’s real potential for me to make this more integrated with the framework. I also believe I can greatly reduce the main thread costs of Kinemation and build a rigid body physics simulation that has extremely low latency for physics prediction use cases. All of these efforts would likely set the stage for a future framework-exclusive networking stack that provides more flexibility and easier development than NetCode. I have ideas.
Calligraphics is a likely candidate for further improvement. Not just in text, but I’d also like to explore vector graphics capabilities, both for debugging and in-game world-space shapes.
Myri Effect Stacks is at the point where I just need to hard commit to it, and make Myri much more viable as an audio solution.
Terrain, environment, and VFX are on my radar. I’m skeptical I will be able to deliver something good without artist direction. But we’ll see I guess.
I may also do some prototyping with character controllers (specifically FPS-style) and other common gameplay mechanics to help identify gaps in the APIs. However, I’m not sure yet under what license I would release these kinds of developments (if I release them at all), since I really don’t want inexperienced and/or noisy developers around these prototypes.
Lastly, there’s a chance I may explore the world of soft body physics. These could also very easily fall into the prototype category, with restrictions on release.
Of course we can’t forget any curveballs Unity throws at us, especially with 1.3 around the corner.
Anyways, since this is a feature release, I anticipate a few bugs to have slipped through. Make sure to join the Discord and ask questions, report bugs, suggest new features, share tips, showcase your work, and discuss random framework or DOTS things. I may not be taking paid jobs, but I am open to collaboration for mutual benefit.
Enjoy the new release!
Latios Framework 0.10.1 is out!
This is a bugfix release addressing a few small bugs in Core and Kinemation, and a few larger ones in Psyshock.
There have been some behavioral changes in Psyshock to address some of the bugs. While none of these changes should trigger compiler errors, you may encounter new runtime errors due to the additional safety checks, and some of the behavior of various calls might be slightly different (different hit normals or different bucket counts for given collision layer settings).
My schedule for this month is to focus on continuing to address bugs and provide support for those who seek it, and also continue optimizing what I can. July will be a very busy month for me. And August is when I will begin development of the next major features of 0.11. I have not made a final decision on what those features will be yet. So feel free to suggest what you would like to see!
Enjoy the release!
Latios Framework 0.10.2 is out!
This is a bugfix release addressing a few small bugs in Psyshock and Kinemation, and also contains a couple of improvements in Core and Myri.
Since the question has come up a few times, this releases support both Unity 2022.3 LTS and Unity 6 Preview, as well as both Entities 1.2.1 and 1.2.3. In addition, I have verified Entities 1.3.0-exp.1 is functional, though you will encounter a couple of obsolete warnings in Calligraphics if you decide to use this version.
Enjoy the release!
Latios Framework 0.10.3 is out!
This is a bugfix release addressing a few severe issues in Kinemation. If you use deforming meshes at all, you are strongly recommended to update.
My focus is shifting towards research, prototyping, and infrastructure. And consequently, it may be a while before I return to rolling out new user-friendly features. If there is a feature you strongly desire, I encourage you to reach out to me.
Enjoy the release!
This is a small bugfix and improvements release for Core, Psyshock, and Kinemation, including a new community contribution.
Unfortunately, this new community space is plagued with a bunch of problems, a few of those being that I can’t modify this thread’s (topic’s?) title, original post, or tags. And if that isn’t resolved within the next few weeks, then I may decide to create a new thread for release announcements moving forward.
Additionally, read/unread tracking is very buggy for me and I can’t batch-mark things read, so I probably won’t post in this community as much in the short term. You are always welcome to ask general DOTS questions in the framework’s discord: Latios Framework and you are always welcome to @ me or invite me to other servers on Discord if you ever want my opinion on things. Though keep in mind I live in an uncommon time zone for DOTS gamedevs, so I may be slow to respond or choose not to if the conversation drifted somewhere else before I see your ping.
As for what is happening with framework development right now, I’m working on a new module called Unika, which I have lately started describing as “MonoBehaviours for Entities”. That might sound like a bad idea, but I promise you there are some parts of you game that would benefit from polymorphic data-driven execution as a means of existence-based processing of sparse data, as opposed to polling such sparse data. I also believe it will significantly reduce the boilerplate for code that doesn’t need performance but you don’t want to run on the main thread, saving development time and letting you rely on your traditional OOP-style problem solving skills.
If any of that interests you, and you’d like to be involved, feel free to reach out! There’s plenty of independent pieces to this puzzle (mostly of the source-generator flavor).
Enjoy the release!
This is a bugfix for Kinemation, specifically skeleton shadow rendering.
I am still really struggling with this new site, so if you are hoping for me to chime in on a particular discussion, please @ me.
As for development, I am currently a bit more open to feature requests. This will only last for a short while, so please reach out if you feel there is a hole somewhere and are hoping someone with experience can fill it.
Enjoy the release!
This is a bugfix for Core and Calligraphics.
I can finally edit the original post and title! I still can’t make this simultaneously show up in both the DOTS list and the Community Showcase, but it is still a step forward.
I also realized that the original post had a couple sections out of date, which explains some of the questions I received recently. The latest framework supports the latest ECS versions (though you need to use ENTITY_STORE_V1) and it has a Unity Transforms compatibility mode which only disables a small number of framework features but provides compatibility with Unity Physics, Unity Character Controller, Unity NetCode, and other third-party assets.
Some of the other questions I have received recently pertain to the framework’s viability for productions. And I would like to address some of them here.
Q: Why don’t you split each of these features into separate packages?
This is my personal framework. I share it because I believe in sharing. And I take feature requests because I have experimentally determined I am more efficient with the insights and involvement of the community. I always have to weigh the productivity boost of a stronger community with the cost of solving use cases that aren’t mine. Making the packages independent has a high cost with not enough value for me. I’m open to discussions on how to bring this cost down.
Q: What is the benefit of QVVS Transforms, since it isn’t compatible with anything Unity does?
It has a significantly better and more expressive transform hierarchy. That’s something I needed, and it has been something that has saved me a lot of development time compared to hacking solutions on top of Unity Transforms.
Also, don’t confuse the QVVS Transform System with the TransformQvvs type. The latter is simply a struct you can do whatever with, and is used throughout the framework’s APIs regardless of which transform system you are using.
Q: I like Kinemation, but do I need to use Psyshock?
If you are using Unity Transforms mode, no. I recognize the appeal of a code-free out-of-the-box physics engine. Unity Physics is that. But it comes with a very expensive event system and doesn’t support animation-focused simulation features. And those are the main reasons Psyshock exists.
Q: Why not make the framework support Entities Graphics instead of rewriting it?
I originally tried that. It performed very poorly. It still has the same problems today. In general, most common use cases for Entities Graphics will continue to just work in Kinemation. There are a couple of exceptions regarding custom baking and LODs, but I am only aware of one big show-shopper.
A lot of you find Mimic’s Mecanim implementation inadequate, and I agree with you. Personally, I use an entirely different workflow that is more code-focused (I am a programmer first) involving explicit states and inertial blending. I would love to share a demo of this workflow, but I have been struggling to find compatible assets I can legally share.
Many people instead use Rukhanka, which currently uses the horrible Entities Graphics APIs that is part of the performance problem I encountered. I would love to provide a patch that makes that asset run on top of Kinemation (I don’t think it would take me very long), but legally my hands are tied. I’m open to discussions on how to address this.
Q: Do you talk to studios at all? Or just hobbyists?
I am in contact with people from the industry, but I will say that my contacts currently disproportionately represent smaller studios, and they are all programmers. I am currently working on Unika, which I believe will alleviate the biggest time cost those studios are facing. If you would like to provide your own perspective, let’s connect!
Q: Can you make this drop-in replacement for this feature?
If it involves editor tooling in any way, probably not. Editor tooling is my biggest weakness right now, partly because I struggle with the APIs, and partly because I don’t have designers and artists willing to provide rapid feedback. Otherwise, the biggest cost is reverse-engineering all the subtle Unity-isms of said feature. If you instead ask explicitly for the functionality you want, there’s a much better chance I can do it within a reasonable timeframe.
I hope these answers were helpful to some of you and helped clarified some things. I’m always open to feedback. Anyways…
Enjoy the release!
This is a bugfix release for Core, Psyshock, and Kinemation, mostly edge-case bugs that are only encountered because people are leveraging the framework in all sorts of unique and unexpected ways.
There are blocking (and confirmed) engine bugs right now for both Myri and Unika, so much of my time currently is being invested towards more research. I would not expect any big features to reach a production-ready level of polish any time soon.
On the bright side, it seems like what we have today is here to stay for the full duration of Unity 6, so even if Entities 2.0 comes out a hot mess, we’ll still have something stable to build upon for a good while.
If you are interested in helping shape the framework’s next big initiative, feel free to reach out!
Enjoy the release!
This is a feature relase targeting Entities 1.3.2. Feature releases contain breaking changes. If you would like to upgrade from [0.10.7], please read the Upgrade Guide. Most projects will not be affected by these changes. However, the minimum editor version has been increased to 2022.3.36f1 which provides better LOD Crossfade support.
This development cycle was quite harsh. The decision to even make this release was quite last-minute, and many things that were worked on are not included in this release. But as for the things that did make it, here were the main goals behind them:
Most modules saw some improvements, with the exceptions being Myri and Mimic which had no changes.
NetCode bootstrap templates have been redesigned to use phased system creation just like the other bootstraps. This also means that some features like explicit system ordering are now supported. In addition, some new utilities have been added for common use cases.
There is also a new Quaternion Characteristic Polynomial (QCP) solver, which is a faster alternative to the Kabsch algorithm. It is a great algorithm when you need to align complex objects with messy inputs.
With the improvements to NetCode comes early experimental support for synchronizing WorldTransform out-of-the-box. This is an ongoing area of investigation and learning, so if you desire to use QVVS Transforms with NetCode and have feedback regarding this integration, feel free to reach out.
Have you ever wanted to raycast multiple CollisionLayer instances all at once? Now you can! All query APIs now support a ReadOnlySpan<CollisionLayer> to simplify your spatial logic.
Kinemation’s culling loop received a massive main-thread performance speedup for cases involving many shadow-casting lights. In 2022 LTS, performance is 50% faster. And in Unity 6, it is up to 300% faster, even outperforming vanilla Entities Graphics while including all the extra features and GPU optimizations!
These performance improvements come with a new graphics and culling loop API that allows for Burst-compiled ISystems to write to manipulate GraphicsBuffers and dispatch compute shaders.
If that went over your head, don’t worry. A new easy-to-use feature is the LOD1 Append. Simply attach this component to a Game Object with a Mesh Renderer to get two LOD levels with crossfade all packed into a single entity. This feature is perfect for projectiles that are instantiated in high quantities.
Lastly, for anyone struggling with the mathematics of root-motion, there’s now a collection of new APIs to help guide you through the process.
Calligraphics didn’t get any new features. However, all the new main-thread performance features in culling have also been applied to Calligraphics as well, demonstrating the extensibility of this new high-performance design.
While 0.11 development was plagued with problems, I do not expect the same to be true about 0.12. Between a recent discovery and Unite’s announcements providing some much-needed hints to the timing of things, I have a clear roadmap for the next few months.
If you’ve been on the framework discord, you may know that prior to Unite, I was starting to draw up plans for both a Mecanim V2 and a terrain baking system that converts trees and details into entities. These are both canceled. I would need significant help in the form of community contributions to offset the time investment for what I believe to be short-term solutions.
Unika and Myri Effect Stacks are currently being held back by this issue and this issue respectively. However, if these issues get resolved, then these will become high priority items. Not only do I believe they provide significant value, but I also believe they have very low risk of being impacted by Unity’s next-gen release.
Tighter NetCode integration is something that I had been procrastinating for a long time, and have only recently started. So far, there are some things that are a lot more solid than I anticipated. But there are also some things that are incredibly frustrating, so development will be very on-and-off and will likely require a lot of assistance from others for me to make substantial progress.
Character technology is something I will continue to improve, especially regarding IK and physics-driven motions. I still maintain my stance that if you want more complete solutions and examples, you should provide characters to me that I can legally work with. However, I now have a solid grasp of a few pieces that I think a lot of you are going to like.
Physics in Psyshock will also be an area of continuous improvement. Terrain colliders and more character controllers are both high on the list. And I’d also like to try and figure out how to make the rigid body APIs a little more accessible.
Lastly, visual effects will likely see some development. I finally have some very concrete goals for what I want to deliver, both for CPU and GPU particles.
Of course, if there are features you think I’m missing, let me know!
Will it use Unity’s new transform system? Will it work with Unity’s new animation system? Will it be compatible with other packages?
I don’t know yet.
I will say, that after Unite, I’m more optimistic than I was prior that the new stack could be really good and I can integrate with it seamlessly and check off all my personal boxes. However, there are so many ways Unity can fall short, that I reserve a lot of skepticism still. What I do know is that when that time comes, I will be stretched extremely thin and will have to make sacrifices to ensure my own needs are met. Most of you probably won’t like that. But if you’d like to see the Latios Framework play a role in the broader ecosystem of Unity’s next generation, my suggestion would be to learn the technology of the Latios Framework now, and maybe even dig into its internals. That way, you’ll better understand the challenges I will face.
With all that said, there are a few things I can list out now that I believe may be potential concerns:
First, Asmref and MSBuild. Currently, it is impossible to extend Unity’s ECS without access to internals or a fork. Asmref provides access to internals. Without it, we are stuck with a fork, which unlike a fork, means that multiple packages that need access to the internals cannot coexist easily.
Second, transforms. I will only be able to move away from QVVS Transforms if Unity’s new system can do the following:
And lastly for animation, I have some very special needs:
IJobEntity).Don’t wait! Things are happening now! So get involved! The framework discord is the place to ask questions, discuss features, show off what you’ve made, help prioritize new features, or get involved in development!
Enjoy the new release!
This is a bugfix release for Core and Psyshock addressing some memory stomps in a couple of the custom containers.
For those of you unfamiliar, Psyshock has a little bit different approach to physics compared to just about every other physics engine. It is more of a toolkit to build your own, and shape it for your projects needs. There are so many tradeoffs you can make to boost performance at the sacrifice of features your project may not use.
However, even with all the utilities provided, composing a rigid body simulation still takes quite a bit of work. It would be nice if there were several out-of-the-box engines tailored for different common use cases that you could use either as a drop-in solution or as a starting point for your own engine.
I made a package for that: GitHub - Dreaming381/Psyshock-Community: Various Physics Engines built on the Latios Framework
It is still very early, and I won’t be developing this to the same standard as the framework. In fact, this is mainly going to be community-driven. Meaning my contributions will almost exclusively be based on requests from the community. I’m accepting all feature requests, change requests, and pull requests. My only rule is that requests should be small and specific (with the exception of pull requests that start a new engine or add a significant feature).
Enjoy the release!