cubing / twisty.js Goto Github PK

I think the following is nice:

var cube = new twisty.cube(...)

This is similar to Three.js.

Basically, an RFC process for (twisty)puzzles/speedcubing. I've had plans for this one since a really long while, but the Regs got in the way.

• Notation:
  • SiGN
  • Various puzzles
  • General "SiGN" template for new puzzles.
    • Specifies grammar for repetitions, inverses, grouping, commutators, conjugates.
      • Context-free (no macros!).
      • As self-delimiting as possible. This helps make white space as irrelevant as possible, and parsing more reliable for humans/computers. (But I expect we will always have to handle something like R 2L !== R2 L, since a lot of thinking has never led to something else that is flexible and concise in most situations.).
  • General JSON/recursive-object-oriented representation format of algs.
    • For example, python lists and dicts can handle the internal JSON representation from twisty.js with a trivial translation. Java/C++ could handle these with only a few definitions, but that requires handling weird things like (implicit and explicit) slice specifications for big puzzles.
• Puzzle serialization formats.
  • See #48.

Then have all devs (e.g. Lucas and Jeremy for now) review each other's code changes before merging pull requests.

I had planned to do this once I got the MVC for this in order (e.g. making it easy to use twisty.js in many different ways), but Jeremy leaped in too early. :-P

Which will be moved to alg.cubing.net

This just requires a negative direction flag, and handling inverse move transitions.

Also see cubing/alg.cubing.net#33

Making the window too narrow makes the cube go off screen left and right.

i.e. extend alg parsing to preserve comments.
Serialization should return the original text, except for normalized whitespace (outside of comments).

i.e. don't add spaces

If this uses an optional argument (rather than an option object), then we need to be careful about the interaction between this and #74 lest we create another JSON.stringify second arg.

Like AnimCube. This takes about 10 lines, and looks pretty nice. I didn't commit it because I need to handle single vs. double-sided textures better for that.

Cubes could have e.g. 3D and plan view (for #12). Ideally, all views should be able to animate.

Along with issue #10.

It's not really needed. In alg.cubing.net, Angular can handle most of the interactivity itself.

• parameters per puzzle
• key handlers
  • variable states? (level of slice for big cubes [visual indicator of those?])
• initmove/revmove stuff?
• visual options (stickers + cubies, stickers only, etc.)
• Random move / alg generation?

Each move is animated a single frame, and then stops. Firefox 8 on Mac.

• Calculate the order of an alg.
• Handle permutation representations of puzzles
  • Import/export from common formats
    • Arbitrary permutation mapping
    • GAP files at http://cubezzz.dyndns.org/drupal/
    • Singmaster positional notation (used by ACube)
• Fast calculation of a position.
  • Even inside many nested commutators/conjugates/repetitions.

Jison gives line+column, but we usually have to convert that into string index to make it useful.

Many alg operations can be supported on "unflattened" algs (i.e. commutators and conjugates unexpanded).

• Move count.
• Total animation time (given time for each move token).
• Puzzle state at a given position.
  • See #46.
  • There's no reason we shouldn't be able to support algs with arbitrarily many moves (millions? trillions?), as long as the nested representation is concise.

It should be simple to write something to do this in general. It just requires something that can handle JSON traversal given handlers for the following nodes:

• basic moves
• groupings
• commutators
• conjugates

If I'm in charge of rendering cubes, they're going to look pretty, Gauss fix it with a needle.

Eventually, everything should be turned into a single include file with simple usage.

Also see #27 .

Perhaps this speeds up rendering if frames are slow.
https://github.com/mrdoob/three.js#usage

I started this a while ago (still uncommitted), but this needs to be done carefully some time. It needs to incorporate things like commutator and comment parsing, and the ability to make text displays of algs correspond to animations.

e.g.

var a = alg.cube.fromString("R U R'")
var b = a.invert()

Allows simplifying [R, U] [R, U] to [R, U]2

Question: is (R U) R == R (U R) ?
(While simplifying, I think it should. But structurally, it's unclear.)

Having an open-source license on this would be great, since I'd really like to make use of it.

This is more valuable for touch input, since it can help us iterate on the touch -> move mappings.

• Incorrect characters (orior maybe-instead of'`)
• Just ignore any unfixable line? (i.e. assume it's a comment?)
• Alternate capitalization/move names (e.g. Y instead of y).
• WCA bracketed rotations

I actually think most of these are not good ideas, but it's a thought.

Probably requires #44.

For WCA scramblers, etc.

Right now, the animation is frame-based, which slows down when the browser does. It seems reasonable to compensate for the framerate by using interpolated time to update the progress of an animation.

Right now, they can slow down the framerate a lot on e.g. a mobile device.

• Animate based on time, not steps
• Update speed before move (reproduce: queue lots of moves; after they're done, the next move is instant, the one after that normal).
  • Rethink speed control in general.
• Negative layer indices
• Proper drag/touch support (#9)

Right now, it's "move".

i.e. the internal plastic. Works, but still not perfect.

i.e. restore the behaviour of the moveQueue. Some devices might depend on this for reasonable performance.

Since switching to r60 of Three.js, there have been some serious drawing artifacts.

Animation should be independent of frame rendering time.

The cube remains unresponsive after the first turn. "Solution": Reloading the page.

R.2L is parsed as R .2 L. It's probably better to forbid repetitions/inverses on raw pauses. Repeating dots are a beautiful alternative: R...L

• Current state (array of (piece + matrix))
• tempo function for each possible ongoing move
• Queueing moves
• Move pause
• Speed up if queue grows (inc. current move straight into next)
• Simultaneous moves
• Metric support?
• Algorithm objects?

The design should definitely be aiming to support this.

(Highlight text on a page, click bookmarklet to view animation. This can then easily be adapted for speedsolving.com)

And/or use prototypes on algs?