Orient First method

[BadgerSex]

I tried to do something similar about half a year ago, but I dropped the idea. Great job developing this method! I think I am going to try practicing it.

Right now I'm going back and forth between this and the corners-first methods (Waterman and the Ortega method on rubikscube.info).

It's great how few algorithms this method has, though.

 

[somerandomkidmike]

Oh, you're using CF? Waterman is one of my main methods. So far I average around 25 with it, and I don't know the whole thing. Something I tried for this method is to.... get 3 edges on the middle layer properly oriented, then get 3 bottom corners, then get the rest of the corners and edges oriented. Doing this, I got a 33 move solve (M is 1 turn). Anyway, I really like this method, and I'm interested to see how fast it can get. I think it has potential.

 

[Athefre]

Reminds me of Ryan Heise's Human Thistlethwaite Algorithm. It also reminds me of something I worked on sometime early last year (also like HTA since the first 3 steps are the same), gave up, then looked at it again late last year. It went something like this:

Step 1: Orient all edges.
Step 2: Move all L/R type edges to L/R, a combination of this step and the first can be done by wisely choosing where to place the edges on F (or B if you prefer) before orienting.
Step 3: Orient all corners relative to the left and right side of the cube, a very easy step.
Step 4: Create the two "Roux" blocks (F and B are constrained to only double turns) and permute M-layer as you finish the last pair (if you want, you can permute later).
Step 5: Finish UFL, UL, UBL, UBR, UR, UFR with a sequence (there probably aren't many cases).

I don't like having edge orienting as a Step 1. I used to think it was promising but I got to where it just doesn't feel right, it's not a very productive first step and it doesn't save as many moves as a lot of people would think because you have to remember that orienting those edges also takes some moves. I don't like this method, I probably will never use it or any of the variations I've seen.

 

[MistArts]

I have a method like this but I put middle layer edges lin first and then orient. I'll look at this after learning OFOTA, MALEP(MistArts' last edge pyraminx), and maybe MGLS.

 

[elrog]

I came up with a similar method on my own. I used the first 3 steps in the HTA method and then solved the f2l and did pll. After I found this method, my hopes of finding a new method were decreased as this was my 3rd attempt at a new method that I find has already been done. Anyway, with hta, you can orient the edges in 4.6 moves, and then place your middle edges in the middle layer in 4 giving you about 8.6 moves. Then you apply the correct algorithm to solve the corner orientation. According to Ryan Heise, thee algs have an avg of 8.5 moves. This would bring you to about 17 moves to orient everything. The plroblem with this is that there are 60 algs. If you look on Ryan Heise`s site, there is a way to solve 3 of the corners orientation, and then solve the rest with 8 algorithms. He doesnt say the average move count. During the Orient first method, I find that my recognition time on orientating edges is not that great. With hta`s first step, I don`t have this problem. With the orient first method, you get a fair start because you can identify the algorithm in your inspection time. With hta, it is possible to get a good start by planning how to orient all of the edges with inspection and you can track the middle layer edges so you can place them without having to find them afterwards. It is also easier to do this with the middle edges than solving the top/bottom cross by looking at the top/bottom edges because there are only 4 of them. If you were to learn the 60 algorithms to orient the corners, I can see this method being comparable with fridrich because of fairly low recognition time and low move count.

 

[TheNextFeliks]

Love this idea. Just don't know how to solve after orientation.

 

[elrog]

Solving after orientation is intuitive like block building. For the last step you only need to know pll. There are 21 pll algs and there on the wiki. I Solve the f2l by matching a corner up with one of the edges of the top/bottom layers. You can then put the other top/bottom edge that matches by moving this edge to the appropriate side, then moving the block you have to match up with it. You do the same thing till you get a 1x2x3 block on the bottom/top layer. If you position the middle layer correctly while making your block, you can match the middle up while doing this. It is pretty simple to do this because your only using R2, F2, L2, B2, U, and D moves. For the last 3 peices of the bottom/top, get the edge in the opposite side and match it up with corners by putting them on the right side and back into the opposite side beside the edge. You then get your last 2 middle edges aligned so when you turn the last 3 bottom/top edge to the side they go on, the middle corrects itself also. With practice, this can be done in less than 20 moves average.
EDIT: Thank you for pointing that out. I have now fixed the mistakes.

 

[aznanimedude]

umm, aren't there 21 PLL cases?

and it's simple because you use wide slice moves?
you just listed every face but with a lower case letter to indicate wide turns.

 

[AHornbaker]

Here's an idea that i've been toying around with for the last day or so (and to me it seems less complicated than this method)
I would appreciate any feedback and constructive criticism Not sure if this is original in any way, but this post spurred rekindled some old ideas.

1.) Orient two 1x2x3 blocks on L and R (ie. red and orange, regardless if orange is on red and vice versa)
2.) Use OLL-type algs to orient last four corners on U (using the traditional algs was fairly confusing)
3.) EO and "keyhole" edges (remaining red or orange; from corners-first method) using M and U moves
4.) F2L and E slice using U2, L and R moves
5.) PLL

Note: The only part I don't like is step 2, it's very inefficient in my view. Someone experienced with this method might do this with step 1.

Orienting both the corners and edges at the same time seems a lot easier for me to recognize and form into a coherent thought instead of micro-managing the corners and edges separately. I just look for the side with the most red and orange, blue and green, or white and yellow pieces, and from that point I can get the 1x2x3 blocks in less than 10 moves (usually 5-8). From here step 2 might be grouped with step 1 intuitively, or could be part of an alg set for step 3 EO(? cases) and CO(7 cases) (if the method ever gets developed). I can foresee this method being a 3 step method (1x2x3, remaining orientation, PBL) with a good move count, and a very useful application for OH. I like the way things can be easily grouped that allow for look-ahead, rather than Friedrich where OLL gives no hint for PLL and is strictly alg based.

Let me know what you guys think! I would love for this to be developed, either way i'm making this my secondary method.

Other related questions:
-I haven't dabbled in roux at all, are there some algs made up just for EO in step 3?
-Is there any method to PBL once past step 3? I haven't been able to do it, but with just U2 moves it doesn't seem like it would be impractical to learn. Someone should definitely work on that.

 

[TheNextFeliks]

Does anyone know like the fastest time with this method?

 

[elrog]

I find it interesting that you used L R and U2 moves rather than U, D, R2, and L2 moves. I've been working on a method that orients everything, then uses a single alg to create columns, then solve the top and bottom 4 edges. I have come up with a good way to orient everything for a speedcubing situation.

I get everything oriented by first orienting all the edges and placing 2 E edges in the E layer beside eachother. Then you get 2 correctly orientated corners on the bottom layer and do a D move to get them under your 2 E edges. Then you match up 1 more corner with an E edge, and insert it like an F2L pair. You then put the last E edge in the E layer at the same time as orienting 3 corners, and do some very simple algs to do the last 2 corners. I can usually get everything oriented in under 20 moves, and it is very quick for recognition.

After orienting everything, in your method, you'd solve 2 of the E edges into their correct positions with a miximum of 2 moves, and do a z or z' cube rotation. You'd then be ready to proceed solving the F2L with L, R, and U2 moves on the left/right side, whichever you prefer, and finish by doing z or z' and PLL.

I have a method for solving the F2L also, but I'm not sure how to explain it. You basically just match up a corner with an edge, and move it to the correct side creating a 1x2x2 block and then a 1x2x3 block. After this you would match up a 1x1x3 block on the opposite side and add it to your 2x2x3 to make that whole side complete. You should also make sure those top 2 middle edges are turned the right way so that thy will be solved after you switch the 1x3x3 to the correct side.

Sorry if it is hard to follow. I hope it helps though.

 

[BPM]

I have a beginner's method for step 3 of this method.

First, solve the E layer. This is intuitive.

Then, find two corners that share two colors. Ex. Orange/White/Blue and Orange/White/Green

Make sure they're on the U layer right next to each other, so that mismatched colors are pointing away from each other.

Afterwards, put it over its matching edges, move the orange side to the left, and preform U2 L2 U2 L2.

Do this twice.

Then, solve the white edges using M' U2 M. It brings an edge from UF to DF without changing any orientation of any piece.

Also, would this be possible as your method?

Orient all corners
Solve E layer, orient all edges
Sort, then permute all corners (U/D color)
Last 8 edges (not sure how many cases this has, but can be done in 2 E-PLLs with a parity fixer M' U2 M)

 

[TheNextFeliks]

How many algs would solving all corners at once take. Including separation.

 

[BPM]

If you sort U/D color, (white corners by white center, etc.) you can PBL corners with 6 Algs. Seperation, however, should be intuitive. You can seperate all the corners using U/D/L2/R2 moves, without misorienting any edges. I'm not sure if all the XLL ortega algs save EO, but I'll churn out some algs.

 

[elrog]

I've been coming up with a method that does PBL to solve the corners, but I solve the middle layer at the same time using 47 algorithms. I also orient edges before corners. As for the last 8 edges, doing EPPL cases to solve them would require seperating out the top and bottom edges and possibly a parity alg. I think if you were to seperate them and fix the parity, you might aswell do 2 EPLLs at once using 25 algs. This could use only 10 algorithms if you don't include mirrors.

 

[BPM]

Some algs:

UF-UR and DF-DB

R2 U R2 U' M2 U2 M2 U' R2 U' R2

UF-UB and DF-DB

M2 U2 M2 U2

UF-UR and DF-DR

R2 U' F2 R2 F2 U2 R2 F2 R2 U' R2

(All 3 cycles are between U/DF, U/DR, and U/DB)

Double CW 3-cycle

D2 F2 L2 U' M2 U R2 B2 U2 (x2)

Double CCW 3-cycle

U2 F2 R2 U M2 U' L2 B2 D2 (x2)

Double H-Perm

M2 U2 M2 U2 y M2 U2 M2 U2

It's all I got. All the 2x2 cycles are done and all the 3x3 cycles are done. The only problem with this would be AUF/ADF. Also, if you don't know the alg, you might have to do an x2 rotation to make some work.