Alright great. Rescaling objects is very cheap in most engines. It’s currently pretty tedious to implement and not very performant to rescale models in Roblox.
Also, how much memory does offset caching use per-model? I’m curious how well it scales if I have hundreds of identical models. I’m hoping for features that allow our worlds to support more parts loaded in a scene overall. New properties like PivotOffset seem like they’re just going to make BaseParts less efficient over time. I would prefer lightweight objects over objects with feature bloat, especially if it means we can instantiate more before causing lag. I want to create a world filled with detail. PivotOffset seems like it’s useful in studio, but has little use at during run time.
Some way to create a prototype model, and create instances of it with specific scales/cframes would be the most performant I think. The prototype could have LOD info that gets generated, instead of calculating it for tens of thousands of potentially identical models spread across a huge game world.
I think this is a really cool feature for people who actually build some different parts but for me, since I use many parts and when I select the entire thing it looks like a mess but otherwise I think it is a good feature. Maybe we should be allowed to customize pivots point like set transparency to it or something on the lines of that.
Not very performant is an understatement, it should be avoided at all costs.
A lot, since it’s using the most stable approach to do this, which is completely unopinionated about what’s going on with the models in your level. Specifically, it needs to temporarily store two extra CFrames per part in any of the models that you call PivotTo on.
That’s the reason I did not backport the offset caching behavior to MoveTo / SetPrimaryPartCFrame, because it has a non-negligible cost. The next round of package system changes that I mentioned above will give me an opportunity to reduce that cost significantly but only on models which are packages.
It may not seem like PivotOffset is very useful right now, but once we make the Mesh importers set PivotOffset = mesh origin for MeshParts it will be extremely important in mesh based modeling workflows.
But overall there’s no easy answer to this, compounded by the fact that there is no “in studio” right now: Your place is your place whether it’s in studio or in-game, with no processing step in-between them.
I’ve been thinking about this problem too, of how to reduce the part overhead, and I don’t think adding properties that have good value is doing irreparable damage in any way: There’s lots of things we could do in the future to introspect what usage patterns your game is actually performing and optimize the parts for those for instance, and that’s just one option.
I don’t know if we’ll have a page in the onboarding document initially, but we will have a detailed page on how pivot works in the DevHub documentation beyond simply the documentation on the API methods.
Does this mean that setting part.CFrame has the additional overhead of checking to clear this cache?
This still seems like a studio-only convenience that could be achieved using something like Attributes. While these features may be convenient when building, but I don’t think it’s worth it if they impact performance outside of studio. Even if it seems relevant to something like avatar packages, it’s still not relevant to what a BasePart actually is because this affects all parts in the worlds we create.
My perspective relates this to properties like part.FormFactor, part.Locked, as well as part surface types. These properties are just conveniences for building, and can start to hurt performance outside of building-centric environments as they accumulate up due to feature bloat. Experiences we create are always going to push the limits of how many parts are possible on both high and low end hardware, and these properties don’t help.
My projects have always had various setup / compile stages when the game first runs, mainly to process models and clear properties and objects that are only needed in studio. I don’t think I’m the only one. Currently I run them before publishing
Alright that’s good to hear. I suppose I’m mainly worried about whether setting part.CFrame will be slower because it needs to clear the PivotTo cache.
Perhaps building-related properties (Locked, PivotOffset, LeftSurface , LeftSurfaceInput , LeftParamA , LeftParamB , RightSurface , RightSurfaceInput , RightParamA , RightParamB , TopSurface , TopSurfaceInput , TopParamA , TopParamB , BottomSurface , BottomSurfaceInput , BottomParamA , BottomParamB , FrontSurface , FrontSurfaceInput , FrontParamA , FrontParamB , BackSurface , BackSurfaceInput , BackParamA , BackParamB) could eventually use the attribute system internally with non-alphanumeric keys, or something similar. I remember hearing something like this is done for surfaces (where they collectively use 1 byte by default), but this way there’s no memory impact on parts that don’t use them.
No, that’s why it needs two extra CFrames, so that the cost of the offset caching can be totally isolated to the PivotTo call itself. (It stores where it thinks the part was, and what it thinks the offset is, so that it can lazily tell if something else moved the part and the cached offset is invalid)
Yes… but the point is, doing something like that is not a requirement / core part of how deploying a game works right now, and it’s not something that we want to make a part of the normal process either. The fact that code can generally work the same regardless of whether it’s running in studio or a live game is something really powerful about Roblox that we aren’t planning to give up.
There’s quite a few reasons that using the attribute system is undesirable for this, but something similar to the attribute system is one way that this could be solved, yes.
Thanks for helping me understand. It seems like a good implementation that doesn’t affect the performance of other features.
I completely agree, so long as building-centric properties don’t affect the performance of instances that don’t use them and don’t bloat the API page too much.
Understandable. My reasoning was that multiple expandable structures might use slightly more memory for cases that don’t use either of them, which is relevant to all inert / legacy properties (not just for BasePart) where access speed isn’t a priority.
It would, but there’s some very large benefits to not using attributes for that, for instance:
Network replication would have to be broken down into multiple different codepaths for Attributes because you would not want to double-replicate changes to Attribute backed properties.
Attributes can be added to an object, but also removed. This comes at a cost of using a data structure that can support this. Infrequently used properties would rather be backed by a data structure that you can only add items to which would let it be smaller and faster.
It would be a leaky abstraction where you could cheat and look at the attributes backing the properties without really making the code jump through some hoops.
You can check that your places are working with them enabled, but please hold for a few hours on publishing live code that relies on the APIs in case something goes wrong and we have to turn them back off.
What are the chances that the feature will be disabled? (since couple hours have passed already) and I am planning to use it in a live game soon and I want to know if I might need to revert it back to the custom Pivot implementation.
Pretty low given that I’ve not heard any issues so far, but to be completely safe wait until tomorrow. That gives people who have work / school a chance to get home and find issues in their games.
If there hasn’t been anything requiring a revert by tomorrow then I’ll deal with any place breakages that get found later by individually disabling it for those specific places.
Well I was downstairs for lunch with studio on, and I come back to an error, stating that there was an error downloading a plugin. I go to my plugins list to find this: (Which I had never even touched or seen before) I tried to open the workspace area view but it just didn’t change from script view, and the drafts tab was completely white, so I assumed I was completely disconnected from the game. I had to restart studio to find a fair amount of my progress gone.
Either this is just my problem or Roblox’s problem. : |
Sorry for the issue that you experienced there. That would be something unrelated to this though. The Pivot Editor is a built-in plugin that’s delivered as part of the Studio install itself, it won’t ever be separately downloaded.
We had an issue crop up with our custom furniture scaling system in RoCitizens. It uses GetBoundingBox so I’m assuming it’s related. Would it be possible to turn it off for our live game (RoCitizens - Roblox) until we’ve fixed the issue?
Update: I’m going to have to disable the API in Roblox Studio only until next Wednesday because the Pivot Editor plugin is showing up in the Plugins tab even when the beta is not enabled thanks to it. I’m going to disable it tomorrow morning.
This won’t effect live games (the API will remain enabled on live servers).
This won’t effect people with the beta enabled (the API will be enabled by the by the beta feature).
This will effect you if you updated one of your Plugins to use PivotTo or other pivot APIs between Monday and today: People might see errors using the plugin if they update it between now and next Wednesday and don’t have the Pivot Editor beta enabled.
(Which I had never even touched or seen before) I tried to open the workspace area view but it just didn’t change from script view, and the drafts tab was completely white, so I assumed I was completely disconnected from the game. I had to restart studio to find a fair amount of my progress gone.
