# Last Layer Optimized Blockbuilding [LLOB Method]



## CriticalCubing (Jun 8, 2017)

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



Spoiler: More Info



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.


----------



## Sajwo (Jun 8, 2017)

What TPS is achievable with F2L?


----------



## CriticalCubing (Jun 8, 2017)

Sajwo said:


> 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.


----------



## Hazel (Jun 10, 2017)

I already use a very similar method for Roux (I'm mainly a CFOP user though), where it's the same as regular Roux but you solve L6E by first inserting DB edge while correcting centers, then insert DF edge while orienting LL edges (14 super easy algs), then EPLL.
Here's my alg list I came up with, LE-OLL (Last Edge - OLL): https://docs.google.com/spreadsheets/d/1cCDVpuPzUXq_c2lItT3dBg0r2HscVXtT8ptqkD19c6I/edit?usp=sharing


----------



## bobthegiraffemonkey (Jun 10, 2017)

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 (Jun 10, 2017)

bobthegiraffemonkey said:


> 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 (Jun 10, 2017)

Ghost Cuber said:


> Are you talking to CriticalCubing or Aerma?


CriticalCubing, Aerma is just doing a different LSE so it's still Roux I guess.


----------



## SolemnAttic (Jun 12, 2017)

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 (Jun 30, 2017)

bobthegiraffemonkey said:


> 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.



SolemnAttic said:


> 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 (Jun 30, 2017)

CriticalCubing said:


> 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 (Jul 1, 2017)

bobthegiraffemonkey said:


> 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.


----------



## Gomorrite (Jul 1, 2017)

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


----------



## CriticalCubing (Jul 1, 2017)

Gomorrite said:


> 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 (Jul 2, 2017)

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


----------



## efattah (Jul 18, 2017)

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 (Jul 19, 2017)

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 *G*arza) who had the idea for this variant, and Justin *T*aylor 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 (Jul 19, 2017)

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



)


----------



## Neuro (Jul 19, 2017)

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 (Jul 19, 2017)

y not just use petrus?


----------



## Teoidus (Jul 19, 2017)

Neuro said:


> 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)
> 
> ...



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


----------



## efattah (Jul 19, 2017)

As with most methods the problem is the number of years needed to master it. I'd love to see the true potential of this method in a few months-- which brings up the question, how many (if any?) people know full ZBLL (and know it well) and also can do F2B at sub-10 Roux speed? I hope there is at least one person, but I suspect zero...

EDIT: Perhaps a temporary measure of the method could be to execute ZBRoux Ao100 by someone who only knows partial ZBLL. If you end up with a ZBLL case you don't know, delete that solve from the average. Not great, but still gives an idea.


----------



## Tao Yu (Jul 19, 2017)

efattah said:


> which brings up the question, how many (if any?) people know full ZBLL (and know it well) and also can do F2B at sub-10 Roux speed?



Me, in two or three months. I'm sub 10 with roux, and know about 190 ZBLL algorithms, and am learning it at a rate of 12 algorithms per two/three days.

To be honest, I would prepare to be disappointed. It will be a long time before I get the recognition up to speed, and also, sub 10 level blocks probably won't get me to world class level. Even if I get sub 9 or 8 averages, it's not that impressive since those kind of times can be achieved using CFOP + 4LLL at this stage.


----------



## efattah (Jul 19, 2017)

Well theoretically we really only need to time the last 10 pieces. In other words, start with a cube that has the first two blocks already built. Now finish the solve with CMLL+LSE, time 100 solves, then do another hundred finishing with DFDBEO+ZBLL. That already gives a good idea; the real question is if DFDBEO+ZBLL is faster than CMLL+advanced LSE, then this method would beat regular Roux, which Kian already proved is at least equal to the best of CFOP. Do keep in mind that for a fair comparison we need to compare vs. advanced Roux, i.e. multiple CMLL's to improve edge orientation then full EOLR. Still, I believe that DFDBEO+ZBLL would be sufficiently faster to be very obvious.

Assuming the best Roux solvers can identify the CMLL case (including edge orientation) in 0.5 s (this is the slowest part of Roux), then execute the algorithm in 0.9 s average, and finish advanced LSE in 1.5 seconds average, then the total time is 2.9 seconds. So the average time to beat for DFDBEO+ZBLL is less than 2.9 seconds. Assuming 0.9 seconds for DFDBEO and 1.25 seconds for 15 move ZBLL at 12 tps, theoretically DFDBEO+ZBLL should take 2.15 seconds, assuming zero recognition time for ZBLL hoping that recognition occurs during M/U spam. Even adding another 0.25 for recognition still puts it at 2.4.

I will ask Kian to time CMLL+LSE for us.


----------



## shadowslice e (Jul 19, 2017)

efattah said:


> Well theoretically we really only need to time the last 10 pieces. In other words, start with a cube that has the first two blocks already built. Now finish the solve with CMLL+LSE, time 100 solves, then do another hundred finishing with DFDBEO+ZBLL. That already gives a good idea; the real question is if DFDBEO+ZBLL is faster than CMLL+advanced LSE, then this method would beat regular Roux, which Kian already proved is at least equal to the best of CFOP. Do keep in mind that for a fair comparison we need to compare vs. advanced Roux, i.e. multiple CMLL's to improve edge orientation then full EOLR. Still, I believe that DFDBEO+ZBLL would be sufficiently faster to be very obvious.
> 
> Assuming the best Roux solvers can identify the CMLL case (including edge orientation) in 0.5 s (this is the slowest part of Roux), then execute the algorithm in 0.9 s average, and finish advanced LSE in 1.5 seconds average, then the total time is 2.9 seconds. So the average time to beat for DFDBEO+ZBLL is less than 2.9 seconds. Assuming 0.9 seconds for DFDBEO and 1.25 seconds for 15 move ZBLL at 12 tps, theoretically DFDBEO+ZBLL should take 2.15 seconds, assuming zero recognition time for ZBLL hoping that recognition occurs during M/U spam. Even adding another 0.25 for recognition still puts it at 2.4.
> 
> I will ask Kian to time CMLL+LSE for us.


Some issues: ZBLL would take at least 1.5 times as long as CMLL simply due to movecount and given that most CMLLs are more fingertricky than most ZBLL the difference would be even greater.

In addition, you would undoubtedly have a pause when doing DFDBEO because you would have issues recognising what cases you have during second block- sone thing which is usually done in CMLL for Roux as it is just an alg which has the same effect so recognition becomes a lot easier.

Lastly, it is much easier to switch into MU solving than it is out of it.

Source: messing around with alg sets and M-CELL


----------



## efattah (Jul 19, 2017)

shadowslice e said:


> Some issues: ZBLL would take at least 1.5 times as long as CMLL simply due to movecount and given that most CMLLs are more fingertricky than most ZBLL the difference would be even greater.
> 
> In addition, you would undoubtedly have a pause when doing DFDBEO because you would have issues recognising what cases you have during second block- sone thing which is usually done in CMLL for Roux as it is just an alg which has the same effect so recognition becomes a lot easier.
> 
> ...



Good points. So increasing ZBLL to 1.35 seconds and adding 0.3 second DFDBEO recognition gives 0.3+0.9+1.35 = 2.55. I suppose there is also the issue of AUF time. I'm not sure if top ZBLL solvers predict AUF or just look ahead.

EDIT: How many DFDBEO cases are there? I couldn't find it in the LLOB document. I assume around 60? So ZBRoux would need 60+494 = 554, vs. Roux would need 84 CMLL's plus 60 EOLR or 144.


----------



## Teoidus (Jul 19, 2017)

For every EOLR case, there are two DFDBEO cases, since centers matter


----------



## CriticalCubing (Jul 20, 2017)

I will be learning ZBLL's in the future and seeing how this method fares(currently busy with work, so cannot accommodate time for it). Currently with what I have done, FB+SB+EODFDB can be done pauselessly. The undoubt-able pause during EODFDB isn't that big of a issue if you know how your SB inserts are affecting the other pieces. Its probably easy for me because I was a CFOP user, but I don't have any problems with the first 3 steps of this method.
Now comes the inevitable pause: ZBLL Recognition. However, using the concept of LSE and solving EO+DFDB like you solve EO+ULUR, you can easily predict where your edges are going to end up, thus predicting ZBLL case isn't going to be difficult as you only need prediction of 2 edges which isn't a problem. This style of EO+DFDB solving may be a bit inefficient, but you barter some recognition time which may/may not make it worth it the extra moves. Switching out of MU is again not a problem as it just needs some getting use to. Doing LSE scramble, then solving LSE and using RU Ua perm+Ub perm to get the cube back solved, coming out of MU is not difficult to do. 
Only thing remaining is learning ZBLL's and testing this out. (which I shall do as soon as I start learning ZBLL's in due time)


----------



## Arc (Jul 22, 2017)

About the MU to RUF/normal transition, it is a lot easier if you do righty Ms. Just throwing that out there.


----------



## Neuro (Jul 22, 2017)

I do M slices with my left and have no trouble switching to face turns


----------



## efattah (Jul 27, 2017)

Kian says it takes him 2.9 to 3.5 seconds to do CMLL+LSE. So DFDBEO+ZBLL needs to 'beat' 2.9 - 3.5 seconds to be an improvement over advanced Roux. I had estimated DFDFEO+ZBLL at 2.55 seconds, so even if that is aggressive, there is great potential.


----------



## Neuro (Jul 31, 2017)

Although it is't quite enough to be considered accurate, I have done 20 example solves using the OLL/PLL and ZBLL variants of this method as well as completed there Roux counterparts. The solves are from FB, so no solve should have an advantage over another (and all movecounts are NOT including FB) All algs used are speed-optimized, but all of the non-algorithmic steps were done using HARCS so no human error. As expected, ZBLL had the lowest average and OLL/PLL had the highest.

ZBLL=31.6 STM from FB
Roux=34 STM from FB
OLL/PLL=39.05 from FB

I have had yet to test the Ribbon Alpha and CLS/PLL variants of the method. ZBLL from what I can tell has a low variance, and while OLL/PLL's is higher, both Roux and OLL/PLL have fairly large variances. It should be noted that on the Roux solves LSE was done by hand using vanilla Roux and only minor influence on efficiency, so the average given would be lower if EOLR and other tricks were used. My current hypothesis is that ZBLL will have the lowest movecount, and Roux/Ribbon Alpha will be second. Here's a link to the sheet I am using to track solves/calculate stats. If anyone would like to help me complete the test, please PM me your email and I'll add you


----------



## efattah (Jul 31, 2017)

Neuro said:


> ZBLL=31.6 STM from FB
> Roux=34 STM from FB
> OLL/PLL=39.05 from FB



Although these numbers are extremely interesting, since the real benefit of ZBRoux is the elimination of the CMLL recognition time, I don't think move count is the main factor in determining which variant is the best one. Sadly I don't think there is any way to really determine it without actually mastering the method...


----------



## Neuro (Jul 31, 2017)

efattah said:


> Although these numbers are extremely interesting, since the real benefit of ZBRoux is the elimination of the CMLL recognition time, I don't think move count is the main factor in determining which variant is the best one. Sadly I don't think there is any way to really determine it without actually mastering the method...


I agree with this, but I still feel like getting a true avg movecount for each of the variants is useful and will help determine the "best" variant.

Once I have completed 50 solves, I am going to add a stats page and provide a conclusion based not only on the stats, but also looking at things like ergonomics, recog time, and alg count to determine the pros/ cons of each and the overall best variant. May take a while to get them all completed, but I'll come back with my findings soon enough.


----------



## CriticalCubing (Aug 1, 2017)

efattah said:


> ZBRoux


*TRIGGERED!!! 
*


Neuro said:


> I agree with this, but I still feel like getting a true avg movecount for each of the variants is useful and will help determine the "best" variant.
> 
> Once I have completed 50 solves, I am going to add a stats page and provide a conclusion based not only on the stats, but also looking at things like ergonomics, recog time, and alg count to determine the pros/ cons of each and the overall best variant. May take a while to get them all completed, but I'll come back with my findings soon enough.



Thank you for doing this. I'm also interested in these stats


----------



## Teoidus (Aug 1, 2017)

CriticalCubing said:


> *TRIGGERED!!! *



It's a better name than LLOB, though.


----------



## mDiPalma (Aug 1, 2017)

'*optimized*' isn't exactly accurate


----------



## Neuro (Aug 3, 2017)

38 move solve using ZBLL from the example solve thread. May not seem super impressive, but sub-40 is actually pretty common with LLOB using ZBLL (may I suggest ZR Method (Zbignew-Roux) or vice-versa?) On one scramble, I got a 28 but unfortunately I no longer have the solution. It ended in lefty Niklas and F2B was done simultaneously with a 3 move EODFDB.

F2 R2 U L2 D F2 R2 B2 U' B2 R B' D2 R' B D' L F2 U L B'

y2 x U M U' R L U' L B2 x2//FB (8/8)
R U R U2 F R F' R2 U R' U' R//SB (12/20)
U M2 U M U M U2 M' U' M//EODFDB (10/30)
F R' F' r U R U' r'//ZBLL (8/38)

So we have the possibility of reaching intermediate FMC movecounts in speedsolves fairly consistently


----------



## Spencer131 (Aug 6, 2017)

I don't think these advantages are significant enough for anyone to learn all of the zbll algorithms


----------



## efattah (Aug 6, 2017)

Spencer131 said:


> I don't think these advantages are significant enough for anyone to learn all of the zbll algorithms



Well if you consider that the 3x3 WR average had ZBLL in it, then one could argue that ZBRoux could be a method-neutral alternate solve to CFOP-ZBLL. If you see an easy XCross, go CFOP/ZBLL, otherwise use ZBRoux if you see an easy first block.


----------



## Teoidus (Aug 6, 2017)

just learn 1 zbll and go for wr single with every single solve, dnf otherwise


----------



## Alex B71 (Sep 29, 2017)

I felt the need to add an opinion to this.

I first heard of this approach from a video by Tao Yu and since then i have been messing around with this method on and off, my first approach was to mix it with TSLE+TTLL but i would not recommend that as it is extremely inefficient.
I then took the proposed approach of EO+DFDB and then ZBLL and i can say that i love it. My previous main methods were CFOP and ZZ (Both sub-12 but CFOP was faster on average with slightly under half of ZBLL known and committed to muscle memory) so blockbuilding in this manner was difficult and EO+DFDB was confusing. I generated MU based EO+DFDB algs that were as move efficient as they could be whilst still maintaining ergonomics, and i'm very glad i took an algorithmic approach.

ZBLL recognition is pretty much dismissed with this approach as you instantly know your corner recognition after F2B and you know the edge placement from as early as just ending EO+DFDB. The EO+DFDB algs are not even "algs" and seem as easy as commutators to learn (seasoned Roux uses will find this step extremely simple). Most of the cases are reducible into another case with one move and very quickly become second nature due to the intuitiveness of the step.

To summarize, This method harnesses the low move count and awesome flexibility of F2B, has an extremely easy to learn and fast to execute EO+DFDB stage and cuts the recognition time of ZBLL drastically. It's a great hybrid of two well proven methods and has potential to be very fast. The only problems i have with this method are the changing of hand placements between steps and that fact you will need full ZBLL to really harness this method.

It's worth trying.


----------



## @Ratas (Oct 3, 2017)

Alex B71 said:


> I felt the need to add an opinion to this.
> 
> I first heard of this approach from a video by Tao Yu and since then i have been messing around with this method on and off, my first approach was to mix it with TSLE+TTLL but i would not recommend that as it is extremely inefficient.
> I then took the proposed approach of EO+DFDB and then ZBLL and i can say that i love it. My previous main methods were CFOP and ZZ (Both sub-12 but CFOP was faster on average with slightly under half of ZBLL known and committed to muscle memory) so blockbuilding in this manner was difficult and EO+DFDB was confusing. I generated MU based EO+DFDB algs that were as move efficient as they could be whilst still maintaining ergonomics, and i'm very glad i took an algorithmic approach.
> ...


Can you share your EO-DFDB algs?


----------



## Twocubersyt (May 13, 2019)

It's basically the EOLR algs but track the df db during second block then do some nice zblls


----------



## jdh3000 (Dec 17, 2020)

I'm somewhat a late comer to considering this:

I just started looking at Roux because I really don't care for cross in cfop(yes because I'm not the best at it)

I have so much time and effort in cfop that I doubt I want to completely switch, I was just wondering if there's any merit to learning partial Roux and build the f2l from that, then finishing up with my cfop oll/pll.

I never really messed with Roux much until last night, but I think with some practice I could accomplish an f2l quicker in some cases than cross+f2l

I understand that Roux is more complex than just solving 2 blocks and m slicing to make an f2l, and I know what I'm talking about is a hybrid probably viewed by many as an abomination.

I watched cyoubx's video on rotationless, and he briefly touches on this, saying it's just a stupid hybrid or something to that effect, but I also recall Feliks saying in a video that he uses a combination of methods depending on the situation.

I've also read some of the comments in this thread. just wondering if you all have any other thoughts on this.


----------



## Silky (Dec 17, 2020)

jdh3000 said:


> I'm somewhat a late comer to considering this:
> 
> I just started looking at Roux because I really don't care for cross in cfop(yes because I'm not the best at it)
> 
> ...


It would just be better to learn LLOB with OCLL/PLL or COLL/EPLL. The main advantage is that you can incorporate ZBLL but if just don't do EOFDBD you can't really make use of that.


----------



## efattah (Dec 17, 2020)

As most people refer to LLOB as ZBRoux, I have been a strong believer in this method, but only if it used with full ZBLL. Thus far to my knowledge no expert Roux solver knows full ZBLL, so we don't have real data on the method potential. Many Roux solvers have argued *against* ZBRoux, but I have rejected their arguments as unfounded.


----------



## kubnintadni (Dec 19, 2020)

efattah said:


> As most people refer to LLOB as ZBRoux, I have been a strong believer in this method, but only if it used with full ZBLL. Thus far to my knowledge no expert Roux solver knows full ZBLL, so we don't have real data on the method potential. Many Roux solvers have argued *against* ZBRoux, but I have rejected their arguments as unfounded.



How would you compare LLOB to LEOR? They're very similar: they just swap the order of the middle two steps.


----------



## Jam88 (Dec 19, 2020)

jdh3000 said:


> ...but I also recall *Felix* saying in a video...


Felix?????????????? Feliks


----------



## jdh3000 (Dec 20, 2020)

Jam88 said:


> Felix?????????????? Feliks


Yes, Feliks, sorry... I just wasn't paying attention to what I was writing..


----------



## Jam88 (Dec 20, 2020)

jdh3000 said:


> Yes, Feliks, sorry... I just wasn't paying attention to what I was writing..


its fine-just a bit insulting to the GOAT


----------



## Silky (Dec 20, 2020)

kubnintadni said:


> How would you compare LLOB to LEOR? They're very similar: they just swap the order of the middle two steps.


I think this is actually a very interesting comparison similar to that of ZZ and Petrus.
For LEOR the main advantages are that there is less emphasis on slice moves ( higher TPS ), more can be planned in inspection ( this comes at the cost of having to solve EO in the middle of the solve if you can't plan FB + EO in inspection ), and flexibility of the first step. This however comes at the cost of efficiency. On the other hand, LLOB is more efficient and has much easier ZBLL recognition ( since you can identify corners during EODFDB and prediction of edge cycles is possible during the placement of DFDB ). I think that LLOB is a more Rouxesque approach to the method while LEOR is a more ZZesque aproach. Seems that LEOR would have a better used in OH while LLOB would be better used in 2H.


----------

