Send Opensim-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.berlios.de/mailman/listinfo/opensim-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Opensim-dev digest..."
Today's Topics:
1. Re: Built libbullet shared object libraries for Linux but
this isn't what you wanted! (Justin Clark-Casey)
2. The Overte Foundation for OpenSimulator (Justin Clark-Casey)
----------------------------------------------------------------------
Message: 1
Date: Thu, 30 Jun 2011 00:51:27 +0100
From: Justin Clark-Casey<[email protected]>
To: [email protected]
Subject: Re: [Opensim-dev] Built libbullet shared object libraries for
Linux but this isn't what you wanted!
Message-ID:<[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 27/06/11 16:52, Adams, Robert wrote:
Building Bullet itself is a start. Thanks Justin.
The makefile should be fairly straight forward as there are just the two cpp
files and one .h file with the only dependencies being on the std library and
Bullet itself. As you now know, Bullet used CMAKE for its build/configuration
tool and I don't know if there is a way to link a BulletSim build into it (put
the Bullet directory under BulletSim and do a CMAKE which builds both together).
I'm setting up a Linux build environment so I should be able to help anyone
working on this by next weekend. I'm doing some stress testing this week and
then I will look into linksets again -- I want to get vehicles working.
I put in a scratch Makefile and fixed one definition issue in BulletSim.cpp.
However, on make this still brings up the
errors
BulletSim.cpp:38:14: error: ?gDeactivationTime? was declared ?extern? and later
?static?
BulletDynamics/Dynamics/btRigidBody.h:29:17: error: previous declaration of
?gDeactivationTime?
BulletSim.cpp: In member function ?int BulletSim::PhysicsStep(btScalar, int,
btScalar, int*, EntityProperties***, int*,
unsigned int**)?:
BulletSim.cpp:107:79: error: cast from ?void*? to ?unsigned int? loses precision
BulletSim.cpp:108:79: error: cast from ?void*? to ?unsigned int? loses precision
BulletSim.cpp: In member function ?btCollisionShape*
BulletSim::CreateShape(ShapeData*)?:
BulletSim.cpp:405:61: error: no matching function for call to
?BulletSim::AdjustScaleForCollisionMargin(btCollisionShape*&, btVector3)?
BulletSim.h:469:7: note: candidate is: void
BulletSim::AdjustScaleForCollisionMargin(btCollisionShape*, btVector3&)
BulletSim.cpp:426:62: error: no matching function for call to
?BulletSim::AdjustScaleForCollisionMargin(btCollisionShape*&, btVector3)?
BulletSim.h:469:7: note: candidate is: void
BulletSim::AdjustScaleForCollisionMargin(btCollisionShape*, btVector3&)
BulletSim.cpp:432:61: error: no matching function for call to
?BulletSim::AdjustScaleForCollisionMargin(btCollisionShape*&, btVector3)?
BulletSim.h:469:7: note: candidate is: void
BulletSim::AdjustScaleForCollisionMargin(btCollisionShape*, btVector3&)
BulletSim.cpp: In member function ?SweepHit BulletSim::ConvexSweepTest(unsigned int,
btVector3&, btVector3&, btScalar)?:
BulletSim.cpp:1166:95: error: cast from ?void*? to ?unsigned int? loses
precision
BulletSim.cpp: In member function ?RaycastHit BulletSim::RayTest(unsigned int,
btVector3&, btVector3&)?:
BulletSim.cpp:1209:70: error: cast from ?void*? to ?unsigned int? loses
precision
make: *** [BulletSim.o] Error 1
It's a long time since I did any significant c/cpp (and then it wasn't on
Linux) so I'm not sure why this is happening.
Maybe it's gcc specific.
I was able to pull opensim-libs anonymously last week
(http://opensimulator.org/svn/opensim-libs). Has it broken since then?
Thanks Robert - I was trying the wrong url. I put the information into the
wiki.
-- ra
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Justin Clark-Casey
Sent: Sunday, June 26, 2011 4:48 PM
To: [email protected]
Subject: [Opensim-dev] Built libbullet shared object libraries for Linux but
this isn't what you wanted!
Hi Robert. I briefly putzed around with building shared object Bullet 2.78
under Linux tonight and popped the results
in as commit 23bf773 on the bulletsim branch.
However, I just realised that you weren't asking for the bullet libraries to be
built. What you were really asking for
in http://lists.berlios.de/pipermail/opensim-dev/2011-June/010271.html were
Linux/OSX makefiles to build your
BulletSim.dll interfacing library in the opensim-libs svn repo (for which
anonymous access is unfortunately not
currently working - this need to be fixed).
That doesn't look too difficult but it's a little more involved for me since
it's a long time since I wrote a Makefile.
I don't know when I might get a slice of time to do that, so I think help
from anybody else would still be very much
appreciated.
--
Justin Clark-Casey (justincc)
http://justincc.org/blog
http://twitter.com/justincc
------------------------------
Message: 2
Date: Thu, 30 Jun 2011 02:21:51 +0100
From: Justin Clark-Casey<[email protected]>
To: [email protected], [email protected]
Subject: [Opensim-dev] The Overte Foundation for OpenSimulator
Message-ID:<[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Dear all,
As I'm sure everybody on these lists is aware, OpenSimulator currently has some
restrictions on who can contribute code
to the project (http://opensimulator.org/wiki/Contributions_Policy).
The most controversial of these is the one that prevents contributions from
people who have studied the Linden Lab
viewer within the past 6 months.
This policy came about because the early core developers wanted to be very
cautious when dealing with a project that was
intimately intertwined with OpenSimulator through a common virtual world
protocol and concept, but which was licensed
under the copyleft GPL license rather than OpenSimulator's BSD license. It was
also inspired by bad, though unrelated,
early experiences of unwanted inclusion of GPL code within OpenSimulator.
However, this rule increasingly restricts progress and innovation. To state
the obvious, it effectively stops Linden
Lab viewer and third party viewer developers from contributing to OpenSimulator
and it stops OpenSimulator developers
from contributing code to those viewers.
We do want to do something about this. In very broad terms, there are two
choices of action. Either we simply drop the
6 month restriction or we establish a Contributor's License Agreement (CLA) to
explicitly clarify that a developer has
the necessary rights to contribute the code that they're giving.
Simply dropping the restriction is tempting. However, the conditions under
which it was established have not changed -
the core of the Linden Lab viewer and derivatives is still under the copyleft
LGPL license. Some people think that in
general such restrictions are entirely unnecessary but others think that it's a
reasonable precaution in the absence of
a CLA.
So the other alternative is to have that CLA. This is the route that we've
started going down. The proposal is to have
a CLA by which a contributor explicitly grants a copyright license over their
contributions. Each contributor will
continue to own their own code (i.e. there is no transfer of copyright).
Again, there is considerable debate over CLAs, with some people seeing them as
essential and others thinking that they
are entirely unnecessary. However, many open-source projects have CLAs
(Apache, Django, Python, the Linden Lab viewer)
so we would not be in bad company. Having to submit a CLA might also reduce
casual 'drive-by' patches, though we would
make CLA submitting as easy as possible - by accepting them electronically, for
instance.
In order to grant a copyright license there needs to be a receiving entity. To
this end, we are in the process of
setting up an organisation known as the Overte Foundation. The Overte
Foundation will receive the copyright licenses
and become the official distributor of OpenSimulator rather than individual
core developers. This will put it in a good
position to deal with code origin or other issues, if any should ever arise.
Once the CLA is complete, the current contribution restrictions to
OpenSimulator will be removed. It will be down to
each developer (including core developers) to affirm via the CLA that they have
the necessary rights over the code that
they are contributing.
One advantage of going down the foundation route is that it will also be able
to promote and support OpenSimulator in
other ways, quite possibly incorporating members of the community other than
just developers. The foundation could also
extend to cover other open-source virtual-environment/virtual-world projects
and components. In the short term, though,
we will be concentrating on establishing the CLA.
At some point soon we would be very grateful for donations to the Overte
Foundation in order to deal with some of the
costs involved in setting things up and for ongoing support and promotion of
OpenSimulator. Setup costs should not be
too high since Ben Esplin of Pillsbury Law is very kindly donating time and
expertise (he also helped OSgrid establish
their organisation).
We're actually still in the process of setting up the foundation so we'll only
be requesting donations once we have a
bank account for them. However, we wanted to get this out in the open now so
that people know what is being proposed
and so that we can get feedback.
For a much shorter public statement and FAQ about these topics shorn of the
historical context, please see
http://opensimulator.org/wiki/Foundation
http://opensimulator.org/wiki/Foundation_FAQ
I will be acting as the first Overte Foundation president, with Diva as
treasurer, Melanie as secretary and Nebadon and
Ben as initial board members. The foundation itself will not directly control
OpenSimulator development - this will
remain with the OpenSimulator team and community as it does now.
Discussion about this is very welcome, whether supporting or critical. I'm
logging off now so will likely answer any
points tomorrow. Of course, other core developers are very welcome to chip in.
Best,
--
Justin Clark-Casey (justincc)
http://justincc.org/blog
http://twitter.com/justincc
------------------------------
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
End of Opensim-dev Digest, Vol 46, Issue 19
*******************************************
