Tutorial - Freestyle 4BLD center solving

Status
Not open for further replies.

Ollie

Legend
Joined
Mar 31, 2012
Messages
2,833
Location
London, UK
WCA ID
2012FROS01
YouTube
Visit Channel
A couple of points to clear up before reading these. By freestyle I don't specifically mean '3-style' or speed-optimal 3-cycles (which this does indeed use) but I mean using a range of techniques including solving from fixed and floating buffers in the same solve, using a 'pseudo fixed buffer' (discussed in example 4) and other miscellaneous techniques to increase your efficiency and speed (like the one in example 2.) They require a bit of practice but I have used most of these techniques throughout my bigBLD career.

  • My 'main' buffer is Ulb
  • By 'main' buffer I mean my default buffer, for which I have a speed-optimal 3-cycle for every case.
  • I also know a lot of 3-cycles from other buffers. If I do anything like this during example solves it will be referenced in the example
  • Every example solve has commentary of what goes through my head during memorization and execution. Try to focus on the techniques discussed rather than the algs.
  • Perform all scrambles in your normal BLD orientation.
  • slice moves are denoted by lower case letters in the example solutions. Wide turns are denoted by Rw etc.
  • These can also be used for 5BLD, but for the purpose of the tutorial I will reference 4BLD specifically.

Example 1: R B' u2 U D2 B r' R' U2 D B2 D' L2 B' U2 R U' B2 r' f u' f D2 U' f u R2 r' B2 r2 f r' F2 U' R D' f' R' U L'

Techniques discussed: 2-cycle solving, cool 3-style algs, tactics for memorization

x2 z // Straight forward, L and U face centers are easiest to see, don't waste time finding anything else

[2Dw: l', U r' U'] // rotationless and fast alg to execute
[D' x': r' U' r, u2] //
[L': d, r U2 r'] //
[d': r U2 r', d'] // Cancels into a rotationless 9-mover. Also [x': 2Uw r 2Uw', l'] is cool
[l2, U r2 U'] // Leaves a potentially hard opposite center case. During memo I see that the Dfr center is solved, so I can use it to solve the final center with a nice opposite center comm.
[U' r2 U, l2] // And now there are two lone centers on the U and D faces, but now they can be solved with ease with this alg.
[l u l', U'] // Take advantage of my solved 'main' buffer to solve the final R face center.
[r', U l U'] // Simple Niklas from the back to finish.

Example 2: f2 D B' u L2 R2 D2 u' L F' L' R r D2 f D2 B L2 f B' F' u2 r B U D' R2 U u' L' B2 R U2 r L2 R' u2 B' U' r

Techniques discussed: solving difficult isolated 2-cycles speed-optimally, tactics for orientation

x // two good options here, x or x z' both leaves 3x faces with two solved centers each. x is easier to see, but also x z' leaves U face centers on the D face which could be troublesome to solve later on, so x is best.

[R2, r U2 r', d'] //
[u': l', U r2 U'] // Some people don't like algs with u' set-ups, but I prefer them as it takes out a rotation and I generally try to remain as rotationless as possible.
[x': u2, r' U' r] //
[R2 y': U' r U, l] // not an ideal case, but set-ups to Niklas style comms are usually fastest. [R' y': d2, r U' r'] isn't bad, either.
[F: U r U', l] // solves your 'main' buffer
[l2, U' r2 U] // solve this case first so you can leave a super awesome case for the U and L centers.
y' r U2 r' U (l') U' r U2 r' U' (l) U // This cancels into the algorithm [U r U2 r' U, l'] which is far more superior than doing two comms, IMO. This was generated by Matt so he deserves full credit for this - the other algs can be found here.


Example 3: f2 B2 R' U2 B u B f2 r U2 f' L U' F2 u2 B2 f2 U2 u B2 R' F u' B' U f' B F2 U D u L2 r' F U2 D R2 r D u'

Techniques discussed: cool 3-style algs, 2-cycle solving, planning cycles during memorization, tactics for orientation

z' // although doing z solves 2 centers on F and D which might be beneficial to some people, it solves 'main' buffer. I try to avoid this for a few reasons (mostly simplicity and to keep all my solves as uniform as possible) so I do z' instead which leaves U and L face centers solved instead.

[B': U r' U', l2] //
[y' U: l2, U r U'] // a trickier case here as well, the rotation to the 9-mover is my favourite. There is also [3Dw' x': r' U' r, u2]
[R u: r U r', u] // a setup to a 9-mover eliminates rotations, and because the alg is mostly quarter turns I find this to be really fast.
[R: d', r u2 r'] // cancels to leave a 2Rw' at the end which is pretty cool.
[R y: r2, U' l' U] // I have an option of two U face centers on D to end the cycle and keep it nice and neat. Dfr leaves an awkward final case (Ubl -> Rdf -> Dfr) so I'll solve to Drb instead. This also leaves an easier L2C commutator to do afterwards.
[r2, U' l2 U] // see?
[U2: r, U' l' U] // I solve this case like this because it cycles only one U face target, and since I have three separate and easy to solve L2C cases left I can solve it with the faster Niklas case.
[U2: l, U r' U'] // same case from the back. You can also break into that last cycle from that final U face buffer, but since it's not your main buffer it will take some thought (fast BLD is braindead.) Solve it like this and for the final case...
[y': r U r, d2] // boom

Example 4: r2 F2 L2 D B' R U F B' R' u R2 U2 D2 B2 r2 F' U u' L' u2 F' L2 B f' U2 B' R2 u' f2 u2 U' B' U' F2 f2 B2 L' D' L

Techniques discussed: pseudo fixed buffers

y // the other option is x y, but again, my 'main' buffer is solved which I'd rather avoid. y it is, then (plus y is easier.)

[x': l' U' l, u] // algs from the back are cool
[L: r U r', u'] //
[R2 u: r U r, u2] // sets up to a rotationless 9-mover which is fast. But I'll have to end the cycle early here. I could shoot to a different R face target but I could also do this afterwards...
U2 // this was suggested by Noah Arthurs a long time ago and it will save some moves other breaking into a different U face buffer, you just have to remember to do U at the end of the cycle otherwise you'll mess up centers. I pull my legs underneath my seat when I use this 'pseudo' fixed buffer - once the cycle is over, I check the position of my legs to see if I've been using the 'pseudo buffer' (if I don't remember to undo it normally.)
[x: d2, r U' r'] // my default alg, however there is also the possibility of solving that case with the 'pseudo buffer' in its normal position with [U l' U', r2] which is what I'd normally do, but try to keep your solutions simple if you can.
[d', r U2 r'] //
[D2 y': l', U' r2 U] U2 // I can undo the U2 setup from the previous step by cancelling it into that last alg. (D2 l' U' r2 U l U' r2 U' D2)
[U: r', U l U'] // normal finish for L2C


Example 5: F B U2 f2 U' B2 D u' R2 f' D F r2 F f' R' L' F f U' F f' r u' f2 B R' D F2 D' u' B2 F2 f2 D' r L' f D2 L'

Techniques discussed: orientation tactics

x y // I could also do x y2. I would do x y because the two unsolved buffers on U are now my 'main' centers buffer and my corners buffer (Ulf) where some similar corner algs could be transferred over, but that's just me.

[B': l2, U r' U'] //
[L2 y': U' r2 U, l'] //
[z: u, r U r'] // the z algorithms are definitely worth considering, they can be very fast. z' not so much, but again that's just me
[u2, r U r'] //
[y': l, U' r U] // these Niklas type algs are fast too. Learn all of these.
[D' x': l' U' l, u2] //
[R2 y: r2, U' l' U] // lovely cycle, as it leaves a lone commutator at the end.
[F': r U' r', d2] // unfortunately it doesn't draw any parallels with my usual corner commutator but it is easy to see and it is fast.

I hope this is worthy enough to merit its own thread. If it proves to be a dud then we can move it into Random Blindfolded Discussion :)

EDIT: I've just noticed that all of the center solutions are 7-9 commutators long which on reflection is pretty normal for me. Is that efficient? Or are they easy scrambles (they were the first 5 scrambles I generated from qqtimer?)
 
Last edited:
EDIT: I've just noticed that all of the center solutions are 7-9 commutators long which on reflection is pretty normal for me. Is that efficient? Or are they easy scrambles (they were the first 5 scrambles I generated from qqtimer?)

I'm not a particularly good 4BLD solver, but I'm pretty sure my centers are typically 7-9 commutators long. And I can definitely remember my 3 for this week's weekly competition (since I just did them a few minutes ago), and they were 8, 7, and 8 commutators long, so that's consistent.

I do consistently use floating buffers (I never use fixed buffers for centers), so that theoretically keeps my count 1/2 to 1 commutator shorter than for those who don't.

And this is nice - I look forward to walking through these to look for places I might get better.
 
I'm not a particularly good 4BLD solver, but I'm pretty sure my centers are typically 7-9 commutators long. And I can definitely remember my 3 for this week's weekly competition (since I just did them a few minutes ago), and they were 8, 7, and 8 commutators long, so that's consistent.

I do consistently use floating buffers (I never use fixed buffers for centers), so that theoretically keeps my count 1/2 to 1 commutator shorter than for those who don't.

And this is nice - I look forward to walking through these to look for places I might get better.

I did a 'sample' of 4x4x4 scrambles today and found that my solutions ranged between 6-9, with 9 commutator solutions being quite rare unless I spent a bit longer adjusting my memorization, in which case I could usually reduce it by 1 or 2 commutators (which I wouldn't do in a real solve, ain't nobody got time fo dat) but it's nice to see that my solutions are on par, at least :)
 
Yeah 7-9 commutators seems correct. That's what 99% of my solves have at least...
I thought it is worthy to note that on the supercube, it takes a maximum of 12 3-cycles to solve every non-fixed center and wing edge orbit (one at a time).

The exact average number of 3-cycles needed to solve all 24!/2 even permutation cases of 24 objects is 7272437897/669278610 (about 10.87).

For permutations (only) of middle edges (12 objects), a maximum of 6 3-cycles is required, and the exact average number of 3-cycles to handle all 12!/2 even permutations is 34757/6930 which is about 5.02.

Similarly, for permutations (only) of corners (8 objects), a maximum 4 3-cycles is required, and the exact average number of 3-cycles to handle all 8!/2 even permutations is 649/210 which is about 3.09.

(May be 6 3-cycles and 4 3-cycles might be able to handle all even permutation middle edge and corner positions, respectively, but my simple Mathematica program only can be used to solve permutations only.)

All of these calculations include the solved case (which obviously is an even permutation and is included in the k!/2 quantities).
 
Ok. I've checked it few times and it has messed a cube but now it seems to work fine. I had to execute this alg not properly. :)

BTW - thanks for this tutorial.

Is there a list of commutators I have to know to start using this method? I mean not full list (there's in your singature, I ve noticed it) but for example a set of 12 comms for a beginner. For exemaple to execute it by making a setup, alg and undo setup. I hope you know what I mean. :)
 
Is there a list of commutators I have to know to start using this method? I mean not full list (there's in your singature, I ve noticed it) but for example a set of 12 comms start and to apply them making setups. I hope you know what I mean. :)

Here are some 'must know' center algs, if I understand you correctly (not sure what your buffer is, but I'm sure you can correct them):

[r U r', u]
[r U r', u2]
[y: [l u' l', U']] // the three basic cases

[U r U', l2] and [U r' U', l2] for the case from the back
[U r2 U', l'] and [U r2 U', l] for the back case
[U r' U', l']

Learn the inverses and how all the interchanges/insertions work for totally awesome 3-style center algs
 
Thanks Ollie. :)

My bufer is Ubr when I solve centers with U2 but I think Ubl is ok for me, because I've started to learn comms for corners with UBL bufer. I will learn and play around with them next week.
 
Here are some 'must know' center algs, if I understand you correctly (not sure what your buffer is, but I'm sure you can correct them):

[r U r', u]
[r U r', u2]
[y: [l u' l', U']] // the three basic cases

[U r U', l2] and [U r' U', l2] for the case from the back
[U r2 U', l'] and [U r2 U', l] for the back case
[U r' U', l']

Learn the inverses and how all the interchanges/insertions work for totally awesome 3-style center algs

The algs are fine and it looks like I've learnt to solve centers in 4bld with comms. I use floating buffer, rotations etc. I've added some "my" algs etc. It's quite easy now, though it was hard to understand how some of situations I can fix.

But here's the point - is there a similiar set of algs for T-centers in 5bld. I've start to using algs from x-centers. But they are based on r-slice. It works, but I found in your set of algs in your signature you are using m-slice. Can you help me? Or should I stay with r-slice?
 
Last edited:
The algs are fine and it looks like I've learnt to solve centers in 4bld with comms. I use floating buffer, rotations etc. I've added some "my" algs etc. It's quite easy now, though it was hard to understand how some of situations I can fix.

But here's the point - is there a similiar set of algs for T-centers in 5bld. I've start to using algs from x-centers. But they are based on r-slice. It works, but I found in your set of algs in your signature you are using m-slice. Can you help me? Or should I stay with r-slice?

[r U r', E']
[M' U M, E']
[y: [M u' M', U']

[U r U', M2]
[U r2 U', M']
[U r' U', M']

You should choose whatever's more comfortable for your t-center buffer. I optimized about 90% of my algs for just the r and M slices and it works for me.
 
why do you randomly choose centers to shoot to? I always go clockwise from the top left to make things easier to keep track of.
 
why do you randomly choose centers to shoot to? I always go clockwise from the top left to make things easier to keep track of.

I don't pick them randomly. I start at the top left and go top left -> top right -> bottom left -> bottom right. I don't always stick to that system, for the following reasons:

1. To prevent short cycles, or ending a cycle too soon.

By choosing a different target (not always the next clockwise center) and making a cycle longer, I can avoid things like 'center parity' and extra cycle breaks.

2. To get nice center cases.

If I can force an 8-mover with no rotation instead of a 10-mover with a rotation by choosing a different target, I generally will. If it requires too much thought, I don't bother.
 
Last edited:
Status
Not open for further replies.
Back
Top