Complete.Org: Mailing Lists: Archives: freeciv-dev: February 2004:
[Freeciv-Dev] Re: (PR#7287) Extended Topologies
Home

[Freeciv-Dev] Re: (PR#7287) Extended Topologies

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: mburda@xxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#7287) Extended Topologies
From: "rwetmore@xxxxxxxxxxxx" <rwetmore@xxxxxxxxxxxx>
Date: Sun, 22 Feb 2004 06:48:20 -0800
Reply-to: rt@xxxxxxxxxxx

<URL: http://rt.freeciv.org/Ticket/Display.html?id=7287 >


Jason Short wrote:
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=7287 >
> 
> rwetmore@xxxxxxxxxxxx wrote:
[...]
> What I was calling a mobius strip topology was a cylinder with a flipped 
> wrap.  I've diagrammed it plenty of times before.  I believe such a 
> topology should be possible in two dimensions, although I don't know why 
> anyone would want to play it. 
[...]
> 
> What Marcelo was calling a mobius strip was a map with an offset wrap. 
> In the Y direction we wrap normally, but in the X direction each wrap is 
> accompanied by a ysize/2 (or whatever) offset.  I considered this type 
> of topology early on in gen-topologies, and it is pretty interesting. 

My brain starts to hurt when I try to reduce the various flavours of
connecting various edges with translations, inversions and other tricks.
Some of these are actually quite useful and probably easily coded under
a fairly consistent general sewing function of which simple wrapping is
the current easy example.

But before any such case is considered, one needs to define clearly such
things as the normal set, adjacency properties and 2-D gaming properties.
Those that match the current code can then be trivially added, while those
that introduce singularities and new exotic problems need to work out these
issues, show the effect in prototype code and then get engineered back into
the current system with minimal impact and clearly documented extensions to
the generalized model. If properly documented in RFC and proto-code, work
done need never be lost, but can be resurrected when the missing components
are available, or the value becomes clearer to the community.


As to the Jason Strip - I think I agree with Marcelo that a double flavour
has a fair bit of value in understanding how to map a spherical world onto
a torus. I think this is close to what quincuntial is doing, but the brain
dies before I reach the final conclusions on this.

What is missing from a torus-sphere can be thought of as the missing pole
one loses when the second N-S wrapping takes place. One needs a new pole
at the original equator, and thus two semi-cylindrical (inside and outside
if you want) halves of the torus. The inside is inverted. If one does a
double Jason strip in the N-S direction, with a simple wrap in the E-W
one has all the ingredients - maybe.

I prefer to think of the N-S mapping as an inversion in N-S and 1/2 world
shift in E-W, so I'm not sure if it really is a Jason Strip. I'm also not
completely sure that the adjacency rules aren't affected, but I think that
because it is a shift in E-W, and not inversion there are no singularities.
The problem with this is that the GUI display would likely need to do
something about the inverted half world, i.e. autoflipping when the mapview
centre crossed into the inside of the torus.


In any event, such a mapping of multiple 2-D images onto the torus surface
is pretty much what the quincuntial topology is doing, and figuring out the
various ways and relationships between them would perhaaps make the problem
less intractable - and of course the code more symmetrical.

[...]
> ---
> So, I'd consider the extended topologies with both of the above in mind. 
>     Marcelo has already done a lot of work to get a very solid design 
> that gets all the details right.  If we go forward with it, I'm willing 
> to go over it and work through the problems with him.  But if there's 
> _no chance_ that we want this topology, I don't want to do this (and 
> Marcelo's work will have been wasted - very bad!).

I must have missed the design. All I've really seen is the prototype code
postings. Could you repost or provide a link to the design document?

> Consider also that the extended topologies come in several forms.  For 
> instance an offset-wrap as I describe it above will probably not take 
> much work to implement, but gives only a small advantage over the 
> current torus wrapping.  A quincuncial wrapping will take a fair amount 
> of work to implement.  It is of high theoretical interest (how many 
> hours have we spent discussing approximations of a sphere?) but its 
> playability hasn't been determined.  People need to _play_ this thing 
> before we can assess it.

I think I agree totally with this. But if one clarifies the relationship
of the quincuntial mapping to the torus case, I suspect that much of the
fair amount of work goes poof. Quincuntial may just be offset wrapping
across a diagonal rather than coordinate aligned set of axes. If this is
the case, then from the point of view of a sphere these are only of value
if the distortions are somehow minimized in one form over the other.

<ASIDE>
By distortions for example, the offset torus map stretches the point that
is each pole into a line running E-W. The map areas are usually fudged with
the standard Mercator projection algorithms. In play, this means one can
go straight across the pole, but to change direction and come down another
longitudinal line, one needs to first move along the polar line. It is
also not possible to follow great circle paths, or rather the distances
along these are not minimal as in real life.
</ASIDE>


> jason

Cheers,
RossW
=====




[Prev in Thread] Current Thread [Next in Thread]