For this kind of approach, the type of data that needs to be passed to ODE is joint information. Joint information can be divided into 2 types: spatial and non-spatial. <br><br>Spatial joint information is specified by positioning a dummy object in 3D space and giving it a special name, currently either "hingejoint" or "balljoint", which correspond to 2 ODE joint types. For instance, the position and orientation (of the X-axis) in 3D space of an object named "hingejoint" specifies the hinge anchor and hinge axis, to use ODE terminology.<br>
<br>Non-spatial joint information currently only includes the joint type and the bodies that the joint connects, but needs to be expanded to include things like joint stops, joint ERP/CFM, etc. This information is stored in the name and description fields of the dummy joint object. The joint type is specified in the prim name; the bodies that the joint connects are specified in the description field. All body parts within an assembly must be uniquely-named to avoid ambiguity in the joint specification.<br>
<br>A new OSSL command changes into physical objects the currently selected objects. Prims that form parts of the jointed assembly are simply turned physical as normal. Joints are handled last after all parts have been created, and the component parts are looked up and linked with an ODE joint.<br>
<br>OpenSim knows nothing about the ODE joint, so it isn't persisted. The joint, invisible to OpenSim, still exists in ODE and constrains the motion of the parts connected by the joint. If you delete a body, the joint will still exist "in limbo" and will not get deleted, since the joints aren't being kept track of explicitly. There is no way currently to see, change, or even know about the existence of the joint.<br>
<br>Clearly there are many issues to solve to make this cleaner. I think one of the first questions to answer is how and where to store joint-related information. As I said, I'm using a dummy object in 3D space to specify the joint spatial parameters, and the name/description fields to specify non-spatial information. I think using the dummy object is a good idea, but using the name and description fields is not good. I'm not sure about how best to add custom information to a prim. How about a notecard in the prim inventory containing some sort of joint configuration information? Would that be okay, or is there a better way?<br>
<br>Thanks,<br>
N Lin (nlin)<br><br><div class="gmail_quote">2008/11/19 Frisby, Adam <span dir="ltr"><<a href="mailto:adam@deepthink.com.au">adam@deepthink.com.au</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">









<div link="blue" vlink="purple" lang="EN-AU">

<div>

<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">This is very cool – </span></p>

<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>

<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">How are you assigning vehicle parameters, etc?</span></p>

<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>

<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">Adam</span></p>

<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p><br></div></div><a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank"></a><br>
<br></blockquote></div><br>