## Re: [Algorithms] Approximating collision times

 Re: [Algorithms] Approximating collision times From: Mark Wayland - 2002-12-28 13:27:31 ```We use moving swept volume collisions - sphere-sphere, sphere-triangle, triangle-triangle, edge-edge etc. These were used in Carmageddon TDR2000 on the PC, where all the static collision geometry was triangle soup... no boxes or spheres etc. This was mainly due to art pipeline (keeping graphics in sync with collision) issues - something you all should think about ;-) Cheers, Mark ----- Original Message ----- From: "Adam Paul Coates" To: Sent: Saturday, December 28, 2002 2:43 PM Subject: [Algorithms] Approximating collision times > Hey all, > > Back to cracking away on some physics code and was wondering if > anyone had tips on computing approximate collision times. Right now, the > system steps by about 1/100 second slices and then computes the contact > plane using some specialized code. The problem is that the contact plane > is really inaccurate if the objects aren't nearly "just touching". Since > it's something I'll need to do anyway to handle fast objects (or even just > as a speed bump) I'd like to implement a slightly "smarter" predictive > scheme for integrating - i.e., integrate up to a point "near" collision > time and do the contact plane computation then. > Does everyone use bisection for this? I've done that before, and > never really got "nice" results. The separation distance along the > separating axis is available, and it seems like some insight from > continuous CD would solve this. Does anyone do this currently, or is this > probably going to be slower than bisection? Stephane Redon's work uses > screwings to compute the time explicitly, but I'm not sure if all of that > is necessary for this. > Any tips or success/horror stories are welcome. > > Kudos in advance (lol...just realized the abbreviation for that is KIA.. > :( > > Adam C. > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > GDAlgorithms-list mailing list > GDAlgorithms-list@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 ```

 [Algorithms] sorting objects From: Raymond L. Maple - 2002-12-05 08:30:29 Attachments: Message as HTML ```Hello! I have a problem and was wondering if you guys could give me = some insight. The game I'm working has a split screen so two players = can play against each other on the same system. The problem I'm having = is with the rendering of objects. I need to sort the object with an = alpha channel back to front so they'll render correctly. So I need to = do two sorts of my renderable objects, one for each camera view. My = question is how do you set up the rendering portion of your application = to do this. Do you use some sort of bucket like scheme and drop = particles, models, billboards into the buckets that are sorted back to = front. I not sure if I should call each game object and check its = distance from the camera and sort the game objects in some list then = iterate over them calling render() for each. I don't have a huge = problem with just sorting models (I think) but when you have effects = (particles, billboards, streaks) in the mix I'm not exactly sure how I = should do it. Any ideas would be appreciated. Thanks, Raymond```
 Re: [Algorithms] sorting objects From: Odin Jensen - 2002-12-05 09:14:37 ```At 00:40 05-12-2002 -0800, you wrote: >Hello! I have a problem and was wondering if you guys could give me some >insight. The game I'm working has a split screen so two players can play >against each other on the same system. The problem I'm having is with the >rendering of objects. I need to sort the object with an alpha channel >back to front so they'll render correctly. So I need to do two sorts of >my renderable objects, one for each camera view. My question is how do >you set up the rendering portion of your application to do this. Do you >use some sort of bucket like scheme and drop particles, models, billboards >into the buckets that are sorted back to front. I not sure if I should >call each game object and check its distance from the camera and sort the >game objects in some list then iterate over them calling render() for >each. I don't have a huge problem with just sorting models (I think) but >when you have effects (particles, billboards, streaks) in the mix I'm not >exactly sure how I should do it. Any ideas would be appreciated. > > Thanks, > Raymond A bucket sort based on z-distance usually worked well for me using the center of each surface/poly for the z value. Odin ```
 [Algorithms] Approximating collision times From: Adam Paul Coates - 2002-12-28 03:43:44 ```Hey all, Back to cracking away on some physics code and was wondering if anyone had tips on computing approximate collision times. Right now, the system steps by about 1/100 second slices and then computes the contact plane using some specialized code. The problem is that the contact plane is really inaccurate if the objects aren't nearly "just touching". Since it's something I'll need to do anyway to handle fast objects (or even just as a speed bump) I'd like to implement a slightly "smarter" predictive scheme for integrating - i.e., integrate up to a point "near" collision time and do the contact plane computation then. Does everyone use bisection for this? I've done that before, and never really got "nice" results. The separation distance along the separating axis is available, and it seems like some insight from continuous CD would solve this. Does anyone do this currently, or is this probably going to be slower than bisection? Stephane Redon's work uses screwings to compute the time explicitly, but I'm not sure if all of that is necessary for this. Any tips or success/horror stories are welcome. Kudos in advance (lol...just realized the abbreviation for that is KIA.. :( Adam C. ```
 Re: [Algorithms] Approximating collision times From: Mark Wayland - 2002-12-28 13:27:31 ```We use moving swept volume collisions - sphere-sphere, sphere-triangle, triangle-triangle, edge-edge etc. These were used in Carmageddon TDR2000 on the PC, where all the static collision geometry was triangle soup... no boxes or spheres etc. This was mainly due to art pipeline (keeping graphics in sync with collision) issues - something you all should think about ;-) Cheers, Mark ----- Original Message ----- From: "Adam Paul Coates" To: Sent: Saturday, December 28, 2002 2:43 PM Subject: [Algorithms] Approximating collision times > Hey all, > > Back to cracking away on some physics code and was wondering if > anyone had tips on computing approximate collision times. Right now, the > system steps by about 1/100 second slices and then computes the contact > plane using some specialized code. The problem is that the contact plane > is really inaccurate if the objects aren't nearly "just touching". Since > it's something I'll need to do anyway to handle fast objects (or even just > as a speed bump) I'd like to implement a slightly "smarter" predictive > scheme for integrating - i.e., integrate up to a point "near" collision > time and do the contact plane computation then. > Does everyone use bisection for this? I've done that before, and > never really got "nice" results. The separation distance along the > separating axis is available, and it seems like some insight from > continuous CD would solve this. Does anyone do this currently, or is this > probably going to be slower than bisection? Stephane Redon's work uses > screwings to compute the time explicitly, but I'm not sure if all of that > is necessary for this. > Any tips or success/horror stories are welcome. > > Kudos in advance (lol...just realized the abbreviation for that is KIA.. > :( > > Adam C. > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > GDAlgorithms-list mailing list > GDAlgorithms-list@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 ```
 Re: [Algorithms] sorting objects From: Mark Wayland - 2002-12-06 10:39:35 Attachments: Message as HTML ```I've used a bucket sort in the past, but thought that it could be done = better as you occassionally get some incorrect sorting. I used to sort by the center, but thought that it would be better to = sort by nearest vertex. Any other thoughts on this? Then again alot of the successful titles I've played don't even seem to = care - Battlefield 1942 and Giants are two that come to mind (they're = both great games!) Mark. ----- Original Message -----=20 From: Raymond L. Maple=20 To: gdalgorithms-list@...=20 Sent: Thursday, December 05, 2002 7:40 PM Subject: [Algorithms] sorting objects Hello! I have a problem and was wondering if you guys could give me = some insight. The game I'm working has a split screen so two players = can play against each other on the same system. The problem I'm having = is with the rendering of objects. I need to sort the object with an = alpha channel back to front so they'll render correctly. So I need to = do two sorts of my renderable objects, one for each camera view. My = question is how do you set up the rendering portion of your application = to do this. Do you use some sort of bucket like scheme and drop = particles, models, billboards into the buckets that are sorted back to = front. I not sure if I should call each game object and check its = distance from the camera and sort the game objects in some list then = iterate over them calling render() for each. I don't have a huge = problem with just sorting models (I think) but when you have effects = (particles, billboards, streaks) in the mix I'm not exactly sure how I = should do it. Any ideas would be appreciated. Thanks, Raymond ```
 Re: [Algorithms] sorting objects From: Stephen J Baker - 2002-12-09 15:51:53 ```On Fri, 6 Dec 2002, Mark Wayland wrote: > I've used a bucket sort in the past, but thought that it could be done better as you occassionally get some incorrect sorting. > I used to sort by the center, but thought that it would be better to sort by nearest vertex. Any other thoughts on this? There is no sorting algorithm that gives perfect results without splitting polygons. You doubt that? Sort this! /\/\ / \ \ \ \/ /\ \ / \ \ / /\ \ ____/ /__\___\__ | / / | |__/ /___________| /___/ \___\ Whether you sort by center, nearest, furthest or any other point, you'll still find situations where something will go wrong. I have a FAQ here: http://www.sjbaker.org/steve/omniv/alpha_sorting.html If you do intend to do a full sort solution, then at least speed up the sort by excluding: 1) Objects that use alpha only to cut out a shape leaving an opaque area and a fully transparent area but no partial transparency. (These can be rendered along with the opaque polygons - providing you set the glAlphaFunc correctly) 2) Translucent objects that are coplanar with opaque surfaces can be rendered immediately after all opaque surfaces. In neither case is sorting needed. ---- Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation & Training (817)619-2466 (Fax) Work: sjbaker@... http://www.link.com Home: sjbaker1@... http://www.sjbaker.org ```