Excuse me if this is not the adecuate place to speak about it,but ...perhaps, in a future, will be possible to build a complet planet, a real scale, using the <a href="http://www.pandromeda.com/products/">Pandromeda</a> fractal concept o a free licence similar one?<br>
<br>Alberto<br><br><div class="gmail_quote">2010/7/7 Diva Canto <span dir="ltr"><<a href="mailto:diva@metaverseink.com">diva@metaverseink.com</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">



  

<div bgcolor="#ffffff" text="#000000">
There is a ton of interesting engineering challenges on the server side
of these systems. We haven't even begun to scratch the surface. As
such, it's completely unrealistic to expect things like what you
describe to happen any time soon -- at least for interactive, shared,
immersive spaces; non-interactive, non-shared, non-immersive (like
Google Earth) it's another matter. It's also fairly unrealistic to
expect those kinds of optimizations to happen spontaneously and for
free. There needs to be a lot of money thrown in for those things to be
prototyped and experimented with -- research money, for starters;
that's the kind of thing that will keep a lot of graduate students busy
for the next few years.<div><div></div><div class="h5"><br>
<br>
On 7/6/2010 6:54 PM, Mark Malewski wrote:
</div></div><blockquote type="cite"><div><div></div><div class="h5">
  <div>OpenSim/RealXtend,</div>
  <div><br>
  </div>
  <div>Another thought is the issue of "scalability" with the current
OpenSim and/or realXtend Architecture.</div>
  <div><br>
  </div>
  <div>Running hundreds (or thousands) of IDLE regions require too many
system resources (RAM, CPU cycles, etc.)</div>
  <div><br>
  </div>
  <div>I believe that the basic server core (OpenSim) should eventually
be modified so that ALL regions should have a configurable "timeout"
option field (in the regions.ini file). </div>
  <div><br>
  </div>
  <div><a href="http://opensimulator.org/wiki/Configuring_Regions" target="_blank">http://opensimulator.org/wiki/Configuring_Regions</a></div>
  <div><br>
  </div>
  <div>That way an idle "region timeout" can be set (on a region per
region basis), and this would allow the OpenSim server to shut down
idle regions (based on the "idle timeout" configured in the regions.ini
file).  </div>
  <div><br>
  </div>
  <div>So if a region were completely empty for a particular number of
minutes (let's say a region were empty and idle for 5 minutes, then the
idle region could be shut down automatically after the set "idle
timeout" period for that particular region).</div>
  <div><br>
  </div>
  <div>This way idle (and empty) regions are not consuming valuable
system resources.</div>
  <div><br>
  </div>
  <div>Then as a user attempts to "teleport" to an idle (empty) region,
the server would simply start that idle region (on-the-fly) so that the
user could teleport into the idle region.</div>
  <div><br>
  </div>
It may create a little bit of a slight "pause" (as an idle region is
started) while teleporting, but you normally experience a pause anyways
while teleporting, so a few additional two or three seconds shouldn't
make that much of a difference when teleporting to an empty or idle
region.
  <div><br>
  </div>
  <div>A second improvement upon this, would be a "smart idle regions"
grid option (configurable at the grid and/or region level).  The "smart
idle regions" grid option would take things one step further, and would
automatically allow the configuration option to bring nearby idle
regions out of "sleep" mode, and start them automatically (if an avatar
is within a certain number of meters from a nearby neighboring region).</div>
  <div><br>
  </div>
  <div>For example this number could be configurable at the Grid and/or
region level to be anything from 1 meter, to 100 meters, or even 256
meters (thus automatically loading the idle region to the North, the
idle region to the South, the idle region to the East and the idle
region to the West). So that nearby regions could be loaded (as an
avatar gets close to the border of another nearby region).</div>
  <div><br>
  </div>
  <div>This way if avatars are using high speed vehicles (aircraft,
boats, trains, etc.) and they are getting close to a region crossing
(to another region that may be idle) that region could automatically be
started (if "smart regions" was enabled), thus making the region
crossing seamless (and in real-time).  So that flight simulators and
ship simulators could be developed (with large global high resolution
land region maps of the whole world) that could easily be stored on any
single server.  (The idle regions would simply load "on-demand" as
needed).</div>
  <div><br>
  </div>
  <div>This way OpenSim core could be used for Science, Educational,
Flight/Train/Ship simulation or even gaming purposes.</div>
  <div><br>
  </div>
  <div>So that way an OpenSim/realXtend server could technically store
thousands of regions all on a single server instance (possibly even
50-60GB's of high resolution GIS/terrain/region maps of the whole
world).  </div>
  <div><br>
  </div>
  <div>So that things like high resolution "Global Scenery" could be
created (and downloaded) under a "Creative Commons" license for high
resolution scenery (stored in Mega regions) for OpenSim.</div>
  <div><br>
  </div>
  <div><a href="http://www.global-scenery.org/" target="_blank">http://www.global-scenery.org/</a></div>
  <div><br>
  </div>
  <div>I do have a military GIS (Imagery Analysis/Intelligence)
background, and don't mind working on things like basic high resolution
OpenSim/realXtend region content creation (empty regions based on high
resolution GIS/DTED data).  DTED data could be used to create elevation
maps, and high resolution imagery could be used for terrain textures.</div>
  <div><br>
  </div>
  <div>I believe an OpenSim GIS project would be a very good "basis"
for other projects (educational, gaming, city planning, development,
architectural development and multi-person Flight/Train/Ship simulation
& training development) since terrain/region modules would be
available free for download.</div>
  <div><br>
  </div>
  <div>The reason "Smart Regions" (idle region timeouts) would be
necessary, is so things like modeling rural areas like "Yellowstone"
National Park could easily be possible on a small single server (or
even a small single workstation running a single
OpenSim/osgrid/realXtend server instance), since the majority of those
regions would usually remain idle/empty (and with the idle regions
shutting down they would consume NO CPU clock cycles or RAM, thus
making "idle" regions identical to idle web pages that take up nothing
more than hard drive space).</div>
  <div><br>
  </div>
  <div>Certain regions (like a lobby, main Plaza, or high-traffic
regions) would need to remain active (no idle timeout) and would simply
have a idle timeout value of "9999".  (Which would equate to requiring
the region to be completely idle and empty for a minimum of 9999
minutes, or about 7 days) before going into a "sleep" or idle
"shutdown" mode.</div>
  <div><br>
  </div>
  <div>I supposed a timeout value of "0000" could also be used for an
"infinite" time (no idle timeout or idle shut down) so that regions
that want to remain up (forever) with no idle timeout period or idle
shutdown could thus stay running all the time (consuming valuable RAM,
CPU and system resources).</div>
  <div><br>
  </div>
  <div>But as we begin to look at global region mapping and developing
large regions (especially from a GIS perspective) then we need to look
at the "flaws" in the current OpenSim server design architecture, and
see that it would simply not be possible to create something like a
virtual 3D world (on a 1:1 virtual/GIS scale) without having billions
of physical servers (and trillions of dollars for physical hardware,
let alone the costs of electricity and hardware just to even run a
single instance).  It seems to be a major flaw in the basic design
architecture to require the "always-on" concept of regions without
having a region "idle-timeout" feature.</div>
  <div><br>
  </div>
  <div>Wasting RAM and CPU clock cycles on empty/idle regions (without
having an "idle timeout" option would seem like a huge waste of energy,
and system resources, especially when those valuable system resources
could be better spent on active regions with physical avatars that
require the additional processing power and RAM that could be freed up
by shutting down any idle regions (after a specified "time out" period).</div>
  <div><br>
  </div>
  <div>Since the majority of the regions would remain empty and idle on
a server (similar to static web pages that are not being accessed or
viewed on a web server), it seems extremely foolish to waste such
valuable system resources (such as server CPU clock cycles and server
RAM, let alone the energy/power) wasted on idle regions that remain
empty and idle (but must be loaded as "always on").</div>
  <div><br>
  </div>
  <div>Having an "on-the-fly" system that will shut down idle regions
(based on their configurable regions.ini "time out" value in the
regions.ini file, and automatically load idle regions "on-the-fly"
would be much closer to the way the current web is designed, so that
servers can hold thousands (possibly even millions) of web pages that
consume no system resources (other than physical hard drive space)
unless the web pages are being viewed.</div>
  <div><br>
  </div>
  <div>By allowing regions to startup/shutdown dynamically (with a
"region timeout" feature) thus making servers able to hold infinite
amounts of idle regions/land (only limited by the amount of hard
drive/disk storage space, which could easily be expanded via RAID or
SAN devices).</div>
  <div><br>
  </div>
  <div>System Administrators could put "heavy load" regions on separate
dedicated servers, while keeping other "idle load" regions all on the
same server (for regions that are generally idle and not visited very
frequently).</div>
  <div><br>
  </div>
  <div>As we evolve and slowly get into simulation systems, such as
aircraft, train or ship simulators I can see how having large numbers
of "idle" regions would be a requirement for realistic
train/ship/aircraft simulation and gaming (as well as GIS and global
flight) and how it simply would not even be possible to have millions
of regions running all on a single server (due to the current
"architectural" problems with OpenSim).  </div>
  <div><br>
  </div>
  <div>It just wouldn't even be possible to even create a simple
flight, train or ship simulator using OpenSim (because OpenSim couldn't
even store the image/region scenery maps).</div>
  <div><br>
  </div>
  <div>Yet, a small simple "X-Plane" flight simulator can store high
resolution "global scenery" data for the WHOLE world on just 6 or 7
double layer DVD's (about 60+ GB of terrain data) all on a single
workstation.<br>
  <br>
  </div>
  <div><a href="http://www.global-scenery.org/" target="_blank">http://www.global-scenery.org/</a></div>
  <div><br>
  </div>
  <div>I don't mind starting a Global-Scenery package for
OpenSim/realXtend and I do think it would be extremely nice to offer
the community high resolution realistic regions (free of charge under a
"creative commons" license).</div>
  <div><br>
  </div>
  <div>The problem with even starting a large content creation project,
is that the current OpenSim architecture is unable to even use it.</div>
  <div><br>
  </div>
  <div>It would be a complete waste of time and effort to have
realistic global high resolution terrain regions available for OpenSim
to use for Flight/Train/Ship (as well as Education & Science)
simulation but the whole idea of a large scale GIS/terrain project for
OpenSim/realXtend seems somewhat pointless since the current
realXtend/OpenSim server architecture is not designed to currently even
use/store thousands (or even millions) of idle regions (and the current
server architecture of keeping ALL idle regions running is "flawed" by
architectural design).  </div>
  <div><br>
  </div>
  <div>It would seem to make much more sense (from an engineering
standpoint) to have the option to shut any idle regions down, and only
leave active regions running (or at least give users/operators/grid
owners the ability to configure regions & a grid to allow for idle
region timeouts).  I believe this "region idle time out" time should be
configured in the regions.ini configuration file.  With an option of
"9999" for a 7 day idle timeout and a "0000" option to disable the idle
timeout for a particular region (for regions that don't ever want to
shut down due to an idle timeout).</div>
  <div><br>
  </div>
  <div>It would make sense to see OpenSim/realXtend support a "smart
region" type of system which servers would/could be configured to shut
idle regions down by default (configurable in the regions.ini file for
each region) and the server could load idle regions "On-The-Fly"
freeing up valuable system resources on a physical server.</div>
  <div><br>
  </div>
  <div>By implementing "smart regions" into the OpenSim core, a high
resolution global GIS/terrain project would seem like a viable project
to start (and I wouldn't mind starting such a project) especially for
future science/flight/ship/train simulation.  I could probably find
other universities (and sponsors) that would be willing to host mirror
copies of the empty raw .OAR global terrain region files.  So that
other developers, educators or users could freely download high
resolution realistic region terrains (for educational, gaming or
simulation purposes).</div>
  <div><br>
  </div>
  <div>If OpenSim was able to shut down idle regions on the fly, then
it could be used for flight simulation, terrain simulation, or even
realistic game simulation (could have large high resolution realistic
global terrain maps).</div>
  <div><br>
  </div>
  <div>I don't mind starting/doing free "creative commons" (attribution
by) based global GIS/terrain content creation work for the
OpenSim/realXtend community, but the current problem that I see is that
the current OpenSim architecture design would NEVER even be able to
support such a feature (since the current server architecture would
require thousands, or millions or possibly even billions of OpenSim
servers just to handle ONE single copy of "the world" terrain in
high-res region data.  </div>
  <div><br>
  </div>
  <div>Thus making it completely impossible to ever "sail a ship" or
"fly an aircraft" around the world on a standalone OpenSim server.  </div>
  <div><br>
  </div>
  <div>I believe the basics of good simulation programs starts with
high resolution image maps (and scenery data).  A flight simulation
program is fairly useless without realistic global imagery.</div>
  <div><br>
  </div>
  <div>Although the basic default high resolution terrain/region data
would probably only consume about 50-60 GB's of storage space (empty
terrain regions stored in "mega region" OAR format), it would still be
impossible to even store or use the terrain region data on a single
OpenSim server (since an OpenSim server would require that all the
regions be running at the same time, with no way to load/unload the
regions (on-the-fly) as they are accessed or needed.  We would need to
have an "idle time-out" feature and also a "load-on-demand" feature to
load regions and shut down idle regions based on a region "idle
time-out" system (and to load nearby regions, and load regions that
users attempt to teleport to).</div>
  <div><br>
  </div>
  <div>I apologize for sounding repetitive.</div>
  </div></div><pre><fieldset></fieldset>
_______________________________________________
Opensim-dev mailing list
<div class="im"><a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a>
  </div></pre>
</blockquote>
<br>
</div>

<br>_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
<br></blockquote></div><br>