Hmm looks interesting but how can one detect when an InstanceObject3D is touched?
By default the mesh of an InstanceObject3D is not touched by IBR. If you do alter the mesh data, you already have access to the Mesh / Object3D as you've altered the vertices / uvs. If you do alter the mesh, note that it will affect all instances as it uses a shared mesh. If you need to get the Object3D of an InstanceObject3D type, use the InstanceManager.getObject3DOfInstanceType().
As for the transform matrices of the InstanceObject3D, by default it does a sort of lazy-transformations. Any time you do a scale/translation/rotation, it sets a protected boolean changed to true. On call of getTransformMatrix(), it will re-create the transform matrix if changed==true, otherwise it just returns the previously calculated transform matrix. getTransformMatrix() get called when rendering each instance (every frame). I have added a method to the code called hasChanged(), which will return true if there has been a translate, scale or rotation since last getTransformMatrix(). I hope this answers your question.
Another question, does the order in which the InstanceObject3D's are drawn matter?
It can, and Egon may be able to better explain some of this. It should only matter if your Object3D uses transparency or you set the OpenGL to disable the depth test, in which case it will render in synchronous order. To put it simply, I don't believe transparency InstanceObject3D's are going to play nicely with other transparent Object3D's, other transparent InstanceObject3D types, or overlaps of the multiple IntanceObject3D of that type. I believe jPCT has software-side ordering (based off the Object3D's origin distance from camera?) when it comes to transparent objects, and the transparent objects are rendered last as transparency requires the solid pixels behind it for the different pixel write modes (add, modulate, blend, etc...). Because all Object3D's for this method are stacked a certain distance from the camera, they will be picked up by jPCT render pipeline in regards to that distance from the camera. All InstanceObject3D's that are rendered would be synchronously rendered on top of one another according to the order when added. I could add simple sorting, but it won't solve all problems, as transparency is a complex subject that requires work arounds and tweaks for speed. But it will never work great with IBR as the distance from the camera will mess up jPCT's sorting order.
Egon, did I miss anything or is anything inaccurate?