Smalltalk
› Squeak
› Croquet
›
Croquet - User
Dimensions in Croquet space
Locked
 
|
Hello, When creating an object in a croquet space e.g. a floor like this here: floor := self makeFloor: space fileName: 'lawn.bmp'.
what are the dimensions in the above example ? Meter or feet ? Best regards, Marc Holz Siemens AG
Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Heinrich v. Pierer; Vorstand: Klaus Kleinfeld, Vorsitzender; Johannes Feldmayer, Joe Kaeser, Rudi Lamprecht, Eduardo Montes, Jürgen Radomski, Erich R. Reinhardt, Hermann Requardt, Uriel J. Sharef, Klaus Wucherer |
Re: Dimensions in Croquet space
|
|
Croquet doesn't really use units ... but the default eye height is
1.6 if I remember correctly so meters is what everybody assumes. - Bert - On May 14, 2007, at 16:52 , Holz, Marc wrote: > Hello, > > When creating an object in a croquet space e.g. a floor like this > here: > > floor := self makeFloor: space fileName: 'lawn.bmp'. > floor extentX: 300 y: 0 z: 300. > > what are the dimensions in the above example ? Meter or feet ? > > Best regards, > > Marc Holz > > Siemens AG > A&D ATS4 > D-90475 Nürnberg > Gleiwitzerstrasse 555 > Tel ++49 911 895-3578 > Fax ++49 911 895-4903 > Email: [hidden email] > > Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: > Heinrich v. Pierer; Vorstand: Klaus Kleinfeld, Vorsitzender; > Johannes Feldmayer, Joe Kaeser, Rudi Lamprecht, Eduardo Montes, > Jürgen Radomski, Erich R. Reinhardt, Hermann Requardt, Uriel J. > Sharef, Klaus Wucherer > Sitz der Gesellschaft: Berlin und München > Registergericht: Berlin Charlottenburg, HRB 12300, München, HRB 6684 > WEEE-Reg.-Nr. DE 23691322 > > |
Re: Dimensions in Croquet space
|
|
In reply to this post by Holz, Marc
Let's assume meters, but note that this makes the avatars quite tall. I
did not choose a size, per se. I wanted the TWindows to be 3x4 units, and this stuck, so an avatar is just a little over 4 units tall - just a bit taller than a TWindow. I think meters is the right thing to use, though - so if someone wants to take the time to fix up the default size values, that would be nice. David Holz, Marc wrote: > > Hello, > > When creating an object in a croquet space e.g. a floor like this here: > > floor := self makeFloor: space fileName: 'lawn.bmp'. > floor extentX: 300 y: 0 z: 300. > > what are the dimensions in the above example ? Meter or feet ? > > Best regards, > > Marc Holz > > Siemens AG > A&D ATS4 > D-90475 Nürnberg > Gleiwitzerstrasse 555 > Tel ++49 911 895-3578 > Fax ++49 911 895-4903 > Email: [hidden email] > > Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Heinrich > v. Pierer; Vorstand: Klaus Kleinfeld, Vorsitzender; Johannes > Feldmayer, Joe Kaeser, Rudi Lamprecht, Eduardo Montes, Jürgen > Radomski, Erich R. Reinhardt, Hermann Requardt, Uriel J. Sharef, Klaus > Wucherer > Sitz der Gesellschaft: Berlin und München > Registergericht: Berlin Charlottenburg, HRB 12300, München, HRB 6684 > WEEE-Reg.-Nr. DE 23691322 > > |
Re: [croquet-dev] Re: Dimensions in Croquet space
|
|
You know, I think of the windows as being about 3 cm x 4 cm. The
avatars are just over 4 cm tall, in my mind. Why do you think that avatars are as big as humans? It never occurred to me that they would be, since they are so much less capable physically or intellectually. I "peek into" the Croquet world - I don't live there. David A Smith wrote: > Let's assume meters, but note that this makes the avatars quite tall. > I did not choose a size, per se. I wanted the TWindows to be 3x4 > units, and this stuck, so an avatar is just a little over 4 units tall > - just a bit taller than a TWindow. I think meters is the right thing > to use, though - so if someone wants to take the time to fix up the > default size values, that would be nice. > > David > > > > Holz, Marc wrote: >> >> Hello, >> >> When creating an object in a croquet space e.g. a floor like this here: >> >> floor := self makeFloor: space fileName: 'lawn.bmp'. >> floor extentX: 300 y: 0 z: 300. >> >> what are the dimensions in the above example ? Meter or feet ? >> >> Best regards, >> >> Marc Holz >> >> Siemens AG >> A&D ATS4 >> D-90475 Nürnberg >> Gleiwitzerstrasse 555 >> Tel ++49 911 895-3578 >> Fax ++49 911 895-4903 >> Email: [hidden email] >> >> Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Heinrich >> v. Pierer; Vorstand: Klaus Kleinfeld, Vorsitzender; Johannes >> Feldmayer, Joe Kaeser, Rudi Lamprecht, Eduardo Montes, Jürgen >> Radomski, Erich R. Reinhardt, Hermann Requardt, Uriel J. Sharef, >> Klaus Wucherer >> Sitz der Gesellschaft: Berlin und München >> Registergericht: Berlin Charlottenburg, HRB 12300, München, HRB 6684 >> WEEE-Reg.-Nr. DE 23691322 >> >> > > |
Re: [croquet-dev] Re: Dimensions in Croquet space
|
|
On Mon, May 14, 2007 at 03:14:48PM -0400, David P. Reed wrote:
> I "peek into" the Croquet world - I don't live there. Most users identify strongly with their avatars, which means they automatically assume they're ~human sized. -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE |
Re: [croquet-dev] Re: Dimensions in Croquet space
|
|
Agreed. On a practical level, people modeling avatars and non-player
characters need to have a spatial scale reference. It becomes really important when we want model movement, whether the differences between a tortoise and a hare in covering a distance in a give time, or the way different creatures walk up a staircase. The scale of the staircase affects the way they ascend. Referring to my earlier post where I suggested the space container should include methods for measuring distance, it seems it should also include a method to determine its scale, and we might want to think about how to represent really big (galactic) and really small (molecular) worlds. -- Peter ----- Original Message ----- From: "Eugen Leitl" <[hidden email]> To: <[hidden email]> Sent: Monday, May 14, 2007 4:25 PM Subject: Re: [croquet-dev] Re: [croquet-user] Dimensions in Croquet space > On Mon, May 14, 2007 at 03:14:48PM -0400, David P. Reed wrote: > >> I "peek into" the Croquet world - I don't live there. > > Most users identify strongly with their avatars, which means > they automatically assume they're ~human sized. > > -- > Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org > ______________________________________________________________ > ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org > 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE > |
Re: [croquet-dev] Re: Dimensions in Croquet space
|
|
Making reference to another 3D space, I know that SecondLife has problems with avatars that go over a certain altitude, they become distorted and at some point find that they can no longer move at all, most likely due to their maximum flight velocity being below the roundoff error of the altitude that they are at.
This may not be an issue with absolute scaling unless you are trying to model the orbital path of an ant, but distance from the origin can also pose a problem when dealing with the relatively small scale of an avatar. On 5/14/07, [hidden email] <[hidden email]
> wrote: Agreed. On a practical level, people modeling avatars and non-player |
Re: [croquet-dev] Re: Dimensions in Croquet space
|
|
In reply to this post by Holz, Marc
Erik Anderson wrote something about roundoff error I personally experienced.
I have a little virtual reality on my newton message pad I built to navigate with gps. Note : lat lons are an abbreviation for latitude and longitude. I made coordinate systems : mine associates with each map picture lat lons, just like a mathematical coordinate system associates with points coordinates. I had a standard coordinate 0..1 on each axis and then I had calibration associate that with a formula mapping that range to the lat lons. I have these lat lon lists that draw a route as a zig zag line even if I am off a map that has associated Well, to travel the Unites States, I had to make sure that I had maps near where I was because if I were too far off a map or scaled up too much my zig zag lines would disappear as well as the dot where my car was. I've seen this virtual world manifestation of "the math" and it was exciting. |
Re: [croquet-dev] Re: Dimensions in Croquet space
|
|
On Tue, 2007-05-15 at 09:36 -0800, [hidden email] wrote:
> Erik Anderson wrote something about roundoff error I personally experienced. > > I have a little virtual reality on my newton message pad I built > to navigate with gps. > > Note : lat lons are an abbreviation for latitude and longitude. > > I made coordinate systems : mine associates with each map picture lat lons, > just like a mathematical coordinate system associates with points > coordinates. > I had a standard coordinate 0..1 on each axis and then I had calibration > associate > that with a formula mapping that range to the lat lons. > > I have these lat lon lists that draw a route as a zig zag line even if I am > off a map > that has associated > > Well, to travel the Unites States, I had to make sure that I had maps > near where I was because if I were too far off a map or scaled up too much > my zig zag lines would disappear as well as the dot where my car was. > > I've seen this virtual world manifestation of "the math" and it was > exciting. > There are other effects as well. In VR when you scale and rotate, you multiply the values, occasionally multiple times. With each pair of multiplications you effectively lose one bit of accuracy. Thus a float which starts with 24 bits is reduced almost immediately to 23, then to 22 with a zoom, and finally to a 21 bit accuracy with a translation by rotation in 3d space. This may not seem like much error, but if you are looking at a building, it has gone from being accurate at say 30.000meters to being off by one centimeter (approximately) Walls no longer meet, angles have openings, color fills leak, and joins don't. Collisions can occur and things just are not pretty. This gets worse with distance, reducing shapes, losing texture, and actually changing appearance. I took some time a long time ago to create my own 3d program in C using all doubles. The difference in perception is tremendous. But even 64 bit can produce errors that are "funny". The future for 3d is beyond doubles, although I don't think that for general graphics use to be good for most people, that more than a long double would be necessary. However, people with good visual acuity will find that even long doubles will require some "willful suspension of disbelief" for VR to be "real". As I have seen these effects, and even run into them when playing with simulations of things like the 3 object in space issue (gravity, speed, inertia simulation to achieve orbits), it is apparent that accuracy and precision are vital to many aspects of VR and simulation calculation. This is one reason I cringe when people talk about simulations of earths environment far into the future. Small round off and truncation errors will propogate and like Baron Rothschild said “I cannot, but I know that the eigth wonder of the world is compound interest.” The same can be said of compounding errors of round-oiff and truncation. Other problems exist between numeric representations, such as binary floating point to hexadecimal floating point which yields an odd error on multiples of something like 39 or 78 if I remember right. The limits of course must be determined by the technology and whatever is chosen as the acceptable level of error. Regards, Les H. |
Re: [croquet-dev] Re: Dimensions in Croquet space
|
|
In reply to this post by David P. Reed
To explain such a system in its simplest and most crude form, all you have to do is define the unit conversions factors as values TO whatever global system of units you decide for the current standard. This could be MKS, CGS, or whatever. You would certainly need a set of length and time constants. Then depending on how much you want to be able to simulate, the system could possibly also include mass, substance, charge, temperature, and luminosity, giving you a comprehensive method of scaling all kinds of dimensional values simulated in croquet or just used as pure data. To extend it is simple. If you decide you need a new measure like bigNose as 3.21 inches, where her hand is 2.3 bigNoses long then: bigNose := 3.21 * in. "inches per bigNose times meters per inch is going to be meters per bigNose." herHand := 2.3 * bigNose. "bigNoses times meters per bigNose is going to be meters" DisplayValueInCentimeters := herHand / cm. "meters divided by meters per centimeter is going to be centimeters" Another example: if you want to talk about 23 inches per second and convert this to miles per hour, it would look something like this: currentVelocity := 23 * inches / sec. displayValueInMilesPerHour := currentVelocity / ( mi / hr ). This gracefully generalizes to just about any measure. For example if you want to convert from 111112 cubic feet per day to cubic yards per minute, you could say: volumeRate := 111112 * (ft raisedTo: 3) / day. displayValueInCubicYardsPerSecond := volumeRate /( (yd raisedTo: 3) / sec ). Otherwise, as you do your calculations, you don't really have to worry about conversions, because once you incorporate the dimensions into your input quantities, any calculations you do will be internally correct to your MKS , CGS, or whatever system. It is only upon displaying results you need to convert to apply the correct dimensions in whatever different units you wish to display. David Gleason wrote:
|
Re: Dimensions in Croquet space
|
|
You might want to check out the Units package:
http://map.squeak.org/package/8664cb28-916b-4e8a-8cd6-b6db73f5024c - Bert - On May 30, 2007, at 6:58 , [hidden email] wrote: > Actually dimensions are a great idea. If any of you have see > MathCad, it has a good implementation of dimensioning. It is really > wonderful and enables conversion to be gracefully and effectively > handled for just about any situation where dimensions are involved, > no matter how complicated. > > To explain such a system in its simplest and most crude form, all > you have to do is define the unit conversions factors as values TO > whatever global system of units you decide for the current > standard. This could be MKS, CGS, or whatever. You would > certainly need a set of length and time constants. Then depending > on how much you want to be able to simulate, the system could > possibly also include mass, substance, charge, temperature, and > luminosity, giving you a comprehensive method of scaling all kinds > of dimensional values simulated in croquet or just used as pure data. > > To extend it is simple. If you decide you need a new measure like > bigNose as 3.21 inches, where her hand is 2.3 bigNoses long then: > > bigNose := 3.21 * in. "inches per bigNose times meters per > inch is going to be meters per bigNose." > herHand := 2.3 * bigNose. "bigNoses times meters per > bigNose is going to be meters" > DisplayValueInCentimeters := herHand / cm. "meters divided > by meters per centimeter is going to be centimeters" > > Another example: if you want to talk about 23 inches per second and > convert this to miles per hour, it would look something like this: > > currentVelocity := 23 * inches / sec. > displayValueInMilesPerHour := currentVelocity / ( mi / hr ). > > This gracefully generalizes to just about any measure. For example > if you want to convert from 111112 cubic feet per day to cubic > yards per minute, you could say: > > volumeRate := 111112 * (ft raisedTo: 3) / day. > displayValueInCubicYardsPerSecond := volumeRate /( (yd raisedTo: > 3) / sec ). > > Otherwise, as you do your calculations, you don't really have to > worry about conversions, because once you incorporate the > dimensions into your input quantities, any calculations you do will > be internally correct to your MKS , CGS, or whatever system. It is > only upon displaying results you need to convert to apply the > correct dimensions in whatever different units you wish to display. > > David Gleason wrote: >> I'm new to Croquet, but I think the reason it's a great paradigm >> is that it's intuitive, because it mimics our 3d space-time >> reality. Well, real numbers almost always have some kind of units >> associated with them (unless it's a dimensionless quantity such as >> a ratio). e.g. if I order some carpet and say "I need 100 x 200 >> of tan carpet" they are going to ask "100 x 200 what?, feet? >> yards? meters?). >> >> And from an API perspective, I think for the long term success of >> a system, it should be possible to just specify the units, instead >> of having to go and lookup whatever arbitrary units are being used >> by every thing you call, which would waste a lot of time, and >> facilitate bugs. (e.g. the NASA Mars mission that crashed because >> the thing that calculated distance to the surface returned feet, >> and the thing that decided when to inflate the landing system >> interpreted the return value in meters.) >> >> For things to be simple and intuitive we should be able to say >> simply "floor extentX: 300 meters y: 0 z: 300 feet." for example. >> Is there some uniform support in Croquet for this to happen, i.e. >> can number objects store what units they are in? I would be happy >> to contibute some time to look into this if there is interest. >> >> -David Gleason >> >> >> -----Original Message----- >> From: David P. Reed [mailto:[hidden email]] >> Sent: Mon 5/14/2007 12:14 PM >> To: [hidden email]; David A Smith >> Cc: [hidden email]; Holz, Marc >> Subject: Re: [croquet-dev] Re: [croquet-user] Dimensions in >> Croquet space >> >> You know, I think of the windows as being about 3 cm x 4 cm. The >> avatars are just over 4 cm tall, in my mind. Why do you think that >> avatars are as big as humans? It never occurred to me that they >> would >> be, since they are so much less capable physically or intellectually. >> >> I "peek into" the Croquet world - I don't live there. >> >> David A Smith wrote: >> > Let's assume meters, but note that this makes the avatars quite >> tall. >> > I did not choose a size, per se. I wanted the TWindows to be 3x4 >> > units, and this stuck, so an avatar is just a little over 4 >> units tall >> > - just a bit taller than a TWindow. I think meters is the right >> thing >> > to use, though - so if someone wants to take the time to fix up the >> > default size values, that would be nice. >> > >> > David >> > >> > >> > >> > Holz, Marc wrote: >> >> >> >> Hello, >> >> >> >> When creating an object in a croquet space e.g. a floor like >> this here: >> >> >> >> floor := self makeFloor: space fileName: 'lawn.bmp'. >> >> floor extentX: 300 y: 0 z: 300. >> >> >> >> what are the dimensions in the above example ? Meter or feet ? >> >> >> >> Best regards, >> >> >> >> Marc Holz >> >> >> >> Siemens AG >> >> A&D ATS4 >> >> D-90475 Nürnberg >> >> Gleiwitzerstrasse 555 >> >> Tel ++49 911 895-3578 >> >> Fax ++49 911 895-4903 >> >> Email: [hidden email] >> >> >> >> Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: >> Heinrich >> >> v. Pierer; Vorstand: Klaus Kleinfeld, Vorsitzender; Johannes >> >> Feldmayer, Joe Kaeser, Rudi Lamprecht, Eduardo Montes, Jürgen >> >> Radomski, Erich R. Reinhardt, Hermann Requardt, Uriel J. Sharef, >> >> Klaus Wucherer >> >> Sitz der Gesellschaft: Berlin und München >> >> Registergericht: Berlin Charlottenburg, HRB 12300, München, HRB >> 6684 >> >> WEEE-Reg.-Nr. DE 23691322 >> >> >> >> >> > >> > >> |
«
Return to Croquet - User
|
1 view|%1 views
| Free forum by Nabble | Edit this page |