OK. 1.5 ! hurrah!
I actually wasn’t going to aim for trimeshes quite yet anyway. Convex polyhedra first. We could stitch a load of convex polyhydra together with fixed joints to form arbitary shapes. anyway. I am thinkning I am getting there now…
what is better anyway, multiple bodies tied together with fixed joints or a single body with multiple geometries encapsulated in GeomTransforms?
In current ODEJava the second version is better - but lets see how it’ll be with JOODE.
Oh yeah. Of course. Multiple geometries on one body. I am not really worrying about the details yet…
Would developers like me to use the requests-bug-assignment-thingamyjig and assign work? I think it would help greatly with making sure people don’t attack the same problem, and also be a great way for people to see what needs to be done. The drawbacks are it is a bit heavy weight and the pages take a long time to load.
There is no point me spending ages filling it up with tasks if people are not going to spend the time crossing out the tasks as they are done. I personally think it would be a good idea.
Things that I think need doing next currently are:
Box-Box collisions
Slider joint, Ball joint then hinge joint (these should be very easy to fill in, also make sure each joint is not requesting feedback by default)
Refactor out the vtable nonsense in the joints (not urgent, medium difficulty)
Quickstep (big task!)
FastLCP(bigger task, also requires refactoring the common interface between it and SlowLCP, very useful to do becuase only the FastLCP algorithm can provides joint feedback functionality)
We need a test that also destroys bodies and geometries becuase that code is untested at the moment.
I am working on convex trimesh collisions. I have the outline of the implementation sorted now. I know how to do the problem and I have just started implementing it. I think I will manage approximatly O(n^2) where n is the number of vertices involved. I have read papers that can do it in almost linear time but they are way complicated.
I am away this weekend.
Good idea, I’ll fill in tasks now…
and then I’ll see, what I’ll tackle next.
I’m currently trying to implement Box to Box collisions and I have to implement a collision specific function that’s probably also needed by other Collisions (I don’t know), I’ve now implemented it into Colliders, but it actually does math and should from that context belong to MathUtils. So: should I keep it in Colliders, or should I move it to MathUtils?
Here’s just one thing we could do better than ODE.
May we do something like :
- Body can “move/control” either a Geom, either a GeomGroup
- GeomGroup is a class and not an ugly system like in ODE
It’s a minor change, but it seems a way more natural to me.
Can you explain it a bit more, I haven’t understood it yet, what you’re talking about.
Are you saying, that it should be more build like a scenegraph? Like the position of the Geom doesn’t have to be the position of the Body, it can e.g. be translated like with GeomTransform relative to the BodyS origin, and you can have GeomGroupS that contain different GeomS?
Should GeomGroup extend Geom?
I think posting a TODO list would be quite useful. I wasn’t sure where to go next after working with the Mass class.
I’m not sure when I’ll have time to work on it again, but I’ll take another look when I can.
I made one: https://sourceforge.net/tracker/?atid=782659&group_id=151965&func=browse
I think this is the best place, because then it’s easy to extend.
I tried to do BoxBoxCollisions, but it doesn’t work yet (I hate pointers, grr…) I’ll commit the code anyways, maybe someone does find the error. The error seems to be in the new by me implemented Colliders.intersectRectQuad
Yes, a bit like a scenegraph, but maybe GeomTransform isn’t necessary, if we have static joint… I don’t think GeomGroup should extends Geom
but how should static joint be implemented, so it doesn’t show the behavior we’ve now got in ODEJava?
We wouldn’t be able to use the joint system that’s currently used by odejava (simply applying forces to correct the joint), because then a change of one geom of such a static joint will only influence the other geom in the next step. I believe this is different with GeomTransforms - making GeomTransforms better.
I do not really understand this debate.
By static joints do you mean joints that can be attached to other joints so that you can link one body to another body via a chain of multiple joints?
Geometry has nothing to do with the joint system.
Geoms are classes at the moment.
I was thinking myself when I have used ODE that GeomTransform is a bit of a naff way of dealing with indirection. I am not sure how much work it would be to do it properly and whether there would be all that much benifits.
[quote]Body can “move/control” either a Geom, either a GeomGroup
[/quote]
So you want the geom transforms to be mallable? I think that is a no brainer to implement, and would be very useful functionality.
As for GeomGroups I don’t think it is really fundamental functionality. If we made GeomTransforms changeable then it would not take a user much to alter multiple geomTransforms themselves in one go, to me the functionality looks like a convenience method. Which is no bad thing, but I don’t think convinience should be catered for until the API is stabalized.
I will add GeomTransforms to the todo list…
[quote]I do not really understand this debate.
By static joints do you mean joints that can be attached to other joints so that you can link one body to another body via a chain of multiple joints?
Geometry has nothing to do with the joint system.
[/quote]
I think we were talking here about JointFixed. So it would be an alternate way of dealing with multiple Geoms inside one Body. And then it has to do with Geometry.
[quote]So you want the geom transforms to be mallable? I think that is a no brainer to implement, and would be very useful functionality.
[/quote]
Now I don’t understand that.
[quote]As for GeomGroups I don’t think it is really fundamental functionality. If we made GeomTransforms changeable then it would not take a user much to alter multiple geomTransforms themselves in one go, to me the functionality looks like a convenience method. Which is no bad thing, but I don’t think convinience should be catered for until the API is stabalized.
[/quote]
You want to change the Body during Runtime? Is that wise? Joints should be used for such things!
But to get over the GeomTransformBusiness - until now it’s something like this: The Geom’s position is the same like the Body’s position. Why don’t we save the Geom’s position relative to the Body and if this relative position and rotation is inequal to (0|0|0) and Matrix.Identity we deal with it as if there were a GeomTransform.
We would then ofcourse have to change all the direct acessing of the Geom’s position and rotation.
[quote]I think we were talking here about JointFixed. So it would be an alternate way of dealing with multiple Geoms inside one Body. And then it has to do with Geometry.
[/quote]
Joint fixed is implemented in ODE and ODEjava (and it works in ODEjava), it allows bodies to be fixed relative to one another. If a set of geoms are attached to one body then they are automatically fixed relative to one another. Joints have nothing to do with geometry.
Now I don’t understand that.
[/quote]
That was in response to:-
[quote] - Body can “move/control” either a Geom, either a GeomGroup
[/quote]
At the moment you can set a Geoms position relative to a body using a GeomTransform, but I am not sure you can change it once it is up and running. MagicSpark seems to want to be able to move a geom relative to a body a sim time.
[quote]But to get over the GeomTransformBusiness - until now it’s something like this: The Geom’s position is the same like the Body’s position. Why don’t we save the Geom’s position relative to the Body and if this relative position and rotation is inequal to (0|0|0) and Matrix.Identity we deal with it as if there were a GeomTransform.
[/quote]
that is fine for the case when geoms are attached to bodies, but what about when geoms are static?
Joint fixed is implemented in ODE and ODEjava (and it works in ODEjava), it allows bodies to be fixed relative to one another. If a set of geoms are attached to one body then they are automatically fixed relative to one another. Joints have nothing to do with geometry.
[/quote]
Yes. It works, but how well - wasn’t there once a topic, where Bodies attached with fixed joints started to oscilate. See http://www.java-gaming.org/forums/index.php?topic=9822.0
that is fine for the case when geoms are attached to bodies, but what about when geoms are static?
[/quote]
Then you can set the position directly for the geom. I’ve never had issues with that.
[quote]Yes. It works, but how well - wasn’t there once a topic, where Bodies attached with fixed joints started to oscilate. See http://www.java-gaming.org/forums/index.php?topic=9822.0
[/quote]
Well I have had situations like that in my simulation. Its normally a matter of scaling the mass or fixing the joint at the right time or tons of other things. I have used fixed joints before quite well in my simulations. It is not advised becuase it takes extra computation to enforce the joint integrety and gives more possibilities for the LCP algorithm to fail. But JointFixed do have their uses in enforcing temporary constraints on bodies. To do this without JointFixed would be quite tricky. If two bodies are to be joined with a virtual jointFixed you would need to
- record the positions of the bodies and their geoms
- remove one body from simulation
- adjust the remaining bodies mass by the removed mass (we can actually do that now with the new mass functions!)
- moved the goems of the one body to the other (possibly having to create GeomTransforms to do so)
Then when you would want to release the body you would need to go back to the prerecorded situation.
This is alot more complex when you imagine that this could happen multiple times and could be undone in any order.
I spose the introduction of a CompositeBody might be the answer. If a Body is JointFixed to another body, create a CompositeBody from the two (that has 2 parts). If a Body is JointFixed to another CompositeBody the add the Body to the Composites primatives etc.
Still… you have all the Joints to deal with as well as the Geoms.
This is what I wanted to introduce when I talked about “GeomGroup”, but, err… it’s a bit more logic to do “BodyGroup(s)”, you’re right (or CompositeBody if you want).
Ahh now I understand 