Show HN: Walk around unusual geometries | Hacker News Reader

Show HN: Walk around unusual geometries

parametricity.com

149 pointsihm34 comments

Feature request: always show the line that you will walk when you keep going forward (e.g. in a light color).

Suggestion: allow me to move in discrete steps of a specified length, and rotate in discrete steps too. Then I can see what happens in different geometries when I go forward n, left 90 degrees, forward n, etc.

In fact, how about implementing a Logo turtle graphics system :)?

This is really cool. My suggestion is similar to (perhaps the same as) jameshart's. I want to be able to form a sequence of known steps in flat space (say, draw a square), then see what that same sequence of steps produces in other spaces. It may help build some sort of intuition for the different spaces.

Looks really cool! One question though, how did you implement the movement? When you press up and left at the same time in the flat you'd expect to trace the same circle over and over again, but instead it diverts in some apparently non-deterministic way.

Movement is implemented by using approximate numerical solutions to the geodesic equations (a system a differential equations whose solutions give geodesics in a Riemannian manifold). As such, there are some numerical inaccuracies due both to an imprecise solution to the equations and (I can only assume) due to accumulation errors from adding thousands of floating points together.

Looking at the source code (I think this is it: https://github.com/imeckler/diffgeo/blob/master/Main.elm#L32..., https://github.com/imeckler/diffgeo/blob/master/Native/ODE.j...) it looks like the Dormand-Prince method is being used.

In general, ODE solvers can't be expected to maintain invariants of the ODE system, such as periodicity. This is typically handled by choosing a solver that maintains such invariants by construction, e.g., symplectic methods for Hamiltonian systems conserve symplectic 2-form. Adding many floating-point numbers together causes serious problems only in relatively rare cases, unlikely to occur here (e.g., see Higham's accuracy and stability book).

If I were to guess, the issue is maybe here (https://github.com/imeckler/diffgeo/blob/master/Main.elm#L45...), where the direction change is applied when the key is pressed, which means that the direction change doesn't happen inside the ODE itself: in effect this might be solving "go straight-tiny turn-go straight-tiny turn...", which would not be periodic even with perfectly exact solutions. If this is the case, this is like applying a first-order splitting method in which turns are handled with the forward Euler method, which would be quite inaccurate.

An extra source of error would be a positive Lyapunov exponent of the geodesic flow. When it is positive, the errors in the geodesic ODE solutions accumulate, causing exponentially large (in time) changes, meaning that the accumulated errors are much more noticeable than in geometries with non-positive Lyapunov exponents of geodesics (e.g., flat geometry would have smaller errors).

That said, it's not clear that you should actually expect to get periodic case in every case like this. I just kind of assumed they would be periodic based on how close they got. Still, flat circles seem to deviate after about half a dozen orbits. (Edit: With a bit of further experimenting, it seems curves in the hyperbolic upper half-plane that constantly turn should be periodic, so there's probably a bug.)

Speaking of Higham, folks in this thread interested in ODE solvers or numerical methods in general should really check out Chebfun.

http://www.chebfun.org

http://www.chebfun.org/docs/guide/guide07.html http://www.chebfun.org/docs/guide/guide10.html

A friend of mind suggested the very good idea of solving the diffeq for the constantly turning curve and using this when the user is simultaneously turning and going forward instead of doing one or the other first.

Another thing you could do is add an analog input ('virtual joystick') in the corner. Basically, a little box which someone could touch/click inside of to start moving the arrow with a specific turning radius + velocity.

That should work.

Nice work. I'm curious if there are any similar projects which use Oculus/VR to put you in the midst of these strange worlds. I wonder if it could be used to improve your intuition about things like hyperbolic space.

Jeff Weeks has done some excellent stuff. His Curved Spaces[0], lets you fly around funny 3 manifolds.

[0]: http://www.geometrygames.org/CurvedSpaces/index.html

That would be a fascinating, probably nausea and vertigo inducing, minecraft mod. Plus or minus using VR with the minecraft mod.

It might help to mod minecraft because players have a general idea of "how things should be" so you'd have a common frame of reference. No need to explain how flat world looks.

It ain't VR, but check out HyperRogue: A roguelike game in hyperbolic space.

http://www.roguetemple.com/z/hyper/

Feature suggestion: use the arrow's frame of reference instead of a global one.

Wouldn't they all look the same from the arrow's frame of reference? They're all locally flat.

I guess the lines of curvature in e.g. the cylindrical geometry would look different.

The trail lines and any distant landmarks would move differently

This is awesome!

Reminds me of a game that was featured recently on HN: HyperRogue[0]. It's a simple roguelike on a hyperbolic plane.

[0] - http://www.roguetemple.com/z/hyper/

I tried this in Firefox (latest) and the scrollbars kept perpetually disappearing/reappearing, causing the entire page to just shake violently.

Hm. Do you have any other info about your setup? I can't reproduce the behavior.

I'm on Ubuntu 15.04 with Firefox 39.0+build5-0ubuntu0.15.04.1, and with my window maximized the <body> alternates between 1411x689px and 1404x689px (with the difference being related to the size of the scrollbars that keep (dis)appearing.

I can see the style attributes of some <div>s are being manually updated by JavaScript, probably reacting to a window resize event caused by the (dis)appearing scrollbars changing the viewport size (which probably triggers the contents to change, which triggers showing/hiding the scrollbars...).

>Use the up arrow key to go forward along the geodesic in the direction you're facing and the left and right arrow keys to change direction. > >Scroll to zoom, click and drag to pan.

How do you scroll to zoom? Down arrow and Page Up/Down do nothing, and there's no scroll bar.

Using a two finger scroll on my touchpad works fine. I'd try that or a scroll wheel on a mouse or similar.

Great work! Can you add the Klein model?

It's kind of interesting that moving while turning at a constant rate in the hyperbolic plane makes you gradually "drift". Is that actually true, or is it an artifact of the software?

I think it’s just an artifact of the way the ODE gets discretized. You could probably figure out more precisely by reading the code, though it seems to be written in an ML-like language without any comments, so code readability is going to depend a bit on your familiarity with such languages.

https://github.com/imeckler/diffgeo/blob/master/Main.elm

https://github.com/imeckler/diffgeo/blob/master/ODE.elm

For the curious (and if it wasn't obvious enough from the file extension), the language is "Elm" : http://elm-lang.org/

The actual guts of the algorithm are in compiled javascript

https://github.com/imeckler/diffgeo/blob/master/Native/ODE.j...

However, this seems to simply be using the numeric library.

http://www.numericjs.com/documentation.html

Which uses 'Dormand-Prince RK'.

https://en.wikipedia.org/wiki/Dormand%E2%80%93Prince_method

You mean something like this?

http://i.imgur.com/e9s29Jl.png

Added the Klein model! WRT your question, I'm not sure.

Yeah, I'm pretty sure it's an artifact. I'm seeing the same drift in the cylinder geometry, which definitely shouldn't be happening. A cylinder has the same internal geometry as a plane, so turning while moving at a constant rate should give you the transformed version of a circle.

Also, I notice that doing the same thing in the Klein model gives you very weird curves. Maybe you don't have the turning logic quite right? It should turn at a constant rate in the internal geometry, not in the plane geometry. (That shouldn't matter for the hyperbolic disk because it's conformal, so I guess something else is going on.)

Thank you for creating this. It is beautifully implemented.

Regarding the infobox: a given geodesic path between two points is not necessarily the shortest path between them.

Yes yes, just wanted to keep things simple for those without much mathematical background (and for a small infobox. I didn't want to try to explain that they locally minimize distance, or that the vector field given by the derivative has zero covariant derivative, etc. in such a small space.)

Really cool!

Yet another feature request: support moving backwards

Reply on news.ycombinator.com