LSL and geometry hierarchy issues

Mark Meijer meijer78 at
Tue Jan 22 16:29:02 PST 2008

Which may lead one to conclude that having both Havok4 and Mono on all
MG sims is... not something to expect shortly.

On 23/01/2008, Mark Meijer <meijer78 at> wrote:
> I think you are right and there is no clearly defined and bounded
> chunk of code that could easily stand up and say "I am that framework"
> for scripting that sits on top of the rest of the sim code. No I think
> not.
> The reason I think not, aside from evidence from the entire history of
> software engineering, is because I remember something that recently
> struck me as odd, initially, until I began to think more on't... And
> that something can be found by following this link, provided by Jesse
> Barnett earlier in this thread: -
> and the relevant quote is this:
> "Once Mono passes our internal QA we are going to deploy it to our
> beta grid. That grid is currently being used by Havok 4, the new
> version of our physics engine. However, through the wonders of Het
> Grid, we will be able to share the grid with Havok. Het Grid allows us
> to make some regions on a grid run different simulator software than
> others. So we can have some regions on the beta grid running Havok,
> and some running Mono!"
> So... They seem quite proud about the fact that their marvel of
> technology allows them to test both havok4 and mono at the same time.
> No, not because they are separate chunks of code that can replace
> existing chunks of code simply, as in, plug-out havok3 and plug-in
> havok4, do the same for the scripting module, and we've got a new and
> improved sim... No. Instead, why did they say they could test both
> Havok4 and Mono at the same time? Because different regions can "run
> different simulator software"... quote/unquote.
> Indeed I probably wouldn't enjoy going to sleep tonight and dream
> about how exactly all the parts of a sim fit together.
> In LL's defense, though, I think I'm not far off when I say that this
> is practically unavoidable for something as complex as SL. At least to
> some extent...
> On 23/01/2008, Taran Rampersad <cnd at> wrote:
> > Mark Meijer wrote:
> > > On 22/01/2008, Taran Rampersad <cnd at> wrote:
> > >
> > > But adding the following suggestion: The scripting engine
> > > part of a sim probably needs to deal with a lot more concurrency, than
> > > any other part.
> > >
> > Right. Thats really what I meant.
> > > I'm not sure what you mean by framework, if not "the scripting engine
> > > part of a sim". But if rather you mean the fundamental core and
> > > libraries upon which the entire sim is built (if there even is such a
> > > thing)... Then I think, firstly, Mono is not being used in that way
> > > afaik, and secondly, it is not strictly necessary for such a framework
> > > to be able to handle the same level of concurrency that the
> > > scripting-portion of the sim does (this of course does not get into
> > > the requirements of other parts of SL that are not tied to any
> > > individual sim, such as asset servers).
> > >
> > Well, this is part of my problem. I'm guessing about the black box.
> >
> > Within the black box, from what I can tell... (anything below this is
> > pure speculation on my part, and is open to  injection of facts)
> >
> >  The LAMP servers and their configuration as a grid within Beowulf
> > clusters is fairly concurrent, though beowulf clusters are kind of known
> > for lazy convergence. That is a separate topic, of course, but deals
> > with a concurrency issue that we all have probably seen - hiccoughs when
> > moving from one sim to the next. This is a matter of moving a
> > *presence*, including scripts, from one server to the next. From what I
> > can tell, this is par for the course when it comes to the clusters
> > themselves. Maybe ghosting presences in adjacent sims would help with
> > that, but that is so simple that I am sure that someone has already
> > thought of it and probably discarded it because of the amount of
> > resources it would use.
> >
> > So we have these sim servers churning away with people teleporting in
> > and out, scripts running in whatever order of precedence that they may
> > run. The scripts are probably stored on the Asset Server(s), since they
> > have permissions associated with them. When they start running, the
> > Asset Server is pinged - so thats pretty straightforward. I somehow
> > doubt that the Asset Server is touched again until a modification
> > occurs, but it might be possible if someone inspects the permissions of
> > the script (dunno). Depends on how they have that set up.
> >
> > The framework for the Asset Server end of things should be pretty
> > 'concurrent', in that it gets requests and deals with them as quickly as
> > possible, though at times it seems sluggish.
> >
> > So now we get to where LSL hooks - the Framework that the Embedded
> > Scripting Language deals with. Likely, it hooks into all of these things
> > based on the functionality of the scripting language itself. How they'd
> > shove Mono in there seems kind of peculiar to me. To me, it means that
> > they are either rewriting code that they already have into .Net/Mono, or
> > they are talking about an abstraction layer. I certainly hope it isn't
> > an abstraction layer, because that seems like a *slower* headache to me.
> > Given that there is claimed to be an increase of speed to that end, it
> > would seem that they are rewriting server code. This also mixes well
> > with the fact that they haven't been talking about opening the server
> > code as much as they haven't been talking about Mono of late. I suspect
> > the two are linked.
> >
> > And now we get back to what the framework is. If they are doing the
> > abstraction layer, it becomes easier to *talk* about the framework
> > because there is this chunk of code that easily stands up and says, "I
> > am the framework that LSL lives in." But I think the framework is really
> > the muscle to much of SL, and LSL only uses cups to take from the river
> > of code.
> >
> > Am I right? Gee, I really hope not - both options I wrote of do not make
> > me ecstatic. Mono might help with presence issues, but I don't see how
> > it can help with much else. And without looking at the server code, I'm
> > really as clueless as the next person. I just make a nice house of cards
> > based on what I have seen and my own experience, just like everyone else.
> >
> > --
> > --
> > Taran Rampersad
> > cnd at
> >
> >
> >
> >
> >
> >
> > "Criticize by Creating" - Michelangelo
> > "The present is theirs; the future, for which I really worked, is mine." - Nikola Tesla
> >
> > _______________________________________________
> > Click here to unsubscribe or manage your list subscription:
> >
> >

More information about the secondlifescripters mailing list