Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007528opensim[REGION] Script Functionspublic2015-04-13 16:092017-08-04 21:42
Assigned ToRobert Adams 
PlatformOperating SystemOperating System Version
Product Versionmaster (dev code) 
Target VersionFixed in Version0.9.0 
Summary0007528: Discover Region Physics Engine Type by LSL Script Function
DescriptionPROPOSED: Extension of the llGetEnv() function by the addition of a new "opensim_physics" string. This is a unique phrase and does not conflict with existing or future SL function strings. It would return a unique string such as "ODE" or "Bullet" or "empty string" or "XYZ Physics Engine" (whatever engine is in-vogue at the time) or nothing at all. This returned string could also be augmented with a rev number or version of the physics engine.

PROBLEM: Knowing the physics engine type is one of the most basic issues in a region. Products fail when rezzed due to being designed for a different physics engine. Physical objects using LSL scripts require knowing the type of Physics Engine active in the region environment, so that the script can adjust the object's physical parameters to meet performance goals of the content or product. For example, a physical vehicle running in ODE requires adjustment of different parametric values and functional implementations than BulletSim.

LSL not OSSL: An LSL-only solution is required. An OSSL solution is not suitable at all for this, due to the odd and cumbersome access restrictions imposed upon OSSL script functions. Also, a special OSSL function to request a test for each physics engine type is not suitable, and is equally cumbersome.
Steps To ReproduceIn a region with BulletSim Physics Engine active, rezz an LSL scripted physical object designed for ODE, such as a physical vehicle. Note performance failure or malfunction. This could be corrected to compensate if the Physics Engine Type is known.

In a region with ODE Physics Engine active, rezz an LSL scripted physical object designed for BulletSim, such as a physical vehicle. Note performance failure or malfunction. This could be corrected to compensate if the Physics Engine Type is known.
Additional InformationExtension of the llGetEnv function does not present a security problem issue, due to the simple return of a string describing something (Physics Engine Type) which is easily known through other round-about means, such as avatar movement or non-scripted bounce tests.

Both ODE and BulletSim physics engines will continue to be used in OpenSimulator, and at the present time, even though BulletSim Physics Engine is the default in core dev OpenSim releases, there are many regions and entire grids still continuing to use ODE. Due to the modular nature of OpenSim, it is likely that another physics engine could be available in the future.

Content creators who make OpenSim products require LSL script function to manufacture virtual goods which may be marketed to the mainstream average user who has no control over the simulator environment in which the product is rezzed.
TagsNo tags attached.
Git Revision or version number
Run Mode Grid (Multiple Regions per Sim)
Physics EngineOther
Script Engine
Mono VersionOther
ViewerViewer independent
Attached Files

- Relationships

-  Notes
LaniGlobal (reporter)
2015-04-13 16:18

// llGetEnv Test Unit for OpenSim
// (C)2015 LANI GLOBAL SYSTEMS. Offered Under License:CC-BY-SA
// APRIL 2015
string SCRIPTNAME = "llGetEnv"; // Name of Script
string SCRIPTVERSION = " for OpenSim v1.4"; // Script version
    on_rez(integer start_param)
        llSetObjectName(SCRIPTNAME+" "+SCRIPTVERSION);
        llSay(0, "SL description of this function:" [^]);
        llOwnerSay("in Local Chat channel 0, Upon touch, returns a string with the requested data about the region.");
        llSetObjectName(SCRIPTNAME+" "+SCRIPTVERSION);
    touch_start(integer total_number)
        llSay(0,"dynamic_pathfinding = " + llGetEnv("estate_id"));
        llSay(0,"estate_id = " + llGetEnv("dynamic_pathfinding"));
        llSay(0,"frame_number = " + llGetEnv("frame_number"));
        llSay(0,"region_idle = " + llGetEnv("region_idle"));
        llSay(0,"sim_channel = " + llGetEnv("sim_channel"));
        llSay(0,"sim_version = " + llGetEnv("sim_version"));
        llSay(0,"opensim_physics = " + llGetEnv("opensim_physics"));
        llSetObjectName(SCRIPTNAME+" "+SCRIPTVERSION);
danbanner (manager)
2015-04-13 16:21

osCheckODE has already been added and does not require ossl functions to be enabled.
LaniGlobal (reporter)
2015-04-13 18:51
edited on: 2015-04-13 18:57

osCheckODE is not sufficient, will not accomplish the needed task.

Under such an odd contrivance, the scripter would require a ridiculous array of osCheckNNN function calls, such as:
osCheckBullet, osCheckHavok, osCheckNewPhys, osCheckUndocumented.

llGetEnv provides a much simpler means to determine exactly which physics engine is active in the region.

This is Open Source software. Applications require knowledge of the environment in which they are running.

nebadon (administrator)
2015-04-13 18:54

why is it not sufficient?
LaniGlobal (reporter)
2015-04-13 21:42

OpenSim is Open Source, we need to keep that in mind.

Applications (in this case scripted physical objects) must know the operating system environment in which they run.

A single-function LSL call is required, which returns the physics engine type, so that precise dynamic parameters may be determined and applied to the product performance.

There are many many nuances in physics, and no two engines (or even two versions) perform the same for all aspects of physical simulation, nor is it likely that they ever will be exactly the same.

It therefore must be left up to the content creator (script writer) or product designer to have the freedom to optimize the performance of the content script while knowing the operating system environment in which it will be marketed, and to which it will utilized by the average user.

A special OSSL function to request tests in piecemeal fashion for each physics engine type is cumbersome. Forcing a need for numerous osCheckNNN function calls, such as: osCheckODE, osCheckBullet, osCheckHavok, osCheckNewPhys, osCheckNinja, osCheckUndocumented... ad infinitum is shortsighted, unproductive. It fails to provide backward and forward compatibility.

Both ODE and BulletSim physics engines continue to be used in OpenSimulator. As of mid-2015, entire OpenSim grids still continue to use ODE. Others use BulletSim. These are connected together by HyperGrid in an entire OpenSim metaverse, forming a wide market for virtual goods. Producers of those virtual goods require a platform which informs the product of its application environment.
Robert Adams (administrator)
2015-04-13 22:16

The argument that was made is that all physics engines should be working 'correctly' and they should be fixed if not working the same. That is, in the ideal world, the script should not need to know which physics engine is being used. The osCheckODE() function allows one to check for the one legacy physics engine that people still use and that is not being supported and not getting bug fixes.

That argument aside, there are still the osGetPhysicsEngineType() and osGetPhysicsEngineName() functions that are available when ossl functions are enabled.
AliciaRaven (manager)
2015-04-13 22:30

I think Lani has a point. The function osCheckODE only checks ODE and is not very future proof. I was surprised that the comment in the commit message said "The presumption is that all other physics engines work the same" i would say that was impossible?

Wouldn't it be better for this function to return an enumeration value and provide constants to be easier for scripts to match the exact engine? For example

if(osGetPhysics() == PHYSICS_BULLET)

Basically a simple true or false for ODE may work now while there are only two main options, but what if the people wanting PhysX get that added or some other future engine.
AliciaRaven (manager)
2015-04-13 22:42

Sorry I posted before i saw Roberts last post, why cant osGetPhysicsEngineType be used in this case?
LaniGlobal (reporter)
2015-04-13 23:52

If osGetPhysicsEngineType() and osGetPhysicsEngineName() were always available by default in all regions, for everyone, then they would be a viable solution for the mainstream. However, the OSSL situation as it currently stands (April 2015), is entirely useless for mainstream products.
nebadon (administrator)
2015-04-13 23:54

there is a long standing rule that LSL must conform to standard LSL and not be extended, any new functionality must remain as OSSL
LaniGlobal (reporter)
2015-04-14 00:30

There are existing non-standard LSL functions in OpenSim. Also, many LSL functions that operate and have results entirely different in OpenSim than in SL. So, if any long standing rule has existed, it has many exceptions to it.
nebadon (administrator)
2015-04-14 06:31

incomplete or malfunctioning LSL is to be expected this is not intentional, extending LSL and adding new functionality is something else entirely, I don't really know of any LSL that has been extended with new functions that do not exist in SL
aiaustin (developer)
2015-04-14 08:35
edited on: 2015-04-14 13:36

I am all for adding in a suitable function (or extending in a permitted way an existing one that allows for environmental information to be passed) that is guaranteed to be available whatever OSSL enabling, disabling or restricting settings are used in a "No threat, always available" category for example.

osCheckODE() does seem to be a bit specific and rather hard codes that specific engine into the function name.

It clearly is not the case that all physics engines that can be selected are either ODE (= legacy as Mister Blue called it) and all others equally (barring bugs) to SL physics.

    ;; Default is BulletSim
    ; physics = OpenDynamicsEngine
    ; physics = BulletSim
    ; physics = basicphysics
    ; physics = POS

What about BasicPhsics?

What about when PhysX is added?

And what about the unpredictable future when other physics related partial and complete implementations for a range of special needs (fire simulation for example) are added.

aiaustin (developer)
2015-04-14 08:41

Is there a real threat in just knowing the physics type or engine.. rather than what you can do if you know that? If there is no threat, then why not make

osGetPhysicsEngineType() and osGetPhysicsEngineName()

be "no threat, always available" ossl functions that are guaranteed to be available from the 0.8.2 (eventual) release onwards, and remove the always available osCheckODE() special case?
melanie (administrator)
2015-04-14 09:16

This isn't about threats at all, but rather about future code maintainability. All future physics engines are _required_ to be compatible with SL/Bullet.

Not allowing a default discovery mechanism is designed to prevent scripting that needs updates for every future engine.

If a future physics engine doesn't work with the same params as SL/Bullet, then it is buggy and needs to be fixed. It is the wrong philosophy to assume that scripters have the time and inclination to adapt to every new engine. The engines need to be written to be predictable and working as much identical as the underlying architecture permits.
LaniGlobal (reporter)
2015-04-14 09:41

Physics engines will always have nuances and differences. Some new engine may have a new feature. Certainly older engines will have deprecated features. Discovery of the exact "engine" that is in use is necessary. It is the same as a program needing to know whether it is running under Linux or Windows.
1derful (reporter)
2015-04-14 10:21

I'm a creator of physical vehicles in OpenSim. We need this function now. As far as ODE, I would highly suggest in leaving it as a option. More than you can imagine are still using it for its current superiority over vehicles.
LaniGlobal (reporter)
2017-07-16 11:27

This report and proposal can be closed.
An alternative method has been implemented.
The alternative implementation is not quite as good as the original one proposed, but it is certainly better than anything before.
Thank you to the dev(s) who added the new OSSL function!

See the OSSL function "OsGetPhysicsEngineName" [^]
Robert Adams (administrator)
2017-08-04 21:42

As last comment says:
This report and proposal can be closed.
An alternative method has been implemented.
The alternative implementation is not quite as good as the original one proposed, but it is certainly better than anything before.
Thank you to the dev(s) who added the new OSSL function!

See the OSSL function "OsGetPhysicsEngineName" [^]

- Issue History
Date Modified Username Field Change
2015-04-13 16:09 LaniGlobal New Issue
2015-04-13 16:18 LaniGlobal Note Added: 0028003
2015-04-13 16:21 danbanner Note Added: 0028004
2015-04-13 18:51 LaniGlobal Note Added: 0028005
2015-04-13 18:54 nebadon Note Added: 0028006
2015-04-13 18:57 LaniGlobal Note Edited: 0028005 View Revisions
2015-04-13 21:42 LaniGlobal Note Added: 0028007
2015-04-13 22:16 Robert Adams Note Added: 0028008
2015-04-13 22:30 AliciaRaven Note Added: 0028009
2015-04-13 22:42 AliciaRaven Note Added: 0028010
2015-04-13 23:52 LaniGlobal Note Added: 0028011
2015-04-13 23:54 nebadon Note Added: 0028012
2015-04-14 00:30 LaniGlobal Note Added: 0028013
2015-04-14 06:31 nebadon Note Added: 0028014
2015-04-14 08:35 aiaustin Note Added: 0028015
2015-04-14 08:41 aiaustin Note Added: 0028016
2015-04-14 08:55 LaniGlobal Summary Determine Region Physics Engine Type by LSL Script Function => Discover Region Physics Engine Type by LSL Script Function
2015-04-14 09:16 melanie Note Added: 0028017
2015-04-14 09:41 LaniGlobal Note Added: 0028018
2015-04-14 10:21 1derful Note Added: 0028019
2015-04-14 13:36 aiaustin Note Edited: 0028015 View Revisions
2017-07-16 11:27 LaniGlobal Note Added: 0032153
2017-08-04 21:42 Robert Adams Note Added: 0032233
2017-08-04 21:42 Robert Adams Status new => resolved
2017-08-04 21:42 Robert Adams Fixed in Version => 0.9.0
2017-08-04 21:42 Robert Adams Resolution open => fixed
2017-08-04 21:42 Robert Adams Assigned To => Robert Adams
2017-08-04 21:42 Robert Adams Status resolved => closed

Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker