Re: [Opensim-users] ubODE vs. Bullet (Ferd Frederix)

2017-05-02 Thread Rob Lindman
Hi,

Thanks for doing it wrong in spite of knowing otherwise.

Regards.

On Tue, 2 May 2017 09:24:04 +0100
"AJLDuarte" <ajldua...@sapo.pt> wrote:

> Hi,
>   Thanks for telling things everyone already knows
> Regards,
> UBit
> 
> 
> -Original Message-
> From: opensim-users-boun...@opensimulator.org
> [mailto:opensim-users-boun...@opensimulator.org] On Behalf Of Rob
> Lindman Sent: Tuesday, May 02, 2017 08:09 To:
> opensim-users@opensimulator.org Subject: Re: [Opensim-users] ubODE
> vs. Bullet (Ferd Frederix)
> 
> Hi,
> 
> The user expectation will most likely be 'this script I wrote in
> Second Life should work in OpenSim' and if this is some 'reinvent the
> wheel by way of deformity' then my assessment is it is being done
> incorrectly. 
> 
> If there's some desire to make it 'work differently' then the
> recommendation is call it something else... rename all of the
> constants to UBODE_WHATNOT and all of the functions to
> osFunctionWhatever and then you will not be colliding with a
> pre-existing expectation. 
> 
> Otherwise, OpenSim becomes a wolf-in-sheep's-clothing... looking like
> a duck, walking like a duck, and barking like a bowl of oatmeal. It
> won't make sense to people. 
> 
> Me
> 
> 
> On Mon, 1 May 2017 21:52:06 -0400
> <tring...@gmail.com> wrote:
> 
> > Ubit,
> > 
> > I appreciate the information.  It certainly helps me understand
> > what some of these functions do.
> > 
> > I have been thinking about changing over to using ubOde now for 
> > awhile. Many months ago when I tried doing that my residents went
> > nuts because so many things stopped working or worked differently.
> > I have been running it on my personal region now for maybe 6 months
> > and I have not noticed any strange problems, but then I don't have
> > a lot of the glitzy things some of my residents like to use.
> > 
> > 
> > 
> > -Original Message-
> > From: AJLDuarte
> > Sent: Monday, May 1, 2017 12:51 PM
> > To: opensim-users@opensimulator.org
> > Subject: Re: [Opensim-users] ubODE vs. Bullet (Ferd Frederix)
> > 
> > Hi just a few more notes about ubOde:
> > 
> > VEHICLE_FLAG_HOVER_GLOBAL_HEIGHT is dominant, if present 
> > VEHICLE_HOVER_HEIGHT is a region height Else it is a height
> > relative to water and or terrain according to:
> > 
> > If VEHICLE_FLAG_HOVER_WATER_ONLY is present, water is the
> > reference, terrain is ignored Else if HOVER_TERRAIN_ONLY is present
> > terrain is used, water is ignored.
> > Else it none of this two are presence the higher height of terrain
> > or water is used
> > 
> > VEHICLE_HOVER_HEIGHT can be a negative value but under the generic 
> > constrain that objects can't go (much) underground.
> > 
> > VEHICLE_HOVER is disabled by setting VEHICLE_HOVER_TIMESCALE higher 
> > than 300, not height of zero.
> > 
> > Regards,
> > Ubit
> > 
> > 
> > -Original Message-
> > From: opensim-users-boun...@opensimulator.org
> > [mailto:opensim-users-boun...@opensimulator.org] On Behalf Of 
> > AJLDuarte Sent: Monday, May 01, 2017 16:16
> > To: opensim-users@opensimulator.org
> > Subject: Re: [Opensim-users] ubODE vs. Bullet (Ferd Frederix)
> > 
> > Hi,
> > Sorry Fred, this is not correct
> > VEHICLE_HOVER_HEIGHT  can work with terrain, water, higher of both,
> > or fixed value.
> > This is controlled by flags:
> > 
> > VEHICLE_FLAG_HOVER_GLOBAL_HEIGHT
> > VEHICLE_FLAG_HOVER_WATER_ONLY
> > VEHICLE_FLAG_HOVER_TERRAIN_ONLY
> > 
> > Each vehicle sets defaults for this, and they be present at same
> > time, giving unpredictable results according to wiki I did added a
> > hierarchy on this flags in ubOde to reduce unpredictability, but
> > sure that’s not like the one on bullet, if any.
> > So we should use llRemoveVehicleFlags() to remove the ones we don't 
> > want, before llSetVehicleFlags();
> > 
> > We also have VEHICLE_FLAG_HOVER_UP_ONLY...
> > 
> > See http://wiki.secondlife.com/wiki/Linden_Vehicle_Tutorial  and
> > links on it for more information.
> > 
> > ubOde will try to follow VEHICLE_HOVER_HEIGHT on the fly subject to 
> > timescale and efficiency (ie how fast) In fact it will also follow 
> > region water level changes on the fly subject to same parameters
> > 
> > Also keep in mind that using llSetPos(), setvelocity, and similar 
> > should be avoid on physics objects in active simulation, specially 
> > vehicles.
> > 
> > Ubit.
> > 
> > 
> >

Re: [Opensim-users] ubODE vs. Bullet (Ferd Frederix)

2017-05-02 Thread AJLDuarte
Hi,
Thanks for telling things everyone already knows
Regards,
UBit


-Original Message-
From: opensim-users-boun...@opensimulator.org 
[mailto:opensim-users-boun...@opensimulator.org] On Behalf Of Rob Lindman
Sent: Tuesday, May 02, 2017 08:09
To: opensim-users@opensimulator.org
Subject: Re: [Opensim-users] ubODE vs. Bullet (Ferd Frederix)

Hi,

The user expectation will most likely be 'this script I wrote in Second Life 
should work in OpenSim' and if this is some 'reinvent the wheel by way of 
deformity' then my assessment is it is being done incorrectly. 

If there's some desire to make it 'work differently' then the recommendation is 
call it something else... rename all of the constants to UBODE_WHATNOT and all 
of the functions to osFunctionWhatever and then you will not be colliding with 
a pre-existing expectation. 

Otherwise, OpenSim becomes a wolf-in-sheep's-clothing... looking like a duck, 
walking like a duck, and barking like a bowl of oatmeal. It won't make sense to 
people. 

Me


On Mon, 1 May 2017 21:52:06 -0400
<tring...@gmail.com> wrote:

> Ubit,
> 
> I appreciate the information.  It certainly helps me understand what 
> some of these functions do.
> 
> I have been thinking about changing over to using ubOde now for 
> awhile. Many months ago when I tried doing that my residents went nuts 
> because so many things stopped working or worked differently.  I have 
> been running it on my personal region now for maybe 6 months and I 
> have not noticed any strange problems, but then I don't have a lot of 
> the glitzy things some of my residents like to use.
> 
> 
> 
> -Original Message-
> From: AJLDuarte
> Sent: Monday, May 1, 2017 12:51 PM
> To: opensim-users@opensimulator.org
> Subject: Re: [Opensim-users] ubODE vs. Bullet (Ferd Frederix)
> 
> Hi just a few more notes about ubOde:
> 
> VEHICLE_FLAG_HOVER_GLOBAL_HEIGHT is dominant, if present 
> VEHICLE_HOVER_HEIGHT is a region height Else it is a height relative 
> to water and or terrain according to:
> 
> If VEHICLE_FLAG_HOVER_WATER_ONLY is present, water is the reference, 
> terrain is ignored Else if HOVER_TERRAIN_ONLY is present terrain is 
> used, water is ignored.
> Else it none of this two are presence the higher height of terrain or 
> water is used
> 
> VEHICLE_HOVER_HEIGHT can be a negative value but under the generic 
> constrain that objects can't go (much) underground.
> 
> VEHICLE_HOVER is disabled by setting VEHICLE_HOVER_TIMESCALE higher 
> than 300, not height of zero.
> 
> Regards,
> Ubit
> 
> 
> -Original Message-
> From: opensim-users-boun...@opensimulator.org
> [mailto:opensim-users-boun...@opensimulator.org] On Behalf Of 
> AJLDuarte Sent: Monday, May 01, 2017 16:16
> To: opensim-users@opensimulator.org
> Subject: Re: [Opensim-users] ubODE vs. Bullet (Ferd Frederix)
> 
> Hi,
> Sorry Fred, this is not correct
> VEHICLE_HOVER_HEIGHT  can work with terrain, water, higher of both, or 
> fixed value.
> This is controlled by flags:
> 
> VEHICLE_FLAG_HOVER_GLOBAL_HEIGHT
> VEHICLE_FLAG_HOVER_WATER_ONLY
> VEHICLE_FLAG_HOVER_TERRAIN_ONLY
> 
> Each vehicle sets defaults for this, and they be present at same time, 
> giving unpredictable results according to wiki I did added a hierarchy 
> on this flags in ubOde to reduce unpredictability, but sure that’s not 
> like the one on bullet, if any.
> So we should use llRemoveVehicleFlags() to remove the ones we don't 
> want, before llSetVehicleFlags();
> 
> We also have VEHICLE_FLAG_HOVER_UP_ONLY...
> 
> See http://wiki.secondlife.com/wiki/Linden_Vehicle_Tutorial  and links 
> on it for more information.
> 
> ubOde will try to follow VEHICLE_HOVER_HEIGHT on the fly subject to 
> timescale and efficiency (ie how fast) In fact it will also follow 
> region water level changes on the fly subject to same parameters
> 
> Also keep in mind that using llSetPos(), setvelocity, and similar 
> should be avoid on physics objects in active simulation, specially 
> vehicles.
> 
> Ubit.
> 
> 
> From: opensim-users-boun...@opensimulator.org
> [mailto:opensim-users-boun...@opensimulator.org] On Behalf Of Fred 
> Beckhusen Sent: Monday, May 01, 2017 15:46
> To: opensim-users@opensimulator.org
> Subject: Re: [Opensim-users] ubODE vs. Bullet (Ferd Frederix)
> 
> Tom, I think this is a difference in implementation details.  To me, 
> Bullet actually gets it correct. Your script is setting Hover height 
> to go up and down. It is effectively llSetVehicleFloatParam( 
> VEHICLE_HOVER_HEIGHT, HovHeightBase += .02 ); each click Up and -= 
> 0.02 on Down, while starting from a negative
> value.   Zero is water height (typically 20 meters). Water height can
> range from 0 to +100 in 

Re: [Opensim-users] ubODE vs. Bullet (Ferd Frederix)

2017-05-01 Thread tringate

Ubit,

I appreciate the information.  It certainly helps me understand what some of 
these functions do.


I have been thinking about changing over to using ubOde now for awhile. 
Many months ago when I tried doing that my residents went nuts because so 
many things stopped working or worked differently.  I have been running it 
on my personal region now for maybe 6 months and I have not noticed any 
strange problems, but then I don't have a lot of the glitzy things some of 
my residents like to use.




-Original Message- 
From: AJLDuarte

Sent: Monday, May 1, 2017 12:51 PM
To: opensim-users@opensimulator.org
Subject: Re: [Opensim-users] ubODE vs. Bullet (Ferd Frederix)

Hi just a few more notes about ubOde:

VEHICLE_FLAG_HOVER_GLOBAL_HEIGHT is dominant, if present
VEHICLE_HOVER_HEIGHT is a region height
Else it is a height relative to water and or terrain according to:

If VEHICLE_FLAG_HOVER_WATER_ONLY is present, water is the reference,
terrain is ignored
Else if HOVER_TERRAIN_ONLY is present terrain is used, water is
ignored.
Else it none of this two are presence the higher height of terrain
or water is used

VEHICLE_HOVER_HEIGHT can be a negative value but under the generic
constrain that objects can't go (much) underground.

VEHICLE_HOVER is disabled by setting VEHICLE_HOVER_TIMESCALE higher
than 300, not height of zero.

Regards,
Ubit


-Original Message-
From: opensim-users-boun...@opensimulator.org
[mailto:opensim-users-boun...@opensimulator.org] On Behalf Of AJLDuarte
Sent: Monday, May 01, 2017 16:16
To: opensim-users@opensimulator.org
Subject: Re: [Opensim-users] ubODE vs. Bullet (Ferd Frederix)

Hi,
Sorry Fred, this is not correct
VEHICLE_HOVER_HEIGHT  can work with terrain, water, higher of both,
or fixed value.
This is controlled by flags:

VEHICLE_FLAG_HOVER_GLOBAL_HEIGHT
VEHICLE_FLAG_HOVER_WATER_ONLY
VEHICLE_FLAG_HOVER_TERRAIN_ONLY

Each vehicle sets defaults for this, and they be present at same
time, giving unpredictable results according to wiki
I did added a hierarchy on this flags in ubOde to reduce
unpredictability, but sure that’s not like the one on bullet, if any.
So we should use llRemoveVehicleFlags() to remove the ones we don't
want, before llSetVehicleFlags();

We also have VEHICLE_FLAG_HOVER_UP_ONLY...

See http://wiki.secondlife.com/wiki/Linden_Vehicle_Tutorial  and
links on it for more information.

ubOde will try to follow VEHICLE_HOVER_HEIGHT on the fly subject to
timescale and efficiency (ie how fast)
In fact it will also follow region water level changes on the fly
subject to same parameters

Also keep in mind that using llSetPos(), setvelocity, and similar
should be avoid on physics objects in active simulation, specially vehicles.

Ubit.


From: opensim-users-boun...@opensimulator.org
[mailto:opensim-users-boun...@opensimulator.org] On Behalf Of Fred Beckhusen
Sent: Monday, May 01, 2017 15:46
To: opensim-users@opensimulator.org
Subject: Re: [Opensim-users] ubODE vs. Bullet (Ferd Frederix)

Tom, I think this is a difference in implementation details.  To me, Bullet
actually gets it correct. Your script is setting Hover height to go up and
down. It is effectively llSetVehicleFloatParam( VEHICLE_HOVER_HEIGHT,
HovHeightBase += .02 ); each click Up and -= 0.02 on Down, while starting
from a negative value.   Zero is water height (typically 20 meters).
Water height can range from 0 to
+100 in a sim.
The problem is that VEHICLE_HOVER_HEIGHT is for use only above ground.It
is not defined in LSL by Second Life for use with negative numbers, with
additional proof of this is that zero (water height) disables it entirely.
So it is implementation specific.  I would chalk this up as expected
behavior in Bullet. Try adding a float Z variable to your
VEHICLE_LINEAR_MOTOR_DIRECTION and add or subtract a small amount from the Z
(up)  axis. Your axis seems suspicious. In vehicles, X is forward/back, Y is
L-R, and Z is up.  Your script right and left controls are setting
VEHICLE_ANGULAR_MOTOR_DIRECTION, <0, 0, 5.0>, which is mucking around with Z
(Up).  Sounds correct for a prim that rotates around Z, but not for a
vehicle.  I could be wrong here.  There may be a VEHICLE_REFERENCE_FRAME set
in your script elsewhere that is overriding the reference axis, so be wary
of it.
Also, take a look at the function llWater(), and think about doing this:

vector water = llWater(ZERO_VECTOR);
HovHeightBase += water.z - 20;

This will handle sims where water is at a different level.
regards and good luck:\
 Ferd Frederix/Fred Beckhusen

On 2017-05-01 5:20 AM, opensim-users-requ...@opensimulator.org wrote:
Send Opensim-users mailing list submissions to
opensim-users@opensimulator.org

To subscribe or unsubscribe via the World Wide Web, visit
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
or, via email, send a message with subject or body 'help' to
opensim-users-requ...@opensimulator.org

You can reach the person managing the list at
opensim-us

Re: [Opensim-users] ubODE vs. Bullet (Ferd Frederix)

2017-05-01 Thread AJLDuarte
Hi just a few more notes about ubOde:

VEHICLE_FLAG_HOVER_GLOBAL_HEIGHT is dominant, if present
VEHICLE_HOVER_HEIGHT is a region height
Else it is a height relative to water and or terrain according to:

If VEHICLE_FLAG_HOVER_WATER_ONLY is present, water is the reference,
terrain is ignored
Else if HOVER_TERRAIN_ONLY is present terrain is used, water is
ignored.
Else it none of this two are presence the higher height of terrain
or water is used

VEHICLE_HOVER_HEIGHT can be a negative value but under the generic
constrain that objects can't go (much) underground.

VEHICLE_HOVER is disabled by setting VEHICLE_HOVER_TIMESCALE higher
than 300, not height of zero.

Regards,
Ubit


-Original Message-
From: opensim-users-boun...@opensimulator.org
[mailto:opensim-users-boun...@opensimulator.org] On Behalf Of AJLDuarte
Sent: Monday, May 01, 2017 16:16
To: opensim-users@opensimulator.org
Subject: Re: [Opensim-users] ubODE vs. Bullet (Ferd Frederix)

Hi,
Sorry Fred, this is not correct
VEHICLE_HOVER_HEIGHT  can work with terrain, water, higher of both,
or fixed value.
This is controlled by flags:

VEHICLE_FLAG_HOVER_GLOBAL_HEIGHT 
VEHICLE_FLAG_HOVER_WATER_ONLY  
VEHICLE_FLAG_HOVER_TERRAIN_ONLY 

Each vehicle sets defaults for this, and they be present at same
time, giving unpredictable results according to wiki
I did added a hierarchy on this flags in ubOde to reduce
unpredictability, but sure that’s not like the one on bullet, if any.
So we should use llRemoveVehicleFlags() to remove the ones we don't
want, before llSetVehicleFlags();  

We also have VEHICLE_FLAG_HOVER_UP_ONLY...

See http://wiki.secondlife.com/wiki/Linden_Vehicle_Tutorial  and
links on it for more information.

ubOde will try to follow VEHICLE_HOVER_HEIGHT on the fly subject to
timescale and efficiency (ie how fast)
In fact it will also follow region water level changes on the fly
subject to same parameters

Also keep in mind that using llSetPos(), setvelocity, and similar
should be avoid on physics objects in active simulation, specially vehicles.

Ubit.


From: opensim-users-boun...@opensimulator.org
[mailto:opensim-users-boun...@opensimulator.org] On Behalf Of Fred Beckhusen
Sent: Monday, May 01, 2017 15:46
To: opensim-users@opensimulator.org
Subject: Re: [Opensim-users] ubODE vs. Bullet (Ferd Frederix)

Tom, I think this is a difference in implementation details.  To me, Bullet
actually gets it correct. Your script is setting Hover height to go up and
down. It is effectively llSetVehicleFloatParam( VEHICLE_HOVER_HEIGHT,
HovHeightBase += .02 ); each click Up and -= 0.02 on Down, while starting
from a negative value.   Zero is water height (typically 20 meters).   
Water height can range from 0 to
+100 in a sim.
The problem is that VEHICLE_HOVER_HEIGHT is for use only above ground.    It
is not defined in LSL by Second Life for use with negative numbers, with
additional proof of this is that zero (water height) disables it entirely.
So it is implementation specific.  I would chalk this up as expected
behavior in Bullet. Try adding a float Z variable to your
VEHICLE_LINEAR_MOTOR_DIRECTION and add or subtract a small amount from the Z
(up)  axis. Your axis seems suspicious. In vehicles, X is forward/back, Y is
L-R, and Z is up.  Your script right and left controls are setting
VEHICLE_ANGULAR_MOTOR_DIRECTION, <0, 0, 5.0>, which is mucking around with Z
(Up).  Sounds correct for a prim that rotates around Z, but not for a
vehicle.  I could be wrong here.  There may be a VEHICLE_REFERENCE_FRAME set
in your script elsewhere that is overriding the reference axis, so be wary
of it.
Also, take a look at the function llWater(), and think about doing this:

vector water = llWater(ZERO_VECTOR);
HovHeightBase += water.z - 20;

This will handle sims where water is at a different level. 
regards and good luck:\
  Ferd Frederix/Fred Beckhusen

On 2017-05-01 5:20 AM, opensim-users-requ...@opensimulator.org wrote:
Send Opensim-users mailing list submissions to
opensim-users@opensimulator.org

To subscribe or unsubscribe via the World Wide Web, visit
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
or, via email, send a message with subject or body 'help' to
opensim-users-requ...@opensimulator.org

You can reach the person managing the list at
opensim-users-ow...@opensimulator.org

When replying, please edit your Subject line so it is more specific than
"Re: Contents of Opensim-users digest..."


Today's Topics:

   1. ubODE vs. Bullet (tring...@gmail.com)
   2. Re: ubODE vs. Bullet (AJLDuarte)


--

Message: 1
Date: Sun, 30 Apr 2017 23:27:37 -0400
From: <tring...@gmail.com>
To: "OS-Opensim Users" <opensim-users@opensimulator.org

Re: [Opensim-users] ubODE vs. Bullet (Ferd Frederix)

2017-05-01 Thread AJLDuarte
Hi,
Sorry Fred, this is not correct
VEHICLE_HOVER_HEIGHT  can work with terrain, water, higher of both,
or fixed value.
This is controlled by flags:

VEHICLE_FLAG_HOVER_GLOBAL_HEIGHT 
VEHICLE_FLAG_HOVER_WATER_ONLY  
VEHICLE_FLAG_HOVER_TERRAIN_ONLY 

Each vehicle sets defaults for this, and they be present at same
time, giving unpredictable results according to wiki
I did added a hierarchy on this flags in ubOde to reduce
unpredictability, but sure that’s not like the one on bullet, if any.
So we should use llRemoveVehicleFlags() to remove the ones we don't
want, before llSetVehicleFlags();  

We also have VEHICLE_FLAG_HOVER_UP_ONLY...

See http://wiki.secondlife.com/wiki/Linden_Vehicle_Tutorial  and
links on it for more information.

ubOde will try to follow VEHICLE_HOVER_HEIGHT on the fly subject to
timescale and efficiency (ie how fast)
In fact it will also follow region water level changes on the fly
subject to same parameters

Also keep in mind that using llSetPos(), setvelocity, and similar
should be avoid on physics objects in active simulation, specially vehicles.

Ubit.


From: opensim-users-boun...@opensimulator.org
[mailto:opensim-users-boun...@opensimulator.org] On Behalf Of Fred Beckhusen
Sent: Monday, May 01, 2017 15:46
To: opensim-users@opensimulator.org
Subject: Re: [Opensim-users] ubODE vs. Bullet (Ferd Frederix)

Tom, I think this is a difference in implementation details.  To me, Bullet
actually gets it correct.   
Your script is setting Hover height to go up and down. It is effectively 
llSetVehicleFloatParam( VEHICLE_HOVER_HEIGHT, HovHeightBase += .02 ); each
click Up and -= 0.02 on Down, while starting from a negative value.   Zero
is water height (typically 20 meters).    Water height can range from 0 to
+100 in a sim.
The problem is that VEHICLE_HOVER_HEIGHT is for use only above ground.    It
is not defined in LSL by Second Life for use with negative numbers, with
additional proof of this is that zero (water height) disables it entirely.  
So it is implementation specific.  I would chalk this up as expected
behavior in Bullet.   
Try adding a float Z variable to your VEHICLE_LINEAR_MOTOR_DIRECTION and add
or subtract a small amount from the Z (up)  axis. 
Your axis seems suspicious. In vehicles, X is forward/back, Y is L-R, and Z
is up.  Your script right and left controls are setting
VEHICLE_ANGULAR_MOTOR_DIRECTION, <0, 0, 5.0>, which is mucking around with Z
(Up).  Sounds correct for a prim that rotates around Z, but not for a
vehicle.  I could be wrong here.  There may be a VEHICLE_REFERENCE_FRAME set
in your script elsewhere that is overriding the reference axis, so be wary
of it.
Also, take a look at the function llWater(), and think about doing this:

vector water = llWater(ZERO_VECTOR);
HovHeightBase += water.z - 20;

This will handle sims where water is at a different level. 
regards and good luck:\
  Ferd Frederix/Fred Beckhusen

On 2017-05-01 5:20 AM, opensim-users-requ...@opensimulator.org wrote:
Send Opensim-users mailing list submissions to
opensim-users@opensimulator.org

To subscribe or unsubscribe via the World Wide Web, visit
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
or, via email, send a message with subject or body 'help' to
opensim-users-requ...@opensimulator.org

You can reach the person managing the list at
opensim-users-ow...@opensimulator.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Opensim-users digest..."


Today's Topics:

   1. ubODE vs. Bullet (tring...@gmail.com)
   2. Re: ubODE vs. Bullet (AJLDuarte)


--

Message: 1
Date: Sun, 30 Apr 2017 23:27:37 -0400
From: <tring...@gmail.com>
To: "OS-Opensim Users" <opensim-users@opensimulator.org>
Subject: [Opensim-users] ubODE vs. Bullet
Message-ID: <65ED585961044A12B8C19EA5984238E3@TomsDesktop>
Content-Type: text/plain; charset="utf-8"

I am working on a script for a submarine and am having issues with it
working fine in ubode but will not dive or surface in Bullet physics.

Here are the primary items that are involved with the physics.

This is the initial settings the object is set with.

set_engine(){
llSetVehicleType(VEHICLE_TYPE_BOAT);
llSetVehicleFloatParam(VEHICLE_LINEAR_DEFLECTION_TIMESCALE, 0.5);
llSetVehicleFloatParam(VEHICLE_LINEAR_MOTOR_TIMESCALE, 0.1);
llSetVehicleFloatParam(VEHICLE_LINEAR_MOTOR_DECAY_TIMESCALE, 0.1);
llSetVehicleFloatParam(VEHICLE_LINEAR_DEFLECTION_EFFICIENCY, 0.80);
llSetVehicleVectorParam(VEHICLE_LINEAR_FRICTION_TIMESCALE, <1, 1, 1>);

llSetVehicleFloatParam(VEHICLE_ANGULAR_DEFLECTION_EFFICIENCY, 0.2);
llSetVehicleFloatParam(VEHICLE_ANGULAR_DEFLECTION_TIMESCALE, 1.0);
   

Re: [Opensim-users] ubODE vs. Bullet (Ferd Frederix)

2017-05-01 Thread Fred Beckhusen
Tom, I think this is a difference in implementation details.  To me, 
Bullet actually gets it correct.


Your script is setting Hover height to go up and down. It is 
effectively  llSetVehicleFloatParam( VEHICLE_HOVER_HEIGHT, HovHeightBase 
+= .02 ); each click Up and -= 0.02 on Down, while starting from a 
negative value.   Zero is water height (typically 20 meters).Water 
height can range from 0 to +100 in a sim.


The problem is that VEHICLE_HOVER_HEIGHT is for use only above 
ground.It is not defined in LSL by Second Life for use with negative 
numbers, with additional proof of this is that zero (water height) 
disables it entirely.   So it is implementation specific.  I would chalk 
this up as expected behavior in Bullet.


Try adding a float Z variable to your VEHICLE_LINEAR_MOTOR_DIRECTION and 
add or subtract a small amount from the Z (up)  axis.


Your axis seems suspicious. In vehicles, X is forward/back, Y is L-R, 
and Z is up.  Your script right and left controls are setting 
VEHICLE_ANGULAR_MOTOR_DIRECTION, <0, 0, 5.0>, which is mucking around 
with Z (Up).  Sounds correct for a prim that rotates around Z, but not 
for a vehicle.  I could be wrong here. There may be a 
VEHICLE_REFERENCE_FRAME set in your script elsewhere that is overriding 
the reference axis, so be wary of it.


Also, take a look at the function llWater(), and think about doing this:

vector water = llWater(ZERO_VECTOR);
HovHeightBase += water.z - 20;

This will handle sims where water is at a different level.

regards and good luck:\
  Ferd Frederix/Fred Beckhusen

On 2017-05-01 5:20 AM, opensim-users-requ...@opensimulator.org wrote:

Send Opensim-users mailing list submissions to
opensim-users@opensimulator.org

To subscribe or unsubscribe via the World Wide Web, visit
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
or, via email, send a message with subject or body 'help' to
opensim-users-requ...@opensimulator.org

You can reach the person managing the list at
opensim-users-ow...@opensimulator.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Opensim-users digest..."


Today's Topics:

1. ubODE vs. Bullet (tring...@gmail.com)
2. Re: ubODE vs. Bullet (AJLDuarte)


--

Message: 1
Date: Sun, 30 Apr 2017 23:27:37 -0400
From: 
To: "OS-Opensim Users" 
Subject: [Opensim-users] ubODE vs. Bullet
Message-ID: <65ED585961044A12B8C19EA5984238E3@TomsDesktop>
Content-Type: text/plain; charset="utf-8"

I am working on a script for a submarine and am having issues with it working 
fine in ubode but will not dive or surface in Bullet physics.

Here are the primary items that are involved with the physics.

This is the initial settings the object is set with.

set_engine(){
 llSetVehicleType(VEHICLE_TYPE_BOAT);
 llSetVehicleFloatParam(VEHICLE_LINEAR_DEFLECTION_TIMESCALE, 0.5);
 llSetVehicleFloatParam(VEHICLE_LINEAR_MOTOR_TIMESCALE, 0.1);
 llSetVehicleFloatParam(VEHICLE_LINEAR_MOTOR_DECAY_TIMESCALE, 0.1);
 llSetVehicleFloatParam(VEHICLE_LINEAR_DEFLECTION_EFFICIENCY, 0.80);
 llSetVehicleVectorParam(VEHICLE_LINEAR_FRICTION_TIMESCALE, <1, 1, 1>);
 llSetVehicleFloatParam(VEHICLE_ANGULAR_DEFLECTION_EFFICIENCY, 0.2);
 llSetVehicleFloatParam(VEHICLE_ANGULAR_DEFLECTION_TIMESCALE, 1.0);
 llSetVehicleFloatParam(VEHICLE_ANGULAR_MOTOR_TIMESCALE, 0.5);
 llSetVehicleFloatParam(VEHICLE_ANGULAR_MOTOR_DECAY_TIMESCALE, 0.2);
 llSetVehicleVectorParam(VEHICLE_ANGULAR_FRICTION_TIMESCALE, <0.1, 0.1, 
0.1>);
 llSetVehicleFloatParam(VEHICLE_VERTICAL_ATTRACTION_EFFICIENCY, 0.5);
 llSetVehicleFloatParam(VEHICLE_VERTICAL_ATTRACTION_TIMESCALE, 1.0);
 llSetVehicleFloatParam( VEHICLE_HOVER_HEIGHT, 0.0); // set ball at water 
surface
 llSetVehicleFloatParam( VEHICLE_HOVER_EFFICIENCY, 0.5 );
 llSetVehicleFloatParam( VEHICLE_HOVER_TIMESCALE, 1.0 );
}

These are the controls and they work fine in ubODE, but CONTROL_UP and 
CONTROL_DOWN do nothing in Bullet.

control(key id, integer level, integer edge)
 {
 floatgForwardThrust; // variable for forward thrust
 floatgReverseThrust = -1.5; // reverse thrust backup speed
 if(level & CONTROL_FWD)
 {
 Swimming();
 gForwardThrust = 3; // normal forward speed
 vTarget = llGetPos(); // get our current position
 // if near region edge, slow down
 if (vTarget.x > xlimit || vTarget.x < gGuard || vTarget.y > ylimit || 
vTarget.y < gGuard)
 {
 if (vTarget.x > xlimit) vTarget.x = xlimit;
 if (vTarget.x < gGuard) vTarget.x = gGuard;
 if (vTarget.y > xlimit) vTarget.y = ylimit;
 if (vTarget.y < gGuard) vTarget.y = gGuard;
 gForwardThrust = .3; // slow us down