It is something worth discussing, but we would like to avoid this route if possible.
I would be inclined to agree, fixed-axis force would be a huge benefit, so Iām glad youāre looking into it.
How much of an improvement does this see in physics performance? Iāve not had a chance to test adaptive yet. Sounds like it could be a significant improvement!
Itās quite the opposite actually. The setting is not to increase performance, but to decrease it for games that donāt need it. The spare CPU cycles could be used to power something else in the game for example, if you donāt need to simulate lots objects being flung around the players.
Thanks for the feedback. Iām interested in getting a repro with the issues you are seeing with your game. (DMd)
Hmm I will try to message bug reports asap, hereās what I had around 10 QA testers report when testing adaptive timestepping in short tho:
- When a player walks into another player they both get flung into air. This bug used to be in roblox many years ago but was patched in fixed.
- If thereās an unanchored object standing on an unanchored object the object on top will end up tripping
- Unanchored assets shake like crazy for no reason
- Purposely dragging the player makes the player fling in Adaptive only
- If you walk into a wall the camera starts shaking and so does the player
- If you hold the left/right arrow keys + w the camera starts stuttering
- If thereās too many parts (around 50) adaptive becomes really laggy and ends up just freezing most of the parts in air
Other bugs iād like to report while iām on it
-Strafing enabled toggle is broken
-Video looped/playing toggle is broken
Both reset to off when publishing/reopening studio and can only be enabled thru scripts.
Some of those bugs happen to the games in my profile. I am hosting another QA test tomorrow so Adaptive is on.
I would like an option in which itās adaptive between 120Hz and 240Hz. Iād like to use this, but 60hz just too often breaks stuff, as others have reported as well. I do feel like 120Hz would be enough, but I canāt properly test this.
At least consider this, I have no idea how difficult this would be to implement.
Maybe it would be better if we saw a Dynamic option that allowed us to individually set the physics behavior of each BasePart/Assembly, as well as the ability to set what the default behavior for all BaseParts/Assemblies is. An extension of this for code, as MANY systems rely on RunService events would be .stepped type events for both physics behaviors that can be used interchangeably, i.e. RunService.AdaptiveRenderStepped and RunService.FixedRenderStepped, assuming that is possible of course. Iām pretty sure in Unity there is something similar, but donāt quote me on that.
Hey, thanks for the feedback. We have the ability to tune the aggressiveness of the system, so in the future we plan to provide the option to select between different modes
It depends on the game, but if your game doesnāt involve any hard-to-solve mechanisms (which will default to 240hz) you can expect ~2x perf boost for physics simulation time.
I just tested adaptive timestepping right now on my community fighting game (squid game chaos mode)
Itās a small game that really only has close quarters combat
Things I noticed immediately:
- Random flinging during combat (even though mostly everything is can collide false)
- Note that Iām not using any body movers or stuff for combat, just pure animations and tools. (The tools are can collide false, and using r6)
- The adonis fly command, has random glitchbacks and caused a massive FPS drop that didnāt subside even when I rejoined the game (very odd)
These are just 2 instances I found right now, so Iāll probably keep fixed on for most of my games, I will continue testing and reporting on other issues I find though!
Weāve been working on tuning humanoid simulation behavior a lot recently. Iām interested in knowing if the humanoid related issues still there.
Thanks for taking time to post the videos, these are super helpful.
Iāll try out your game to see if I can catch anything.
While youāre there fixing the missing vector3 maxforce issue, itād probably be a good idea to wrapper or clean up the whole API for bodyAlignmentā¦
For something that is meant to be the ācoreā of making things like baddies and elevators and doors in roblox, its API and workflow has a few problems. Especially now if you really are pushing hard to take away bodyPositions.
A very common experience is: " Add BodyAlignment to unanchored part. Add attachment to unanchored part. Put into single attachment mode. part still falls to the ground"
In general:
-
The default values are poor for the common use case. Most people just want to use a bodyAlignment to glue a part into a fixed position in the air, much like using a bodyPosition. Figuring out how to make this work via single attachment mode and the correct forces is actually fairly difficult.
-
It has a lot of properties. Many of which are contextual and donāt do anything, depending on what mode it is in. This is super confusing especially when you encounter issue 1
-
There is little to no feedback as to what goes wrong when your bodyAlignment doesnāt do the thing. Did I use the wrong setting? Are the attachments wrong? Whatās going on?! Warnings or errors would be appreciated.
-
The way youāre meant to put the attachment somewhere else other than on the object is ultra confusing. Why the heck doesnāt this work, or at least give feedback why its not working.
Hereās a fun experiment: Try a blind test where you watch someone whos never used roblox before try and make an unanchored part stick in the air with a bodyAlignment. Just give them the rough outline of āOh, you make parts fly with a bodyalignmentā and watch them goā¦
That would be good! I donāt know performance increases, but for stability I think a lot of feedback/issues by people in this thread would be solved with 120Hz/240Hz. Or just a lower āagressivenessā could help, although that may be tricky for all use cases.
Something else you could consider is dividing the workspace up in regions to apply this to, but that might technically be impossible (not sure how the system works under the hood) and thus I didnāt suggest it at first.
Can I ask how the flying command is implemented? Are you using constraints or is the character being CFramed?
Perhaps bodyalignments could be set to a āsimpleā mode by default that make them behave more like old bodymovers, while the more niche, power-user capabilities can be relegated to an enum or a true/false boolean
This is awesome feedback. Thanks for sharing.
The admin seems to be using Body gyro and body position
Adonis is an open sourced admin thatās used by a lot of developers, the source code can be found here if youād like to take a look
Adonis Admin Loader [Epix Incorporated] - Creator Marketplace (roblox.com)
Adonis MainModule - Roblox
Was DMd some repros that might be related. Iāll take this cases into consideration and polish the logic a little more!
Below is an example of a problem I have run into with a bridge made with sections connected together via RopeConstraints
.
With Adaptive
timestepping:
With Fixed
timestepping:
Admittedly, this is the most egregious instance I have. Even in Fixed
mode, getting this bridge to play nice has always been a problem. This is a shame because the game the bridge is in would otherwise benefit from adaptive timestepping if this issue did not occur.
Adaptive timestepping is a feature that Iām on board for and will use where I can get away with it, but without a means of highlighting problem children to the engine, developers are at the mercy of the engine to prioritize things the same way they do. This point has been addressed before, so I will not belabor it, but I do want to throw my chips into the ādo not remove Fixed
modeā pot so long as there is no reliable workaround to problems like these.