<!-- MHonArc v2.4.4 -->
<!--X-Subject: [MUD-Dev] Re: Nested coorindate space model -->
<!--X-From-R13: [vpunry Vburafrr <zvpunryNfcnegn.znvafgernz.arg> -->
<!--X-Date: Fri, 5 Jun 1998 19:41:03 -0700 -->
<!--X-Message-Id: 357873C4.4D497408#sparta,mainstream.net -->
<!--X-Content-Type: multipart/mixed -->
<!--X-Reference: 199806031847.LAA01035#under,engr.sgi.com -->
<!--X-Derived: jpg00001.jpg -->
<!--X-Derived: jpg00002.jpg -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, [MUD-Dev] Re: Nested coorindate space model</title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:michael#sparta,mainstream.net">
</head>
<body background="/backgrounds/paperback.gif" bgcolor="#ffffff"
text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000">
<font size="+4" color="#804040">
<strong><em>MUD-Dev<br>mailing list archive</em></strong>
</font>
<br>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
<br clear=all><hr>
<!--X-Body-Begin-->
<!--X-User-Header-->
<!--X-User-Header-End-->
<!--X-TopPNI-->
Date:
[ <a href="msg00892.html">Previous</a>
| <a href="msg00894.html">Next</a>
]
Thread:
[ <a href="msg00869.html">Previous</a>
| <a href="msg01061.html">Next</a>
]
Index:
[ <A HREF="author.html#00893">Author</A>
| <A HREF="#00893">Date</A>
| <A HREF="thread.html#00893">Thread</A>
]
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>[MUD-Dev] Re: Nested coorindate space model</H1>
<HR>
<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->
<UL>
<LI><em>To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
<LI><em>Subject</em>: [MUD-Dev] Re: Nested coorindate space model</LI>
<LI><em>From</em>: Michael Hohensee <<A HREF="mailto:michael#sparta,mainstream.net">michael#sparta,mainstream.net</A>></LI>
<LI><em>Date</em>: Fri, 05 Jun 1998 18:40:04 -0400</LI>
<LI><em>Reply-To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
</UL>
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<HR>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<PRE>
Sorry it took me so long to respond to this message. I've had to do
some heavy number crunching. :)
J C Lawrence wrote:
>
> On Sat, 30 May 1998 12:07:44 -0400
> Michael Hohensee<michael#sparta,mainstream.net> wrote:
>
> > Ling wrote:
>
> >> I think so too, scaling would be horrid. A builder wanting to
> >> mimick Alice in Wonderland's scaling feats could stick in code for
> >> that kinda thing... Then again, given that there is an interface
> >> between domains that converts objects, it oughta be pretty
> >> transparent to the players. Bubba lobbing a stick into the TARDIS
> >> should still see a stick entering the TARDIS, not a tree.
> >> Conversely, Boffo inside the TARDIS shouldn't see a twig coming in
> >> turning into a stick.
> >>
>
> > This wouldn't actually happen, if the stick's dimensions are left
> > alone. All we need to define a domain like the TARDIS is to give it
> > a "scale" value of less than 1.
>
> > It isn't the stick's responsibility to worry about whether it is
> > inside a TARDIS or not, that's the TARDIS's job. So we leave the
> > dimensions of the stick unchanged. Say the TARDIS is 5 units long
> > on the outside, and 20 units long on the inside. It would have a
> > scale value of .25. Now take a stick, and place it within the
> > TARDIS. Now, if you look at the stick from the outside of the
> > TARDIS, it will still look like it is the same length as it is on
> > the outside. (see the attached image to see what I mean).
>
> This is dependant on another assumption: the mapping of the
> translation layers between domains, and breaks at the translation
> layer when the a' and b' lengths are zero. You need to take account
> of the translation layers between coordinate systems.
>
> Consider a domain X which contains a nested domain Y. Y has external
> dimensions of 1x1x1 in X's coordinate system, but has internal
> dimensions of 100x100x100 in Y's internal coordinate system. All 6
> external faces of the cube formed by Y translate to surfaces in X.
>
> Now take your stick of length 1. It starts in X's coordinate system
> and moves in Y's. In Y's coordinate system it too has a length of 1,
> however, as it crosses the border into Y, it instantly apparently
> shrinks to a viewer in X due to the fact that its length now subtends
> a tiny fraction of the visual angle that it did immediately prior to
> crossing the border.
>
> +--------------------------------------------+
> | \ |
> | \ |
> | X domain Y domain |
> | / |
> | / |
> | ...........+-----------------+ |
> | ^ | ^ | |
> | | | | | |
> | | | | | |
> | | 1 unit | | 100 units | |
> | | | | | |
> | | | | | |
> | | | | | |
> | V | V | |
> | ...........+-----------------+ |
> | |
> | |
> +--------------------------------------------+
Not so. For the viewer determines the size of the object not from just
the angle between each end of the object's ends, but also from the
distance between him and each end. As long as one end of the stick is
inside the Y domain, a portion of the distance between the observer in
the X domain is stretched by the warping factor in the Y domain.
I think there's a slight conceptual barrier here. There are two kinds
of distances: Absolute distance, and Percieved distance. The absolute
distance is what you get if you calculate the distance based on
coordinates alone. When we look at the picture above, we are looking at
it in terms of its absolute coordinates.
Observers in the MUD, on the other hand, see things in terms of the
*percieved* distances. While an object may look like it is one unit
away from another in terms of absolute coordinates, it may seem to be
10, 100, or 1,000 units away to the observer standing one absolute unit
away, depending upon the warping factor.
So, if you do the math, you find that as the angle subtended by the
stick decreases, the distance that the observer's vision-path travels
through Y increases. If we use the right formula, we get the same
length of the stick no matter where we look at it from.
That said, let me be the first to announce that the formula that I
initially suggested *is not* the correct one. I've been grinding some
numbers through it, and while it works fine in a normal, evenly warped
environment, it's not so hot when it has to deal with an example like
the one above. But here's the most interesting thing of all: as the
stick moves into Y, it doesn't return a smaller length for the stick,
but instead returns a *larger* one! (see domains2.jpg, attached).
Try it yourself: take a stick of length 10, put an observer somewhere,
and calculate its length with the formula L^2 = X^2 + Y^2
-2*X*Y*cos(theta). You'll get 10. Now try it with the stick halfway
into a space where one absolute unit equals five real units (warp 5,
rather than JC's 100). Remember to take into account the warp, and
multiply the
The problem, of course, is that while we're taking the compression of
space into account for the distance between the observer and the object,
we're determining the observer's viewing angle from the *absolute*
coordinates of the object's endpoints alone. Just as we modify the
absolute coordinate distances by the spacial compression to find the
percieved distance, we have to somehow modify the angle absolute angle
to find the percieved one. In the case of the second arrangement in
domains2.jpg, the viewing angle should have been about 47.31 degrees,
rather than 56.309 degrees.
My initial thought was that perhaps we should apply some variation of
the law of refraction to this case (after all, light--and everything
else-- travels 5 times slower (in terms of absolute coordinates) inside
the compressed domain). There are two problems with this. First, I
haven't the foggiest idea of how to scrunch it down into one equation.
And second, it wouldn't always work properly, because if you passed the
critical angle, you wouldn't *ever* see the object in the compressed
space.
My second attachment, domain3.jpg, is a quick visual description of what
I think needs to happen. Unfortunately, I do not yet have a way to
determine how much to perturb the viewing angle based upon the
differences between the degree of compression. I'm still working on it,
but I'd love to hear it if someone has the answer. Any ideas?
> The other approach is to define constant sized translation
> interfaces, the base concept being that a translation interface must
> occupy the same dimensional units in both coordinate systems. This
> seems much closer to the TARDIS model, and also explains and allows
> many of the cute multi-blob domain mappings.
>
[ascii images of a compressed space snipped]
>
> Further this allows the TARDIS-like mechanics of being in X, moving
> south thru the B interface into Y, turning around 180 degrees and
> exiting Y thru the D interface to find yourself facing in the same
> dirction as when you started, and having traveled to the opposite side
> of Y.
Yes, but if you do it this way, what you've really got are portals which
have the property of shrinking or enlarging an object that passes
through them. The spacial compression isn't really a property of the
space that one resides in, but one of the entrances and exits of that
space. The main problem with this is that you have to be especially
careful to ensure that objects can't enter or exit the space without
going through the portals. It also prevents the creation of a variably
compressed/stretched space, and complicates (where it doesn't prevent)
calculations of space "lens" effects. It's not the most elegant and
universal solution... :/
> > If we're doing this in an object oriented language, like C++, (as I
> > am), it isn't hard to get the location of one end of the object, and
> > that of the other. From there, we can do a simple calculation of
> > the distance between each end and the observer location. We simply
> > get the distance in absolute coordinates, and divide it by the scale
> > of the domain the objects are contained in. If the lines cross into
> > other domains, we first find the distance from the edge of that
> > domain to the observer, and then ask the intervening domain to tell
> > us how far it is to the object. If still another domain intervenes,
> > it repeats this and asks that domain to find the distance to the
> > object. Eventually, everything returns and sums up the real
> > distance (i.e. how far the observer would have to walk to get to the
> > object) is discovered. Then all we have to find is the angle
> > between the two lines, but that isn't particularly hard, either.
> > Now we plug it all into the equation, and bang, we see how big the
> > object appears to be. No sudden shrinking or anything.
>
> Except for the case when an object lies just other side of a
> translation layer.
>
Not if you've got the right formula! (which I don't, yet.. :)
--
Michael Hohensee michael#mainstream,net
<A HREF="http://www.geocities.com/SiliconValley/Heights/9025/">http://www.geocities.com/SiliconValley/Heights/9025/</A>
Finger me for my PGP Public Key, or use:
<A HREF="http://sparta.mainstream.net/michael/pgpkey.txt">http://sparta.mainstream.net/michael/pgpkey.txt</A></PRE>
<P><A HREF="jpg00001.jpg" ><IMG SRC="jpg00001.jpg" ALT="JPEG image"></A></P>
<P><A HREF="jpg00002.jpg" ><IMG SRC="jpg00002.jpg" ALT="JPEG image"></A></P>
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<HR>
<ul compact><li><strong>Follow-Ups</strong>:
<ul>
<li><strong><A NAME="01061" HREF="msg01061.html">[MUD-Dev] Re: Nested coorindate space model</A></strong>
<ul compact><li><em>From:</em> J C Lawrence <claw#under,engr.sgi.com></li></ul>
</UL></LI></UL>
<!--X-Follow-Ups-End-->
<!--X-References-->
<UL><LI><STRONG>References</STRONG>:
<UL>
<LI><STRONG><A NAME="00869" HREF="msg00869.html">[MUD-Dev] Re: Nested coorindate space model</A></STRONG>
<UL><LI><EM>From:</EM> J C Lawrence <claw#under,engr.sgi.com></LI></UL></LI>
</UL></LI></UL>
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00892.html">[MUD-Dev] Re: CGDC, a summary</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00894.html">[MUD-Dev] Re:(fwd) Re: Multiple currencies</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00869.html">[MUD-Dev] Re: Nested coorindate space model</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg01061.html">[MUD-Dev] Re: Nested coorindate space model</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00893"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00893"><STRONG>Thread</STRONG></A></LI>
</UL>
</LI>
</UL>
<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->
<ul><li>Thread context:
<BLOCKQUOTE><UL>
<LI><STRONG>[MUD-Dev] Re: Nested coorindate space model</STRONG>, <EM>(continued)</EM>
<ul compact>
<ul compact>
<ul compact>
<LI><strong><A NAME="00853" HREF="msg00853.html">[MUD-Dev] Re: Nested coorindate space model</A></strong>,
Ling <a href="mailto:K.L.Lo-94#student,lboro.ac.uk">K.L.Lo-94#student,lboro.ac.uk</a>, Sat 30 May 1998, 15:39 GMT
<UL>
<LI><strong><A NAME="00854" HREF="msg00854.html">[MUD-Dev] Re: Nested coorindate space model</A></strong>,
Michael Hohensee <a href="mailto:michael#sparta,mainstream.net">michael#sparta,mainstream.net</a>, Sat 30 May 1998, 20:07 GMT
<UL>
<LI><strong><A NAME="00855" HREF="msg00855.html">[MUD-Dev] Re: Nested coorindate space model</A></strong>,
Michael Hohensee <a href="mailto:michael#sparta,mainstream.net">michael#sparta,mainstream.net</a>, Sun 31 May 1998, 13:32 GMT
</LI>
<LI><strong><A NAME="00869" HREF="msg00869.html">[MUD-Dev] Re: Nested coorindate space model</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Wed 03 Jun 1998, 18:49 GMT
<UL>
<LI><strong><A NAME="00893" HREF="msg00893.html">[MUD-Dev] Re: Nested coorindate space model</A></strong>,
Michael Hohensee <a href="mailto:michael#sparta,mainstream.net">michael#sparta,mainstream.net</a>, Sat 06 Jun 1998, 02:41 GMT
<UL>
<LI><strong><A NAME="01061" HREF="msg01061.html">[MUD-Dev] Re: Nested coorindate space model</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Tue 16 Jun 1998, 02:04 GMT
<UL>
<LI><strong><A NAME="01063" HREF="msg01063.html">[MUD-Dev] Re: Nested coorindate space model</A></strong>,
Michael Hohensee <a href="mailto:michael#sparta,mainstream.net">michael#sparta,mainstream.net</a>, Tue 16 Jun 1998, 02:33 GMT
</LI>
</UL>
</LI>
</UL>
</LI>
</UL>
</LI>
</UL>
</LI>
<LI><strong><A NAME="00868" HREF="msg00868.html">[MUD-Dev] Re: Nested coorindate space model</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Wed 03 Jun 1998, 18:09 GMT
</LI>
</UL>
</LI>
</ul>
</ul>
</ul>
</LI>
<LI><strong><A NAME="00725" HREF="msg00725.html">[MUD-Dev] Re: Java multithreading test source</A></strong>,
Chris Gray <a href="mailto:cg#ami-cg,GraySage.Edmonton.AB.CA">cg#ami-cg,GraySage.Edmonton.AB.CA</a>, Wed 20 May 1998, 13:49 GMT
</LI>
</UL></BLOCKQUOTE>
</ul>
<hr>
<center>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
</center>
<hr>
</body>
</html>
