Physics Modeling - Java3D suitability

Engines, Libraries and Tools Java 3D
#1

Hi there,

I have a question on Java 3D’s applicability on a project I’m soon to embark upon. I need to do some physics modeling/simulation of cloths using a mass spring system (with some colision detection). Since I’ve yet to learn Java 3D I was thinking this might be a good time for that.

I’ve perused the docs a bit, and it seems it might be suitable for such a project (by using GeometryArray for instance). My question is thus, would Java 3D be suitable for such an endevaour or is it too high-level? I have also been comtemplating using JOGL, but with Java 3D all the basic stuff is taken care of (like matrix and vector classes, quaternions etc), and I can focus on the physics part.

Any opinions and comments are velcome. Thanks.

#2

Java3D is quick and easy for representing a 3D scene. If you’re doing physics I would keep the physics implementation well away from the 3D stuff (so for example don’t use Java3D to calculate when and where things have collided) and just use the physics to update the 3D scene as and when changes occur.

#3

This is probably OT for this thread but…

Physics libraries can be thought of as big black boxes…feed data in about forces and torques, out comes new positions and rotations in world coordinates. The problem is actually feeding the scenegraph with the new transforms while still maintaining a nice heirarchy for culling and all sorts of nice optimisations. Anyone have any cool special algorithms to do that ?

DP

#4

The counter example is Shawn Kendall at IMI, who Cosmic Racer uses a rigid physics system that is directly driven off of the
Java3D scene graph structure. The advantages are as follows:

(a) Cannot get out of synch with rendered data. (Removes whole classes of potential bugs.)
(b) Uses the Java3D bounding system for hirearchical bounding volumes. (Less coding, already optimized for the
J3D structures and update path, again less likely to get out of synch.)
© Less memory usage (you arent representing your geometry twice in two diffferent ways.)

He still does his own final tri v. tri collision and penetration depth calculation.

i dont THINK Im giving away any trade secrets by revealing this much,

#5

Btw… Shawn did a Jakobsen soft body physics model in Java3D more then 2 years ago with some fairly sophistcated exampels (one was in fact cloth) so its definitely doable.

#6

That’s very interesting- I’d always been lead to believe it was likely to be safer to keep them separate…

#7

Would you mind explaining more about this? how exactly is it “driven off”. You need to exachange transformation data between the physics layer and the graphics layer. (Ofcourse, if the physics and the graphics are using the same math classes, you could just pass a pointer to the tranform). But my question is still valid, how do you keep a tight scenegraph while allowing free movement ?

Cosmic Racer (as far as physics examples go) is pretty simple, but if you look at some of the videos by Artificial Stuidos and what they do with their physics, thousands of dynamic objects everywhere that can literally move from one end of the level to the next. How do you keep a clean and tight scenegraph so that the frustum culling is effecient in these cases?

DP

#8

Ooi, wasn’t the game called Cosmic Birdie?

Kev

#9

A while back, I did some research on collision detection and briefly considered using the scene graph as the bounding volume hierarchy (BVH). [A BVH is used during a broad phase of collision detection to more quickly prune away distance objects from collision consideration. Other tighter volumes up to and including the actual geometry are typically used in the narrow phase.]. There are many ways to create a BVH depending on the application (binary trees, n-ary trees, spheres, axis aligned boxes, oriented bounding boxes, etc. Since the BVH is used for the broad phase of collision detection and my situation (a particle system) could involve many shapes, I elected to go with a separate axis aligned box BVH. This was mostly because the particles could have little or no locality coherence (they could go anywhere). I also elected to use ‘subtree volume’ as the cost function to determine how to build the BVH for the same reasons. If an application has a relatively static scene, then the scene graph seems like it could double as a fine BVH. It has a collision bounds at each level and already has a tree structure. Ultimately, the decision is primarly about the perfomance of the collision detection.

Mike

#10

Ah ok, so you are using the bounding volume heirarchy to do wide area collision detection? Nice…

Why doesn’t any physics engine out there at the moment do that? They all have their own weird way of dividing up the universe (im thinking Spaces for ODE) for collision detection. Looks like ive found myself something to code for a few days :slight_smile:

But the question still remains, once that dynamic object has traveled across the scenegraph, how do you stop the bounding heirarchy severly overlapping itself…maybe some PhD student should write a dissertation about it

DP

#11

DP,
I was trying to justify the possibility that using the scene graph as a basis for the BVH was reasonable for applications with relatively static scenes. I have no first hand knowledge that IMI did what I described (sorry if that was not clear). My physics stuff does the weird stuff (with axis-aligned bounding boxes (AABB) and a binary tree). Java3D does not reveal a BVH, so one would have to manage the volumes within the application (presumably with BoundingBox and the collision bounds) using the scene graph.

The severely overlapping volumes is a common issue in a BVH implementation. Because I selected ‘minimum added volume’ as the cost function to determine the ‘best’ tree location, the tree does need to be rebuilt occasionally if the objects are long lived.

Entire books have been written the subject.

Mike

#12

Got a few links that are specific to my question? Im interested in that area at the moment…

DP

#13

“Five Balltree Construction Algorithms,” Technical Report TR-89-063, International Computer Science Institute, Berkeley, CA, November 1989. [http://http.icsi.berkeley.edu/ftp/global/pub/techreports/1989/tr-89-063.pdf]

"Using Dynamic Bounding Volume Hierarchies To Improve Efficiency of Rigid Body Simulations’, Robert Webb and Mike Gigante.
[http://portal.acm.org/citation.cfm?id=135556&dl=ACM&coll=ACM&CFID=74193598&CFTOKEN=33406427]. I had to order a hardcopy (cannot find an online version).

Google ‘Gino Van De Bergen’

Mike

#14

That is incorrect. Java3D does have and exposes the BVH (bounding volume heirarchy) and we use it in our traversal down to the shape level. Then at the point we added addition partitioning down to the triangle. This way we could use as much of the J3D graph as possible AND it makes it easy on the artist since most of the time the collision geometry is the same as the visual geoemtry.
Another reason we did this is because you can deform the geometry in our engine, so we had to manipulate the J3D shapes. In that case you really want the visual and collision to be one in the same. [quote]
[/quote]

#15

That’s interesting. When I asked earlier, the answer was no. See http://forums.java.net/jive/thread.jspa?forumID=70&threadID=4723&messageID=42803#42803. I would not call the scene graph the BVH. Is that our difference?

Mike

#16

Perhaps they were confusing what you wanted with the Java3D internal BINARY tree that is used for culling.

Every node in the Java3D graph has a bounding geometry (usually a sphere for each grouping node, and a box for each Shape3D). We are using those exact bounds to traverse the graph looking for collision (we even do some caching and manipulations of those bounds). Shoot, our system even inverse transforms into local Shape3D space to do the bounds test on the Local axis aligned box (which is oriented in global space) It works great, I love it ;-).

Who is Jada that made that response?

Oh I see it’s Chien.
He must have misunderstood your question :slight_smile:

#17

This sounds very interesting … maybe you should write a paper? :slight_smile:

#18

The best I can offer right now is my blog :slight_smile:

#19

I think it depends on the purpose of the physics modeling. Sometimes physics modeling is used to enhance the visual experence and sometimes it’s used to learn more about physics. In the first case it’s probably no harm in integrating the physics quite tightly with the scenegraph, but in the other it’s definately a mistake.

Also note the emerging physics cards. To be able to use them I guess its not a good idea to intertwine the physics modeling to much with Java3D.