# Last Layer Optimized Blockbuilding [LLOB Method]

#### CriticalCubing

##### Member
LLOB is a method whose aim is to provide an alternative way to finish L10P that allows for higher max TPS and lower movecount. It gives the solver the flexibility to turn fast and spam TPS during ZBLL, while still being efficient for the Block building/F2L part of the solve. It’s also for people who don’t want to use traditional Roux (CMLL + LSE). It has lower move count than CFOP, is more efficient than CFOP, rotationless and efficient than ZZ-a EOF2L. You get the same result as CFOP F2L while being more efficient and turning slower, while ending with ZBLL and allowing good prediction ability for ZBLL. Your solve, for the most parts, is pauseless.
LLOB Document: http://bit.ly/llobmethod

The approach we propose is EO+DFDB + ZBLL for LL. The aim was to provide an alternative way to finish L10P that allows for higher max TPS and lower movecount in exchange for a very large alg count. Yes, sure, it might sound very similar to something people propose on a weekly basis, but in this case, the details matter and are what make this something other than a regular roux-cfop hybrid post.

Let's look at the 3 L10P methods

CMLL + LSE
This is standard for Roux. Avg movecount: 10 CMLL (computed from avg of all the algs in my cmll sheet + 0.25 AUF) + 13 LSE (assuming 8 EOLR/EOFB and 5 4c, essentially the most advanced LSE there is) = 23 STM total

DF+DB, OLL, PLL
This is what beginners propose all the time. Avg movecount: 6 DFDB (I just got 10 random state LSE scrambles from cstimer and solved DFDB) + 10 OLL (from here + 0.25 AUF) + 13 PLL (from avging algdb.net algs + 0.5 AUFs) = 29 STM total

DF+DB+EO, ZBLL
This is what we are proposing. Avg movecount: ~8 DF+DB+EO (again, got 10 random state LSE scrambles and solved) + 15 ZBLL (optimal movecount for ZBLL is 12.08, so I'm overestimating generously for the sake of argument. For comparison, optimal PLL movecount is 11.5 and avg movecount for speedoptimized PLL algorithms on algdb.net is ~12.8) = 23 STM total

Note that our proposed L10P finish, on average, would take as many moves as CMLL + very advanced LSE (which often entails learning additional CMLLs to influence EOLR cases). So yes, the "only" difference between this and what a beginner proposes is that EO is done with insertion of DF/DB edges, and we use ZBLL instead of OLL/PLL, but it's clear that this difference is crucial. In this case, this method is as efficient as world-class L10P and so the standard objection to "roux-cfop hybrid" posts (namely, inefficiency) that prevents them from taking off does not stand; hence the indicator that "it looks like other methods that have been shot down before" shouldn't come into play here.

Now there are two further objections that I think can be raised at this point:
1) It may be just as efficient as vanilla roux, but why do this silly stuff? It disrupts flow; CMLL/LSE is a cleaner approach.
2) If you're going to learn FULL ZBLL, why not learn the method that was meant to be used with it, ZZ?

And my responses:
Objection 1) I'm going to assume the crux of this objection is not that EO+DFDB just "feels unclean" or "unnatural," as these are rather subjective points; instead I'm assuming the main point is that there seems no reason to go to such lengths if you can get as much bang for only 42 algs' buck. My response to this is that there is indeed a small advantage to this approach over standard CMLL/LSE: specifically, flow can be much better with EODFDB/ZBLL. There are two advantages I see:

(i) Very good prediction. During SB, it is very easy to track DFDB edges + D center, so there should be no pause between SB and EODFDB. During EODFDB, it is very easy to recognize CP (because corners are just being AUFed back and forth), and imo possible to predict the position of two edges; hence, there should be no pause between EODFDB and ZBLL. Currently, Kian believes the main bottleneck of a Roux solve is the often frustratingly long pause to recognize CMLL (the rest of his solves are pretty much pauseless). By performing this recognition during the execution of EODFDB, we can eliminate this pause, leading even more fluid solves.

(ii) Higher tps. In CMLL/LSE, 10 moves are drilled algorithmic face turns and 13 are MU spam; in EODFDB/ZBLL, 8 moves are MU spam and 15 are drilled algorithmic face turns. I think it is safe to say that face turns can achieve a higher max tps than MU spam (Lau's 0.6 Uperm suggests 11.6 stps, while... well, I believe there's a 20TPS T perm somewhere out there?), so even if EODFDB/ZBLL may achieve the same movecount as CMLL/LSE, it has the potential to be faster.

Objection 2) Well, this is an interesting one. ZBLL was invented for ZB, and then used in ZZ, and now we are trying to say it can be used in this Roux-hybrid thing as well. So now let's compare ZZ-a and EODFDB/ZBLL: both finish with ZBLL, so we'll just compare EOF2L movecounts:

ZZ-a: 6 EOLine + 25 F2L (stepwise optimal, taken from ss forums post) = 31 STM EOF2L
EODFDB/ZBLL
: 7 FB + 15 SB + 8 EODFDB = 30 STM EOF2L
Importantly, I have way more experience with Roux than I do with ZZ, so for the sake of argument I took stepwise optimal F2L movecount for ZZ and the average movecounts I get for my own F2B in Roux (which are, I'm sure, able to be improved). Note that even with these conservative figures the Roux approach to building EOF2L appears to be as (if not more) efficient. There is now a question of ergonomics, and on this front I think the the two approaches can be equally fast. Some may prefer ZZ F2L (slightly awkward EOLine but rotationless, easy lookahead and RUL) while others may prefer Roux F2B (slightly awkward FB but rotationless and RrUM). I'm not sure an argument can be made for one being strictly better than the other, but if someone equally competent/experienced with both methods says otherwise then I'd gladly stand corrected.

So in sum I think that this method is nothing amazingly innovative or revolutionary, but certainly deserves more than to be simply dismissed as another reinvention of a shitty wheel. The ideas are simple (the only differences between this and commonly proposed DFDB/OLL/PLL are really just EO+DFDB and ZBLL in place of OLL/PLL), but they have merit.
8.41 ao5 with OLL/PLL for LL instead of ZBLL, as I don't know ZBLL yet. You can be sub 8 with this method and even sub 7.

Last edited:

#### Sajwo

##### Member
What TPS is achievable with F2L?

#### CriticalCubing

##### Member
What TPS is achievable with F2L?
Block building can reach 8-10 TPS, and DFDB+EO can do the same. Last Layer can reach higher TPS as its just alg spam. However, reliance on TPS is not needed for LLOB as with just over 5 TPS, I'm getting 8 sec solves. 6-6.5 TPS can get you low 7 solves.

#### bobthegiraffemonkey

##### Member
Sorry, but this is just a Roux/CFOP hybrid that countless others have thought of, and is generally considered to be worse than either method.

#### Ghost Cuber

##### Member
Sorry, but this is just a Roux/CFOP hybrid that countless others have thought of, and is generally considered to be worse than either method.
Are you talking to CriticalCubing or Aerma?

#### bobthegiraffemonkey

##### Member
Are you talking to CriticalCubing or Aerma?
CriticalCubing, Aerma is just doing a different LSE so it's still Roux I guess.

#### SolemnAttic

##### Member
Actually, I think this is better depending on your blockbuilding skill and LL tps. I mean, my OLLCP and E Pll algs are better than my CMLL ones.

#### CriticalCubing

##### Member
Sorry, but this is just a Roux/CFOP hybrid that countless others have thought of, and is generally considered to be worse than either method.
The thing that people think of is just inserting the DF and DB edges and using CFOP Last Layer techniques for solving the rest (I also did the same thing in my solving video). Every person who has used Roux while being a CFOP user, has done the same thing.
The approach we propose is EO+DFDB + ZBLL for LL. The aim was to provide an alternative way to finish L10P that allows for higher max TPS and lower movecount in exchange for a very large alg count. Yes, sure, it might sound very similar to something people propose on a weekly basis, but in this case, the details matter and are what make this something other than a regular roux-cfop hybrid post.

Let's look at the 3 L10P methods

CMLL + LSE
This is standard for Roux. Avg movecount: 10 CMLL (computed from avg of all the algs in my cmll sheet + 0.25 AUF) + 13 LSE (assuming 8 EOLR/EOFB and 5 4c, essentially the most advanced LSE there is) = 23 STM total

DF+DB, OLL, PLL
This is what beginners propose all the time. Avg movecount: 6 DFDB (I just got 10 random state LSE scrambles from cstimer and solved DFDB) + 10 OLL (from here + 0.25 AUF) + 13 PLL (from avging algdb.net algs + 0.5 AUFs) = 29 STM total

DF+DB+EO, ZBLL
This is what we are proposing. Avg movecount: ~8 DF+DB+EO (again, got 10 random state LSE scrambles and solved) + 15 ZBLL (optimal movecount for ZBLL is 12.08, so I'm overestimating generously for the sake of argument. For comparison, optimal PLL movecount is 11.5 and avg movecount for speedoptimized PLL algorithms on algdb.net is ~12.8) = 23 STM total

Note that our proposed L10P finish, on average, would take as many moves as CMLL + very advanced LSE (which often entails learning additional CMLLs to influence EOLR cases). So yes, the "only" difference between this and what a beginner proposes is that EO is done with insertion of DF/DB edges, and we use ZBLL instead of OLL/PLL, but it's clear that this difference is crucial. In this case, this method is as efficient as world-class L10P and so the standard objection to "roux-cfop hybrid" posts (namely, inefficiency) that prevents them from taking off does not stand; hence the indicator that "it looks like other methods that have been shot down before" shouldn't come into play here.

Now there are two further objections that I think can be raised at this point:
1) It may be just as efficient as vanilla roux, but why do this silly stuff? It disrupts flow; CMLL/LSE is a cleaner approach.
2) If you're going to learn FULL ZBLL, why not learn the method that was meant to be used with it, ZZ?

And my responses:
Objection 1) I'm going to assume the crux of this objection is not that EO+DFDB just "feels unclean" or "unnatural," as these are rather subjective points; instead I'm assuming the main point is that there seems no reason to go to such lengths if you can get as much bang for only 42 algs' buck. My response to this is that there is indeed a small advantage to this approach over standard CMLL/LSE: specifically, flow can be much better with EODFDB/ZBLL. There are two advantages I see:

(i) Very good prediction. During SB, it is very easy to track DFDB edges + D center, so there should be no pause between SB and EODFDB. During EODFDB, it is very easy to recognize CP (because corners are just being AUFed back and forth), and imo possible to predict the position of two edges; hence, there should be no pause between EODFDB and ZBLL. Currently, Kian believes the main bottleneck of a Roux solve is the often frustratingly long pause to recognize CMLL (the rest of his solves are pretty much pauseless). By performing this recognition during the execution of EODFDB, we can eliminate this pause, leading even more fluid solves.

(ii) Higher tps. In CMLL/LSE, 10 moves are drilled algorithmic face turns and 13 are MU spam; in EODFDB/ZBLL, 8 moves are MU spam and 15 are drilled algorithmic face turns. I think it is safe to say that face turns can achieve a higher max tps than MU spam (Lau's 0.6 Uperm suggests 11.6 stps, while... well, I believe there's a 20TPS T perm somewhere out there?), so even if EODFDB/ZBLL may achieve the same movecount as CMLL/LSE, it has the potential to be faster.

Objection 2) Well, this is an interesting one. ZBLL was invented for ZB, and then used in ZZ, and now we are trying to say it can be used in this Roux-hybrid thing as well. So now let's compare ZZ-a and EODFDB/ZBLL: both finish with ZBLL, so we'll just compare EOF2L movecounts:

ZZ-a: 6 EOLine + 25 F2L (stepwise optimal, taken from ss forums post) = 31 STM EOF2L
EODFDB/ZBLL
: 7 FB + 15 SB + 8 EODFDB = 30 STM EOF2L
Importantly, I have way more experience with Roux than I do with ZZ, so for the sake of argument I took stepwise optimal F2L movecount for ZZ and the average movecounts I get for my own F2B in Roux (which are, I'm sure, able to be improved). Note that even with these conservative figures the Roux approach to building EOF2L appears to be as (if not more) efficient. There is now a question of ergonomics, and on this front I think the the two approaches can be equally fast. Some may prefer ZZ F2L (slightly awkward EOLine but rotationless, easy lookahead and RUL) while others may prefer Roux F2B (slightly awkward FB but rotationless and RrUM). I'm not sure an argument can be made for one being strictly better than the other, but if someone equally competent/experienced with both methods says otherwise then I'd gladly stand corrected.

So in sum I think that this method is nothing amazingly innovative or revolutionary, but certainly deserves more than to be simply dismissed as another reinvention of a shitty wheel. The ideas are simple (the only differences between this and commonly proposed DFDB/OLL/PLL are really just EO+DFDB and ZBLL in place of OLL/PLL), but they have merit.

Actually, I think this is better depending on your blockbuilding skill and LL tps. I mean, my OLLCP and E Pll algs are better than my CMLL ones.
Yes. I have the same opinion. Please check the above write up

#### bobthegiraffemonkey

##### Member
The thing that people think of is just inserting the DF and DB edges and using CFOP Last Layer techniques for solving the rest (I also did the same thing in my solving video). Every person who has used Roux while being a CFOP user, has done the same thing.
The approach we propose is EO+DFDB + ZBLL for LL. The aim was to provide an alternative way to finish L10P that allows for higher max TPS and lower movecount in exchange for a very large alg count. Yes, sure, it might sound very similar to something people propose on a weekly basis, but in this case, the details matter and are what make this something other than a regular roux-cfop hybrid post.

So in sum I think that this method is nothing amazingly innovative or revolutionary, but certainly deserves more than to be simply dismissed as another reinvention of a shitty wheel. The ideas are simple (the only differences between this and commonly proposed DFDB/OLL/PLL are really just EO+DFDB and ZBLL in place of OLL/PLL), but they have merit.
Funny, you seem to be criticising me here for dismissing EO+DFDB -> ZBLL as bad, but you hadn't mentioned that variation before in this thread. If that's what you want people to think about and discuss, try actually mentioning it in the OP, otherwise people will obviously get the wrong idea.

#### CriticalCubing

##### Member
Funny, you seem to be criticising me here for dismissing EO+DFDB -> ZBLL as bad, but you hadn't mentioned that variation before in this thread. If that's what you want people to think about and discuss, try actually mentioning it in the OP, otherwise people will obviously get the wrong idea.
Yes certainly. I'm sorry I missed it before xD I'll edit the OP and add that part.
Thank you
PS: Didn't criticize.

Last edited:

#### Gomorrite

##### Member
If you think it has a future, please give it a catchy name before people start adopting it.

#### CriticalCubing

##### Member
If you think it has a future, please give it a catchy name before people start adopting it.
Haha what name would you suggest?

#### SolemnAttic

##### Member
I would suggest "Lacking Lovers of Boston". Catchy and better than TCMLL(i think).

PS :- Just broke my pure roux pb with this. Gotta love ZBLL

Last edited:

#### efattah

##### Member
I think this method has amazing potential, primarily by eliminating the difficult recognition time of ZBLL. However I agree that it needs a better name. Personally I think this method is only viable if you know full ZBLL so this should figure into the name. Something like ZBRoux = Zebra.

#### Neuro

##### Member
What I proposed in the New Method Thread is a variant of LLOB that I thinkk has serious potential. It goes something like this:

1: FB (standard)
2: F2L-C
2a: SB-1 corner (RrUM)
2b: DF+DB (MU)
3: TOLS (part of the Ribbon method, orients last 9 pieces in a manner similar to TSLE)
4: TTLL (straightforward)

I have gotten numerous sub-40 move example solves using this. FB can't really be improved so let's continue. F2L-C, by being done in 2 steps, allows you to easily look into what TOLS you will have as is preserves corners and EO is easy to track while doing MU. Not to mention it still has the amazing ergonomics/efficiency of Roux SB combined with minimal MU makes this step pretty fast. As stated earlier, TOLS is not only easy to recognize on it's own, but can be entirely pause-less because of how the second step works. TTLL is easy to recognize and can be quite fast, we just need to optimize the algs.

The only real negative is that you *may* have to do 1 rotation (y) but let's be honest: that's not going to affect your solving time much at all. This method, including algs for OLL and PLL, has a total of 266 algs. This is in comparison to 500+ in ZBRoux. The methods in my experience are not that far away from each other in terms of efficiency.

*50/50 chance

I'd like to call it Roux-GT, after myself (Max Garza) who had the idea for this variant, and Justin Taylor who created Ribbon (TOLS+TTLL) but I am certainly up to suggestions.

ZBRoux does still have great potential however, and I absolutely love the idea of both of these methods! I will do my best to run some tests over the week and see how they compare

#### Micah Walker

##### Member
I believe cyoubx once called this a stupid version of roux...
(
)

#### Neuro

##### Member
Although I like Cyoubx and think he's done great things for the community, I believe he is sadly mistaken. I can see why one might believe that, but let's view it like this

Face turns are generally much faster than M slices, and at least in my method they are minimized (0.6 MU U perm by Alex Lau=~11 TPS meanwhile near 20 TPS on J/T perms)

CMLL recog pause is eliminated, having sets that are easy to predict and are nearly seamless from the rest of the solve.

In comparison to CFOP, F2L is solved MUCH more efficiently with no rotations and it is believed that F2B can be solved faster than F2L due to ergonomics and efficiency increase

For some people, standard Roux might be better (I'm debating doing OLL/PLL vs CMLL/LSE if full blocks are done in my variant) and others will find this better. I think that the benefits of this are great, but everyone has different tastes and may find other things better (hence why I think everyone should at minimum try both CFOP and Roux) so take my word as it is and form your own opinion

#### I_<3_SCS

##### Member
y not just use petrus?

#### Teoidus

##### Member
Although I like Cyoubx and think he's done great things for the community, I believe he is sadly mistaken. I can see why one might believe that, but let's view it like this

Face turns are generally much faster than M slices, and at least in my method they are minimized (0.6 MU U perm by Alex Lau=~11 TPS meanwhile near 20 TPS on J/T perms)

CMLL recog pause is eliminated, having sets that are easy to predict and are nearly seamless from the rest of the solve.

In comparison to CFOP, F2L is solved MUCH more efficiently with no rotations and it is believed that F2B can be solved faster than F2L due to ergonomics and efficiency increase

For some people, standard Roux might be better (I'm debating doing OLL/PLL vs CMLL/LSE if full blocks are done in my variant) and others will find this better. I think that the benefits of this are great, but everyone has different tastes and may find other things better (hence why I think everyone should at minimum try both CFOP and Roux) so take my word as it is and form your own opinion
cyoubx is criticizing a different method in that video (cross, then using r U r' U' M and variants to insert every pair rotationlessly) that I'd agree is quite bad. It's completely different from LLOB