Will try that later. My question is not related to the topic, but do you have any projects at the moment? Just curious
Oh, of course, only one project. I am currently working on my first serious project - Help and Feedback / Creations Feedback - Developer Forum | Roblox
Might play it somewhen later with friends. Iâll give the feedback
OldAnimationEditor.rbxm (97.5 KB)
Here is the old source code, Iâll get the new one for you after I find out how to
that not really hard to understand how roblox animator works if you keep looking at its behavior.
The main thing to optimize is to suspend animation untill object stops being streamed to player.
If possible create only one RunService thread for absolutelly all animations you made.
Second is the replication,you should not and NEVER play it on server and instead let client download it and send âexpectedâ position of timeline of where player should start playing it at.
Thirdly you should get rid of :Adjust etc methods in your animator since they are useless unlike in roblox animator.
Additional:
KeyframeReached absolutelly demolishes âoptimizationâ as you said since firing bindable each time is crazy if your animation is more complex aswell as usage of C0 or C1 that were replaced into .Transform for a good reason
easing:ModuleScript specifically for no reason creates a bunch of functions that could be easily avoided
Also i ran into an error with your module
local ReplicatedStorage = game:GetService("ReplicatedStorage")
local AnimatorModule = require(ReplicatedStorage:WaitForChild("Animator"))
local dd = ReplicatedStorage:WaitForChild("Default Dance")
local Animator = AnimatorModule.new(script.Parent:WaitForChild("Humanoid"))
local class = Animator:LoadAnimation(dd)
class:Play()
aswell as some of values being questionable and having no sense
By no mean accept it as critisism but rather as suggestion becouse i didnt made any deep analisis of your code
In principle, youâre right about everything, thank you, this is really good advice. There is only one question, why did you decide that creating an Easing module is unnecessary?
i have seen you create a new function to each iteration in code that why i said that
Hey I will improve your module if you donât mind and I can send it to you
Ok I made it better
Instead of making an entire new Easing module you can just do this
function AnimationTrack:_interpolatePoses(lastPose, nextPose, timePosition)
local style, direction = nextPose.easingStyle, nextPose.easingDirection
local arguments = {
(timePosition - lastPose.time) / (nextPose.time - lastPose.time),
Enum.EasingStyle:FromValue(style),
Enum.EasingDirection:FromValue(direction)
}
local alpha =
if style == 1 then -- Constant
math.round(unpack(arguments))
else
TweenService:GetValue(unpack(arguments))
return lastPose.CFrame:Lerp(nextPose.CFrame, alpha)
end
I think itâs inappropriate to get rid of this thing. It wonât do anything. Unless it worsens readability. I am currently working on updating the module
I have updated the module to the second version
You are acting like it was readable in the first place???
And how wonât it do anything it is removing unnecessary lines of code you had for no reason
In fact, yes, for me it is in second place after productivity, I think many people agree with me. Still, the second most important function of the module is to give the user the opportunity to edit it, and in order for this opportunity to be, it is necessary that the readability be good. In my opinion, this is very convenient when, instead of 10 lines of code, I replace it with a single function with a âtalking nameâ. Well, like, for example, I could create all the types right inside the main module, but this cumbersome code doesnât make sense in the context of animation. The situation is quite similar here.
SRP - the principle of OOP, which means that each object should have one responsibility. A function called âpose interpolationâ code should not be responsible for the interpolation method.
Maybe my memory is failing me, but there is also an ISP principle that literally says that too âfatâ interfaces need to be divided into smaller and more specific ones
But that is the only place where you use the function so why not just handle everything in the same place?
And the Easing module had so much unnecessary parts to it
Besides Why would you need to create an entirely new module just for it to be used once?
âEven if the smoothing function is currently used only in one place, this does not mean that it will always be like this. That is why it is important to follow the principles of good design, such as the principle of openness/closeness (OCP) and the principle of sole responsibility (SRP)â
Thatâs what one person told me, I think heâs right. In general, if performance does not suffer, then of course I will give my voice in favor of readability, even if it requires more lines of code.
In general, for me personally, it is just convenient to adhere to all the principles at once, and not just some. Well, like, itâs more convenient this way
Didnât you just say readability was second? And besides, where did you get the âperformance does not sufferâ part? Did you make a benchmark?
Because it just canât suffer.
The cost of importing and calling functions from another module is negligible, literally, the memory cost for this is no more than that of some âprintâ function. Iâm sorry I didnât answer right away, I had trouble articulating my thoughts.
â
Metatables suck⌠You might observe that I try pretty⌠| by Elttob | Medium
This might be helpful
Maybe youâre right. But link is not loading, XD