Just wondering, what’s the exact reason for doing this? (Not that I have anything against it!) Performance, Clarity or just for the sake of it?
Also will we possibly be getting more graphical features for viewport frames such as particles, beams, trails, Ambient Occlusion, PBR lighting etc?
btw will this help performance?
Now all we need is actual PBR lighting in the viewport frames lol
This behavior change is only for WorldModels, it will not be extended to regular Models.
Yea it’s a performance blocker. Allowing the animator to step joints across different WorldModels can cause issues when trying to step all the animators in parallel. Knowing that all the joints of a given Animator are in the same world dramatically simplifies things.
I’m not sure what is the reason for this update.
No clue if this is related or not, but was this the predicted fix to the persistent animation bug that you were investigating?
I’m really wondering why this is happening
Will this see significant performance improvements for games with many animated WorldModels (eg: a store UI with many ViewportFrames with a WorldModel and Animator in each)? If so, what’s the gained amount?
I can tell off the bat that this is a performance blocker and I’m actually happy with this. Separating animators per WorldModel is neat and much easier to manage.
I’m confused also i wanna know what this means for people who use animation plugins i personally liked the one roblox animator.
So does this mean I will need to put multiple WorldModels if I want to animate multiple characters in a single ViewportFrame?
No, just make sure all joints are in the same WorldModel.
Is there some notable changes to a player should it occur when joining the experience on or after Thursday 2021-08-26, ie one of my experiences RDK 3000-Tristar World or ones I regularly visit ie Sizzleburger, or Pinewood Computer Core?
Why not make it have a new property instead, I actually think this is better, but some may not want this, so if you add a new property, they will have the option to make it this way, this may actually interfere with a lot of current games that use multiple animators that are playing different animations per child, plus, you’ll add a new feature instead of deprecating the system that everyone is use to, no problems, no harm right?
There would be a performance impact of doing this, I believe.
This update doesn’t affect this, it only affects animators not being able to sense joints outside of their WorldModel from now on.
The impact is moreso engineering efficiency. Every option like that which we add is an additional option that Roblox engineers have to work around and test against when adding new features. This builds up exponentially too, not linearly: If you have three options, that’s not just three things to test, that’s eight combinations of options to test against. This can seriously slow down our ability to add new features.
Backwards compatibility is really valuable to Roblox, but we have to draw the line somewhere. Things like this which are likely to only affect a very small number of devs (or none if things go well) in a way which is relatively easy to work around aren’t worth supporting options for.
Having a million options isn’t ideal for developers using the platform either: That’s more (often irrelevant) info to sift through when they’re trying to find the what they need on the DevHub.
By any chance would this update fix this bug? I’ve been experiencing this issue for the past couple of days;
Animations not replicating to all clients until getting close to them - Help and Feedback / Scripting Support - DevForum | Roblox
EDIT;
Forgot to link this one as well;
Client-side animations won’t play correctly on models welded to another client’s character - Bug Reports / Engine Bugs - DevForum | Roblox
This right here sums it up perfectly. I just wish that newer, more modern devices were opt-in or something of that nature so that we, as developers, didn’t have to abide by all the different limits for lower end users. That’s one of the biggest gripes I have about this platform. The fact that I have to treat almost every player I have as a low end device user and it seriously hurts my ability to create anything past, quite frankly, “childish low poly”.
It seems incredibly hard for no real reason to create experiences for anyone older than… lets say 14 years of age. I wish there was a notice or more appeal to older audiences where the rules were a bit more lenient and a bit less constrained.
Wondering if anything address these gripes both long or short term.
Ok this change has been activated! So far no issues have been reported.
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.