I’ve already done more than enough on my end. Setting a bone’s position takes 85% of the total update time alone - and I perform a whole summed gerstner wave algorithm per every bone, so you can see how it’s quite expensive.
Oh, well I am no expert but at the top of this post, they featured a wave, and it did not look to expensive so there may be a better way
It updates at 2ms. The issue is that I need to limit how much I can update - I can’t make the waves more detailed (more bones per square stud), and have to resort to spreading out the bones over a bigger grid, like tyridge does in his video.
We would like to optimize this eventually. Is there a way you can get the same effect using animations? That would be the fastest way to do it for now.
Sadly no, as it would ultimately be much less dynamic - I customize ocean settings where for instance the shore has calm waves, whilst the ocean has dangerous storms with huge waves. Animations would be not only extremely hard to use, but you’d have to remake them every time we would want to decide to fine tune them.
I had been struggling with the same issue for a long time. Updating bones every frame is just to computationally heavy at the moment.
In this reply I posted the method I use to efficiently move the bones of my waves: In-Game Realistic Ocean Thunderstorm - #11 by apenzijncoolenleuk1
Basically, instead of updating every frame, I divide all the bones into tables that get smoothly interpolated over a few frames. This way the work that has to be done is nicely divided. Instead of having to compute 4000 positions at once, it now is reduced to 400 for example.
I found TweenService to be really slow and buggy, so I created my own (simple) interpolation module.
The code for my waves can be found here: https://github.com/noah-peeters/Roblox-Procedural-Ocean (the interpolation module is here: src/shared/WaveHandler/InterpolateVector3)
Having an option similar to BulkMoveTo would be extremely handy though. As it would improve every bulk bone movement.
This reminds me of the original Doom workarounds. They got around all the hard computations that created lag by hard coding it all.
Like others, when I edit my character which is a skinned mesh - it uses Dogu15 - it flickers all the limbs. This needs a fix soon as it’s making games that used skinned mesh rigs look worse.
Heres an example:
I’ve found out that it only happens when something in the character has been edited (transparency, size, colour etc.)
I’ve also found out that it only flickers when you change the character on the server, but if you change it on the client it does not flicker.
I know many people have mentioned this already but I just posted to flag up the problem.
Thanks for your patience, we are investigating.
What happened to my request of allowing us to use any constraint such as springs, to skin meshes? Im still not able to create a trampoline, or a strechy rope.
wait for some reason this has been my question
will Importing S15 directly autorigs if there is no bone for it?
because i don’t wanna use Mixamo since it’s problematic with name Detecting it’s named mixamorigs:RightHand and i want it to be “RightHand” instead since willbobdie’s script is only working for few rigs I’ve downloaded from roblox dev hub
it works fine until realized that they still won’t go with RightHand
also when will there be auto rigs because i need this to be added! and since i’m confused how are they able to rig without getting stretch error
Could this “non-animated state” be manipulated, specifically by saving/changing default poses within Roblox? Seems like it could solve more than one problem.
I run into the same issue of reverting to the initial pose, but only because my mesh is R15 compatible. The default jumping animation does not use the arms, so they revert to the “T pose” midjump. The problem is there’s no combination of arm positions that would be acceptable for the entirety of the game, so there’s no point changing the pose during loading.
Being able to take a snapshot/freeze of a frame of an animated pose (and make it the default pose) right before doing something that isn’t animated (or just partially animated) would solve a lot of problems.
If such a thing is possible, I do not know what words to search for. This doesn’t sound restricted to skinned meshes, but skinned meshes are more likely to show up in their design pose.
Can’t you just run a looped Core priority animation that consists of the frame that you want it to revert to. I think that would work because animations from any priority will overlap if there are no keyframes assigned to a certain bone/motor6d.
This is how I intend to work around the problem, once I actually have to solve it. It’s not entirely clear how much work that will be, due to the newness of it all. Do I have to record a new single-frame animation for every variation I have to fix, or is there a way to truncate an animation via code? And if I can truncate an animation to one frame on the fly, isn’t that essentially a snapshot?
You actually just answered a question I posted a while back that had no replies. Thanks for that! I was always wondering if I could circumvent all of this by separating left arm/right arm animations from the legs (and making autonomous animations like blinking and breathing part of core movement). This would be a lot more elegant solution to a tool heavy game.
Can you, or someone else, elaborate on what this means?
As far as I know placing a bone from your base imported mesh to a random part will just completely break your skinned mesh, as it can’t function without its bones being directly under it (which you recommend we parent to another part). Might be wrong though.
And how do you recommend we connect those separate parts? With BallSocketConstraints? I am pretty new to Constraints so not really sure what it takes to actually connect them.
This morning, we will be enabling a change in skinned MeshParts that should go unnoticed. If you do notice any problems, please reach out, and we will work with you to resolve them asap. Thanks for your hard work and patience!
– Your Roblox Avatar Engineering Team
Could you elaborate on what the change is?
Glad to see this feature is still being improved.
It is an internal code change that will be used in the future to enable new layered clothing features, although you won’t see any new features quite yet.
Yes, there is still a lot of work to do, but we are moving forward with a lot of improvements that you will start seeing over time. Thanks again for your patience with this!
I thought I noticed a new problem surface, but I actually just revisited an old skinned mesh problem. “Can’t name the meshpart and bone the same” breaks in the model importer, too.
Here’s the issue (part1): when loading in a meshpart and bone with the same name, the rig attachments load, but the bone does not. The importer creates multiples of this bone attachment.
(part2): when loading the animation, the animation for the bone loads, but the meshpart is the bone. All sorts of shenanigans ensue. You can modify the animation, manipulate the skinned mesh. This is where it becomes apparent that the bone is not there. The bone is represented by the meshpart origin.
Seems like an easy mistake to make. I’ve made it twice already. There could be some sort of warning during the model importer that a bone and a meshpart share a name. Or, if the intent is to allow this sort of naming convention, there are multiple places causing issues.
As skinned meshparts gain in popularity, this will be a bigger problem for developers.
it changes into R15 instead of S15 hopefully i can have S15 autorigs than R15 since i hate it being separated