MY GOD, SORRY I READ IT WRONG. It seems that I thought it would be unrefreshed on the client, and would no longer be replicated and therefore readable on the client, rereading I see that it meant it would be calculated seperately, sorry again, this is actually useful! Considering client effects and all that!
I know itâs not being removed, it can be locally spoofed which is why I checked it on server
Actually, previously the value was replicated from client to server. So a spoofed value on the client was being replicated to the server.
In terms of performance issues - performing your own raycasts not every frame might be more efficient then listening to the floor material. Listening to FloorMaterial on the local player humanoid on client would be more efficient.
Just a note: Depending on the situation, the reason Raycasting yourself could be cheaper is that if you donât need super high fidelity you can do less work than the Humanoid does. The humanoid may Raycast up to 9 times to determine the floor in order to catch every edge case, but you might be happy enough with the result from a single Raycast.
EDIT: Though remember, if your code is running on the same peer thatâs simulating the Humanoid, the floor has to be calculated every frame anyways for the Humanoid to work. Thereâs only any additional cost if you ask for the FloorMaterial on a different peer that wasnât calculating it by default (such as asking for a playerâs FloorMaterial on the server).
Whatâs the point of this property now, if listening to its changes is bad for performance?
I really donât understand it. What happens internally when we access this property? Does it raycast 9 times and then gives us a result?
If so, can someone tell me whatâs the point of using this property if it turns out to be really bad for performance?
FloorMaterial
catches all edge cases, while a single raycast might miss the floor if the humanoid is standing on the edge.
Haha kinda surprised it wasnât already calculated this way.
Thanks for the update!
More likely than not, non-network owned humanoids will not be âfully simulatedâ for performance reasons, so the humanoid does not compute the FloorMaterial
property.
However, network-owned humanoids will be âfully simulatedâ, so the humanoid is already doing the computation for the FloorMaterial
property, regardless of whether or not the property is read. In this situation, reading the FloorMaterial
property will not trigger any additional raycasting. This is very efficient if you are perhaps listening to FloorMaterial
property on the local humanoid to play custom footstep sounds for different kinds of part materials.
There is a performance improvement in that for games not using the FloorMaterial
every frame because now we no longer replicate an unused property. Additionally, accessing the property perhaps whenever a Humanoid changes to the jump state would probably not be too much overhead and you would not have to implement your own raycasting.
So itâs really dependent on your own use case.
Can we get access to the internal floor normal calculated by humanoids? Sure, you could fire a single (or multiple) raycasts down to find it yourself but since the humanoid is already doing it better itâs just extra wasted raycasts.
I was expecting this change for quite some time, and I cant say that Iâm too mad about it. Iâm wondering about the preformance effects of this change as I imagine itâs pretty great. I do actually wish this was completely toggled in the settings because most experiences on Roblox dont use this feature, and some do (IE server-sided movement sounds).
Iâd imagine in the future there will be a better community written version of this, but for now au revoir!
This change is extremely useful as in addition to some performance benefits, it also improves server side sanity checks to determine if a player is actually grounded or not on the server and not locally it self (as this member was previously calculated locally on the client and then replicated to the server) and clients can no longer spoof this member anymore finally.
If so, can someone tell me whatâs the point of using this property if it turns out to be really bad for performance?
@focasds The humanoid may cast up to 9 rays to determine the floor reliably in some edge cases and itâs worth reminding you that ray casting is very cheap over short distances. For longer distances, they have been improved performance wise thanks to this update: Upgraded, Improved, and Faster Raycasts
when will we get a humanoid.FloorPart property i mean i love this update and all but i feel like it wouldnt be too costly on performance right? you are searching for the part already anyway so you might as well give the part as a property as well so we dont have to repeat the floor checking even though the humanoid system is already doing it
One complication that prevents it from being a âfreeâ addition is that itâs less likely to âjust workâ out of the box:
-
If you have one foot on one part and the other foot on a different one, will the code using FloorPart do the right thing? The same issue does exist for FloorMaterial but its less likely to cause issues in practice because youâre less likely to being doing something gameplay critical with the result.
-
What if the FloorPart is terrain? To work correctly all the code using FloorPart would likely have to handle both branches (Terrain vs non-Terrain) separately. FloorMaterial doesnât have the same issue.
I think Iâve found some type of bug within this change because my shadows have a huge circle cut out every time I change position
This was working before the update and this is bugged in multiple games other than just mine.
This is what is looks like:
ohh i see why this isnt a thing yet; in that case is it feasible for roblox to tell how they get the floorpart is it just simple raycasting every frame??
edit: am asking cuz i wanna make a function for this and open source with a buncha other things i made
Is there a way to view this script that youâre talking about? Iâm interested in seeing how thatâs done.
Hi, what game is this? And/or how are you using Humanoid.FloorMaterial
?
Hey, I believe their issue is related to mine also:
Iâve attached a repro file in there.
Iâve been unable to repro this⌠what sort of device are you using?
Going back into this place again, it seems that the issue has seemingly been fixed. I will try also looking in my studioâs place, where the issue was much more prominent.