## RE: [Algorithms] Collision and Visual triangle data structures

 RE: [Algorithms] Collision and Visual triangle data structures From: Chris Butcher (BUNGIE) - 2002-04-30 16:45:11 ```> -----Original Message----- > From: Duncan Hewat [mailto:duncanhewat@...]=20 > Sent: Tuesday, April 30, 2002 03:18 > To: tomf@...; gdalgorithms-list@... > Subject: RE: [Algorithms] Collision and Visual triangle data structures > > I thought this may be the case (thanks!) - additional question: is this also=20 > done on consoles even though there is a lack of memory? It also brings up=20 > an interesting issue in that I was planning to use the same structure I used=20 > for collision detection for computing silhouette edges and I now wonder if=20 > this is a good idea as I may now be tempted to simplify my collision=20 > geometry which would cause problems... I suppose I could always have three=20 > seperate structures... > You'll probably find that the set of edges on which you require collision adjacency structures is very different to the set of edges that you want to track for silhouette purposes. A dual representation is (IMHO) definitely the way to go here. For any really high-detail geometry you will probably want to have a low-detail collision approximation mesh anyway. The real trick comes with integrating environmental response between the two different representations. For example, given this impact at point x in the collision representation, how do I find surface and lighting properties from the render representation? And how do I modify the render representation to handle any persistent visual state? The answers to these questions, and whether or not they apply to your game, will probably determine what representations you end up using. -- Chris Butcher AI Engineer | Halo Bungie Studios butcher@... ```

 RE: [Algorithms] Collision and Visual triangle data structures From: Tom Forsyth - 2002-04-29 12:23:46 ```Seconded. Generally, you will need very different data structures for each part (rendering and collision), different mesh resolutions, different workaround and shortcuts (what does alpha-test mean to a collision engine for example), and frequently you will have the two sides done in different modules, at different rates, and sometimes even in different threads. Additionally, you usually have collisions happening in parts of the world that are not rendered. Trying to use the same data for both just makes both halves slower, and leads to cache pollution and poor paging performance. In practice there is almost no useful data sharing going on. In some particular cases, we go so far as to author two different Max/Maya models, one for collision and one for rendering. However we usually start from the same model and generate the two different data sets - far more efficient. But for some things it is useful to be able to make two completely separate models. Tom Forsyth - purely hypothetical Muckyfoot bloke. This email is the product of your deranged imagination, and does not in any way imply existence of the author. > -----Original Message----- > From: Sam McGrath [mailto:sammy@...] > Sent: 28 April 2002 11:11 > To: gdalgorithms-list@... > Subject: RE: [Algorithms] Collision and Visual triangle data > structures > > > I find it's generally a smart idea to separate these out. I > would keep > two separate structures for your collision and your visual > geometry, and > do whatever you need to do with the copy to make it suitable for your > collision system. > > Our engine uses convex surfaces only for collision, and these are > represented as a series of planes rather than vertex/face > data. As far > as the engine is concerned, these are two distinct and separate > structures, not dependent on each other in any way. > > -Sam ```
 RE: [Algorithms] Collision and Visual triangle data structures From: Duncan Hewat - 2002-04-30 10:18:11 ```I thought this may be the case (thanks!) - additional question: is this also done on consoles even though there is a lack of memory? It also brings up an interesting issue in that I was planning to use the same structure I used for collision detection for computing silhouette edges and I now wonder if this is a good idea as I may now be tempted to simplify my collision geometry which would cause problems... I suppose I could always have three seperate structures... Thanks, Duncan. >From: Tom Forsyth >To: gdalgorithms-list@... >Subject: RE: [Algorithms] Collision and Visual triangle data structures >Date: Mon, 29 Apr 2002 13:20:50 +0100 > >Seconded. Generally, you will need very different data structures for each >part (rendering and collision), different mesh resolutions, different >workaround and shortcuts (what does alpha-test mean to a collision engine >for example), and frequently you will have the two sides done in different >modules, at different rates, and sometimes even in different threads. >Additionally, you usually have collisions happening in parts of the world >that are not rendered. > >Trying to use the same data for both just makes both halves slower, and >leads to cache pollution and poor paging performance. In practice there is >almost no useful data sharing going on. > >In some particular cases, we go so far as to author two different Max/Maya >models, one for collision and one for rendering. However we usually start >from the same model and generate the two different data sets - far more >efficient. But for some things it is useful to be able to make two >completely separate models. > >Tom Forsyth - purely hypothetical Muckyfoot bloke. > >This email is the product of your deranged imagination, >and does not in any way imply existence of the author. > > > -----Original Message----- > > From: Sam McGrath [mailto:sammy@...] > > Sent: 28 April 2002 11:11 > > To: gdalgorithms-list@... > > Subject: RE: [Algorithms] Collision and Visual triangle data > > structures > > > > > > I find it's generally a smart idea to separate these out. I > > would keep > > two separate structures for your collision and your visual > > geometry, and > > do whatever you need to do with the copy to make it suitable for your > > collision system. > > > > Our engine uses convex surfaces only for collision, and these are > > represented as a series of planes rather than vertex/face > > data. As far > > as the engine is concerned, these are two distinct and separate > > structures, not dependent on each other in any way. > > > > -Sam > >_______________________________________________ >GDAlgorithms-list mailing list >GDAlgorithms-list@... >https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >Archives: >http://sourceforge.net/mailarchive/forum.php?forum_id=6188 _________________________________________________________________ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com ```
 RE: [Algorithms] Collision and Visual triangle data structures From: Chris Butcher (BUNGIE) - 2002-04-30 16:45:11 ```> -----Original Message----- > From: Duncan Hewat [mailto:duncanhewat@...]=20 > Sent: Tuesday, April 30, 2002 03:18 > To: tomf@...; gdalgorithms-list@... > Subject: RE: [Algorithms] Collision and Visual triangle data structures > > I thought this may be the case (thanks!) - additional question: is this also=20 > done on consoles even though there is a lack of memory? It also brings up=20 > an interesting issue in that I was planning to use the same structure I used=20 > for collision detection for computing silhouette edges and I now wonder if=20 > this is a good idea as I may now be tempted to simplify my collision=20 > geometry which would cause problems... I suppose I could always have three=20 > seperate structures... > You'll probably find that the set of edges on which you require collision adjacency structures is very different to the set of edges that you want to track for silhouette purposes. A dual representation is (IMHO) definitely the way to go here. For any really high-detail geometry you will probably want to have a low-detail collision approximation mesh anyway. The real trick comes with integrating environmental response between the two different representations. For example, given this impact at point x in the collision representation, how do I find surface and lighting properties from the render representation? And how do I modify the render representation to handle any persistent visual state? The answers to these questions, and whether or not they apply to your game, will probably determine what representations you end up using. -- Chris Butcher AI Engineer | Halo Bungie Studios butcher@... ```
 RE: [Algorithms] Collision and Visual triangle data structures From: - 2002-04-30 18:34:10 ```You piqued my curiousity a while back when you explained how you stairs were slopes for collision, but you cast down to find the step location for placing feet. Does this mean that you've got a graphical representation that you can query spatially, or did you treat stairs as special cases and store two different collision datasets for stairs? I've used both techniques in the past, but our current engine has a heavily pre-processed visual representation that makes doing anything other than rendering it, very tricky. Cheers, Phil "Chris Butcher (BUNGIE)" To: "Duncan Hewat" , , Sent by: gdalgorithms-list-admin@... cc: eforge.net Subject: RE: [Algorithms] Collision and Visual triangle data structures 04/30/2002 09:45 AM > -----Original Message----- > From: Duncan Hewat [mailto:duncanhewat@...] > Sent: Tuesday, April 30, 2002 03:18 > To: tomf@...; gdalgorithms-list@... > Subject: RE: [Algorithms] Collision and Visual triangle data structures > > I thought this may be the case (thanks!) - additional question: is this also > done on consoles even though there is a lack of memory? It also brings up > an interesting issue in that I was planning to use the same structure I used > for collision detection for computing silhouette edges and I now wonder if > this is a good idea as I may now be tempted to simplify my collision > geometry which would cause problems... I suppose I could always have three > seperate structures... > You'll probably find that the set of edges on which you require collision adjacency structures is very different to the set of edges that you want to track for silhouette purposes. A dual representation is (IMHO) definitely the way to go here. For any really high-detail geometry you will probably want to have a low-detail collision approximation mesh anyway. The real trick comes with integrating environmental response between the two different representations. For example, given this impact at point x in the collision representation, how do I find surface and lighting properties from the render representation? And how do I modify the render representation to handle any persistent visual state? The answers to these questions, and whether or not they apply to your game, will probably determine what representations you end up using. -- Chris Butcher AI Engineer | Halo Bungie Studios butcher@... _______________________________________________ GDAlgorithms-list mailing list GDAlgorithms-list@... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_ida88 ```