You can subscribe to this list here.
2000 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}
(390) 
_{Aug}
(767) 
_{Sep}
(940) 
_{Oct}
(964) 
_{Nov}
(819) 
_{Dec}
(762) 

2001 
_{Jan}
(680) 
_{Feb}
(1075) 
_{Mar}
(954) 
_{Apr}
(595) 
_{May}
(725) 
_{Jun}
(868) 
_{Jul}
(678) 
_{Aug}
(785) 
_{Sep}
(410) 
_{Oct}
(395) 
_{Nov}
(374) 
_{Dec}
(419) 
2002 
_{Jan}
(699) 
_{Feb}
(501) 
_{Mar}
(311) 
_{Apr}
(334) 
_{May}
(501) 
_{Jun}
(507) 
_{Jul}
(441) 
_{Aug}
(395) 
_{Sep}
(540) 
_{Oct}
(416) 
_{Nov}
(369) 
_{Dec}
(373) 
2003 
_{Jan}
(514) 
_{Feb}
(488) 
_{Mar}
(396) 
_{Apr}
(624) 
_{May}
(590) 
_{Jun}
(562) 
_{Jul}
(546) 
_{Aug}
(463) 
_{Sep}
(389) 
_{Oct}
(399) 
_{Nov}
(333) 
_{Dec}
(449) 
2004 
_{Jan}
(317) 
_{Feb}
(395) 
_{Mar}
(136) 
_{Apr}
(338) 
_{May}
(488) 
_{Jun}
(306) 
_{Jul}
(266) 
_{Aug}
(424) 
_{Sep}
(502) 
_{Oct}
(170) 
_{Nov}
(170) 
_{Dec}
(134) 
2005 
_{Jan}
(249) 
_{Feb}
(109) 
_{Mar}
(119) 
_{Apr}
(282) 
_{May}
(82) 
_{Jun}
(113) 
_{Jul}
(56) 
_{Aug}
(160) 
_{Sep}
(89) 
_{Oct}
(98) 
_{Nov}
(237) 
_{Dec}
(297) 
2006 
_{Jan}
(151) 
_{Feb}
(250) 
_{Mar}
(222) 
_{Apr}
(147) 
_{May}
(266) 
_{Jun}
(313) 
_{Jul}
(367) 
_{Aug}
(135) 
_{Sep}
(108) 
_{Oct}
(110) 
_{Nov}
(220) 
_{Dec}
(47) 
2007 
_{Jan}
(133) 
_{Feb}
(144) 
_{Mar}
(247) 
_{Apr}
(191) 
_{May}
(191) 
_{Jun}
(171) 
_{Jul}
(160) 
_{Aug}
(51) 
_{Sep}
(125) 
_{Oct}
(115) 
_{Nov}
(78) 
_{Dec}
(67) 
2008 
_{Jan}
(165) 
_{Feb}
(37) 
_{Mar}
(130) 
_{Apr}
(111) 
_{May}
(91) 
_{Jun}
(142) 
_{Jul}
(54) 
_{Aug}
(104) 
_{Sep}
(89) 
_{Oct}
(87) 
_{Nov}
(44) 
_{Dec}
(54) 
2009 
_{Jan}
(283) 
_{Feb}
(113) 
_{Mar}
(154) 
_{Apr}
(395) 
_{May}
(62) 
_{Jun}
(48) 
_{Jul}
(52) 
_{Aug}
(54) 
_{Sep}
(131) 
_{Oct}
(29) 
_{Nov}
(32) 
_{Dec}
(37) 
2010 
_{Jan}
(34) 
_{Feb}
(36) 
_{Mar}
(40) 
_{Apr}
(23) 
_{May}
(38) 
_{Jun}
(34) 
_{Jul}
(36) 
_{Aug}
(27) 
_{Sep}
(9) 
_{Oct}
(18) 
_{Nov}
(25) 
_{Dec}

2011 
_{Jan}
(1) 
_{Feb}
(14) 
_{Mar}
(1) 
_{Apr}
(5) 
_{May}
(1) 
_{Jun}

_{Jul}

_{Aug}
(37) 
_{Sep}
(6) 
_{Oct}
(2) 
_{Nov}

_{Dec}

2012 
_{Jan}

_{Feb}
(7) 
_{Mar}

_{Apr}
(4) 
_{May}

_{Jun}
(3) 
_{Jul}

_{Aug}

_{Sep}
(1) 
_{Oct}

_{Nov}

_{Dec}
(10) 
2013 
_{Jan}

_{Feb}
(1) 
_{Mar}
(7) 
_{Apr}
(2) 
_{May}

_{Jun}

_{Jul}
(9) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

2014 
_{Jan}
(14) 
_{Feb}

_{Mar}
(2) 
_{Apr}

_{May}
(10) 
_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 






1
(28) 
2
(15) 
3
(4) 
4
(22) 
5
(22) 
6
(24) 
7
(4) 
8
(7) 
9
(6) 
10
(13) 
11
(4) 
12
(22) 
13
(55) 
14
(30) 
15
(24) 
16
(1) 
17
(2) 
18
(11) 
19
(28) 
20
(14) 
21
(18) 
22
(15) 
23
(7) 
24

25
(30) 
26
(26) 
27
(43) 
28
(26) 


From: Chris Butcher (BUNGIE) <cbutcher@mi...>  20020228 00:01:28

> Original Message > From: Ratcliff, John [mailto:jratcliff@...] >=20 > What I need to be able to do is take the result of an impact event and = then > create a generic orientation, either quaternion or euler, I don't care > which, that can be passed on to other routines like for generating = decals or > oriented effects. >=20 If I understand you correctly, you're looking for a quaternion that = will rotate a Zaxisaligned object to face along a given vector. Take the cross product of this vector with +Z to get a rotation axis, = and the dot product of this vector with +Z (i.e. the Z component of the = vector) to give the cosine of the angle of the rotation. That gives you an axis a and a rotation magnitude cos(theta). Use = trigonometric identities to generate cos(theta/2) and sin(theta/2). You = can build the quaternion directly as: q.w =3D cos(theta/2) q.v =3D sin(theta/2)*normalize(a) The only real problem with this is that there's no control over the = 'roll' component of the rotation. If you wanted to modify that (e.g. by = randomizing it) you could premultiply by a random quaternion that is a = rotation about +Z.  Chris Butcher AI Engineer  Halo Bungie Studios butcher@... 
From: Ratcliff, John <jratcliff@so...>  20020227 23:36:16

I thought I had this as a solved problem in my code. In fact I was just going to post a question to the list asking if anyone knew of an optimization technique. However, now I'm not certain I even have the problem solved corectly in the first place. What I need to be able to do is take the result of an impact event and then create a generic orientation, either quaternion or euler, I don't care which, that can be passed on to other routines like for generating decals or oriented effects. What my current code does is as follows: (1) Take the triangle that was hit and compute it's face normal. (2) Build a 3x3 rotation matrix from that vector normal, using some arbitrary 'facing' vector. (3) Extract the euler rotation from this matrix using the published graphics gems sample code routines. Now, this isn't necessarily that efficient, and I would certainly be interested in more direct routes to convert a surface normal into either an euler or quaternion rotation that would orient and abitrary object so that it were aligned with this surface. That said, I'm not sure my code, as is, is working correctly. Suggestions on more efficient techniques welcome. I assume this is a very common problem that many people have needed to solve. John 
From: James Johnson <James.J<ohnson@si...>  20020227 22:40:13

My guess is you're calculating your indices [into your map] incorrectly for some edge case(s). It's pretty easy to get a one off error, that will generate these types of anomalies. Combine Tom's approach (remove the random part), and seeding the four corners with known values. You should be able to produce a gradient. James Original Message From: David Zaadstra [mailto:mythomania@...] Sent: Wednesday, February 27, 2002 1:35 PM To: gdalgorithmslist@... Subject: Re: [Algorithms] midpoint displacement problems hmm...I think I just found out that the algorithm as it is described in GPG1 doesn't really work. I can't explain why, but I calculated a small 8*8 heightmap on paper, and I get wrong results. The points get interpolated like an exponential function from the middle of the square to its edges. When I read how it works with a line I thought that the algorithm is ok. And it is, but only in 2D, with the line. I think the problem with the 3D version is that the 4 points which get interpolated don't lie in a plane. Or is it because the distance of the points is sqrt(2) in the diamond step and 1 in the square step? Can anybody else comment on this? Somebody how knows the algorithm, and is better at maths and explaining than me maybe? 
From: David Zaadstra <mythomania@gm...>  20020227 21:34:30

hmm...I think I just found out that the algorithm as it is described in GPG1 doesn't really work. I can't explain why, but I calculated a small 8*8 heightmap on paper, and I get wrong results. The points get interpolated like an exponential function from the middle of the square to its edges. When I read how it works with a line I thought that the algorithm is ok. And it is, but only in 2D, with the line. I think the problem with the 3D version is that the 4 points which get interpolated don't lie in a plane. Or is it because the distance of the points is sqrt(2) in the diamond step and 1 in the square step? Can anybody else comment on this? Somebody how knows the algorithm, and is better at maths and explaining than me maybe?  Original Message  From: "Tom Forsyth" <tomf@...> To: "David Zaadstra" <mythomania@...>; <gdalgorithmslist@...> Sent: Wednesday, February 27, 2002 9:24 PM Subject: RE: [Algorithms] midpoint displacement problems > That looks like your midpoint calculation isn't working right  the peaks > are the "coarse" divisions, but then the rest of the subdivisions don't > interpolate through them properly. Try turning off any random variation > after, say, three divisons  you should then get a nice smooth surface. But > I don't think you will, because the calculation of the new midpoint isn't > working right. > > 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: David Zaadstra [mailto:mythomania@...] > > Sent: 27 February 2002 20:12 > > To: gdalgorithmslist@... > > Subject: [Algorithms] midpoint displacement problems > > > > > > Hello everybody, > > > > I have a problem with the midpoint displacement algorithm (from GPG1). > > I get strange little peaks all around my landscape. I've been > > looking for > > the bug for hours now and starting to believe that I'm a > > complete idiot. > > Could it be that the peaks are normal? That would explain why > > an erosion > > filter was added to the example file in GPG... > > Please take a look at this screenshot to see what I mean: > > http://www.gameprogramming.de/screen.jpg (not a very good one, i know) > > > > Thanks for your help, > > David > > > > > > _______________________________________________ > > GDAlgorithmslist mailing list > > GDAlgorithmslist@... > > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > > Archives: > > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > 
From: Tom Forsyth <tomf@mu...>  20020227 20:26:05

That looks like your midpoint calculation isn't working right  the peaks are the "coarse" divisions, but then the rest of the subdivisions don't interpolate through them properly. Try turning off any random variation after, say, three divisons  you should then get a nice smooth surface. But I don't think you will, because the calculation of the new midpoint isn't working right. 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: David Zaadstra [mailto:mythomania@...] > Sent: 27 February 2002 20:12 > To: gdalgorithmslist@... > Subject: [Algorithms] midpoint displacement problems > > > Hello everybody, > > I have a problem with the midpoint displacement algorithm (from GPG1). > I get strange little peaks all around my landscape. I've been > looking for > the bug for hours now and starting to believe that I'm a > complete idiot. > Could it be that the peaks are normal? That would explain why > an erosion > filter was added to the example file in GPG... > Please take a look at this screenshot to see what I mean: > http://www.gameprogramming.de/screen.jpg (not a very good one, i know) > > Thanks for your help, > David > > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > 
From: David Zaadstra <mythomania@gm...>  20020227 20:12:09

Hello everybody, I have a problem with the midpoint displacement algorithm (from GPG1). I get strange little peaks all around my landscape. I've been looking for the bug for hours now and starting to believe that I'm a complete idiot. Could it be that the peaks are normal? That would explain why an erosion filter was added to the example file in GPG... Please take a look at this screenshot to see what I mean: http://www.gameprogramming.de/screen.jpg (not a very good one, i know) Thanks for your help, David 
From: phil_wilkins@Playstation.sony.com  20020227 17:49:56

Only if your solid is convex. Think of barbells, then donuts, then another aproach...;) Cheers, Phil Chris Perry <perry@...> Sent by: To: "gdalgorithmslist@..." gdalgorithmslistadmin@... <gdalgorithmslist@...> eforge.net cc: Subject: RE: [Algorithms] Generating Shadow Volumes with open geometry 02/27/2002 12:16 AM Please respond to "perry@..." if a triangle is facing the light, then you can safely extrude any edges that either have no neighbor or have a neighbor that is not facing the light. It's funny, I'm actually working on shadow volumes right now and I was trying to think of a way to speed up the edge detection process. It wouldn't work on objects with holes, but if you knew you had a solid object you could theoretically trace one edge to the next until you came full circle, right? limiting the search space to only child edges. I've been wasting too much time trying to create a tree structure that links them together in a way which won't produce endless circles. I think you have to treat the edges as symbolic vectors and keep a "head" to "tail" orientation... i.e. an edge is a child if it's "tail" is the parent edge's "head"... hmmm...who knows, maybe it's impossible... Chris Perry Angel Studios Original Message From: Jason Zisk [SMTP:ziskj@...] Sent: Tuesday, February 26, 2002 8:32 PM To: gdalgorithmslist@... Subject: [Algorithms] Generating Shadow Volumes with open geometry Quick question about shadow volumes. A lot of our geometry is "open", for instance a cylinder with no top or bottom. When generating a shadow volume for it, what do you do with the triangle edges that aren't shared between two triangles when it comes to checking if the edge is a silhouette? With two triangles you just see if one is facing the light and one isnt, then extrude that edge. With only one triangle, do you simply check if the triangle is backfacing, if so extrude? I'd like to hear what others do in this situation. Thanks,  Jason Zisk  nFusion Interactive LLC _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 
From: phil_wilkins@Playstation.sony.com  20020227 17:45:06

> It might be possible to write a tool to auto seal an object, although that sounds like a hard thing to write. It is. I wrote one for Alien as part of my experiments in generating grown BSP trees from polygon soups. The source is probably on a server / backup over there, somewhere (EdgeModel.h & cpp ). However, my general conclusion was that it's easier to hilight errors in the model viewer, and get the artists to fix it. Cheers, Phil Alex Clarke <alexc@...> Sent by: To: "'Jason Zisk'" <ziskj@...>, gdalgorithmslistadmin@... gdalgorithmslist@... eforge.net cc: Subject: RE: [Algorithms] Generating Shadow Volumes with open geometry 02/27/2002 01:08 AM Generally you need shadow volumes to be sealed, particularly if you are using the robust variant of stencil shadows (the one where you inc / dec the stencil value where the ztest fails). In Malice we tag surfaces as being display and or shadow. If an object casts shadows, the shadow surface must be properly sealed and manifold. There is no such requirement for display faces. Designing levels / art from scratch to be sealed is generally OK. However retrofitting objects to be sealed is really quite a chore. It might be possible to write a tool to auto seal an object, although that sounds like a hard thing to write. In the end you have to work out what's better: spending (perhaps a lot of) artist time on a solution that will work OR a potentially open ended research project that might save lots of artist time. Alex Clarke, Programmer (www.argonaut.com/malice.asp) Argonaut Games PLC > Original Message > From: Jason Zisk [mailto:ziskj@...] > Sent: 27 February 2002 04:32 > To: gdalgorithmslist@... > Subject: [Algorithms] Generating Shadow Volumes with open geometry > > > Quick question about shadow volumes. A lot of our geometry > is "open", for > instance a cylinder with no top or bottom. When generating a > shadow volume > for it, what do you do with the triangle edges that aren't > shared between > two triangles when it comes to checking if the edge is a > silhouette? With > two triangles you just see if one is facing the light and one > isnt, then > extrude that edge. With only one triangle, do you simply check if the > triangle is backfacing, if so extrude? I'd like to hear > what others do in > this situation. > > Thanks, > >  Jason Zisk >  nFusion Interactive LLC > > > > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 
From: Jon Watte <hplus@mi...>  20020227 17:08:43

I have no idea what the function is that maps a 16bit depth value to a 32bit color value, but suppose it just adds zeros to the high halfword. Then the high byte of the depth buffer would end up in the green byte of the 32bit color value, and thus it would be quite natural that the green one was the one you wanted, as it will then basically be the 8bit version of the full depth buffer. Of course, the mapping may work totally differently, in which case I'm interested in hearing about that mapping (but probably in another thread :) Cheers, / h+ > This is the green channel of the Zbufferreadasatexture. So nothing to > do with perception at all. The red/green/blue selection just determines > which particular set of bits we use out of the 16 that the Z buffer has to > offer. At no time is the colour actually shown on the screen. 
From: Jon Watte <hplus@mi...>  20020227 17:08:42

> Just out of interest, does anyone know how mip mapping works on > graphics hardware? More specifically, how does the hardware > factor in the angle of the triangle into the LOD selection equation (is > this done in the driver, or is it actually a hardware feature)? For hardware transform cards, this has to be a hardware feature, else they'd have to run a full position transform in software just to determine the MIP level, which kinda defeats the purpose. > Also, when specifying UV's and using bilinear filtering we all know > its important to start a half pixel inwards to avoid the filtering picking > up the wrong texel edges. However, mipmapping can change the map > resolution (and thus the size of half a pixel in UVs) per pixel, > so how on earth do you factor this into the equation? Either you turn on edge clamping (which will clamp to the middle of the outermost pixel) or, if you're using texture sheets, you speicify that no texture vertex can be closer to the edge of one sheet component than (2**N) pixels, and then tell the hardware to only use N+1 MIP levels. For example, on a 256x256 texture sheet with a border of 4 pixels, you will be at the center of a border pixel at the 32x32 resolution, so you tell the MIP engine to use levels 0 (base) through 3 (32x32). Or you decide to not use MIP mapping for textures that have these problems, and only use it for fully tiling grass/rock/brick/whatever. Cheers, / h+ 
From: MH<armon@bl...>  20020227 16:29:48

So is using the ZBuffer as a Texture to create Depth of Field the same technique used for Smoke Blurs, that are regularly seen in Driving Games? 
From: Chris Kline <ckline@ir...>  20020227 15:12:53

From reading your message it seems like you are copying all the render state and vertex information into multiple new Render_Objs each time you render. This is very inefficient. A better approach might be to have each node in the world store pointers to "attributes" such as lighting state, material color, vertices, etc. That way if you need to copy a Render_Obj, you simply copy the pointers instead of deepcopying the data (this also allows multiple objects in the world to share data). Most of the engines I have looked at and worked on perform sorting in this way: 1) traverse the scene, computing a localtoworld transform for each renderable object. 2) group each renderable object into one of several buckets 3) sorting the objects in each buckets in a bucketspecific order 4) rendering all the buckets in a particular bucketorder (each object in each bucket is rendered in world space using the transform computed in step 1). Since material sorting and depthsorting are difficult to reconcile (in a typical scene), transparent objects are placed in to the depthsort bucket, and the remaining ones are placed in the nontransparent bucket. The transparent bucket is sorted by depth (backtofront), and the nontransparent bucket is sorted by material. Then the nontransparent objects are rendered in sorted order (relying on zbuffering for proper depth) and then the transparent objects are rendered backtofront. You might also include special types of buckets for other purposes (rendering certain subscenes in a particular order, etc), or attempt to sort your nontransparent materials fronttoback in order to take advantage of the depthculling available on newer graphics hardware. The bottom line is that there is no best way to sort, so make your sorting code flexible, and profile your scenes to find the sorting method that gives the best results. Regarding your first question, I'm not sure why state/z sorting would prevent you from writing your particle data directly into a dynamic buffer. Typically, all your particles will share the same render state (texture, lighting properties, etc). Also, particles systems are usually depthsorted based on centroid or some other global metric (I've never seen an engine that depthsorts individual particles). For more information, check out John Ratcliff's notes and slides from his talk at GDC2001. They are speech.doc and speech.ppt available at: http://jratcliff.flipcode.com/ It's an excellent introduction to 3d engine structure for modern T&L graphics cards, and is being used (as far as I know) in Planetside, Sony's new MMP shooter. Looked very impressive at his GDC presentation, and he gave a great talk. It's also educational to wade through the code and docs for SGL, an opensource OpenGLbased scene graph on SourceForge. It should give you some good ideas for state management/sorting and attribute and data storage. http://sourceforge.net/projects/sgl/ And I have to agree with Parveen Kaler's response  the only way to write a good engine is to write a bunch of them. Good luck! chris kline irrational games Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...]On Behalf Of zhang jason Sent: Wednesday, February 27, 2002 12:06 AM To: gdalgorithmslist@... Subject: [Algorithms] questions about graphics engine structure Hi Folks, Here are some questions for which I cannot find satisfying solutions. Now my engine is divided into three parts: First part is the actual graphic world, include terrain, rooms, particle system, static mesh, etc. It does rendering by creating Render_Objs and transfering these objs to next part. The Render_Obj records world_matrix, lighting parameters, static vertex buffer(or raw vertex arrays if dynamic), textures, render_effects, etc. Second part will classify and sort those Render_Objs and render them by calling the functions from the third part. Third part is the abstract layer on Graphics API(OGL and D3D). My questions are: 1. For dynamic objects such as particle system, I have to first write vertex data into my arrays, then copy it to dynamic vbuffer in next engine_part. Under my current structure, sorting in 2nd part prevents from writing directly into the dynamic buffer. Is there a way to eliminate one copy? 2. Having to record almost all the rendering infomation, the Render_Obj is a big object. Is it reasonable to write a Render_Obj for every render call? 3. How do you sort your objects by textures, render_effect, Z_depth, etc in your engine structure? 4. Is this structure reasonable? (I mean Can it fit into real game needs?) 5. What is the most common way? Or there are a few ways different from each other very much? I'm eager to learn knowledge about engine_design, so any advices, links are appreciate. Jason Z. 
From: Stephen J Baker <sjbaker@li...>  20020227 14:38:33

On Wed, 27 Feb 2002, Paul Firth wrote: > Just out of interest, does anyone know how mip mapping works on > graphics hardware? It's described in some detail in the OpenGL specification (not the usual Red/Blue books  I mean the actual formal specification on http://www.opengl.org). > More specifically, how does the hardware > factor in the angle of the triangle into the LOD selection equation (is > this done in the driver, or is it actually a hardware feature)? What is done (down in the hardware) for each pixel that's rendered is something more or less functionally equivelent to this algorithm: * Compute the texture coordinates of the four corners of each pixel. * You can use those coordinates to imagine the pixel as a little quadrilateral drawn on top of your texture map. * Look at the maximum width and height of the pixel in texturespace. * Take the largest of those two numbers. * Take logtobase2 of that. * Some OpenGL implementations allow you to bias that number up or down using an OpenGL extension. OpenGL 1.2 allows you to clamp that number to a smaller range. * This number is the MIPmap level you need. * Since the number is not (in general) an integer, you either pick the nearest integer and use that to select a MIPmap to use for this pixel  or you can do a linear blend between the next larger and next smaller MIPmap. The result of that is that the orientation, range and size of the textured polygon are all taken into account. On some *very* ancient hardware, the MIPmap level for the entire polygon was estimated once for each triangle in software  but those systems are not common anymore because they look like *CRAP*. There are better ways to do this (but they aren't cheap in hardware terms)  and some modern cards have Anisotropic MIPmapping which tends to stop polygons from getting so fuzzy as they go edgeon. > Also, when specifying UV's and using bilinear filtering we all know > its important to start a half pixel inwards to avoid the filtering picking > up the wrong texel edges. However, mipmapping can change the map > resolution (and thus the size of half a pixel in UVs) per pixel, > so how on earth do you factor this into the equation? You don't. :( Read my FAQ: http://www.sjbaker.org/steve/omniv/tiling_textures.html  Steve Baker (817)6192657 (Vox/VoxMail) L3Com/Link Simulation & Training (817)6192466 (Fax) Work: sjbaker@... http://www.link.com Home: sjbaker1@... http://www.sjbaker.org 
From: Tom Forsyth <tomf@mu...>  20020227 13:45:43

This is the green channel of the Zbufferreadasatexture. So nothing to do with perception at all. The red/green/blue selection just determines which particular set of bits we use out of the 16 that the Z buffer has to offer. At no time is the colour actually shown on the screen. Which channel you use will depend on exactly whay you near & far clip planes are. Ours happened to work out so that green was the one most useful for depthoffocus. 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: Martin Gladnishki [mailto:bzb@...] > Sent: 27 February 2002 14:30 > To: GDAlgorithmslist@... > Subject: Re: [Algorithms] Depth of Field and Smoke Blurs > > > > Just a lot of mucking about, really. Green just proved to be > > the most useful in our game. There is no clearcut explanation > > for it. :) > > Maybe because the human eye is more sensitive to the green > channel than to > the red/blue. > > Cheers, > Martin 
From: Martin Gladnishki <bzb@wi...>  20020227 13:31:36

> Just a lot of mucking about, really. Green just proved to be > the most useful in our game. There is no clearcut explanation > for it. :) Maybe because the human eye is more sensitive to the green channel than to the red/blue. Cheers, Martin 
From: Ulf Ochsenfahrt <ulfjack@gm...>  20020227 13:17:46

There is the problem. The amount of edges in the edge list is not static. Edges may need to be included although no edges can be removed. That is, just checking the edges in the list may not suffice as it might be possible that none of them may be removed though new edges must be included. (??) (I may be wrong at this point?) Of course, the silhoutte line must always be closed, but for nonconvex may have more than one (closed) silhoutte line. Imagine two Balls at opposite ends of a stick. When the stick points directly to the sun, you have two silhoutte lines. (Like two circles.) When the stick does not point to the sun, you may only have one silhoutte line. (Two circles connected by a quad.) So, my question is: Does it suffice to check the "active edges" list? By the way, you're right. My first posting is not very much of an improvement. Only if it's possible to quickly determine whether a face has changed orientation. Is it?  Ulf "Willem H. de Boer" <Willem@...> wrote on 27/02/02 13:09:36: > >"start with the {edge list} of the >last frame and if an edge of the last frame is not a silhouette >edge in this frame, check the edges it connects to." > >Oh, I think I should point out that with {edge list} I mean >the silhouette edge list, not the entire mesh's edge list > >Original Message >From: Ulf Ochsenfahrt [mailto:ulfjack@...] >Sent: 27 February 2002 11:32 >To: GDAlgorithms List >Subject: RE:[2] [Algorithms] Generating Shadow Volumes with open >geometry > > >I think I'd do this differently. > >What about this: >Put in a bit flag for each triangle which show which way the triangle is >facing. Whenever a triangle changes, you check the adjacent edges. >Some of the are then moved out of the silhouette edges list and some >are inserted. > >This may be more accurate if you have concave objects. > > Ulf. > >"Willem H. de Boer" <Willem@...> wrote on 27/02/02 10:31:22: >> >>Well, one way of going about speeding up edge detection, would >>be temporal coherence. So, calculate the silhouette edges for >>the shadowcasting object the expensive way (some winged edge >>structure, find the edges connecting a backfacing triangle >>with a frontfacing one), and store it in a list. Then for the >>next frame, or after T frames, start with the edge list of the >>last frame and if an edge of the last frame is not a silhouette >>edge in this frame, check the edges it connects to. This saves >>a lot of edge tracking; more efficient with higher temporal coherence. >> >>Cheers, >> >>Willem >>MuckyFoot Goat Boy >> >>Original Message >>From: Chris Perry [mailto:perry@...] >>Sent: 27 February 2002 08:16 >>To: gdalgorithmslist@... >>Subject: RE: [Algorithms] Generating Shadow Volumes with open geometry >> >> >>if a triangle is facing the light, then you can safely extrude any edges >>that >>either have no neighbor or have a neighbor that is not facing the light. >> >>It's funny, I'm actually working on shadow volumes right now and I was >>trying to think of a way to speed up the edge detection process. It >>wouldn't >>work on objects with holes, but if you knew you had a solid object >>you could theoretically trace one edge to the next until you came >>full circle, right? limiting the search space to only child edges. >>I've been wasting too much time trying to create a tree structure that >>links them together in a way which won't produce endless circles. I >>think you have to treat the edges as symbolic vectors and keep >>a "head" to "tail" orientation... i.e. an edge is a child if it's "tail" is >>the >>parent edge's "head"... hmmm...who knows, maybe it's impossible... >> >>Chris Perry >>Angel Studios >> >> >> >>Original Message >>From: Jason Zisk [SMTP:ziskj@...] >>Sent: Tuesday, February 26, 2002 8:32 PM >>To: gdalgorithmslist@... >>Subject: [Algorithms] Generating Shadow Volumes with open geometry >> >>Quick question about shadow volumes. A lot of our geometry is "open", for >>instance a cylinder with no top or bottom. When generating a shadow volume >>for it, what do you do with the triangle edges that aren't shared between >>two triangles when it comes to checking if the edge is a silhouette? With >>two triangles you just see if one is facing the light and one isnt, then >>extrude that edge. With only one triangle, do you simply check if the >>triangle is backfacing, if so extrude? I'd like to hear what others do in >>this situation. >> >>Thanks, >> >>  Jason Zisk >> nFusion Interactive LLC >> >> >> >> >>_______________________________________________ >>GDAlgorithmslist mailing list >>GDAlgorithmslist@... >>https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist >>Archives: >>http://sourceforge.net/mailarchive/forum.php?forum_id=6188 >> >>_______________________________________________ >>GDAlgorithmslist mailing list >>GDAlgorithmslist@... >>https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist >>Archives: >>http://sourceforge.net/mailarchive/forum.php?forum_id=6188 >> >>_______________________________________________ >>GDAlgorithmslist mailing list >>GDAlgorithmslist@... >>https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist >>Archives: >>http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > > >_______________________________________________ >GDAlgorithmslist mailing list >GDAlgorithmslist@... >https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist >Archives: >http://sourceforge.net/mailarchive/forum.php?forum_id=6188 
From: Tom Forsyth <tomf@mu...>  20020227 12:56:14

The other way to things is to divide objectlocal space into segments = (e.g. using a BSP tree). Each segment stores the silhouetteedge list that is correct when the camera is inside that segment. This can either be done perfectly, or the segments can be larger, and the list of edges only be = a "probable" list. The list will hold all possible silhouette edges, but = some of them may not actually be silhouettes, depending on camera position. = This reduces the number of segments, but obviously increases computation = time. This is similar to the partitioning used in "Silhouette Clipping"  P. Sander, X. Gu, S. Gortler, H. Hoppe, J. Snyder and "Silhouette Mapping" =  X. Gu, S. Gortler, H. Hoppe, L. McMillan, B. Brown, A. Stone. (both = available from http://www.research.microsoft.com/~hoppe/), though it's been a = while since I read these papers, so I forget the details. This method may be combined with any of the others mentioned of course. 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: Willem H. de Boer [mailto:Willem@...] > Sent: 27 February 2002 12:45 > To: Emmanuel Astier; GDAlgorithms List > Subject: RE: [2] [Algorithms] Generating Shadow Volumes with open > geometr y >=20 >=20 > The method I mentioned only gives a speedup with reasonably > high temporal coherence. It's still an O(N) algorithm with > a worst case scenario of having to check every edge of the > mesh. Reusing the silhouette edge list from the previous > frame gives you a starting point, and you basically work > from there, so if the immediate neighbouring edge isn't > a silhouette edge, you move on to the immediate > neighbouring edge's neighbour, and so on.=20 >=20 > Reusing the silhouette edge list of the previous frame > basically gives you a headstart and will hopefully get > you to the right solution quicker. >=20 > Cheers, >=20 > Willem > MuckyFoot Goat Boy >=20 > Original Message > From: Emmanuel Astier [mailto:emmanuel.astier@...] > Sent: 27 February 2002 12:36 > To: GDAlgorithms List > Subject: RE: [2] [Algorithms] Generating Shadow Volumes with open > geometry >=20 >=20 > But that only works if the light+mesh move is small enougth. > You can't insure every edge of the silhouette at trame t as a common > triangle with a edge at trame t1 ? >=20 > And if you're using quad, it's very possible that the silhouette edge > come from one of the quad edge to the quad opposite edge... > * > /* > / * > * * > * * > * * > * * > \ * > \* > * >=20 >=20 > Here if the light moves ( in the quad world ) is orthogonal to the = '*' > edges, the silhouette will jump from the first * edge to the = second... >=20 > Am I completely wrong ??? >=20 > Emmanuel >=20 >=20 >=20 > > Original Message > > From: Willem H. de Boer [mailto:Willem@...] > > Sent: mercredi 27 f=E9vrier 2002 13:10 > > To: Ulf Ochsenfahrt; GDAlgorithms List > > Subject: RE: [2] [Algorithms] Generating Shadow Volumes with open > > geometry > >=20 > >=20 > > "start with the {edge list} of the=20 > > last frame and if an edge of the last frame is not a silhouette=20 > > edge in this frame, check the edges it connects to." > >=20 > > Oh, I think I should point out that with {edge list} I mean > > the silhouette edge list, not the entire mesh's edge list > >=20 > > Original Message > > From: Ulf Ochsenfahrt [mailto:ulfjack@...] > > Sent: 27 February 2002 11:32 > > To: GDAlgorithms List > > Subject: RE:[2] [Algorithms] Generating Shadow Volumes with open > > geometry > >=20 > >=20 > > I think I'd do this differently. > >=20 > > What about this: > > Put in a bit flag for each triangle which show which way the=20 > > triangle is > > facing. Whenever a triangle changes, you check the adjacent edges. > > Some of the are then moved out of the silhouette edges list and = some > > are inserted. > >=20 > > This may be more accurate if you have concave objects. > >=20 > >  Ulf. > >=20 > > "Willem H. de Boer" <Willem@...> wrote on=20 > 27/02/02 10:31:22: > > > > > >Well, one way of going about speeding up edge detection, would > > >be temporal coherence. So, calculate the silhouette edges for > > >the shadowcasting object the expensive way (some winged edge > > >structure, find the edges connecting a backfacing triangle > > >with a frontfacing one), and store it in a list. Then for the=20 > > >next frame, or after T frames, start with the edge list of the=20 > > >last frame and if an edge of the last frame is not a silhouette=20 > > >edge in this frame, check the edges it connects to. This saves=20 > > >a lot of edge tracking; more efficient with higher temporal=20 > > coherence. > > > > > >Cheers, > > > > > >Willem > > >MuckyFoot Goat Boy > > > > > >Original Message > > >From: Chris Perry [mailto:perry@...] > > >Sent: 27 February 2002 08:16 > > >To: gdalgorithmslist@... > > >Subject: RE: [Algorithms] Generating Shadow Volumes with=20 > > open geometry > > > > > > > > >if a triangle is facing the light, then you can safely=20 > > extrude any edges > > >that=20 > > >either have no neighbor or have a neighbor that is not=20 > > facing the light. > > > > > >It's funny, I'm actually working on shadow volumes right now=20 > > and I was > > >trying to think of a way to speed up the edge detection=20 > process. It > > >wouldn't > > >work on objects with holes, but if you knew you had a solid object > > >you could theoretically trace one edge to the next until you came=20 > > >full circle, right? limiting the search space to only=20 > child edges. > > >I've been wasting too much time trying to create a tree=20 > > structure that > > >links them together in a way which won't produce endless=20 > circles. I=20 > > >think you have to treat the edges as symbolic vectors and keep=20 > > >a "head" to "tail" orientation... i.e. an edge is a child if=20 > > it's "tail" is > > >the > > >parent edge's "head"... hmmm...who knows, maybe it's impossible... > > > > > >Chris Perry > > >Angel Studios > > > > > > > > > > > >Original Message > > >From: Jason Zisk [SMTP:ziskj@...] > > >Sent: Tuesday, February 26, 2002 8:32 PM > > >To: gdalgorithmslist@... > > >Subject: [Algorithms] Generating Shadow Volumes with=20 > > open geometry > > > > > >Quick question about shadow volumes. A lot of our geometry=20 > > is "open", for > > >instance a cylinder with no top or bottom. When generating=20 > > a shadow volume > > >for it, what do you do with the triangle edges that aren't=20 > > shared between > > >two triangles when it comes to checking if the edge is a=20 > > silhouette? With > > >two triangles you just see if one is facing the light and=20 > > one isnt, then > > >extrude that edge. With only one triangle, do you simply=20 > > check if the > > >triangle is backfacing, if so extrude? I'd like to hear=20 > > what others do in > > >this situation. > > > > > >Thanks, > > > > > >  Jason Zisk > > > nFusion Interactive LLC > > > > > > > > > > > > > > >_______________________________________________ > > >GDAlgorithmslist mailing list > > >GDAlgorithmslist@... > > >https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > > >Archives: > > >http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 > > > > > >_______________________________________________ > > >GDAlgorithmslist mailing list > > >GDAlgorithmslist@... > > >https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > > >Archives: > > >http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 > > > > > >_______________________________________________ > > >GDAlgorithmslist mailing list > > >GDAlgorithmslist@... > > >https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > > >Archives: > > >http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 > >=20 > >=20 > >=20 > > _______________________________________________ > > GDAlgorithmslist mailing list > > GDAlgorithmslist@... > > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > > Archives: > > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 > >=20 > > _______________________________________________ > > GDAlgorithmslist mailing list > > GDAlgorithmslist@... > > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > > Archives: > > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 > >=20 >=20 > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_ida88 >=20 > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_ida88 >=20 
From: Willem H. de Boer <W<illem@mu...>  20020227 12:46:01

The method I mentioned only gives a speedup with reasonably high temporal coherence. It's still an O(N) algorithm with a worst case scenario of having to check every edge of the mesh. Reusing the silhouette edge list from the previous frame gives you a starting point, and you basically work from there, so if the immediate neighbouring edge isn't a silhouette edge, you move on to the immediate neighbouring edge's neighbour, and so on.=20 Reusing the silhouette edge list of the previous frame basically gives you a headstart and will hopefully get you to the right solution quicker. Cheers, Willem MuckyFoot Goat Boy Original Message From: Emmanuel Astier [mailto:emmanuel.astier@...] Sent: 27 February 2002 12:36 To: GDAlgorithms List Subject: RE: [2] [Algorithms] Generating Shadow Volumes with open geometry But that only works if the light+mesh move is small enougth. You can't insure every edge of the silhouette at trame t as a common triangle with a edge at trame t1 ? And if you're using quad, it's very possible that the silhouette edge come from one of the quad edge to the quad opposite edge... * /* / * * * * * * * * * \ * \* * Here if the light moves ( in the quad world ) is orthogonal to the '*' edges, the silhouette will jump from the first * edge to the second... Am I completely wrong ??? Emmanuel > Original Message > From: Willem H. de Boer [mailto:Willem@...] > Sent: mercredi 27 f=E9vrier 2002 13:10 > To: Ulf Ochsenfahrt; GDAlgorithms List > Subject: RE: [2] [Algorithms] Generating Shadow Volumes with open > geometry >=20 >=20 > "start with the {edge list} of the=20 > last frame and if an edge of the last frame is not a silhouette=20 > edge in this frame, check the edges it connects to." >=20 > Oh, I think I should point out that with {edge list} I mean > the silhouette edge list, not the entire mesh's edge list >=20 > Original Message > From: Ulf Ochsenfahrt [mailto:ulfjack@...] > Sent: 27 February 2002 11:32 > To: GDAlgorithms List > Subject: RE:[2] [Algorithms] Generating Shadow Volumes with open > geometry >=20 >=20 > I think I'd do this differently. >=20 > What about this: > Put in a bit flag for each triangle which show which way the=20 > triangle is > facing. Whenever a triangle changes, you check the adjacent edges. > Some of the are then moved out of the silhouette edges list and some > are inserted. >=20 > This may be more accurate if you have concave objects. >=20 >  Ulf. >=20 > "Willem H. de Boer" <Willem@...> wrote on 27/02/02 = 10:31:22: > > > >Well, one way of going about speeding up edge detection, would > >be temporal coherence. So, calculate the silhouette edges for > >the shadowcasting object the expensive way (some winged edge > >structure, find the edges connecting a backfacing triangle > >with a frontfacing one), and store it in a list. Then for the=20 > >next frame, or after T frames, start with the edge list of the=20 > >last frame and if an edge of the last frame is not a silhouette=20 > >edge in this frame, check the edges it connects to. This saves=20 > >a lot of edge tracking; more efficient with higher temporal=20 > coherence. > > > >Cheers, > > > >Willem > >MuckyFoot Goat Boy > > > >Original Message > >From: Chris Perry [mailto:perry@...] > >Sent: 27 February 2002 08:16 > >To: gdalgorithmslist@... > >Subject: RE: [Algorithms] Generating Shadow Volumes with=20 > open geometry > > > > > >if a triangle is facing the light, then you can safely=20 > extrude any edges > >that=20 > >either have no neighbor or have a neighbor that is not=20 > facing the light. > > > >It's funny, I'm actually working on shadow volumes right now=20 > and I was > >trying to think of a way to speed up the edge detection process. It > >wouldn't > >work on objects with holes, but if you knew you had a solid object > >you could theoretically trace one edge to the next until you came=20 > >full circle, right? limiting the search space to only child edges. > >I've been wasting too much time trying to create a tree=20 > structure that > >links them together in a way which won't produce endless circles. I=20 > >think you have to treat the edges as symbolic vectors and keep=20 > >a "head" to "tail" orientation... i.e. an edge is a child if=20 > it's "tail" is > >the > >parent edge's "head"... hmmm...who knows, maybe it's impossible... > > > >Chris Perry > >Angel Studios > > > > > > > >Original Message > >From: Jason Zisk [SMTP:ziskj@...] > >Sent: Tuesday, February 26, 2002 8:32 PM > >To: gdalgorithmslist@... > >Subject: [Algorithms] Generating Shadow Volumes with=20 > open geometry > > > >Quick question about shadow volumes. A lot of our geometry=20 > is "open", for > >instance a cylinder with no top or bottom. When generating=20 > a shadow volume > >for it, what do you do with the triangle edges that aren't=20 > shared between > >two triangles when it comes to checking if the edge is a=20 > silhouette? With > >two triangles you just see if one is facing the light and=20 > one isnt, then > >extrude that edge. With only one triangle, do you simply=20 > check if the > >triangle is backfacing, if so extrude? I'd like to hear=20 > what others do in > >this situation. > > > >Thanks, > > > >  Jason Zisk > > nFusion Interactive LLC > > > > > > > > > >_______________________________________________ > >GDAlgorithmslist mailing list > >GDAlgorithmslist@... > >https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > >Archives: > >http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 > > > >_______________________________________________ > >GDAlgorithmslist mailing list > >GDAlgorithmslist@... > >https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > >Archives: > >http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 > > > >_______________________________________________ > >GDAlgorithmslist mailing list > >GDAlgorithmslist@... > >https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > >Archives: > >http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 >=20 >=20 >=20 > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 >=20 > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 >=20 _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_ida88 
From: Emmanuel Astier <emmanuel.astier@wi...>  20020227 12:36:09

But that only works if the light+mesh move is small enougth. You can't insure every edge of the silhouette at trame t as a common triangle with a edge at trame t1 ? And if you're using quad, it's very possible that the silhouette edge come from one of the quad edge to the quad opposite edge... * /* / * * * * * * * * * \ * \* * Here if the light moves ( in the quad world ) is orthogonal to the '*' edges, the silhouette will jump from the first * edge to the second... Am I completely wrong ??? Emmanuel > Original Message > From: Willem H. de Boer [mailto:Willem@...] > Sent: mercredi 27 f=E9vrier 2002 13:10 > To: Ulf Ochsenfahrt; GDAlgorithms List > Subject: RE: [2] [Algorithms] Generating Shadow Volumes with open > geometry >=20 >=20 > "start with the {edge list} of the=20 > last frame and if an edge of the last frame is not a silhouette=20 > edge in this frame, check the edges it connects to." >=20 > Oh, I think I should point out that with {edge list} I mean > the silhouette edge list, not the entire mesh's edge list >=20 > Original Message > From: Ulf Ochsenfahrt [mailto:ulfjack@...] > Sent: 27 February 2002 11:32 > To: GDAlgorithms List > Subject: RE:[2] [Algorithms] Generating Shadow Volumes with open > geometry >=20 >=20 > I think I'd do this differently. >=20 > What about this: > Put in a bit flag for each triangle which show which way the=20 > triangle is > facing. Whenever a triangle changes, you check the adjacent edges. > Some of the are then moved out of the silhouette edges list and some > are inserted. >=20 > This may be more accurate if you have concave objects. >=20 >  Ulf. >=20 > "Willem H. de Boer" <Willem@...> wrote on 27/02/02 10:31:22: > > > >Well, one way of going about speeding up edge detection, would > >be temporal coherence. So, calculate the silhouette edges for > >the shadowcasting object the expensive way (some winged edge > >structure, find the edges connecting a backfacing triangle > >with a frontfacing one), and store it in a list. Then for the=20 > >next frame, or after T frames, start with the edge list of the=20 > >last frame and if an edge of the last frame is not a silhouette=20 > >edge in this frame, check the edges it connects to. This saves=20 > >a lot of edge tracking; more efficient with higher temporal=20 > coherence. > > > >Cheers, > > > >Willem > >MuckyFoot Goat Boy > > > >Original Message > >From: Chris Perry [mailto:perry@...] > >Sent: 27 February 2002 08:16 > >To: gdalgorithmslist@... > >Subject: RE: [Algorithms] Generating Shadow Volumes with=20 > open geometry > > > > > >if a triangle is facing the light, then you can safely=20 > extrude any edges > >that=20 > >either have no neighbor or have a neighbor that is not=20 > facing the light. > > > >It's funny, I'm actually working on shadow volumes right now=20 > and I was > >trying to think of a way to speed up the edge detection process. It > >wouldn't > >work on objects with holes, but if you knew you had a solid object > >you could theoretically trace one edge to the next until you came=20 > >full circle, right? limiting the search space to only child edges. > >I've been wasting too much time trying to create a tree=20 > structure that > >links them together in a way which won't produce endless circles. I=20 > >think you have to treat the edges as symbolic vectors and keep=20 > >a "head" to "tail" orientation... i.e. an edge is a child if=20 > it's "tail" is > >the > >parent edge's "head"... hmmm...who knows, maybe it's impossible... > > > >Chris Perry > >Angel Studios > > > > > > > >Original Message > >From: Jason Zisk [SMTP:ziskj@...] > >Sent: Tuesday, February 26, 2002 8:32 PM > >To: gdalgorithmslist@... > >Subject: [Algorithms] Generating Shadow Volumes with=20 > open geometry > > > >Quick question about shadow volumes. A lot of our geometry=20 > is "open", for > >instance a cylinder with no top or bottom. When generating=20 > a shadow volume > >for it, what do you do with the triangle edges that aren't=20 > shared between > >two triangles when it comes to checking if the edge is a=20 > silhouette? With > >two triangles you just see if one is facing the light and=20 > one isnt, then > >extrude that edge. With only one triangle, do you simply=20 > check if the > >triangle is backfacing, if so extrude? I'd like to hear=20 > what others do in > >this situation. > > > >Thanks, > > > >  Jason Zisk > > nFusion Interactive LLC > > > > > > > > > >_______________________________________________ > >GDAlgorithmslist mailing list > >GDAlgorithmslist@... > >https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > >Archives: > >http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 > > > >_______________________________________________ > >GDAlgorithmslist mailing list > >GDAlgorithmslist@... > >https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > >Archives: > >http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 > > > >_______________________________________________ > >GDAlgorithmslist mailing list > >GDAlgorithmslist@... > >https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > >Archives: > >http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 >=20 >=20 >=20 > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 >=20 > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 >=20 
From: Willem H. de Boer <W<illem@mu...>  20020227 12:10:42

"start with the {edge list} of the last frame and if an edge of the last frame is not a silhouette edge in this frame, check the edges it connects to." Oh, I think I should point out that with {edge list} I mean the silhouette edge list, not the entire mesh's edge list Original Message From: Ulf Ochsenfahrt [mailto:ulfjack@...] Sent: 27 February 2002 11:32 To: GDAlgorithms List Subject: RE:[2] [Algorithms] Generating Shadow Volumes with open geometry I think I'd do this differently. What about this: Put in a bit flag for each triangle which show which way the triangle is facing. Whenever a triangle changes, you check the adjacent edges. Some of the are then moved out of the silhouette edges list and some are inserted. This may be more accurate if you have concave objects.  Ulf. "Willem H. de Boer" <Willem@...> wrote on 27/02/02 10:31:22: > >Well, one way of going about speeding up edge detection, would >be temporal coherence. So, calculate the silhouette edges for >the shadowcasting object the expensive way (some winged edge >structure, find the edges connecting a backfacing triangle >with a frontfacing one), and store it in a list. Then for the >next frame, or after T frames, start with the edge list of the >last frame and if an edge of the last frame is not a silhouette >edge in this frame, check the edges it connects to. This saves >a lot of edge tracking; more efficient with higher temporal coherence. > >Cheers, > >Willem >MuckyFoot Goat Boy > >Original Message >From: Chris Perry [mailto:perry@...] >Sent: 27 February 2002 08:16 >To: gdalgorithmslist@... >Subject: RE: [Algorithms] Generating Shadow Volumes with open geometry > > >if a triangle is facing the light, then you can safely extrude any edges >that >either have no neighbor or have a neighbor that is not facing the light. > >It's funny, I'm actually working on shadow volumes right now and I was >trying to think of a way to speed up the edge detection process. It >wouldn't >work on objects with holes, but if you knew you had a solid object >you could theoretically trace one edge to the next until you came >full circle, right? limiting the search space to only child edges. >I've been wasting too much time trying to create a tree structure that >links them together in a way which won't produce endless circles. I >think you have to treat the edges as symbolic vectors and keep >a "head" to "tail" orientation... i.e. an edge is a child if it's "tail" is >the >parent edge's "head"... hmmm...who knows, maybe it's impossible... > >Chris Perry >Angel Studios > > > >Original Message >From: Jason Zisk [SMTP:ziskj@...] >Sent: Tuesday, February 26, 2002 8:32 PM >To: gdalgorithmslist@... >Subject: [Algorithms] Generating Shadow Volumes with open geometry > >Quick question about shadow volumes. A lot of our geometry is "open", for >instance a cylinder with no top or bottom. When generating a shadow volume >for it, what do you do with the triangle edges that aren't shared between >two triangles when it comes to checking if the edge is a silhouette? With >two triangles you just see if one is facing the light and one isnt, then >extrude that edge. With only one triangle, do you simply check if the >triangle is backfacing, if so extrude? I'd like to hear what others do in >this situation. > >Thanks, > >  Jason Zisk > nFusion Interactive LLC > > > > >_______________________________________________ >GDAlgorithmslist mailing list >GDAlgorithmslist@... >https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist >Archives: >http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > >_______________________________________________ >GDAlgorithmslist mailing list >GDAlgorithmslist@... >https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist >Archives: >http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > >_______________________________________________ >GDAlgorithmslist mailing list >GDAlgorithmslist@... >https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist >Archives: >http://sourceforge.net/mailarchive/forum.php?forum_id=6188 _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 
From: Willem H. de Boer <W<illem@mu...>  20020227 12:03:45

That's just a more indepth explanation of "start with the edge list of the last frame and if an edge of the last frame is not a silhouette edge in this frame, check the edges it connects to." isn't it? :) But what good would the bitflags be? You'll still have to check triangle orientation the more expensive way each frame (or once every T frames) anyway? Or maybe I misunderstand your method. In which case, feel free to correct me. Willem MuckyFoot Goat Boy Original Message From: Ulf Ochsenfahrt [mailto:ulfjack@...] Sent: 27 February 2002 11:32 To: GDAlgorithms List Subject: RE:[2] [Algorithms] Generating Shadow Volumes with open geometry I think I'd do this differently. What about this: Put in a bit flag for each triangle which show which way the triangle is facing. Whenever a triangle changes, you check the adjacent edges. Some of the are then moved out of the silhouette edges list and some are inserted. This may be more accurate if you have concave objects.  Ulf. "Willem H. de Boer" <Willem@...> wrote on 27/02/02 10:31:22: > >Well, one way of going about speeding up edge detection, would >be temporal coherence. So, calculate the silhouette edges for >the shadowcasting object the expensive way (some winged edge >structure, find the edges connecting a backfacing triangle >with a frontfacing one), and store it in a list. Then for the >next frame, or after T frames, start with the edge list of the >last frame and if an edge of the last frame is not a silhouette >edge in this frame, check the edges it connects to. This saves >a lot of edge tracking; more efficient with higher temporal coherence. > >Cheers, > >Willem >MuckyFoot Goat Boy > >Original Message >From: Chris Perry [mailto:perry@...] >Sent: 27 February 2002 08:16 >To: gdalgorithmslist@... >Subject: RE: [Algorithms] Generating Shadow Volumes with open geometry > > >if a triangle is facing the light, then you can safely extrude any edges >that >either have no neighbor or have a neighbor that is not facing the light. > >It's funny, I'm actually working on shadow volumes right now and I was >trying to think of a way to speed up the edge detection process. It >wouldn't >work on objects with holes, but if you knew you had a solid object >you could theoretically trace one edge to the next until you came >full circle, right? limiting the search space to only child edges. >I've been wasting too much time trying to create a tree structure that >links them together in a way which won't produce endless circles. I >think you have to treat the edges as symbolic vectors and keep >a "head" to "tail" orientation... i.e. an edge is a child if it's "tail" is >the >parent edge's "head"... hmmm...who knows, maybe it's impossible... > >Chris Perry >Angel Studios > > > >Original Message >From: Jason Zisk [SMTP:ziskj@...] >Sent: Tuesday, February 26, 2002 8:32 PM >To: gdalgorithmslist@... >Subject: [Algorithms] Generating Shadow Volumes with open geometry > >Quick question about shadow volumes. A lot of our geometry is "open", for >instance a cylinder with no top or bottom. When generating a shadow volume >for it, what do you do with the triangle edges that aren't shared between >two triangles when it comes to checking if the edge is a silhouette? With >two triangles you just see if one is facing the light and one isnt, then >extrude that edge. With only one triangle, do you simply check if the >triangle is backfacing, if so extrude? I'd like to hear what others do in >this situation. > >Thanks, > >  Jason Zisk > nFusion Interactive LLC > > > > >_______________________________________________ >GDAlgorithmslist mailing list >GDAlgorithmslist@... >https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist >Archives: >http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > >_______________________________________________ >GDAlgorithmslist mailing list >GDAlgorithmslist@... >https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist >Archives: >http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > >_______________________________________________ >GDAlgorithmslist mailing list >GDAlgorithmslist@... >https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist >Archives: >http://sourceforge.net/mailarchive/forum.php?forum_id=6188 _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 
From: Tom Forsyth <tomf@mu...>  20020227 12:02:56

The most common technique is to have two UV interpolators. One tracks the current UV value (and it is this that you use to look up your texel), and the second walks a scanline behind  above the current pixel. You also remember the previous pixel's UV coords in a register. So you now have the UV coords of the current pixel, the pixel above, and the pixel to the left. From these you calculate the dUdV in the X axis and the Y axis. And usually you take the largest of the two magnitudes, take the log2 value, and that's your mipmap value. Specifically: mipmap = log2 ( max ( sqrt(dUdX^2+dVdX^2), sqrt(dUdY^2+dVdY^2) ) ) I believe this is the same as the one given in the OpenGL book (red or blue  can't remember which), and it is the one many hardware manufacturers actually use. Of course, real hardware may do completely different things, especially as we move to tilerendering architectures and so on. In addition, things like cube maps and dependentreads mangle the above equation, since the texture mapping in screen space is no longer planar, and other methods are required to get meaningful mipmap values. But you get the idea. 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: Paul Firth [mailto:pfirth@...] > Sent: 27 February 2002 10:53 > To: GDAlgorithmslist@... > Subject: [Algorithms] mipmapping technicalities > > > Hey ppl, > > Just out of interest, does anyone know how mip mapping works on > graphics hardware? More specifically, how does the hardware > factor in the angle of the triangle into the LOD selection > equation (is > this done in the driver, or is it actually a hardware feature)? > > Also, when specifying UV's and using bilinear filtering we all know > its important to start a half pixel inwards to avoid the > filtering picking > up the wrong texel edges. However, mipmapping can change the map > resolution (and thus the size of half a pixel in UVs) per pixel, > so how on earth do you factor this into the equation? > > Cheers, Paul. > > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > 
From: Ulf Ochsenfahrt <ulfjack@gm...>  20020227 11:56:25

I think I'd do this differently. What about this: Put in a bit flag for each triangle which show which way the triangle is facing. Whenever a triangle changes, you check the adjacent edges. Some of the are then moved out of the silhouette edges list and some are inserted. This may be more accurate if you have concave objects.  Ulf. "Willem H. de Boer" <Willem@...> wrote on 27/02/02 10:31:22: > >Well, one way of going about speeding up edge detection, would >be temporal coherence. So, calculate the silhouette edges for >the shadowcasting object the expensive way (some winged edge >structure, find the edges connecting a backfacing triangle >with a frontfacing one), and store it in a list. Then for the >next frame, or after T frames, start with the edge list of the >last frame and if an edge of the last frame is not a silhouette >edge in this frame, check the edges it connects to. This saves >a lot of edge tracking; more efficient with higher temporal coherence. > >Cheers, > >Willem >MuckyFoot Goat Boy > >Original Message >From: Chris Perry [mailto:perry@...] >Sent: 27 February 2002 08:16 >To: gdalgorithmslist@... >Subject: RE: [Algorithms] Generating Shadow Volumes with open geometry > > >if a triangle is facing the light, then you can safely extrude any edges >that >either have no neighbor or have a neighbor that is not facing the light. > >It's funny, I'm actually working on shadow volumes right now and I was >trying to think of a way to speed up the edge detection process. It >wouldn't >work on objects with holes, but if you knew you had a solid object >you could theoretically trace one edge to the next until you came >full circle, right? limiting the search space to only child edges. >I've been wasting too much time trying to create a tree structure that >links them together in a way which won't produce endless circles. I >think you have to treat the edges as symbolic vectors and keep >a "head" to "tail" orientation... i.e. an edge is a child if it's "tail" is >the >parent edge's "head"... hmmm...who knows, maybe it's impossible... > >Chris Perry >Angel Studios > > > >Original Message >From: Jason Zisk [SMTP:ziskj@...] >Sent: Tuesday, February 26, 2002 8:32 PM >To: gdalgorithmslist@... >Subject: [Algorithms] Generating Shadow Volumes with open geometry > >Quick question about shadow volumes. A lot of our geometry is "open", for >instance a cylinder with no top or bottom. When generating a shadow volume >for it, what do you do with the triangle edges that aren't shared between >two triangles when it comes to checking if the edge is a silhouette? With >two triangles you just see if one is facing the light and one isnt, then >extrude that edge. With only one triangle, do you simply check if the >triangle is backfacing, if so extrude? I'd like to hear what others do in >this situation. > >Thanks, > >  Jason Zisk > nFusion Interactive LLC > > > > >_______________________________________________ >GDAlgorithmslist mailing list >GDAlgorithmslist@... >https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist >Archives: >http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > >_______________________________________________ >GDAlgorithmslist mailing list >GDAlgorithmslist@... >https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist >Archives: >http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > >_______________________________________________ >GDAlgorithmslist mailing list >GDAlgorithmslist@... >https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist >Archives: >http://sourceforge.net/mailarchive/forum.php?forum_id=6188 
From: Paul Firth <pfirth@at...>  20020227 11:51:27

John White wrote: > As for your second point I'm unsure of what you mean. Yes this half offset > is halved but the texel itself is effectively halved too. What I mean is, when specifiying UVs in normalised form (ie 0  1) I factor in the half pixel shift as (1 / (size in pixels)) / 2 which is different for each mip level? Cheers, Paul. 
From: John White <johnw@de...>  20020227 11:27:34

All modern cards perform per pixel mip mapping and as a result it has to be done in silicon. (earlier cards, and software renderers, performed mip mapping on a per poly or per scanline basis) What the silicon does is a relatively simple calculation on the rate of change of the U and V tex coords at that pixel position and base the mip level off that. The angle of the triangle (as well as the texel aspect ratio) affects the U and V rate of change. For an anisotropic mapped texel there can be a huge difference between the U and V rates of change and the HW will make a tradeoff of picking the mip level to balance between the two axes. This ior course is what anisotropic filtering is designed to solve (within a given extreme). As for your second point I'm unsure of what you mean. Yes this half offset is halved but the texel itself is effectively halved too. There is an equation in the OpenGL spec that details the mip level selection process. JohnW Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...]On Behalf Of Paul Firth Sent: 27 February 2002 10:53 To: GDAlgorithmslist@... Subject: [Algorithms] mipmapping technicalities Hey ppl, Just out of interest, does anyone know how mip mapping works on graphics hardware? More specifically, how does the hardware factor in the angle of the triangle into the LOD selection equation (is this done in the driver, or is it actually a hardware feature)? Also, when specifying UV's and using bilinear filtering we all know its important to start a half pixel inwards to avoid the filtering picking up the wrong texel edges. However, mipmapping can change the map resolution (and thus the size of half a pixel in UVs) per pixel, so how on earth do you factor this into the equation? Cheers, Paul. _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=6188 