## Re: [Algorithms] Distance formula problem

 Re: [Algorithms] Distance formula problem From: Stephan Rose - 2006-07-02 00:36:32 ```*Smack forehead*... Of course...man I feel stupid now =) Thanks very much!!! Stephan -----Original Message----- From: gdalgorithms-list-bounces@... [mailto:gdalgorithms-list-bounces@...] On Behalf Of Brian Osman Sent: Sunday, July 02, 2006 02:31 To: Game Development Algorithms Subject: Re: [Algorithms] Distance formula problem Your units are wrong. When you multiply two values that have the unit 'mm', the result is no longer a measure of 'mm'. It's a measure of 'mm^2'. Likewise for mil. And of course, 100 mil^2 == 0.064516 mm^2 -Brian ----- Original Message ----- From: "Stephan Rose" To: "'Game Development Algorithms'" Sent: Saturday, July 01, 2006 6:48 PM Subject: [Algorithms] Distance formula problem >I am having a weird problem with my distance formula, maybe someone here >has > an idea! > > My math system is capable of doing math between various units. Mil, inch, > mm, cm, etc. It automatically converts operations to matching units and > then > performs the operation and so far this has been working out great. > > But today I ran into a rather interesting problem. > > Just taking the first half of the distance formula (x1-x2)*(x1-x2) > > Plug in test millimeter values: > > (-0.254 mm - 0)*(-0.254 mm - 0) = 0.064516 mm or 2.54 mil > > So far...so good. > > Now, 0.254 mm = 10 mil > > So plug in 10 mil into the same equation: > > (-10 mil - 0)*(-10 mil -0) = 100 mil = 2.54 mm > > 2.54 mm != 0.064516 mm.... > > Even though 10 mil = 0.254 mm, plugging the other value into the same > formula yields a different result. This is extremely bad. > > Anyone have any suggestions what I could do about this? > > Thanks! > > Stephan Rose > > > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > GDAlgorithms-list mailing list > GDAlgorithms-list@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ 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] Optimizing fill-rate for particle generators? From: Matt J - 2006-06-30 13:20:59 ```Hi, I have a 200-400 particle generator that I released on my first (private) game alpha. It represents the exhaust fumes of a futuristic space ship. So this generator is pretty fast on the mobility raydeon 9700. However, when the camera gets very close to the particle generator (ala the ship exhaust) it slows down noticeably. Well at this early in the stage I want things running at full speed and glory, not fill-rate limited! I'm assuming that the blending ops themselves are taxing the system..not just because your sorting 400-800 textured/blended triangles, but because up close, all things being constant, it simply can't fill enough pixels. Also it must be the overdraw as well.. if I'm viewing it at an angle there won't be as much overdraw as head-on. So, Is there a way to create maybe a reverse level of detail so when you zoom-up the particles decrease in count but add to the size ..? Is there some way of reducing overdraw by simplication, stencil buffer, anything? Or is this simply something that is handled by avoiding the situation? I want zoom-ups for the cinematic parts of the game... Thanks, Matt http://otowngraphics.blogspot.com ```
 Re: [Algorithms] Optimizing fill-rate for particle generators? From: Jamie Fowlston - 2006-06-30 13:28:31 ```We've talked about this sort of thing before (although it might have been about 6 - 7 years ago... :) At the time, there was a lot of support for the idea of having a few polys covering the screen, using low res render targets onto which you accumulated the influence of large / close particles. I think somebody referred to it as reverse mip mapping, on the grounds that the closer the layer was to you, the smaller the render target you would use. Anyway, still seems like a valid approach to me. Jamie Matt J wrote: > Hi, I have a 200-400 particle generator that I released on my first > (private) game alpha. It represents the exhaust fumes of a futuristic > space ship. So this generator is pretty fast on the mobility raydeon > 9700. However, when the camera gets very close to the particle > generator (ala the ship exhaust) it slows down noticeably. Well at > this early in the stage I want things running at full speed and glory, > not fill-rate limited! I'm assuming that the blending ops themselves > are taxing the system..not just because your sorting 400-800 > textured/blended triangles, but because up close, all things being > constant, it simply can't fill enough pixels. Also it must be the > overdraw as well.. if I'm viewing it at an angle there won't be as > much overdraw as head-on. > > So, Is there a way to create maybe a reverse level of detail so when > you zoom-up the particles decrease in count but add to the size ..? Is > there some way of reducing overdraw by simplication, stencil buffer, > anything? Or is this simply something that is handled by avoiding the > situation? I want zoom-ups for the cinematic parts of the game... > > Thanks, > > Matt > http://otowngraphics.blogspot.com > > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > 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] Optimizing fill-rate for particle generators? From: Matt J - 2006-06-30 14:30:33 ```Hi Jamie, can you please provide more detail? Are you referring to ARB_render_texture? Do you mean blend multiple textures into a texture and then expand it as one particle, so that when you do render it it doesn't require multiple blend passes? But this combining is view-angle dependent, right? Wouldn't this require a way to project all the textures as a non-axis aligned bounding box in order to find the proper texture size? Sounds like I've ventured into non-trivial. Can you please clarify..? Matthew > We've talked about this sort of thing before (although it might have > been about 6 - 7 years ago... :) > > At the time, there was a lot of support for the idea of having a few > polys covering the screen, using low res render targets onto which you > accumulated the influence of large / close particles. I think somebody > referred to it as reverse mip mapping, on the grounds that the closer > the layer was to you, the smaller the render target you would use. > > Anyway, still seems like a valid approach to me. > > Jamie ```
 Re: [Algorithms] Optimizing fill-rate for particle generators? From: Jamie Fowlston - 2006-06-30 14:42:12 ```Matt J wrote: > Hi Jamie, can you please provide more detail? Sure... > Are you referring to > ARB_render_texture? Possibly; I'm not good on my OpenGL extensions. > Do you mean blend multiple textures into a texture > and then expand it as one particle, so that when you do render it it > doesn't require multiple blend passes? The idea is to avoid using too much fill rate. The idea initially occurred to me when working on PS2, where blending comes for free anyway. Basically, for close enough particles, rather than render them onto the frame buffer, you render them to a smaller render target. This saves you fill rate. Then at some point, you blat the render target onto the frame buffer in some way, e.g. by using it to modulate a higher resolution texture so that things don't look too blocky. You could do this in several layers, with varying sizes of render target. > But this combining is view-angle dependent, right? Wouldn't this > require a way to project all the textures as a non-axis aligned > bounding box in order to find the proper texture size? Sounds like > I've ventured into non-trivial. Can you please clarify..? I'm afraid I don't understand what you're getting at here. Certainly what I'm suggesting is pretty trivial :) Jamie ```
 Re: [Algorithms] Optimizing fill-rate for particle generators? From: Will Vale - 2006-07-01 09:59:54 ``` > At the time, there was a lot of support for the idea of having a few > polys covering the screen, using low res render targets onto which you > accumulated the influence of large / close particles. I think somebody > referred to it as reverse mip mapping, on the grounds that the closer > the layer was to you, the smaller the render target you would use. It's a really tempting technique, but it's a pain to get really good Z-integration with that kind of thing - assuming you need it, of course. That said, we had great success using this technique for reducing overdraw on lens-flare sprites. These should be rendered over the top of everything anyway, so Z isn't a problem. You can than use pixel counters (on invisible billboards drawn into the real scene) to capture the interaction with the depth buffer and fade the flares in and out. In the implementation, we wrote the flares on top of our little glare buffer. We thus didn't pay for the final upsample (already happening) and therefore didn't have any break-even point to be concerned about. I don't have any figures now, but in the rosy garden of my memory, a big chunk of postprocess fill time became so small it wasn't worth worrying about. A very tangible improvement. > Anyway, still seems like a valid approach to me. Worth fiddling with, at least. There never seems to be enough fill rate (apart from maybe that one console) to do what you want, so anything that saves it in extreme cases is great. For effects which do need to interact with other objects in the scene, and especially for things like engine effects, I'd also consider sidestepping the problem using fewer particles and more polygonal effect geometry if your artistic vision allows it. Will ```
 [Algorithms] Distance formula problem From: Stephan Rose - 2006-07-01 22:48:05 ```I am having a weird problem with my distance formula, maybe someone here has an idea! My math system is capable of doing math between various units. Mil, inch, mm, cm, etc. It automatically converts operations to matching units and then performs the operation and so far this has been working out great. But today I ran into a rather interesting problem. Just taking the first half of the distance formula (x1-x2)*(x1-x2) Plug in test millimeter values: (-0.254 mm - 0)*(-0.254 mm - 0) = 0.064516 mm or 2.54 mil So far...so good. Now, 0.254 mm = 10 mil So plug in 10 mil into the same equation: (-10 mil - 0)*(-10 mil -0) = 100 mil = 2.54 mm 2.54 mm != 0.064516 mm.... Even though 10 mil = 0.254 mm, plugging the other value into the same formula yields a different result. This is extremely bad. Anyone have any suggestions what I could do about this? Thanks! Stephan Rose ```
 Re: [Algorithms] Distance formula problem From: Brian Osman - 2006-07-02 00:30:36 ```Your units are wrong. When you multiply two values that have the unit 'mm', the result is no longer a measure of 'mm'. It's a measure of 'mm^2'. Likewise for mil. And of course, 100 mil^2 == 0.064516 mm^2 -Brian ----- Original Message ----- From: "Stephan Rose" To: "'Game Development Algorithms'" Sent: Saturday, July 01, 2006 6:48 PM Subject: [Algorithms] Distance formula problem >I am having a weird problem with my distance formula, maybe someone here >has > an idea! > > My math system is capable of doing math between various units. Mil, inch, > mm, cm, etc. It automatically converts operations to matching units and > then > performs the operation and so far this has been working out great. > > But today I ran into a rather interesting problem. > > Just taking the first half of the distance formula (x1-x2)*(x1-x2) > > Plug in test millimeter values: > > (-0.254 mm - 0)*(-0.254 mm - 0) = 0.064516 mm or 2.54 mil > > So far...so good. > > Now, 0.254 mm = 10 mil > > So plug in 10 mil into the same equation: > > (-10 mil - 0)*(-10 mil -0) = 100 mil = 2.54 mm > > 2.54 mm != 0.064516 mm.... > > Even though 10 mil = 0.254 mm, plugging the other value into the same > formula yields a different result. This is extremely bad. > > Anyone have any suggestions what I could do about this? > > Thanks! > > Stephan Rose > > > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > 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] Distance formula problem From: Stephan Rose - 2006-07-02 00:36:32 ```*Smack forehead*... Of course...man I feel stupid now =) Thanks very much!!! Stephan -----Original Message----- From: gdalgorithms-list-bounces@... [mailto:gdalgorithms-list-bounces@...] On Behalf Of Brian Osman Sent: Sunday, July 02, 2006 02:31 To: Game Development Algorithms Subject: Re: [Algorithms] Distance formula problem Your units are wrong. When you multiply two values that have the unit 'mm', the result is no longer a measure of 'mm'. It's a measure of 'mm^2'. Likewise for mil. And of course, 100 mil^2 == 0.064516 mm^2 -Brian ----- Original Message ----- From: "Stephan Rose" To: "'Game Development Algorithms'" Sent: Saturday, July 01, 2006 6:48 PM Subject: [Algorithms] Distance formula problem >I am having a weird problem with my distance formula, maybe someone here >has > an idea! > > My math system is capable of doing math between various units. Mil, inch, > mm, cm, etc. It automatically converts operations to matching units and > then > performs the operation and so far this has been working out great. > > But today I ran into a rather interesting problem. > > Just taking the first half of the distance formula (x1-x2)*(x1-x2) > > Plug in test millimeter values: > > (-0.254 mm - 0)*(-0.254 mm - 0) = 0.064516 mm or 2.54 mil > > So far...so good. > > Now, 0.254 mm = 10 mil > > So plug in 10 mil into the same equation: > > (-10 mil - 0)*(-10 mil -0) = 100 mil = 2.54 mm > > 2.54 mm != 0.064516 mm.... > > Even though 10 mil = 0.254 mm, plugging the other value into the same > formula yields a different result. This is extremely bad. > > Anyone have any suggestions what I could do about this? > > Thanks! > > Stephan Rose > > > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > GDAlgorithms-list mailing list > GDAlgorithms-list@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ 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] Optimizing fill-rate for particle generators? From: Phil Teschner - 2006-06-30 20:26:30 ```Matt J Wrote: > Hi, I have a 200-400 particle generator that I released on my first > (private) game alpha. It represents the exhaust fumes of a futuristic > space ship > > [snip] [snip] > > So, Is there a way to create maybe a reverse level of detail > so when you zoom-up the particles decrease in count but add to > the size ..? Something simple that I have successfully used in the past on a racing game, where you had a large dust plume following the car, is to fade particles out as they approach either the near plane, or some kind of screen size limit. I did this in a stateless manner since you don't really want to impact the life-cycle, or overall look of the particle system, you only want to address the issue if the particles happen to be using up a lot of screen space.=20 In my case I did this work on the CPU though I suppose on shader hardware you could actually do this automatically on the GPU and, depending on how it's done, you could avoid pixel processing entirely once the particles are faded out. Phil -----Original Message----- From: Matt J Hi, I have a 200-400 particle generator that I released on my first (private) game alpha. It represents the exhaust fumes of a futuristic space ship. So this generator is pretty fast on the mobility raydeon 9700. However, when the camera gets very close to the particle generator (ala the ship exhaust) it slows down noticeably. Well at this early in the stage I want things running at full speed and glory, not fill-rate limited! I'm assuming that the blending ops themselves are taxing the system..not just because your sorting 400-800 textured/blended triangles, but because up close, all things being constant, it simply can't fill enough pixels. Also it must be the overdraw as well.. if I'm viewing it at an angle there won't be as much overdraw as head-on. So, Is there a way to create maybe a reverse level of detail so when you zoom-up the particles decrease in count but add to the size ..? Is there some way of reducing overdraw by simplication, stencil buffer, anything? Or is this simply something that is handled by avoiding the situation? I want zoom-ups for the cinematic parts of the game... Thanks, Matt http://otowngraphics.blogspot.com ```