[Opensim-dev] Standardizing types in OpenSim

Sat Aug 9 00:57:29 UTC 2008

I've been frustrated in the past with the different math function
inplementations that exist in Opensim, but I dont see a simple way to
combine them into one for all purposes. The quaternions used in LSL differ
from other implementations and it may not be possible to standardize them
and still achieve 100% script language compatability with SL™ (not that I am
a proponent of 100% compatability, but some other devs are). I am aware of
some scripters who directly manipulate rotation structure members and using
an alternate quaternion implementation would break their scripts. Also some
plug-in modules may be written using another incompatable implementation and
it would be a lot of extra work to change them to use a "standard"
implementation when they would work fine with the current one they use.

I'd like to see Opensim keep up to date with the latest libraries it uses
and I believe any reasonable attempts to standardize on high quality
libraries should be considered and implemented in as wide a scope as
possible. However, I was under the impression that recent versions of
libopenmv are bundled with GPL licensed code? If so then updating may
interfere with the BSD license goals of Opensim. If the GPL licensed code
could be seperated it would make it much easier to continue to progress to
newer versions.

On Fri, Aug 8, 2008 at 3:17 PM, Frisby, Adam <adam at deepthink.com.au> wrote:

>  Hrrm, there is some valid points nested in here – perhaps moving these
> out into a common library may be the way to go.
>
>
>
> MetaverseTypes.dll anyone?
>
>
>
> *From:* opensim-dev-bounces at lists.berlios.de [mailto:
> opensim-dev-bounces at lists.berlios.de] *On Behalf Of *Teravus Ovares
> *Sent:* Friday, 8 August 2008 3:16 PM
>
> *To:* opensim-dev at lists.berlios.de
> *Subject:* Re: [Opensim-dev] Standardizing types in OpenSim
>
>
>
> I start this letter by saying, I respect John and I agree on type
> standardization being important.
>
>
>
> Having said that, I disagree that the libomv types are the types to
> standardize on.   Essentially what this means is we will be bringing
> libomv/libsecondlife /back/ into the core parts of opensimulator.   It's my
> understanding that we've spent countless hours trying to eliminate reliance
> on the library so that we are insulated from the breaking changes that we
> invariably see in libomv/libsecondlife between versions.
>
>
>
> Also, to the 'trademark changes'...   no, we adopted this approach before
> all of the 'trademark related' changes.    We adopted this around
> LibSecondLife Revision 1550.   There were 3 non trademark breaking changes
> between the previous release version and this revision.  There was one
> breaking change between Revision 1450 and revision 1550.   Two of those
> breaking changes were subtle, meaning the compiler wouldn't notify you that
> something nasty happened.  I'll list the changes here for brevity;
>
>
>
> 1. LLUUID, LLVector3, and LLQuaternion were no longer serializable.   Base
> types *MUST* be serializable for Grid communications to work.   (Silent and
> nasty) (took approximately 8 man hours to resolve)
>
>
>
> 2. LLUUID.ToString() changed from the non dashed format to the dashed UUID
> format.   I still gawk when I think about this change.   The number of
> applications that were rendered completely useless by this change were
> many(select regionlocation from regions where
> RegionID='65e44815-6d70-4746-abaf-7a5f32272308' does not work if all of the
> data is stored '65e448156d704746abaf7a5f32272308'. (Silent and nasty) (took
> approximately 48 man hours to resolve)
>
>
>
> 3. In addition, several packet identification methods that we use
> extensively were removed. (took approximately 2 man hours to resolve)
>
>
>
> Remember this is just *one* library update that all of this occurred on.
> I know MW and lbsa have stories about extreme issues with previous
> libsecondlife updates.   (Caps, asset upload, XML format changes,
> TextureEntry changes, LLColor changes..   You name it, it's been a problem).
>
>
>
> All in all, I'm 'seriously' suggesting that OpenSimulator maintain a set of
> base types that the project controls, or is in a dedicated library that is
> completely stable (Obviously not LibOMV/LibSecondLife).  Otherwise,
> somewhere down the line a LibOMV update will come that will cause
> OpenSimulator to fail and the devs will throw their arms up in frustration
> at the complete and utter arrogance that the libsecondlife project has shown
> of the effect API changes have on the users.
>
>
>
> In IRC chat, you mentioned something along the lines of 'people must be
> waiting for someone else to do it' implying that the opensimulator devs are
> lazy.
>
>
>
> This is not laziness, this is an attempt to avoid being masochistic.
>
>
>
> Best Regards
>
>
>
> Teravus
>
>
>
>
> On 8/8/08, *Frisby, Adam* <adam at deepthink.com.au> wrote:
>
> I can +1 these patches in principle.
>
>
>
> It's the 'in practice' that will need some fiddling as changing this many
> data types all at once is likely to cause an incredible amount of fun
> debugging later. (and will also mandate every grid update every region as
> our remoting support will break as a guarantee)
>
>
>
> Regards,
>
>
>
> Adam
>
>
>
> *From:* opensim-dev-bounces at lists.berlios.de [mailto:
> opensim-dev-bounces at lists.berlios.de] *On Behalf Of *Charles Krinke
> *Sent:* Friday, 8 August 2008 1:55 PM
> *To:* opensim-dev at lists.berlios.de
> *Subject:* Re: [Opensim-dev] Standardizing types in OpenSim
>
>
>
> Well, I'll merely say that I have the highest of respect for jhurliman's
> opinion and what he says here seems like a set of reasonable ideas.
>
> Charles
>
>
>
> ----- Original Message ----
> From: "Hurliman, John" <john.hurliman at intel.com>
> To: opensim-dev at lists.berlios.de
> Sent: Friday, August 8, 2008 11:44:59 AM
> Subject: [Opensim-dev] Standardizing types in OpenSim
>
> Hello list,
>
> This is my first e-mail to opensim-dev so I'll start with an
> introduction. I'm an engineer at Intel researching scalable models for
> virtual worlds. A lot of the research will revolve around open,
> user-generated content models like Second Life and OpenSim. I'm also the
> primary developer of libOpenMetaverse (formerly libsecondlife, still
> located at http://www.libsecondlife.org/ for the time being).
>
> I've spent some time looking at the lower level components of OpenSim
> and have a patch to propose. The basic type objects (vector, quaternion,
> rays, etc) are spread out and duplicated over several internal classes
> and external libraries. There are at least five different types of
> Vector3, multiple quaternion and matrix classes, etc. Some of these are
> classes instead of structs, meaning a basic operation like subtracting
> two vectors and putting the result in a third creates several new
> objects on the heap that the garbage collector has to track. I believe
> this is responsible for a lot of the heavy memory and garbage collector
> activity I am seeing. There is also a lot of duplicated code which has
> led to incorrect constructors (such as new Vector3(x, y, y)) and makes
> things more difficult to unit test.
>
> The OpenMetaverse library has a set of types useful to virtual worlds
> that have been in development for two years and implement all of the
> functionality needed in OpenSim. I've created a very large patch that
> upgrades OpenSim from libsecondlife to the latest libOpenMetaverse,
> drops Axiom, and uses the built-in libomv types wherever possible. There
> are a few places that I have skipped over for now to avoid introducing
> too many moving parts in a single patch: BulletX still uses Mono.Xna,
> and Meshmerizer still uses PhysicsVector/Vertex/Triangle.
>
> I've spoken with some of the OpenSim developers about problems keeping
> up with libsecondlife changes. The major changes happened to prevent a
> trademark conflict with Linden Lab, and also establish libopenmv as a
> generalized platform for building virtual worlds instead of a library to
> connect to Linden Lab's servers. I think this patch is an important move
> in that direction, and to prevent any future headaches I'm volunteering
> to maintain the OpenSim->libOpenMetaverse dependency in the event of any
> API changes.
>
> I'm working on grid mode compatibility testing (sandbox mode appears to
> work fine) and will have the patch on Mantis early to mid next week. So
> far the patch itself weighs in around 1.7MB plus binaries. Twenty
> revisions have passed since I initially wrote it and maintaining it
> against the latest SVN can be time consuming, so I wanted to kick start
> with this e-mail before posting the patch.
>
> John Hurliman
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080808/157cfe65/attachment-0001.html>