(Continuing from here: Why was :GetModelCFrame() deprecated?)
Since GetModelCFRame() is deprecated due to the reason Sharksie gave, could we get a non-deprecated method for returning the center position (Vector3) of a model, as I use it for Region3 and range calculations for things like automatic doors and regen buttons.
What Sharksie said is wrong. GetModelCFrame should be undeprecated. GetModelCFrame returns the current center of the model – if your code breaks because you expect the center of an unanchored assortment of parts to remain in the same place, that sounds more like a lack of understanding of unanchored parts as opposed to GetModelCFrame not working correctly.
Going off this, I can agree with Echo. I use it all the time in my games for collision checking and haven’t had any issues with it.
I thought things couldn’t be deprecated unless there was a better way of doing the same thing?
Can you describe the intended behavior? Would this be the center of a bounding box, or the average position of the constituent parts?
Finding the center of a bounding box would be a very slow operation; from what I understand, it’s O(n^3).
This is the current behavior, and the behavior I rely on.
I don’t have a use case for the other to be honest.
Sorry, edited my post as you were replying. I’m not really familiar with this method, so excuse my ignorance.
So GetModelCFrame() already does what you want, but is being deprecated?
Personally, when I need a physical property of a model such as the center for distance checks, I just put an invisible block in it to represent that physical property. It’s probably not ideal, but it works for my purposes…
I use it to draw a bounding box around the model. GetModelCFrame and GetModelSize give the dimensions of the part that I use as a highlighting box.
I listed some use cases in the thread linked in the OP if you’re having trouble figuring out what GetModelCFrame could be used for.
I have no doubt of the uses, thanks. The problem is that I don’t know if GetModelCFrame really found you the center of the bounding box or the center of a computed PrimaryPart.
What do you mean? If you have n parts in the descendant tree of the model then it’s O(n) right? I think it’s just a matter of summing the positions of the middle of the parts multiplied by their respective weight, where the weight is determined by the magnitude of the size of the part. And then for the result you simply divide the resulting vector by the total sum of weights.
This would at least work fine for regular parts, wedges, spheres, etc, and for union parts you could simply assume that their center is the middle of the bounding box.
The problem is that that’s not exactly correct. What’s preferred here? Correct but slow, or fast but incorrect (and possibly unstable)?
I don’t think the algorithm I describe is unstable. Or do you think it is too slow instead? I don’t think it should take that long to traverse the descendants tree of a model and sum up the position * size weight like that and then divide the total, and if we’re calling it on a model that is too large then surely that would be the developer’s problem.
I think “center” is an ambiguous word to use. Do we want the center of the model’s AABB or the centroid?
The centroid is obviously cheap and easy to compute in Lua, but it would be better to have the AABB done c-side