Toni,
With the "MegaRegions" support it allows regions that are 8,192m x 8,192m
(instead of 256m x 256m), which would be great for vehicles and boats.
The new "MegaRegions" is the equivalent of up to 1,024 of the old size
regions!
So I think that is a VERY decent size, and that would solve the "handshake"
problem between the old small 256m x 256m regions.
The new larger MegaRegions would eliminate the current border crossings
problem.
MegaRegions seems to be in the OpenSim Trunk right now. A 1,024 region
system (8,192m x 8,192m) would only require about 5GB of memory to host.
You can make regions any size (it's only dependent upon the amount of ram
the server has).
So I think this is a great idea, and I can't imagine anyone wanting to host
more than 1,024 regions on a single server. I have dual quad-core XEON's
(8-cores) and 32GB of ram, and I think this would be great for hosting a
single 1,024 region RealXtend demo region!
Is there any possibility we can get this new MegaRegions feature implemented
and to work properly with RealXtend?
Also, what are your thoughts of replacing the realXtend Physics subsystem
with PAL?
Using PAL (Physics Abstraction Layer), it is an OpenSource wrapper for
several physics engines (allowing for seamless integration of Bullet,
JigLib, Newton, ODE, nVidia PhysX, Tokamak, and TrueAxis). PAL also has
experimental support for Box2D, Havok, IBDS, OpenTissue and Simple Physics
Engine.
But if we implemented PAL into RealXtend, at least we could have seamless
integration of multiple Physics engines (including PhysX), and with PhysX we
could have hardware accelerated Physics, and if you have a server with a
GeForce 8000 series card or higher then the graphics card would perform all
the Physics calculations, thus taking the load off of the CPU (greatly
reducing the lag).
If we get into a sim with racing or boating, we definitely want
hardware-accelerated physics, or at least something better than what ODE can
handle. The use of the Physics Abstraction Layer would definitely open up
new possibilities and streamline the physics code (allowing various physics
engines to be used).
PhysX and Havok are free for personal use. What are your thoughts on
implementing PAL into RealXtend/ModRex, and implementing the OpenSim
MegaRegion support into RealXtend/ModRex?
I believe these are the only three major hurdles that we have left (the
Naali Viewer, MegaRegion support, and PAL support).
What are your thoughts on this?
Mark
On Wed, Sep 30, 2009 at 2:35 PM, Toni Alatalo <ant...@kyperjokki.fi> wrote:
>
> Ryan McDougall kirjoitti:
>
> just chiming in to elaborate on of the reasons why Naali and Idealist
> are not the same:
>
> > The reason why realXtend couldn't proceed with Idealist, although the
> > idea was seriously considered is the following:
> > 2. language and rendering engine: more than half of realXtend are
> > professional C++ programmers with years of experience with Ogre3D;
> > tossing that out for C# and Irrlicht is not a trivial matter
> >
>
> Also the idea with Naali was to quickly get something that is compatible
> with the existing server on a protocol level. At the same time the
> server implementation refactoring from a fork to an opensim module was
> completed, but the protocol and asset formats etc. stayed the same, so
> both the old rexviewer and Naali work with both the old rexserver and
> current opensim+modrex. And we got there relatively quickly: after
> programming started in March, in May we could see Rex scenes at least
> partially how they ought to be.
>
> So with that idea it certainly seems that it made sense to continue
> using Ogre, and not switch the gfx engine at the same time.
>
> Like someone already said in this crazily exploded discussion on the
> various lists, it is also good to have options. The Idealist techs:
> .net, c#, Irrlicht, .net gui libs etc have certain characteristics that
> fit certain usage environments, developers and libraries. Naali techs:
> c++ native code, Ogre, qt for ui and increasingly for other things, and
> cpython for non-native extensions (and javascript as qtscript) are a
> different family.
>
> I do agree that there is and has been too much fragmentation, given how
> little resources most of these projects have (like lookingglass seems
> quite nice but is one guy, Idealist 2-3 occasionally?). It certainly
> would be nice if there was at least one complete enough open modular
> viewer that would be actually usable for stuff. It was interesting to
> hear on irc one day that some (teacher?) found Idealist already complete
> enough so that he could use that with his students - wanted something
> simpler and more restricted than full slviewer. But in some places the
> differing also makes sense, due to different platforms like described
> above.
>
> At least we can learn from each other, like thanks to pyov and Idealist
> (which I think inherited it from pyov) we know one way to do multiregion
> support, which we don't have in Naali at all yet (and I don't know how
> it should / will be done, given that the whole SL way with regions is
> perhaps not a good idea).
>
> In any case there will be several viewers, with different graphics
> engines etc. -- even if some of the open, modular, bsd-like things would
> merge, at least also the slviewer and others based on that will be
> there. So like said the questions about format standards and such
> interoperability are topical. For standardization it is good that there
> is a lot of different kinds of innovation first in many places, so that
> people get to know what actually needs to be standardized (mr.
> Tannenbaums networking book has a nice diagram about this) - some of
> that is already known now (mesh and scene data I think, animations to a
> lesser extent), but not everything I believe.
>
> But I sure also hope that we keep sharing design ideas, perhaps code
> too, and who knows perhaps have some parts where have merged subprojects
> from different efforts.
>
> ~Toni
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/realxtend
http://www.realxtend.org
-~----------~----~----~----~------~----~------~--~---
