Feedback My [0.14.0] Full DOTS spectrum feedback

Hello everyone!

So every few months or so after I complete some personal game dev milestone (in today’s case, that was a new release of my public framework for DOTS, link in signature), I like to tour around Unity’s experimental tech and see what looks promising and what scares me. The last couple of times, I have left my feedback and thoughts on all the DOTS packages. You can find a link to those here: https://forum.unity.com/threads/12-21-19-my-personal-feedback-of-the-full-dots-spectrum.752576/

This time I am doing the same, but with another few months of development experience. I’m going to keep my harshest criticisms for the things that have left betas or previews and for things that have been marketed the most.

This feedback is addressed specifically at you Unity DOTS Team. I don’t expect each of you to read all of this. Just the parts you are involved with or curious about. Anyways, let’s jump right in.

The Engine

While it is probably the last aspect people think about when it comes to DOTS, the engine has probably seen the most improvements reach production-ready status as of late. And that’s the problem. It is the last aspect people think about because it isn’t being marketed correctly. There are way too many people trying to “Convert their game to DOTS” by rewriting their entire game using ECS and then give up, when there is a perfectly production-ready C# job system and Burst compiler that works perfectly fine with GameObjects.

So first, make some marketing material for DOTS tech that doesn’t involve Entities whatsoever. And second, make a subforum in the Scripting section, titled “DOTS for GameObjects” or something. This should be the dedicated subforum for all the APIs for working with jobs, Burst, and APIs that work with NativeArrays like transforms, graphics, particles, and physics.

Transforms

They work. They need more documentation for unintuitive things like how if you have a job chain where the last job is an IJobParallelForTransform and you schedule it in Update and complete it in LateUpdate, it actually completes very shortly after the rest of the MonoBehaviours finish Update because there’s an internal sync point for all IJobParallelForTransform jobs between the Update and LateUpdate invocations. Instead I have found scheduling all but the IJobParallelForTransform job in Update and then finally scheduling IJobParallelForTransform in LateUpdate gets the results I was looking for.

Also, why is there no IJobTransform that passes in a NativeTransformAccessArray in its Execute method? If this tech was marketed properly, I would expect this to skyrocket to the top of the community-demanded priority list.

Particles

I can’t say much about this as I use VFX graph instead. However, you have JobHandles now, which is awesome. Once again, if you marketed this properly, there would probably a smart AI particle system asset on the Asset Store.

Physics

The limit to one hit per request is annoying. I think you guys would do better with an API that let you lock the Physics world to a custom job and perform raycasts. Granted, I know that team is tiny and is doing some cool stuff with articulations and contact modification which people are pretty hyped about, so I guess that’s just a priority thing.

Graphics

Being able to generate meshes, textures, and compute buffers in Bursted jobs off the main thread and dump them to the GPU is AMAZING! I found it most useful for custom UI. The docs are high-quality here too.

Animation

I don’t use animation jobs right now. That’s more a limitation with the tools I have to author animation in a way that could take advantage of this tech. The lack of feedback here is a “me” problem.

Package Manager

Package Manager is the primary way you deliver packages for DOTS. The workflow for developing packages has gotten a lot better. The workflow for discovering Unity packages has gotten a lot worse. Packages which have dependencies that expose public API don’t show up, so you have to manually add it again if you want to see the samples or docs (or explore the Library folder). In addition, discovering some of these packages requires knowing the magic package names. That means that in order to properly discover all the packages in the Unity registry, I would have to write a dictionary attack and bombard the server with queries. I think the right solution is to have a flag that users can add to the manifest.json to expose all packages in the Unity registry and tag the ones that are normally hidden with a “Hidden” symbol. Right now there is no rhyme or reason to what is visible (are Netcode and Havok Physics really going to leave preview this year?) and what isn’t, and it is disgusting.

The other thing that annoys me with packages is the generated code documentation. So the Unity Engine documentation is amazing! Every class has a page listing the properties and methods in a streamlined format. Then you click on a method and get to a page that has all the overloads and some high-quality descriptions and code examples.

Compare that to the packages documentation where you get one page with all the documentation for everything in that class, after it loads for like 30 seconds in some cases. This means I have to scroll halfway down the page the size of 50 monitors just to get at what I am looking for. Please fix this.

Mathematics

Not a whole lot has changed here, which is fine. It is still my favorite math library. I still think you could do with SoA types and operations for doing vector and matrix mathematics on 4 or 8 elements at a time using SIMD (like compute the cross product of 8 float3s at once). I’ve already started my own implementation.

Burst

This is the tech that lets my performance-sensitive code live on the CPU instead of the GPU using the clean C# language syntax and its tooling. I’m having way too much fun with this tech!

As Burst has evolved and allowed for more in-depth optimizations, you wrote up a bunch of documentation to go with it. Thank you! One of the things I was about to complain about (per-processor compile-time dispatch) is now documented with a simple code example. I’ll be busy!

One issue I have been having lately is that when looking at the Burst inspector for larger jobs, it is still difficult to separate what is my code and what is code that is part of the framework, like the IJobParallelFor loop or the IJobChunk iteration and fetching of component arrays. While that stuff is annotated, it is annotated everywhere very heavily, making it difficult to find my code. I would love a side-by-side view similar to Compiler Explorer where you can click on the C# code and it highlights the associated assembly instructions and vice-versa. At the very least, an in-window text search would be awesome.

The second thing I struggle with is I never know when specifying a structure to pass by value or pass by “in” will lead to better Burst assembly. Perhaps you could provide some documentation or tooling in this area?

Lastly, hardware prefetching doesn’t usually have a good sense of arrays of indices. There’s been some research articles on embedding software prefetching knowledge into compilers for this and other simple use cases. Have you looked into this at all?

Regardless of those annoyances I have to push absolute performance, I still have mad respect for you! Keep doing what you are doing!

Collections

I thought Collections was going to go out of preview this spring. But then spring happened and you gave a bunch of stuff an overhaul. I can’t complain. There’s a lot of cool tech. NativeHashSet, NativeReference, and FixedString all made it into my projects very quickly. I do hope Collections goes out of preview soon though because it adds so much value to the C# Job System and Burst and I want to see more crazy cool assets on the Asset Store using the C# Job System and Burst.

You have a major documentation problem. I have no idea from looking at the docs which containers are lock-free, or what locking behavior they exhibit. I have no idea which containers support what level of determinism. I have no idea whether the container is fully a reference or if I need to write the struct back to its source to keep things in sync.

Also there’s no UnsafeQueue type.

Jobs

Custom job and custom native container documentation is fine. But only IJobParallelForDefer is properly documented. Why?

That’s really all I have to say.

Entities

I really like this ECS. The boilerplate reduction has been going down quite a bit. Entities.ForEach has really grown on me. SystemBase was a godsend! The ComponentTypeHandle rename was so seemless most people didn’t even notice! Installing systems at custom locations in the player loop works super well.

Also, code documentation related to the runtime is top-notch! Getting that right with codegen was absolutely necessary, and you did that. Thank you!

Normally, I don’t mind breaking changes if what it takes for me to fix them ends up with me having cleaner code. However, if my code breaks without any obvious replacement other than nasty hacks, I get frustrated. That has only ever happened once with Entities, and it is related to ComponentSystemGroups. I need to be able to control the order of my systems and manually tick them. There’s just no way you are going to make ComponentSystemGroup to do all of that for me correctly automagically. I could go into a lot of details why attribute-based system ordering is horrible (couples code together, can’t reference private systems, becomes a trial-and-error guessing game when you have thread-occupancy issues). But I get that some people prefer it. And I really think that Unity needs to have it, but also be able to override it.

The biggest frustration I have had though is with authoring and Game Object Conversion. Don’t get me wrong, I love the concept, and was a strong advocate of it over a pure DOTS editor. Authoring and runtime representations do need to be split. My issue is with some implementation details that are really annoying.

1) You can’t turn off Unity’s built-in conversion systems for specific objects. I believe every GameObjectConversionSystem that Unity provides should come with an associated DisableConversion MonoBehavior so that we can write custom conversions instead. Either that or use WriteGroups. If I have a custom light-management system that makes lights work as pure Entities, I want to be able to disable Hybrid conversion on my lights and run my own conversion. I don’t want to remove the full GameObjectConversionSystem, and I don’t want to undo whatever that conversion system does.

2) Going along those lines, many GameObjectConversionSystems are private, so you cannot order them with attributes. Unlike with ICustomBootstrap, there’s no equivalent for performing GameObjectConversion. I’m stuck with attributes, but cannot even get my systems ordered relative to Unity’s to know that certain parts of the conversion have already taken place or not.

3) Manually versioning of conversion systems is broken. It sounds like a good idea, but in practice, all it takes is for a bugfix to land that modifies the result of a static method used at runtime that also gets used at authoring but the bugfixer never realized that and now everything is out of sync. Maybe there’s a way to make the ConverterVersion attributes apply to the assembly rather than each class so that I can make a tool auto-update it. But until then, it is clunky and not very maintainable.

4) Declaring of dependencies is poorly documented. Some methods do this for you. Some don’t and you have to do it yourself. This is inconsistent and not documented at all. The only way to know is to dig through the code.

5) There’s no way to tell if a BlobAsset belongs to a subscene or not, so at runtime there is no way to know if the BlobAsset is safe to Dispose. Maybe if there was a guaranteed system group in conversion that ran only when baking to a subscene, I could make this work. There probably is, but I have no idea because the process is not correctly documented whatsoever.

6) [GenerateAuthoringComponent] can only appear once in a file, meaning I can’t keep groups of components in one place. This negates nearly all of the rapid prototyping benefits that the attribute offers.

Not allowing struct IComponentData to be IDisposable makes Unsafe collections require indirecting into a NativeList of unsafe collections instead. That’s an unnecessary performance penalty.

The lack of EntityManager.SetSharedComponentData(NativeArray<Entity>) forces users to do two structural change operations instead of one or do things outside of Burst.

We definitely need API’s for performing structural changes on ArchetypeChunk or NativeArray<ArchetypeChunk> because allocating NativeArray<Entity> is unnecessary.

It would be nice if we didn’t have to find all chunks twice when populating NativeArrays inside Entities.ForEach. Right now we have to do it once for EntityQuery.CalculateEntityCount and again for the ForEach. In addition, if the Entities.ForEach uses filters, we have to pre-apply them. Having an Entities.Initialize((int entityCount, int chunkCount)=>{}).ForEach would be awesome.

Can we get more “dynamic” type handle APIs? I’m not talking about DynamicBuffers (although they need this API too), but equivalents for reading and writing data using only ComponentType in EntityManager and ComponentDataFromEntity contexts. This would give us a ton of potential with regards to Entity merging, diffing, and serialization. A lot of us have been reaching at internal methods to do this. It shouldn’t be hard to wrap this up in an API, even if it was in a Unity.Entities.LowLevel.Unsafe namespace.

While we are on the topic of more accessors, GetSharedComponentIndexFromEntity would also be extremely valuable.

There are other things I could ask for, but I think this is a good enough list for now.

No game engine today can do what I want to do. I thought I would have to write my own custom engine. Instead, I am building what I need against Unity DOTS and ECS. Why? Because I believe it is the fastest route to achieve what I want to achieve. I believed that when I started, and I still believe that. That is a testament to the tech.

Transforms

The Transforms code has for the most part remained unchanged. It was great as an initial implementation to test out good ECS API design and all, but it has not aged as well. The biggest issue is that it is trying to be too flexible for something too fundamental. We really need one Translation, one Rotation, one Scale (probably the non-uniform variant), and then the hierarchy. Composites and pivots and all of that should be in a separate package so that people building assets can focus on the pieces that matter.

Besides that, it has two problems. The first is that the Rotation property on LocalToWorld gives incorrect results when there is scaling applied (if you fixed this recently, I missed it). The second problem is that updating the hierarchy is slow. Really slow. I don’t know if part of that is due to the dynamic buffer change filter bug, or if it is just thrashing caches all the time.

Fortunately, because it was designed with WriteGroups in mind, I think I can optimize it without touching the package. But it really needs a usability evaluation.

Scenes

For the most part, I have used subscenes as a way to reduce the number of modifiable Game Objects in the editor, but otherwise I end up having all the subscenes loaded at once in game and have all the entities alive. I do this, because the behavior of subscene streaming otherwise is very undocumented and very confusing. What qualifies whether a subscene is loaded or not? Which entities get destroyed when the subscene unloads? What happens to blobs that might be stored in custom containers when the subscene unloads?

It’s been nearly a year since you prototyped live link and nearly two since the MegaCity demo, and there’s still zero documentation or explanation on this. I commend the few studios that have figured out how to make it work for their projects. It still feels like a game of spin-the-bottle with a fuse-lit firework canister.

Hybrid Renderer

I am a graphics guy. While HR V2 was broken for me for a while, it is working correctly for me in these last few releases with HDRP. There’s a lot of non-obvious ways it can break. I have fortunately been able to figure out why every time I have run into issues so far. The reality is most of the time it is the SRP Team’s fault. Their priorities are confusing, and I feel bad you have to work with them.

Hybrid-instanced properties are absolutely incredible! They just add so much color and personality to the otherwise repetitive worlds.

The one thing that is still broken for me is that the instance data buffer size setting in the editor doesn’t propagate to builds. I have to set it through code in the bootstrap instead.

Something that would be awesome is if we could have a RenderLocalToWorld that if attached to an Entity, is used instead of LocalToWorld. That way I can keep LocalToWorld synced with the simulation state without having to make a backup, and use RenderLocalToWorld for interpolation.

I could go on a rant about the lack of extensibility. But you have already been good about explaining the “early nature” of Hybrid Renderer V2. I’m still trying to figure out when and how I should implement some custom graphics tech that I really want.

Physics

None of the initial issues I pointed out with the design have been addressed. I think this physics works better in the world of MonoBehaviours than Entities. I wonder how many people have memory leaks from runtime blob generation and don’t realize it? There are only a few cases where blobs actually report memory leaks correctly. There are so many side-effects to everything you do, so much digging through messes of events to customize what you need to customize, and so much fragility with system ordering that it just feels like a simulation framework rather than something meant to be used to design gameplay. I’m still watching its development. But I still think it is going to take you a long time to make it “ready for the masses”.

Data Flow Graph

This one is really unfortunate. It is hidden by its dependencies. Most people think it is just some Unity internal solution. People look up the documentation and there is nothing there that makes them believe otherwise. It really suggests it exists for DOTS Animation.

Those people never realize that it has a samples package titled “Guided Tour in Code”. It is one of the best tutorial/documentation works I have ever come across!

Unfortunately, the tour stops short of the ECS integration. From what I can tell, binding entities to it has to be done outside of Burst on the main thread. So it is making it difficult for me to find a good use case for it to stress test it.

But I want to stress test it because the tour is just that hype!

Oh, and IUpdate in simulation nodes is broken, which means a lot of the non-tour examples are broken. You probably want to fix that.

DSP Graph

I have not been able to use it because

1) It doesn’t use Data Flow Graph

2) It doesn’t have very much documentation, so I have no idea how to get data in, when stuff computes, and how to keep things synchronized properly.

3) I haven’t found any examples other than the way-too-advanced-for-me Megacity Demo or DOTS Shooter.

So I am still waiting for DOTS.Audio.

Netcode

Most likely I am being naïve here because I have never gotten a good online multiplayer to work. But I think part of that is because of how I build and reason about my game logic, which never seems to match the models that networking libraries use. Every networking library either provides low-level transport access, or tries to automagically synchronize everything. Really what I am looking for is a library that abstracts client-server connections into a simple API and then lets me dump buffers over those connections of my choosing. And consequently, I can receive those buffers on the other end as well as some metadata about age and whatnot, and then perform my own logic for synchronization.

Am I stupid?

Build

I am currently duplicating a bunch of Build Configuration Settings for Windows, Mac, and Linux. I thought there was supposed to be an override system so that I could share things like the scene list, whether or not Incremental GC was enabled, and all of those other properties. Am I missing something, or is it not working yet?

Tiny

It seems like it is maturing well, but I can’t give much of an opinion on it yet because a lot of my workarounds to Entities ended up using reflection rather than extend the assemblies. Once I fix my framework to work with Tiny, I will probably have a lot more to say about it. WebGL would be a really nice platform to target with my smaller prototypes.

Animation

There’s no samples included with the package, and the GitHub samples are old. I do not feel like reverse-engineering it to figure out how it works. The code is very complex. I am moving on.

Timeline

I don’t think you wanted me to even see this package. The only reason I know about it is because of a GitHub project that referenced it. However, unlike Animation, this one has samples. And they work!

I am going to have to try and use it in a stress-test project before I can really give opinions about it. I suspect that it has some sync point issues that makes it tricky to scale. I’m also not sure how fragile it is. For example, what happens if you destroy an entity through game logic that was instantiated via a track?

One thing that totally surprised me was when I selected certain GameObjects that had Timeline tracks, and suddenly the scene view became a DOTS entities preview that I could scrub through with the Timeline. How are you doing that?!

I must learn this secret power!

Final Thoughts

As I am building up the technology I need to accomplish my goals, one of the issues I run into is prioritizing where to put my effort. The reason this is so difficult is because unless someone drops a hint about “next release” or “soon” on the forums, I have no idea what you are working on.

I’m not asking for videos or roadmaps or posts on the official Unity Blogs. Those all cause problems with expectations. What I am asking is devlogs. Perhaps every two weeks or a month, one team from DOTS writes a little devlog as to what the team is up to. What problems are they running into? What tech are they planning? What are their goals? This would be on rotation, so each time might only provide one to four updates per year, but the community would get a steady stream of new information so that we know DOTS is making progress in many new and exciting areas.

As for all of you who are on these forums reading these posts and answering questions, thank you! You all are awesome. This has been a fun community to be a part of. And I’m excited for what is yet to come!

And lastly, thanks for making to the bottom of this page. Sorry it was so long. I had a lot to say this time.

 

Hi. Any plan to release preview of Data Flow Graph Visualizer soon? I would like to have something that is better than PlayableGraph Visualizer that can't display the exact name of the current node like animation name.

 

Some of them Exist Like EntityManager.SetComponentDataRaw(). They work with on void* ptr, int TypeIndex, and size. But it's all internal and don't have that many overloads as SetComponentData, also not on ECB.
I really appreciate that this can be Generalized and as @DreamingImLatios said put in Lowlevel.Unsafe namespace.
It will benefit Basic Function System Engineering when component type is unknown or unnecessary to be known.

 

This, and I'd also add that I think it's annoying that the name of the generated component when you search for it with the AddComponent menu is just the name of the file, instead of the name of the struct. I really think this should be changed, because it kinda forces you to name your files with "Authoring" suffix when they contain the components and the systems at the same time. I guess the problem you describe is probably a consequence of this file name limitation, which is probably a problem that was inherited from monobehaviours

Aside from issues related to modifying/creating colliders at runtime, personally, I was a bit blown away by the quality of this package and I really enjoy using it (and I'm making heavy use of it). The APIs give you a lot more power and control than what we had in monobehaviour physics, and the performance of both queries and rigidbody sim is incredible. I think a few utility functions for quick physics queries would help with the accessibility side, but otherwise this package has been a godsend for my needs so far

One thing that's confusing for users however, is the stateless nature of it. This means that collision response quality/stability really isn't on par with what you'd expect, unless you use Havok, and you constantly see new people on the dots physics forum asking "why does my cube keep bouncing up when sliding on the floor". And people will naturally get a bit scared when they learn that in order to have regular-quality physics for offline games (which is what most people need), you need to rely on a pseudo-premium package. Even if they know they are in the tier where they don't have to pay anything, it's still a little uncertainty/fear that stays at the back of your mind

Netcode tries to make it easy to deal with the difficult problem of lag-compensation and prediction in fast-paced online games, and I really think this is a very valuable thing to have. This mecanism is a necessity for almost all online games where players need responsive direct input control over objects, and/or games that need hit detection (and where you care about not making it easy for people to cheat). And it's a lot of work to implement. However, you could choose to ignore NetCode's "Ghost" and "Prediction" systems and work entirely with RPCs to accomplish what you want, I think. If you don't put any ghost components on your objects, NetCode won't sync anything by itself

I think one thing that is a bit weird is how nothing in the name of the package specifies that it's the netcode architecture for fast-paced predicted games (like online shooters, etc....). I know unity mentioned that that was the intention of this package, but it should be in the name. Especially since apparently there's going to be multiple netcode architectures that Unity will release. And I also think it shouldn't be marketed as being "for FPSs" like it's been described a few times. A more genre-agnostic name would be better I think. Something that lets you know this is a netcode architecture for predicted/interpolated ghosts

In a build config, you can define "Dependencies" to other build configs. It works like inheritance. See the "multiplayer" project on github (netcode sample) for an example. Maybe it from a recent version of the package, not sure

 

Most of the networking you're used to from other domains (everything but games and high-frequency trading) is based on TCP. This is a stateful, stream-based protocol managed by your OS's networking stack that abstracts away a lot of details. And over a period of time, you'll also have decent bandwidth. But you won't have good latency because of handshakes, windows, error detection/retransmission, etc. UDP is pretty much "I send you up to 508 bytes of data, you might or might not get it at some point in the future, it might be out of order, and it might be garbled when you get it".

Now tons of games do just fine with TCP and higher latency. Turn-based games, slower paced strategy games, and the parts that aren't latency sensitive (high scores lists, replays, chat, etc). So maybe there would be value in a building a framework around that (above and beyond what .NET already provides).

 

This has not been the case for me at all. Besides mutable primitive colliders, the callback system's design has been an equal show-stopper. While it is true that it is more powerful than classic Unity Physics in that it exposes this data, it exposes it in a way that just does not scale the way I need it to. Burst can't save it. On top of that, it puts some really hard limits on the game loop and transform manipulations that are frustrating to work with. Before you edited your post, you originally asked me to elaborate. I'm not sure if you dug up one of my past forum posts, but this document describes in detail the frustrations I have had as well as the alternative design decisions that resolve them. I'm far from reaching feature parity, but even with the heavily-reduced featureset, my efficiency at writing working code is far greater. https://github.com/Dreaming381/Latios-Framework/blob/v0.2.0/Documentation~/Physics/README.md

This doesn't bother me at all.

The issue I have is that it often fails at maintaining good feel and performance for the types of games I make. I want to solve lag-compensation and prediction myself. Oftentimes part of the simulation can be purely lockstep-deterministic based on time, another much smaller simulation requires the "ghost" and "prediction" pieces, and yet another part just needs a loose synchronization with some spatial priority handling. I'm not afraid to write this myself. What I don't want to worry about is the networking protocols. I shouldn't have to write 500 lines of code to establish and maintain a connection to the server. I just want an interface I can command to set up connections and send and receive buffers along with their metadata. I can deal with the data. It's my data, and I know what to do with it far better than any general-purpose solution. And of course a library like this would probably support some API for compressing and decompressing these buffers in which I can tell it the metadata as to what kind of data it is compressing (transforms vs integer keys). And as long as the library comes with good algorithms, I am okay with it just telling me that parts of data are garbled or lost or whatnot. Again, I just want to work with the data directly.
I don't like RPC. There's nothing data-oriented about it from my past experiences trying to use it.

Well that's why I couldn't find it. In no right mindset would I have ever thought a "Dependency" would act as the "base" in an inheritance tree. I thought it was for chaining build steps.

 

Blob assets have to agree mostly, and I'm sure we have memory leaks in physics over them.

DFG if the simulation phase moves to jobs that resolves the main problem there. It was so far away from being job friendly that for a time I wasn't sure they even planned on making it job friendly.

Networking is a bit of a mess and I think their high level approach is going to fail. I think it's going to end up back where it all started, with those that have the domain experience rolling their own. And third party solutions eclipsing what Unity provides for those that don't. Because Unity is just not setting a very high bar where it really matters.

For studios with people like myself that have the domain experience, the core has to be complete and fully extensible and just overall solid. And it's not. For people that don't know the domain, it has to be easy to use, and it's not.

What's going to happen *again* is that you will end up with very easy to use solutions by third parties that have dubious architectures and technical design. But that won't matter, you don't know what you don't know. I know people at studios that are using some of these dubious solutions. These are studios with a lot of experience just not in networking.

 

Thanks, but that isn't what I am looking for. For anyone interested in proposing, building, or convincing me to purchase a networking solution, PM me. I can provide much more detailed technical requirements than what is appropriate for this forum.

This is definitely the camp I fall into, except for the fact that I have a zero-tolerance policy for "dubiousness" being injected directly into my simulation. As long as those stay separate, I can problem make something decent. I'd at least spend the time to try.

 

Procedural Mesh

In Physics Shape Authoring Click Check Force Unique. then you will get a unique collider blob(not shared with any other one). And you can deform the shape as you wish. AABB still needs to be updated or BoardPhase may fail to overlap your shape.
reducing vertex count is okay. But adding vertex will force you to reallocate your collider blob.

Callbacks
Yes! The data of those callback stages are not uniform-sized and stored in a stream. Random access and parallel can not be done directly. But you can use on job to access your target data and store them in a uniform sized NativeList. And then do parallel processing on that List as you need. Referenced Data like RigidBodys/MotionData/MotionVelocy are all Lists you can parallel/random access as you need. You can find them in PhysicWorld.CollisionWorld/DynamicWorld.

FrameSync
It's an annoying thing. But physic's ESC systems are nothing more and a wrapper of PhysicWorld and ISmulation. You can build and update them whichever way you want.

Sync With Transform
You can disable ExportPhysicWorld System. and use your own Transform update logic. That System is very simple.

Overlap Test
BVH and cell-based spacial partition all have pros and cons.
BVH is more Generic, Cell is more natural to game with Cell-Based Level.
As for a physic engine, BVH is definitely the right choice.

Sorry, if you did not mean Cell-based spacial partition at all.

Full Stack Cutomization
The Core Foundation of a Physic Engine is Overlap Test(BVH, GJK and EPA), Raycast Test And Jacobins. If you want to build your own engine. You can borrow these parts.

 

Never looked at it, as Animation is not working in URP.
DataFlowGraph is a promising tech. It can do much more complicated job than bare ECS.
Thanks for the note!

 

Great and detailed feedback. Thank you for blazing the trail for popular and experimental packages alike.

The DataFlowGraph interactive tutorial really was hype, and I suspect it fits my use case almost perfectly. Only problem is that it's highly experimental and subject to API changes, though this is expected. @DreamingImLatios any way we can structure our code to abstract away the fluctuating aspects of DataFlowGraph?

 

I am going to ask that people read this before trying to convince me that Unity.Physics is a good general-purpose physics engine that meets my use cases. It is a physics engine designed for realistic games with fully-authored colliders. If that is your use case, fine. Use it. It is not mine. https://github.com/Dreaming381/Latios-Framework/blob/v0.2.0/Documentation~/Physics/README.md While I recognize I can be naive at times, this was not a decision I made hastily.
Procedural Mesh - Only works for authored colliders. Also, blobs aren't supposed to be mutable. That's an ugly hack.
Callbacks - The issue isn't accessing the data. The issue is that you have to aggregate all your different archetypes into bitmasks just to have to manually split up all the results later. I go into much more detail about it in the linked rant.
FrameSync - There were issues with things being internal. While this is something I can work around, it is less-maintainable and wasn't worth it with all the other problems I had with the design.
Sync with Transform - It still clobbers GameObject Conversion.
Overlap Test - I did not. I do use a multibox which has some nice multithreaded event processing capabilities even when paired with a BVH.
Full Stack Customization - I do borrow parts, and that's one of the reasons my framework is under UCL. However, I do so cautiously because there are divergent design decisions that have different implications. Discussion on this topic belong in a different thread or PM.

I don't work for Unity, so I have no idea what will change in the future. I suspect NodeSetAPI will become a struct and use pimpl wrt NodeSet and that there will be a NodeCommandBuffer or something. But that's just me speculating.

 

Unity should have had two packages unity colliders and unity physics instead of one package, 99% of games use colliders and i assume less than 50% percent games use realistic physics. I have to use physics package just for collision APIs.

 

Why do I get the impression that whenever people mention procedural meshes they are thinking of voxels?

 

It has been a popular topic lately. Rest assured it is not my use case. I use runtime collider shapes for hitboxes and deformation receivers on VFX objects, as well as trigger shapes for AI spatial queries.

 

+1000000 for doing regular devlogs or something similar. Going months without giving us any idea what's going on or what's coming up is extremely frustrating.

 

It's been three years since DOTS was announced, still we are still hanging in limbo?! We will
support you till you are valued at $1.3 Trillion, just please tell us what are you doing? Are you okay?
Documentation of project tiny just says "Project Under Heavy Development", Forum posts keep going to
"until next time" status, Asset publishers politely say "working until next break" of current
working version and frustrated community is basically reverse engineering test code or scraping forums
like Alaska Gold Rush. How can a solo developer @DreamingImLatios explain more about your technology than you?

 

I agreed with you up until this point. I can't explain more about DOTS than Unity. Many of the engineers there know more than more and have accomplished more than I have ever accomplished. It may be that I do explain more about the tech on these forums than Unity engineers, but that is a matter of choice rather than competency.

I choose to explain things here as a means of learning for myself. I believe that it helps me create better designs. However, I have no anecdotal evidence as I am not aware of anyone other than myself who has even tried to use my publicly available tech (outside of tracker numbers it has been nothing but crickets ). From that alone, I can only conclude that I may be making the wrong choice.

What I am trying to explain here is that communication is complicated. It may not be obvious yet to Unity what information needs to be conveyed and what medium is appropriate for conveying it, or even if such efforts are worth the opportunity cost of time. I am simply one noisy voice. I do not represent the community.

What I do know is that Unity is listening to us. They are not obliged to our every demand, but they are listening. The first two replies of this thread are proof of that!

 

I actually recently started using your physics library as it better aligns with how I'd like to handle collision detection / spacial queries. I totally agree with the pain points you've been talking about with regards to the official package.

Thanks a lot for this work and keep it up!

Ps there's a bug in your capsule ray that I haven't reported /submitted a pr for yet.

Something like math.select(fraction2, fraction2, fraction1 < fraction2)

 

Whoah! That's awesome! And nice catch! No need for a PR. I'm just starting v0.3 today so if you have preferences for which roadmap features you'd like to see in the next couple months, let me know here: https://forum.unity.com/threads/0-2-0-my-personal-dots-framework-latios-framework.797685/

But thanks for suggesting that perhaps I might not be doing something wrong after all!

 

https://blogs.unity3d.com/2020/10/07/the-road-to-2021-team-quality-of-life/

 

I think releasing multiple netcode package based on game genre is not good solution. The better solution I think is putting all into one single netcode package but able to enable/disable features easily based on your game networking requirement. So, at the end you will just add the netcode systems to your game based on features you choose to avoid adding a lot of overhead and at the same time the netcode is still maintain at the same single package.

 

So, if the package that does server simulation is called "Netcode", then what is the lock step/GGPO package going to be called? Codenet?

 

I'm really surprised to hear Unity is investing in this. GGPO is cool, but it has extremely limited use cases (fighting games).

 

Lock step is a fair comparison but it's not a genre. It's an approach. Networking shouldn't care what the genre is. The more you move up the chain ya but then you are talking far more then just networking.

Plus the far more common scenarios it's all quite a bit more fuzzy.

A lot of genre's mix and match various approaches. An FPS game can have npc's, vehicles, siege weapons. Combat related things that vary projectiles slow and fast melee etc... Maybe a mix of kinematic, dynamic bodies as well as no physics at all. They might use snapshot interpolation for some stuff but not others. And the same goes for moba, mmo, etc..

So by genre fails if you carry it forward and account for the most common scenarios. You can only make it work by either severely limiting what some packages can do, or massively duplicating logic.

Or change the common definition of genre.

 

I actually programmed a client / server for an RTS game I am working on. My feeling is client / server is not really great for games where you see a lot of units at once. In an FPS rubber banding is not really a big issue you don't necessarily see all units at once and you don't have complex stuff going on. As client side prediction becomes more complex you end up with re-simulation anyway.

My client server did not use delta compression. Rather it used tribes/halo model.
https://www.gdcvault.com/play/1014345/I-Shot-You-First-Networking

So in the future I plan to switch to a GGPO / Lock step architecture of my own design. I really don't see the benefit in anything beyond a low level transportation layer for networking and even then I am already set on using Steamwork.net and sending floats as fixed point values. Using a custom serialization format.