#ETA of release DOTS Cinemachime
1 messages · Page 1 of 1 (latest)
We've put CM.DOTS on hold because we're not seeing a strong case for it, since CM classic can be used in a DOTS/GameObject hybrid context. May I ask you: why are you waiting for CM.DOTS? What will it bring that you can't get already?
It's kind of hard to make CM track an entity since it requires a gameobject - a lot of us don't want to use a hybrid environment.
I personally just wrote my own CM wrapper for DOTS a couple of years ago and it's worked great for me all this time. Full baking / doesn't require hybrid for user etc.
That said I expect this to all work much better in entities2/u7 where gameobjects/entities become integrated so I totally understand Unitys stance here.
CM classic not just hard to integrate with DOTS but it also looks like not battle tested with DOTS that when u use DOTS Physics and DOTS Character Controller will get camera jitter issue in certain cases. Another reason is CM classic dun have out of the box feature that nicely integrate with DOTS like when DOTS Physics do something CM classic will react accordingly and do something. Furthermore CM.DOTS can easily view all the data since it's ECS data that available globally instead of CM classic that quite a lot of data are hidden and hard to understand what's happening behind it.
https://discussions.unity.com/t/tracking-camera-jitters-while-following-a-dots-physics-entity/889295/6
Can you tell me more about your CM wrapper for DOTS? I'd love to see what you did.
Not sure if you've seen CM3. We've made an effort with that to make things less hidden by implementing CM components as ordinary behaviours without hidden GameObjects. That said, you are right about a lack of integration with Unity Physics. It's on our roadmap to address that directly in CM3.
Ya but I would like to ECS data that split most data into atomic level and make it globally accessible that I think it's not possible with game object. I believe even at CM3 it's still quite hard to access certain CM3 component just to modify some data at runtime. One more thing is performance that enable massive amount of cameras tracking possible. I think long time official announced something like that at one of Unite that enable eSports level game with massive camera tracking to get the best shot moment. I dunno why this nice thing being cancelled that no more news after that.
Yes indeed, CM.DOTS could support a gazillion live cameras, that was a big plus... but not very many people need or want that, unfortunately. At least not enough to justify releasing and supporting a product built around that. Those who need it will have to write it themselves using ECS.
You can think of CM.DOTS as a great showcase for the power of Unity's ECS implementation, but not as a viable product in today's business world.
I can get you the full library in 8 or so hours
Thanks, I would appreciate that!
I basically just hid away all the hybrid interactions so to the user it appears pure, added icomponentdata to match all cm components etc.
Cm3 update made this whole thing a lot easier.
Did you also rewrite the logic with systems and jobs? Without that, what is the point of having the IComponentDatas? Who uses them or keeps them in sync?
quick final output of what it looks like in current project I don't have a tracking camera atm, just a rts style and free camera for debugging in this project
I add support to Bake cinemachine components using companions
[InitializeOnLoad]
public static class AddCinemachineToCompanionComponentSupportedTypes
{
static AddCinemachineToCompanionComponentSupportedTypes()
{
CompanionComponentSupportedTypes.Types = CompanionComponentSupportedTypes
.Types
.Concat(new ComponentType[]
{
typeof(CinemachineBrain),
typeof(CinemachineCamera),
typeof(CinemachineFollow),
typeof(CinemachineThirdPersonFollowDots),
typeof(CinemachineOrbitalFollow),
typeof(CinemachineRotationComposer),
typeof(CinemachinePanTilt),
typeof(CinemachineBasicMultiChannelPerlin),
typeof(CinemachineVolumeSettings),
typeof(CinemachineTrackingAuthoring),
})
.ToArray();
}
}```
then have ICD that match these components
```cs
public struct CMRotationComposer : IComponentData
{
public float3 TargetOffset;
public LookaheadSettings Lookahead;
public Vector2 Damping;
public ScreenComposerSettings Composition;
public bool CenterOnActivate;
}```
private void ComposerChanged()
{
foreach (var (component, composer) in SystemAPI
.Query<CMRotationComposer, SystemAPI.ManagedAPI.UnityEngineComponent<CinemachineRotationComposer>>()
.WithChangeFilter<CMRotationComposer, CinemachineRotationComposer>())
{
composer.Value.TargetOffset = component.TargetOffset;
composer.Value.Lookahead = component.Lookahead;
composer.Value.Damping = component.Damping;
composer.Value.Composition = component.Composition;
composer.Value.CenterOnActivate = component.CenterOnActivate;
}
}```
And a simple change filter to keep them in sync
the CMCamera component is a bit more interesting, with tracking targets
public struct CMCamera : IComponentData
{
public bool Enabled;
public Entity TrackingTarget;
public Entity LookAtTarget;```
this is setup by default in baking usually and has a gameobject automatically associated with it and keeps them in sync
so to track an actual gameplay entity i just make the TrackingTarget clone the transform of whatever i want it to track each frame.
anyway source is here, it's really quite simple, it just hides the hybrid nature of interactions
you'll need https://gitlab.com/tertle/com.bovinelabs.core with extensions enabled for it to actually compile though
Currently I dun need gazillion live cameras yet but I need nice natural dots support that I can just directly access and change unmanaged struct type IComponentData which is burst compatible and just work. Another thing is performance reason that CM3 is still a bit costly to run at Android platform even with basic setup. I believe to achieve these goals nicely will require porting to DOTS land. If I understand correctly, official is going to the direction that writing new feature in dots to maximum performance and then implement some kind of game object wrapper to support game object to benefit both dots and game object users. I'm curious why not just build CM.DOTS and implement game object wrapper instead of building CM3 last time?