#[1.0.0-pre.65] Upgradable Entities and Physics systems still using SystemBase

1 messages · Page 1 of 1 (latest)

orchid igloo
#

I spotted there are still have some systems at Entities and Physics still using SystemBase that able to upgrade ISystem. Will all of the upgradable system upgrade to ISystem at next release? For Entities, I think there's a SystemBase still using EFE at InitializeSystemGroup. For Unity Physics, there are a couple of SystemBase at GraphicsIntegration namespace I guess.

orchid igloo
#

[1.0.0-pre.65] Entities and Physics still using SystemBase

#

[1.0.0-pre.65] Upgradable Entities and Physics systems still using SystemBase

bitter reef
#

we did a pass on these a while ago; i think all the remaining ones that stayed systembase did so because they were interacting with engine managed objects, like mesh or whatever. as we've said elsewhere, getting unmanaged versions of these is a project, which we'd like to do but haven't started yet

orchid igloo
# bitter reef we did a pass on these a while ago; i think all the remaining ones that stayed s...

At entities, I believe ResolveSceneReferenceSystem at runtime should able to upgrade to ISystem. If cannot at least upgrade to idiomatic foreach.

At dots physics, I believe it's rewrite from scratch that should be not have any engine api dependency. I notice all the systems at Unity.Physics.GraphicsIntegration namespace (i.e. BufferInterpolatedRigidBodiesMotion, CopyPhysicsVelocityToSmoothing, RecordMostRecentFixedTime, SmoothRigidBodiesGraphicalMotion) should upgrade all of the them to ISystem

bitter reef
#

@distant coral some of these sound like plausible todos

#

that said, there is an issue of prioritization. would you rather I convert these systems, or (for example) work on making generic isystems work in general (since they don’t right now)?

orchid igloo
bitter reef
#

no, like mysystem<T> : isystem

ripe viper
#

Convert 😄

#

(I don't care much for generic ISystem but I guess it depends now extendable it is)

orchid igloo
bitter reef
#

It would require registergenericsystem

#

so no

#

(we are very conscientious these days about not ruining compilation time more than we already have)

orchid igloo
#

🤔 Interesting. Not sure wat's the magicmake it faster since at regular C# generic it's really slow.

bitter reef
#

registergenericsystem means all the specializations are apparent at compile time without having to walk anything

#

meaning you have to say registergenericsystem(typeof(mysystem<everyT>)) for every T you want to use with the generic isystem

orchid igloo
bitter reef
#

yeah you are a bit over budget there 🙂 so I get it

orchid igloo
#

🤔 Oh yeah. Is that possible to completely disable game object land physics? Currently it's still cost a lot even I never use it.

bitter reef
#

for that the bigger thing is probably the long term project of parallel world updates and then even longer term parallel system updates

#

I think there’s a setting for you to manually call simulate, and then you could just never call simulate

#

Or you could try removing it from the manifest.json

orchid igloo
bitter reef
#

it remains to be seen 🙂

orchid igloo
#

Or should I say update system out of main thread by default? 👀

bitter reef
#

that would be the idea, but it’s a long way off. first we’re doing basic research into parallel worlds, for e.g netcode client & server in the same process

#

because parallel systems is strictly harder than that

orchid igloo
bitter reef
#

did you try the setting?

orchid igloo
bitter reef
#

untick Auto Simulation

#

and also probably Auto Sync Transforms

orchid igloo
#

👀 Btw any plan to solve Unity.Scenes.Editor.LiveConversionEditorSystemGroup gc spike at editor?

bitter reef
#

do you mean EditorSubSceneLiveConversionSystem

bitter reef
#

@potent orbit this seems like a valid question

orchid igloo