Guild of Writers

I have these bowling pins in my age that currently use a box collider shape. Why? Because they won't stand up if I use a triangle mesh or a convex hull.

I want to change this so that the pins use a custom collider geometry that allows them to roll around like pins. The trick is getting the visual pin mesh and the collider mesh linked so that they move together.

I tried having the collider a child of the visuals, then the visuals a child of the collider. Neither one worked - I pass right through the pin.

Has anyone tried something like this for a dynamic object? If so, how did you get your custom collider linked up properly?

[EDIT] I took a look at the Gira baskets, in order to see what should happen.

The visible Gira basket scene object has a plCoordinateInterface with the collider's plCoordinateInterface as its child. The child plCoordinateInterface has LocalToParent and ParentToLocal set to the identity matrix, and it has the kCanEverDelayTransform and kDelayedTransformEval flags set.

The visible Gira basket scene object has the plSimulationInterface containing the plGeneralPhysical with the custom collider geometry; it was taken from the collider scene object, which has no simulation interface.

Looks like the plugin code needs to have the following modifications:
- When a parent object does not have bounds specified, but a child object does, the parent should obtain the plSimulationInterface from the child
- When an object is a child, its LocalToParent and ParentToLocal matrices should be set to identity, and its kCanEverDelayTransform and kDelayedTransformEval flags should be set

I'll see if these changes work...

I seem to recall there being some particular method of creating a "proxy collider" in pyprp, which would create the collision mesh in the prp the same way cyan kickables look, which is that the simulationInterface/physical on a sceneObject with a drawInterface simply contains a mesh that doesn't match the visual mesh in blender. (when you do the parenting thing, it creates multiple sceneObjects and applies only a simulationInterface to one, and only a drawInterface to the other, which is rather wasteful)

It seems to me that the parenting of the physical mesh object to the drawable mesh should work, as long as you ensure that they're both actors, but it should be possible to just get a separate source for the physical export. (if you want to go the crazy hacky route, you could create some physicals, and some drawables, and then with libplasma, remove the sceneObjects pointing to the physicals and link the drawable only sceneObjects to the physicals. >_>)

You can set the textproperty [b]collider-for[b] on the collider object and give it the name of the visual object. PyPRP will export your custom collider as the collider of the visual object.

OK - I tried the "collider-for" string property, adding that to each collider child of the visible parent, making sure that the parent and child were both actors. However, when I link into the age, URU crashes.

In the meantime, I've implemented those changes to prp_ObjClasses.py, and it works! The child's plSimulationInterface is transferred to the parent, and the child's plCoordinateInterface's LocalToParent matrices are set to the identity, and the two flags are set as well.

Strike! Show Spoiler

strike.png (30.77 KiB) Viewed 3456 times

I've placed the new file in my subdirectory of the contrib folder:

http://svn.guildofwriters.com/pyprp/con ... Classes.py

In order for this code to activate:

- The parent must be an actor, as well as the child
- The child must have bounds and be dynamic; the parent must not have bounds set

Hmm, can something similar be done for shadowcasting geometry, perhaps?
(although maybe the complexity of the surface the shadow is cast upon is more relevant to system load than that of the occluding one...?)

Having just spent a week investigating shadows, let me say this: Shadows a screwed up part of Plasma.

I sense a recurring theme... :9

Robert, can I assume that you've followed the release discussion closely enough that if you considered this contribution a candidate for inclusion into the release, you'd have added it to the corresponding list on your own? We have not reached feature freeze yet, as far as I'm concerned.

Oh - I thought we did a feature freeze already!

In that case, I'll add it to the candidate list...

[EDIT] Feature added to list and chart. Still needs documentation, though.

I just experimented with this a bit and in the end had a working kickable with different visible and physical shapes, without using Robert's addition.

Here's the setup:

• The visible shape has Actor and no other special settings.
• The physical shape has Actor, Bounds = Triangle Mesh, Dynamic, Mass = 1.0, rc = 5.0, el = 0.5, type = collider, collider-for = NameOfTheVisibleObject
• No parenting

Does that mean Robert's way is superfluous?