

Show HN: Walk around unusual geometries - ihm
http://parametricity.com/pages/diffgeo/Main.html

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

------
jameshart
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 :)?

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

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

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

~~~
conistonwater
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/Main.elm#L320),
[https://github.com/imeckler/diffgeo/blob/master/Native/ODE.j...](https://github.com/imeckler/diffgeo/blob/master/Native/ODE.js#L19))
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...](https://github.com/imeckler/diffgeo/blob/master/Main.elm#L458)),
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.)

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

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

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

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

[http://www.roguetemple.com/z/hyper/](http://www.roguetemple.com/z/hyper/)

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

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

~~~
ThrustVectoring
The trail lines and any distant landmarks would move differently

------
TeMPOraL
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/](http://www.roguetemple.com/z/hyper/)

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

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

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

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

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

------
cousin_it
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?

~~~
jacobolus
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/Main.elm)

[https://github.com/imeckler/diffgeo/blob/master/ODE.elm](https://github.com/imeckler/diffgeo/blob/master/ODE.elm)

~~~
archgoon
The actual guts of the algorithm are in compiled javascript

[https://github.com/imeckler/diffgeo/blob/master/Native/ODE.j...](https://github.com/imeckler/diffgeo/blob/master/Native/ODE.js)

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

[http://www.numericjs.com/documentation.html](http://www.numericjs.com/documentation.html)

Which uses 'Dormand-Prince RK'.

[https://en.wikipedia.org/wiki/Dormand%E2%80%93Prince_method](https://en.wikipedia.org/wiki/Dormand%E2%80%93Prince_method)

------
drewolbrich
Thank you for creating this. It is beautifully implemented.

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

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

------
blt
Really cool!

Yet another feature request: support moving backwards

