[Opensim-dev] Redesigning the Physics-Interface

Gerhard Dünnebeil Gerhard.Duennebeil at chello.at
Sat Nov 22 15:48:25 UTC 2008


A big leap in the right direction i think.

Just one question: When you delete a physics entity you are aware that 
certain properties must survive this (e.g. settings from LSL scripts)?

Simply delete and reconstruct might be a bit soo simple.

But otherwise: +1

Gerhard



Melanie wrote:
> Hi,
>
> I was planning to do that. The idea is to create / delete / modify 
> physical composition from creation, linking, and deletion only.
> E.g. CreatePhysicsActor(IEntity), RemovePhysicsActor(IEntity), where 
> IEntity is a root entity (e.g. not a child of anything).
> Link would delete the old physics actor and then create a new one 
> from scratch after linking.
>
> Melanie
>
>
> Gerhard Dünnebeil wrote:
>   
>> Stefan,
>>
>> sure, you are completely right.
>>
>> But you should understand the ideas of the ODE. ODE knows about bodies 
>> and geometries.
>>
>> A body is something that has a mass and can move over time.
>> A geometry describes the collision behaviour of a body but is a distinct 
>> concept and the coupling is loose (means you can have bodies without a 
>> geometry and geometries without a body).
>>
>> An object without a geometry won't collide. If this is something 
>> meaningful is another discussion.
>>
>> A geometry without an object won't move on a collision. This is a static 
>> object in SL speak.
>>
>> It is possible to add more than one(!) geometry to one body thus 
>> composing an object with a complex geometry but behaving as one rigid 
>> entity.
>>
>> Currently we create one geometry and one body for each prim. That is -- 
>> as far as I understand things -- part of the instability problems. 
>> Trying to fix that lead me into a situation where I have to reconstruct 
>> the parent/child relationship from a lot of calls to the API. This leads 
>> to situations where a child prim is created first -- with a geometry and 
>> a body -- then linked to a parent so the body is destroyed again, ......
>>
>> This is not only inefficient but very complex and error prone.
>>
>> Things would be much easier if linked objects would be given to the 
>> physics API as such. After all we want them to behave as exactly that: 
>> one object.
>>
>> Look at the new approach, you'll find an Orwell situation "each thing is 
>> entity but some are more entity than others" as the current approach 
>> also knows a hierachical relation ship.
>> I just propose, this hierarchy is given to the phys engine in a 
>> convenient way as well.
>>
>> So "Or, would IEntity have a 'composite mesh' that is a combination of 
>> all child meshes?" Not exactly but in a more lenient way of looking at 
>> it, you are correct.
>>  
>>
>> Best regards
>> Gerhard
>>
>>
>>
>> Stefan Andersson wrote:
>>     
>>> Errr... actually, aren't we going the exact opposite direction, with 
>>> the 'everything is IEntity' approach?
>>>
>>> Or, would IEntity have a 'composite mesh' that is a combination of all 
>>> child meshes?
>>>  
>>> I guess, to be able to collide with a child, you would still have to 
>>> retain it as a separate mesh entity?
>>>
>>> Best regards,
>>> Stefan Andersson
>>> Tribal Media AB
>>>  
>>> Join the 3d web revolution : http://tribalnet.se/
>>>  
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> Date: Sat, 22 Nov 2008 06:44:44 -0600
>>> From: james.stallings at gmail.com
>>> To: opensim-dev at lists.berlios.de
>>> Subject: Re: [Opensim-dev] Redesigning the Physics-Interface
>>>
>>> Hello Gerhard :D
>>>
>>> Unless I am sadly mistaken, something of the sort is currently in 
>>> progress.
>>>
>>> Cheers,
>>> James
>>>
>>>
>>> On Sat, Nov 22, 2008 at 6:37 AM, Gerhard Dünnebeil 
>>> <Gerhard.Duennebeil at chello.at <mailto:Gerhard.Duennebeil at chello.at>> 
>>> wrote:
>>>
>>>     Hi
>>>
>>>     this is the start of a discussion about the interface to the physics
>>>     plugins.
>>>
>>>     After having tried working on the ODE plugin, specially focussed on
>>>     linked objects I think the current interface has a severe short
>>>     coming.
>>>
>>>     The problem I see is, that it is prim orientated while an object
>>>     orientation would better suit the needs.
>>>
>>>     Why is it so?
>>>
>>>     Currently it seems to me, the information is given to the phys engine
>>>     prim by prim. Any object information is only given in fragments.
>>>     This leads to the situation that the object relations must be
>>>     reconstructed by the phys engine and it often leads to the situation
>>>     that individual prims get constructed and shortly after get destructed
>>>     again as it turns out that the respective prim is part of a larger
>>>     link set.
>>>
>>>     For that reason I ask your thoughts about a redesign of that
>>>     interface.
>>>
>>>     Best regards
>>>     Gerhard
>>>
>>>     _______________________________________________
>>>     Opensim-dev mailing list
>>>     Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>
>>>     https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>
>>>
>>>
>>>
>>> -- 
>>> ===================================
>>> The wind
>>> scours the earth for prayers
>>> The night obscures them
>>>
>>> http://osgrid.org <http://osgrid.org/>
>>> http://del.icio.us/SPQR
>>> http://twitter.com/jstallings2
>>> http://www.linkedin.com/pub/5/770/a49
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> 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
>
>   




More information about the Opensim-dev mailing list