3-style optimized for OH

Aergyl

Regular
Joined
Aug 9, 2021
Messages
98
Location
Sweden
So I've been working on a 3-style sheet with algorithms optimized for OH for a while now and if anyone is interested I will share it here: https://docs.google.com/spreadsheet...8h0aYh3L9AhkNUnYpmZZmNIP0Tw/edit?usp=drivesdk

UPDATED ALMOST FINISHED SHEET: https://docs.google.com/spreadsheets/d/1VYBpI7eHlGkNY-_re0DjH-zWygktUXsya2oO4C6JRiY/edit?usp=sharing

It's a work in progress and I'm not done with corners yet, but most of the other parts are done.

For cases with multiple good solutions, I've tried to include them all rather than just choosing one of them.

If you have any questions, thoughts or suggestions etc. feel free to comment :)

I will now explain some details that might not be obvious. First of all, for OH it seems like UR is the best buffer. I can't say for sure though, but at least I've experimented with UF as well and I did not like it as much. This probably has to do with the fact that the F/B mirror and the (diagonal) R/U mirror of all UR cycles are also UR cycles, and the fact that both z and z' (the best rotations for OH) keeps the UR buffer in the RU-layer, and can thus be utilized for making a lot of good cases.

I should probably also mention that I'm writing most slice moves as slice moves for readability, but personally I think most of them (except S') are often best executed as two moves. This can be done in two ways (for example, S can be executed as F' f or f F' and E as u' U or U u'), and the best choice depends on the specific case.
 
Last edited:
So I've been working on a 3-style sheet with algorithms optimized for OH for a while now and if anyone is interested I will share it here: https://docs.google.com/spreadsheet...8h0aYh3L9AhkNUnYpmZZmNIP0Tw/edit?usp=drivesdk

It's a work in progress and I'm not done with corners yet, but most of the other parts are done.

For cases with multiple good solutions, I've tried to include them all rather than just choosing one of them.

If you have any questions, thoughts or suggestions etc. feel free to comment :)

I will now explain some details that might not be obvious. First of all, for OH it seems like UR is the best buffer. I can't say for sure though, but at least I've experimented with UF as well and I did not like it as much. This probably has to do with the fact that the F/B mirror and the (diagonal) R/U mirror of all UR cycles are also UR cycles, and the fact that both z and z' (the best rotations for OH) keeps the UR buffer in the RU-layer, and can thus be utilized for making a lot of good cases.

I should probably also mention that I'm writing most slice moves as slice moves for readability, but personally I think most of them (except S') are often best executed as two moves. This can be done in two ways (for example, S can be executed as F' f or f F' and E as u' U or U u'), and the best choice depends on the specific case.
Most of the algs look nice to execute OH. RU gen 3-style would be fun to do.

Have you implemented these algs in an actual solve and have a video of you using it in a real solve.
 
Most of the algs look nice to execute OH. RU gen 3-style would be fun to do.

Have you implemented these algs in an actual solve and have a video of you using it in a real solve.
Unfortunately I have only practiced the algorithms for the purpose of comparing them to see which are good and which aren't. It will probably take a while before I can do an actual solve with them.

I can however try to practice a few scrambles and make a video showing how the execution would look.
 
Unfortunately I have only practiced the algorithms for the purpose of comparing them to see which are good and which aren't. It will probably take a while before I can do an actual solve with them.

I can however try to practice a few scrambles and make a video showing how the execution would look.
Sure sounds good.

Looking forward to your execution video.
 
Could there perhaps be application in multi-blind?
That'd be very cool, it's a very interesting idea. However, solving two cubes at the same time (one for each hand) would be pretty tough, and you have to keep track of both cubes' letters. I'm not expecting this to be starting to used in the near future, maybe if multi-blind records start plateauing people would start to practice more and use this.
 
With 3 style being as speed optimized as it is, I feel like being able to solve 2 cubes simultaneously would almost always take more time than just solving 2 cubes individually. For example, Graham's most recent world record has an average exec time of 17.59 per cube, meaning that you would need to solve 2 cubes simultaneously in 35.18 or faster on average to even make it worthwhile to try.

To me, it doesn't really seem worth it to try and optimize OH algs (you would need to optimize different algs for RH and LH) when you can just stick with the method you already use for 3bld and work on optimizations like floating (which graham is in the process of) and other alg sets

Then there's also the fact that Mbld values accuracy and that doing 2 things at once is almost certainly going to trip you up :p
 
UPDATE: I'm finally done with corners and have updated a lot of the parity algorithms! There are still some finishing touches needed, but I'll share my almost finished work here for anyone interested: https://docs.google.com/spreadsheets/d/1VYBpI7eHlGkNY-_re0DjH-zWygktUXsya2oO4C6JRiY/edit?usp=sharing

I'll start by explaining the updates to the parity algorithms. Before, I favored RUL algorithms way more than I should have, and also algorithms that didn't end with a rotated cube, because I thought I might want to execute something after it. The new algorithms on the other hand are designed with a more open mindset. They are very speed optimized, and assumes that you drop the cube immediately afterwards. I'm still including multiple options for some cases, but for various reasons I'm excluding inverses and some conjugates to the included algorithms. Also, I will probably make a video soon, showing how to fingertrick them.

For corners, I tried my best to choose solutions that are not only fast to execute, but also flow well into each other. For example, I didn't include anything with x/y-rotations, because most of the time that will cause big pauses between algorithms, making the solve worse overall. I also included several options for many cases. Notably, there are a lot of good RUF commutators that are pretty much never used for two hands.

I'll probably make another update once I'm actually finished with the sheet. If you have any questions, thoughts or suggestions etc. feel free to comment :)
 
I've now made videos on basic flips and twists as well:


For various reasons, I'm probably not going to make videos on all of the 3-cycles, but I'm planning to make an OH Orozco tutorial, which will feature some of the best ones.

Orozco Tutorial when? uwu
 
Back
Top