Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.
Posted 07 March 2011 - 12:44 PM
Posted 07 March 2011 - 02:21 PM
This is still an early version, but I'd definitely appreciate any and all comments. I am also curious to know what those who have more experience with developing rigid body dynamics engines may think about this approach, and what their views are on the general problem.
Posted 07 March 2011 - 02:48 PM
As for the actual idea, seems 'way out there' in terms of concept Because nearly everything is polyhedral in games (with a few spherical exceptions) in terms of collision detection, it seems like converting to frequency space with all the associated ringing problems there in would be counter intuitive...
Can you summarise the main advantages of your technique?
Cheers, Paul.
Posted 08 March 2011 - 10:07 AM
Posted 08 March 2011 - 10:43 AM
Posted 08 March 2011 - 12:30 PM
I do have some concerns though; maybe you can address them.
The biggest of these is that the functions you use to represent solids seem kind of pathological. In particular, they have zero derivative at the boundary of their support. This seems at odds with the idea of differentiating them to determine e.g. contact normals. It's precisely when you need the most information about the normals to the level sets that the gradient of the bump function stops giving you any information. Isn't this problematic?
Posted 08 March 2011 - 01:05 PM
Posted 08 March 2011 - 01:12 PM
To be honest, I didn't read the paper really. I just kind of skimmed it and read your posts.
It's an interesting idea, but have you compared it to just approximating objects with a sphere tree? The last current gen game I worked on basically just represented each object as a collection of spheres (don't even remember if we bothered with a tree..). This is also an approximation of the actual shape, but it's trivial to scale/rotate/translate and it's very predictable and easily controlled. So I think for your work to be taken seriously, you really should make some speed comparisons to sphere tree (or any bounding volume hierarchy) collision - in 3D.
Posted 08 March 2011 - 01:36 PM
To be honest, I didn't read the paper really. I just kind of skimmed it and read your posts.
It's an interesting idea, but have you compared it to just approximating objects with a sphere tree? The last current gen game I worked on basically just represented each object as a collection of spheres (don't even remember if we bothered with a tree..). This is also an approximation of the actual shape, but it's trivial to scale/rotate/translate and it's very predictable and easily controlled. So I think for your work to be taken seriously, you really should make some speed comparisons to sphere tree (or any bounding volume hierarchy) collision - in 3D.
Well, it is not exactly the same thing as approximating your object as a sphere. It is basically like taking your object then offsetting it with a sphere. Also rotations and translations are really easy to do in this method too, (though scaling is currently more problematic). So in this way, I don't really see why it would be less predictable. But you are right, I think that adding some speed comparisons would be a good idea. Do you know of any good commercial code/benchmarks for doing sphere tree intersections of objects?
Posted 08 March 2011 - 02:26 PM
Oh, definitely, the derivative exists. It's that it's zero that bugs me. At the boundary, your constraint Jacobian is just a row of zeros. That makes it seem hard to resolve collisions. In what direction should my configuration-space particle bounce?1. The derivative at the boundary always exists, since it is formed from the convolution of two continuous functions.
This may address that concern; I'd need to reread that section of your paper.2. Since we end up actually low pass filtering the objects, (see below), the level set defining the boundary of the configuration space obstacle turns out to be a smooth curve and so it always has a well defined tangent and normal direction (ie it will not be 0 anywhere).
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.
GameDev.net™, the GameDev.net logo, and GDNet™ are trademarks of GameDev.net, LLC.