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}
(3) 
_{Dec}

2015 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}
(12) 
_{Nov}

_{Dec}
(1) 
2016 
_{Jan}

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

_{Jun}
(1) 
_{Jul}

_{Aug}
(1) 
_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 




1
(30) 
2
(21) 
3
(16) 
4
(5) 
5
(6) 
6
(44) 
7
(36) 
8
(41) 
9
(25) 
10
(17) 
11
(19) 
12
(7) 
13
(26) 
14
(33) 
15
(30) 
16
(44) 
17
(38) 
18
(10) 
19
(16) 
20
(39) 
21
(44) 
22
(8) 
23
(23) 
24
(49) 
25
(26) 
26
(15) 
27
(41) 
28
(29) 
29
(41) 
30
(40) 


From: Pop N Fresh <pop_n_fresh@te...>  20001101 19:13:02

You could possibly use an encrypted socket connection. http://www.openssl.org/ Kelvin  Original Message  From: "Peter Dimov" <pdimov@...> To: <gdalgorithmslist@...> Sent: Wednesday, November 01, 2000 3:44 Subject: [Algorithms] encryption algorithm needed > I have a game that periodically reports its state to a scoreboard > server, using a (key, data) format. Key and data are 128 bit integers. > > I want to encrypt the data with the key; the algorithm would ideally be: > > * reasonably easy to implement in C++, Java, and Php; > * not trivial to reverse, assuming the attacker has several valid (key, > data) pairs and access to the source of the decoder. > > Suggestions? > >  > Peter Dimov > Multi Media Ltd. > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > http://lists.sourceforge.net/mailman/listinfo/gdalgorithmslist 
From: Jay Stelly <Jay@va...>  20001101 19:08:03

> Original Message > From: Andrew Sega [mailto:asega@...] > > In the midst of debugging a SutherlandHodgman style polygon > clipper, I came > across an interesting question: > > How many potential triangles can you get by clipping an arbitrary 3D > triangle to an arbitrary 3D box (6 planes)? And how would one > derive such a > result? Applied iteratively, each clipping plane can add at most one edge to the incremental convex polygon. Therefore, at the end of clipping any convex polygon by any number of planes you have at most (startingEdges + clippingPlanes) edges in the resulting polygon. So, for a triangle (3) clipped to 6 planes (a box in this case) you can get at most 9 sides. Since the polygon is convex it can be fan tessellated into n2 triangles, so at most 7 triangles. Since you don't define "arbitrary 3D box" any more precisely than "6 planes" that's the best I can say at this point. Obviously for many definitions of "box" it is impossible for the triangle to clip all 6 planes, so the max number of triangles will be lower, but always less than 7. Jay 
From: Neal Tringham <neal@ps...>  20001101 18:51:06

From: Andrew Sega <asega@...> > > In the midst of debugging a SutherlandHodgman style polygon clipper, I came > across an interesting question: > > Clipping a 2D triangle to a single plane will give you a most 2 resultant > triangles (when the plane cuts two edges). > Clipping a 2D triangle to a box (4 planes) will give you at most 5 resultant > triangles (when the box cuts through all four edges of the box). > > exxtending the question to 3D... > > How many potential triangles can you get by clipping an arbitrary 3D > triangle to an arbitrary 3D box (6 planes)? And how would one derive such a > result? As I recall, the general result is that for clipping a convex polygon of n vertices against m planes, the resulting clipped polygon can have up to (n+m) vertices, though I can't find my proof for this:) You can wave your hands about and say something along the lines of "the maximum number of output vertices is the number of input vertices plus the number of times an input edge could have cut a plane", though. I think it should then be possible to represent the polygon output by the clipper as a convex triangle fan, in which case you have (k2) separate triangles, where k is the number of vertices in the clipped polygon ((n+m) in the paragraph above). Thus for your example, the triangle clipped against the 6 sided box can yield an output polygon with up to 9 vertices, which in turn can be represented as up to 7 separate convex triangles. Hopefully that was of some use... Does anybody have a counter example for this? Or even a proper proof which contradicts it? :) Neal Tringham (Sick Puppies / Empire Interactive) neal@... neal@... 
From: Max McGuire <amcguire@an...>  20001101 18:49:06

In general, I think you should negate the entire 3rd column on the matrix (or row if you are talking the OpenGL/D3D convention for matrices). Max At 11:25 AM 11/1/00 +0100, you wrote: >Is there a general case way to convert lefthanded projection matrices to >righthanded? And if so, what is it? > >I know how to convert my normal D3D compliant perspective projection matrix >correctly. Simply invert the z.z and z.w elements (or in Direct3DX terms: >[3][3] and [3][4]) of my projection matrix. Will this also work with >different types of projection (specifically orthographic) > >Thanks, > >Jim Offerman >Innovade > > >The Atlantis Project >http://www.theatlantisproject.com > >_______________________________________________ >GDAlgorithmslist mailing list >GDAlgorithmslist@... >http://lists.sourceforge.net/mailman/listinfo/gdalgorithmslist 
From: Daniel Renkel <DanielRenkel@ho...>  20001101 18:46:01

hi andrew, probably i got somethign completely wrong, but i get much more tris than you do (already in 2d) and i believe that this is the same in 3d (but talking to a digital anviler makes me think that i miss a point here =0) take a look at the attached jpeg ;o) [best done in your favourite browser] my 2 cents, Daniel "SirLeto" Renkel [D.Renkel@...] technical design director  creactivity and technowhow Future Interactive [http://www.FutureInt.de]  Original Message  From: "Andrew Sega" <asega@...> To: <gdalgorithmslist@...> Sent: Wednesday, November 01, 2000 7:03 PM Subject: [Algorithms] theoretical clipping behavior > > In the midst of debugging a SutherlandHodgman style polygon clipper, I came > across an interesting question: > > Clipping a 2D triangle to a single plane will give you a most 2 resultant > triangles (when the plane cuts two edges). > Clipping a 2D triangle to a box (4 planes) will give you at most 5 resultant > triangles (when the box cuts through all four edges of the box). > > exxtending the question to 3D... > > How many potential triangles can you get by clipping an arbitrary 3D > triangle to an arbitrary 3D box (6 planes)? And how would one derive such a > result? > >  andrew > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > http://lists.sourceforge.net/mailman/listinfo/gdalgorithmslist > 
From: Andrew Sega <asega@di...>  20001101 18:03:45

In the midst of debugging a SutherlandHodgman style polygon clipper, I came across an interesting question: Clipping a 2D triangle to a single plane will give you a most 2 resultant triangles (when the plane cuts two edges). Clipping a 2D triangle to a box (4 planes) will give you at most 5 resultant triangles (when the box cuts through all four edges of the box). exxtending the question to 3D... How many potential triangles can you get by clipping an arbitrary 3D triangle to an arbitrary 3D box (6 planes)? And how would one derive such a result?  andrew 
From: Joe Ante <Joe@Titansoft.de>  20001101 17:48:50

> Secondly I have tried your code for AABB frustum culling which looked like > being an extremely fast test. > Unfortunately the code seems not to work and I am pretty sure the planes I > feed in are correct because they work with other AABB cullers. > I cant really say what the problem is because I dont really grasp the math > behind it. So are there any watchouts? Does this code really work in Umbra? Sorry. I just got that working. I simply changed if ((MP+NP) < 0.0f) return false;// behind clip plane to if ((MP+NP) < 0.0f) return false;// behind clip plane And it seems to work fine. bye joe 
From: Tom Forsyth <tomf@mu...>  20001101 17:43:31

Ah, I see what you're getting at. I sisdestep the problem by doing all my collapse ordering only within each material. So each material has its own collapse order, its own set of vertices, its own LoD level, etc. That way this problem never arises  the two vertex blocks don't need to be interleaved for collapse order  they stay as two separate blocks: Normal: Material1: start 0 num 2000 Material2: start 2000 num 1000 A bit collapsed: Material1: start 0 num 1843 Material2: start 2000 num 792 Very collapsed: Material1: start 0 num 638 Material2: start 2000 num 38 I try to avoid having any dependencies between materials  no shared vertices or edges, because obviously it breaks above scheme. The solutions to this are: (1) Flanges  make extra "skirts" at the edge of materials of polygons that intersect the neighbouring materials. That way there is no geometrical link between the two material chunks, and the Zbuffer gets rid of any "tears". (2) Don't collapse edges. Just don't. Works suprisingly well, and very simple to implement! Just don't start with material edges that are too highpoly. (3) Interpenetrating geometry. Similar to the "flange" idea, but actually in the model. For example, make columns in rooms go through the floor, not just touch it. Make clothes go into the body, not just touch it, etc. (4) Store some extra structures stating the interdependency of the materials. Each thing will say something like "Material1, LoD 347 and material 2, LoD 1983"  and then either both must be below those LoDs, or both above (usually, LoD = tri count). This makes sure that the same edge in the two materials is either collapsed or not  never a mix. This is possibly the ideal method, but it (a) complicates the VIPM logic, and (b) the data can be tricky to generate. 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: Ales Mlakar [mailto:jazzbre@...] > Sent: 28 October 2000 21:35 > To: gdalgorithmslist@... > Subject: Re: [Algorithms] VIPM & Vertex Buffers > > > Thanks for the answers people. > I don't know If I got you right. Every frame I recompute > Only the Index > list (for all triangles (yes I'm using triangle lists)  just > go thru the > temporary index and remap) based on the collapse order, so that many > triangles become deformed (i.e. have >=2 same indexes  btw is that a > problem? because it seems that it handles it well). So when I > render I don't > have to recompute nothing more, just render from my batch info. > The remapping looks like: > > for (i=0;i<numIndices;i++) > RenderIndex[i]=ReMap(TemporaryIndex[i]); > > RenderIndex is the actual index that is used for rendering  > in DX 8.0s > SetIndices (hm don't know if that is that the right function > name in Dx 8, > since I don't have the code here and I'm not really used to the new > functions names yet). > That's all I got to do. > So normally without the verts being in collapse order I'd > have batch info > something like this (example): > batch 0 > material 2 > start 0 > num 1000 > batch 1 > material 4 > start 1000 > num 200 > > Which as you see looks alright, no unnecessary vertex transforms. > > With verts being in collapse order it looks like: > > batch 0 > material 2 > start 2 > num 1200 > batch 1 > material 4 > start 65 > num 1100 > > Which isn't quite ideal. > > So does this seems like a Big problem to anyone? > > Thanks, > Aleš Mlakar > ( Oh yeah the 's' in my name has a little \/ over it. Most > charsets doesn't > see it  that is if you don't have it installed. > And sorry for the a bit unstructured message.. I'm a bit > unstructured > myself today. But what the heck it's Saturday, it's supposed > to be that way. > :)) > >  Original Message  > From: "Tom Forsyth" <tomf@...> > To: <gdalgorithmslist@...> > Sent: Friday, October 27, 2000 4:01 PM > Subject: RE: [Algorithms] VIPM & Vertex Buffers > > > > Just do many DrawIndPrimVB calls, once per used range, > using a different > > dwStartVertex value (remember also that indices are relative to > > dwStartVertex). The higher number of DIPVB calls won't > affect you much > > (unless you go berzerk and draw a very low number of tris > per call), and > > you're not changing VB, which is the real killer. > > > > Sorry to all the OpenGL people out there  this is a bit borderline > between > > algos and D3D. It's a D3D problem, but needs an algo fix :) > > > > Oh, and Ales's nonASCII "s" characters went splat  sorry > about that. > > Monoculturalism roolz! :( > > > > > > 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: Aleš Mlakar [mailto:jazzbre@...] > > > Sent: 27 October 2000 13:05 > > > To: gdalgorithmslist@... > > > Subject: [Algorithms] VIPM & Vertex Buffers > > > > > > > > > Hi, > > > I recently successfully implemented VIPM that is created > from already > > > VertexBuffered (which usually creates multiple same verts > > > with different > > > info) verts. This all works extremely well even on meshes > with lots of > > > different textures/materials applied on them. However since > > > the verts are in > > > collapse order now I lose all the nice batching. I can't > > > order the vertices > > > by material anymore since I will lose the PM indexing. > > > This is bad for the DrawIndexedPrimitiveVB call, since the > > > first index is > > > always low and that means it has to transform almost the > whole vertex > > > buffer. > > > How do you guys deal with this? > > > Do you just leave it as it is or what? > > > Because I don't see how this can be fixed in anyway. > > > Or does DX 8 only transform the verts not yet transformed? > > > Not like DX 7 > > > which transforms all from min_verts to min_verts + num_verts? > > > > > > Thanks > > > Aleš Mlakar > > _______________________________________________ > > GDAlgorithmslist mailing list > > GDAlgorithmslist@... > > http://lists.sourceforge.net/mailman/listinfo/gdalgorithmslist > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > http://lists.sourceforge.net/mailman/listinfo/gdalgorithmslist > 
From: Kerry L. Bonin <kerry@vs...>  20001101 17:37:19

At 01:44 PM 11/1/00 +0200, Peter Dimov wrote: >I have a game that periodically reports its state to a scoreboard >server, using a (key, data) format. Key and data are 128 bit integers. > >I want to encrypt the data with the key; the algorithm would ideally be: > >* reasonably easy to implement in C++, Java, and Php; >* not trivial to reverse, assuming the attacker has several valid (key, >data) pairs and access to the source of the decoder. > >Suggestions? Hello! Your real problem isn't the encryption algorithm, its key management. Typical protection of this sort of data would be a simple block cipher like 3DES or Twofish, for which source is widely available. Problem is how to setup encryption keys on client in such a way that neither network monitoring nor completely compromised client source allows access to the data stream. Algorithms like "DiffieHellman" are commonly used (SSL, ect.) to exchange a session key in a secure manner, but to be trusted a public/private key pair is commonly used. The server's public key (or a public key in its signing chain) is usually distributed to the clients, and used to authenticate the DiffieHellman exchange with the server. Now to compromise the system the attacker must obtain the private key from the server. I've got free/open/unencumbered source at my web site in Java for something that encapsulated all this in a few lines of code if you want it <http://www.vscape.com/developer/libs/sps/>;, and I'd be happy to point you to building blocks in other languages if you need them. Kerry L. Bonin (speaking for self, insert lawyer joke here...) Sr. Engineer, Security/Cryptography & Advanced Visualization, Cisco Systems. VScape lead architect  Adaptive secure clustering for multiuser VR. 
From: Jason Zisk <ziskj@n...>  20001101 17:25:13

This doesn't work, at least it didn't for me. I had to use the transpose of the matrix that transforms the vertex, no inverse at all. If I use the inverse transpose (or transpose inverse) of the worldlocal matrix it would do position and scaling correctly but the rotation would be all wrong. By not inverting the matrix all would work. I'm working with full 4x4 transformation matrices, the same ones you'd send to D3D or OGL to tell it what to render.  Jason Zisk  nFusion Interactive LLC  Original Message  From: "Zhang Zhong Shan" <ZhangZhongShan@...> To: <gdalgorithmslist@...> Sent: Wednesday, November 01, 2000 3:05 AM Subject: RE: [Algorithms] Correct Way to transform direction vector > hi jason, > > The rule is: To transform direction vectors, use the INVERSE TRANSPOSE OF > THE MATRIX THAT TRANSFORMS VERTEX. > > In your case, you should use the transpose of inversed worldlocal matrix, > which is exactly the transpose of your localworld matrix. > > btw, getting normals by first transforming the 2 vertices does not work when > there is reflection in transformation. > > > > > > Original Message > From: Jason Zisk [mailto:ziskj@...] > Sent: Wednesday, November 01, 2000 3:41 AM > To: Algorithms List > Subject: Re: [Algorithms] Correct Way to transform direction vector > > > Well I know for sure that transforming 2 points doesn't work if the matrix > contains scaling. I'm not entirely sure why, I thought I had it figured out > but you are right, the change in direction is what you want. All I know is > that when I do this, if the matrix has scaling its pointing in the wrong > direction. > > I found out that to go from world space to object space you don't want to > multiply the dir. vector by transpose(inverse), you just want to use just > transpose(matrix). > > This makes sense since I believe transforming normals was in reference to > going from object space to world space. > > So the final outcome is, if you want to transform a direction vector from > one space to another, just multiply it by the transpose of the > transformation matrix. Now if I could remember enough math to know why. :) > >  Jason Zisk >  nFusion Interactive LLC > > >  Original Message  > From: "Peter Warden" <Peter.Warden@...> > To: <gdalgorithmslist@...> > Sent: Tuesday, October 31, 2000 9:21 AM > Subject: RE: [Algorithms] Correct Way to transform direction vector > > > > Jason Zisk wrote: > > > Hey everyone. I'm having a problem transforming a > > > direction vector from one coordinate space to another. I > > > need to transform the direction of the ray from world space > > > to object space so I can do an intersection on the triangles > > > in a mesh. > > > > > > I've tried two things. The first was taking two points on > > > the line that the > > > direction vector forms, transforming those by the inverse > > > matrix of the > > > object I'm trying to intersect with then recreating the > > > vector from those > > > two transformed points. That has problems if you have > > > scaling in the matrix > > > though, the direction of the vector could change. So this > > > solution is no > > > good in my situation. > > > > Surely in this case you _want_ the direction to change if > > there's scaling. As a thought experiment in 2D, imagine you had > > a square centred on the origin with corners at (1,1),(1,1), > > (1,1) and (1,1). Now apply a localtoworld transform to take > > this shape into worldspace, apply a scaling of x=x*2. This > > leaves the corners at (2,1),(2,1),(2,1) and (2,1). Now, put > > a ray into world space that starts at (0,2), and has a direction > > of (2,1). This ray will touch the (2,1) corner of the square > > in worldspace. The inverse of the localtoworld transform for > > the square is x=x/2, and if we apply this to both the ray's > > origin and to its direction vector, we end up with a ray at > > (0,2) with a direction of (1,1) in the square's local space. > > This ray still kisses the same corner of the square, in local > > space coordinates (1,1). If the direction _hadn't_ been > > affected by the scaling, the ray in local space would miss the > > square, which isn't what you want! > > > > I'd say transforming the two points by the inverse matrix was > > the right way to tackle this, the alteration of the direction by > > scaling is needed in this case. > > > > > I looked back at the archives of this list and I noticed a > > > discussion of > > > transforming normals. It seems that using the transpose of > > > the inverted > > > transformation matrix is the right way to transform a normal. > > > By doing this > > > I actually solved some problems (with scaling) but caused others with > > > rotation. > > > > Surface normals are a different case, but I can't come up with > > an explanation as to why that I'm happy with! The closest I've > > come is that the normal is part of a plane definition, and so > > need the rules of plane transformation applied to it, whereas a > > ray's direction vector isn't and doesn't. Implicit versus > > explicit representations? An authorative answer from a maths bod > > would be nice... > > > > I take it you've seen the 'Abnormal Normals' article by Eric > > Haines at > > http://www.acm.org/tog/resources/RTNews/html/rtnews1a.html > > , and the response from David Rogers a few issues later? > > > > Peter Warden > > _______________________________________________ > > GDAlgorithmslist mailing list > > GDAlgorithmslist@... > > http://lists.sourceforge.net/mailman/listinfo/gdalgorithmslist > > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > http://lists.sourceforge.net/mailman/listinfo/gdalgorithmslist > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > http://lists.sourceforge.net/mailman/listinfo/gdalgorithmslist 
From: Joe Ante <Joe@Titansoft.de>  20001101 17:24:33

> What I'm working on right now and what I find very interesting is something > we call "Dynamic Data Layout". > It's a method that requires a bit of metaprogramming and some runtime > access pattern analysis. Hi wili, Do you have any links to or more information on how "Dynamic Data Layout" and metaprogramming works, it sounds like a cool idea. Secondly I have tried your code for AABB frustum culling which looked like being an extremely fast test. Unfortunately the code seems not to work and I am pretty sure the planes I feed in are correct because they work with other AABB cullers. I cant really say what the problem is because I dont really grasp the math behind it. So are there any watchouts? Does this code really work in Umbra? bool intersectAABBFrustum ( const AABB& a, const Vector4* p, unsigned int& outClipMask, unsigned int inClipMask) { Vector3 m = a.getCenter(); // center of AABB Vector3 d = a.getMax()  m; // halfdiagonal unsigned int mk = 1; outClipMask = 0;// init outclip mask // loop while there are active planes.. while (mk <= inClipMask) { // if clip plane is active... if (inClipMask&mk) { float NP = (float)(d.x*fabs(p>x) + d.y*fabs(p>y) + d.z*fabs(p>z)); float MP = m.x*p>x + m.y*p>y + m.z*p>z + p>w; if ((MP+NP) < 0.0f) return false;// behind clip plane if ((MPNP) < 0.0f) outClipMask = mk; } mk+=mk;// mk = (1<<iter) p++;// next plane } return true;// AABB intersects frustum } Thanks in advance. bye joe 
From: Nikolay Stefanov <nikolay@sl...>  20001101 15:43:45

Hi, RC5 or RC6 would be nice candidates. There are some implementations going around the net. Both of them are ultraeasy to implement (just some simple for loops and some magic constants) and are hard to reverse. Try RSA's website for info on the algorithms, or a simple search for source code. Cheers, Niki > I have a game that periodically reports its state to a scoreboard > server, using a (key, data) format. Key and data are 128 bit integers. > > I want to encrypt the data with the key; the algorithm would ideally be: > > * reasonably easy to implement in C++, Java, and Php; > * not trivial to reverse, assuming the attacker has several valid (key, > data) pairs and access to the source of the decoder. > > Suggestions? 
From: Martin Fuller <mfuller@ac...>  20001101 15:12:06

RSA encryption's nice because you do not need to transmit the key, only the key product. It's quite heft computationally but for a scoreboard that shouldn't matter. Even if you had the source code you could not decrypt the data without the original keys which must be held by the server. It can be brute forced but the computational time required is immense. See: http://www.sonic.net/~bear/rsa.htm http://world.std.com/~franl/crypto/rsaguts.html Cheers, Martin Original Message From: Peter Dimov [mailto:pdimov@...] Sent: 01 November 2000 11:45 To: gdalgorithmslist@... Subject: [Algorithms] encryption algorithm needed I have a game that periodically reports its state to a scoreboard server, using a (key, data) format. Key and data are 128 bit integers. I want to encrypt the data with the key; the algorithm would ideally be: * reasonably easy to implement in C++, Java, and Php; * not trivial to reverse, assuming the attacker has several valid (key, data) pairs and access to the source of the decoder. Suggestions?  Peter Dimov Multi Media Ltd. _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... http://lists.sourceforge.net/mailman/listinfo/gdalgorithmslist 
From: Peter Dimov <pdimov@mm...>  20001101 11:45:51

I have a game that periodically reports its state to a scoreboard server, using a (key, data) format. Key and data are 128 bit integers. I want to encrypt the data with the key; the algorithm would ideally be: * reasonably easy to implement in C++, Java, and Php; * not trivial to reverse, assuming the attacker has several valid (key, data) pairs and access to the source of the decoder. Suggestions?  Peter Dimov Multi Media Ltd. 
From: Neal Tringham <neal@ps...>  20001101 11:28:05

From: Zhang Zhong Shan <ZhangZhongShan@...> > The rule is: To transform direction vectors, use the INVERSE TRANSPOSE OF > THE MATRIX THAT TRANSFORMS VERTEX. > > In your case, you should use the transpose of inversed worldlocal matrix, > which is exactly the transpose of your localworld matrix. Presumably this is only valid when the transpose operation is equivalent to the inverse, i.e. when the matrix does not contain scaling / mirroring information? Although I suspect its obvious, I suppose it might also be worth checking that we're talking about the 3x3 matrices here, i.e. the translation component of the 4x4 is not necessary. Neal Tringham (Sick Puppies / Empire Interactive) neal@... neal@... 
From: Neal Tringham <neal@ps...>  20001101 11:23:57

From: Jim Offerman <j.offerman@...> > Is there a general case way to convert lefthanded projection matrices to > righthanded? And if so, what is it? > > I know how to convert my normal D3D compliant perspective projection matrix > correctly. Simply invert the z.z and z.w elements (or in Direct3DX terms: > [3][3] and [3][4]) of my projection matrix. Will this also work with > different types of projection (specifically orthographic) I believe that in general you need to apply a single mirror operation (i.e. a scaling matrix in which two of the scale factors are +1 and one is 1), which should flip the handedness (and determinant) of the matrix. Applying a scaling matrix in which all three axes are mirrored would presumably work as well, but I can't say I've ever tried this:) For both OpenGL and D3D I think you would normally apply a z mirror (i.e. multiply by a scaling matrix corresponding to an x scale of +1, a y scale of +1 and a z scale of 1). Neal Tringham (Sick Puppies / Empire Interactive) neal@... neal@... 
From: Jim Offerman <j.offerman@in...>  20001101 10:26:28

Is there a general case way to convert lefthanded projection matrices to righthanded? And if so, what is it? I know how to convert my normal D3D compliant perspective projection matrix correctly. Simply invert the z.z and z.w elements (or in Direct3DX terms: [3][3] and [3][4]) of my projection matrix. Will this also work with different types of projection (specifically orthographic) Thanks, Jim Offerman Innovade The Atlantis Project http://www.theatlantisproject.com 
From: Zhang Zhong Shan <ZhangZhongShan@ub...>  20001101 08:04:29

hi jason, The rule is: To transform direction vectors, use the INVERSE TRANSPOSE OF THE MATRIX THAT TRANSFORMS VERTEX. In your case, you should use the transpose of inversed worldlocal matrix, which is exactly the transpose of your localworld matrix. btw, getting normals by first transforming the 2 vertices does not work when there is reflection in transformation. Original Message From: Jason Zisk [mailto:ziskj@...] Sent: Wednesday, November 01, 2000 3:41 AM To: Algorithms List Subject: Re: [Algorithms] Correct Way to transform direction vector Well I know for sure that transforming 2 points doesn't work if the matrix contains scaling. I'm not entirely sure why, I thought I had it figured out but you are right, the change in direction is what you want. All I know is that when I do this, if the matrix has scaling its pointing in the wrong direction. I found out that to go from world space to object space you don't want to multiply the dir. vector by transpose(inverse), you just want to use just transpose(matrix). This makes sense since I believe transforming normals was in reference to going from object space to world space. So the final outcome is, if you want to transform a direction vector from one space to another, just multiply it by the transpose of the transformation matrix. Now if I could remember enough math to know why. :)  Jason Zisk  nFusion Interactive LLC  Original Message  From: "Peter Warden" <Peter.Warden@...> To: <gdalgorithmslist@...> Sent: Tuesday, October 31, 2000 9:21 AM Subject: RE: [Algorithms] Correct Way to transform direction vector > Jason Zisk wrote: > > Hey everyone. I'm having a problem transforming a > > direction vector from one coordinate space to another. I > > need to transform the direction of the ray from world space > > to object space so I can do an intersection on the triangles > > in a mesh. > > > > I've tried two things. The first was taking two points on > > the line that the > > direction vector forms, transforming those by the inverse > > matrix of the > > object I'm trying to intersect with then recreating the > > vector from those > > two transformed points. That has problems if you have > > scaling in the matrix > > though, the direction of the vector could change. So this > > solution is no > > good in my situation. > > Surely in this case you _want_ the direction to change if > there's scaling. As a thought experiment in 2D, imagine you had > a square centred on the origin with corners at (1,1),(1,1), > (1,1) and (1,1). Now apply a localtoworld transform to take > this shape into worldspace, apply a scaling of x=x*2. This > leaves the corners at (2,1),(2,1),(2,1) and (2,1). Now, put > a ray into world space that starts at (0,2), and has a direction > of (2,1). This ray will touch the (2,1) corner of the square > in worldspace. The inverse of the localtoworld transform for > the square is x=x/2, and if we apply this to both the ray's > origin and to its direction vector, we end up with a ray at > (0,2) with a direction of (1,1) in the square's local space. > This ray still kisses the same corner of the square, in local > space coordinates (1,1). If the direction _hadn't_ been > affected by the scaling, the ray in local space would miss the > square, which isn't what you want! > > I'd say transforming the two points by the inverse matrix was > the right way to tackle this, the alteration of the direction by > scaling is needed in this case. > > > I looked back at the archives of this list and I noticed a > > discussion of > > transforming normals. It seems that using the transpose of > > the inverted > > transformation matrix is the right way to transform a normal. > > By doing this > > I actually solved some problems (with scaling) but caused others with > > rotation. > > Surface normals are a different case, but I can't come up with > an explanation as to why that I'm happy with! The closest I've > come is that the normal is part of a plane definition, and so > need the rules of plane transformation applied to it, whereas a > ray's direction vector isn't and doesn't. Implicit versus > explicit representations? An authorative answer from a maths bod > would be nice... > > I take it you've seen the 'Abnormal Normals' article by Eric > Haines at > http://www.acm.org/tog/resources/RTNews/html/rtnews1a.html > , and the response from David Rogers a few issues later? > > Peter Warden > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > http://lists.sourceforge.net/mailman/listinfo/gdalgorithmslist _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... http://lists.sourceforge.net/mailman/listinfo/gdalgorithmslist 
From: Jason Zisk <ziskj@n...>  20001101 03:14:45

> Shouldn't this also work: > > Vector3 dirWorld3 = /* three component direction vector of the ray in world > space */ > Vector4 dirWorld4 = { dir3.x, dir3.y, dir3.z, 0 } > > Vector4 dirLocal4 = dirWorld4 * worldToLocal; > > (Where worldToLocal is the inverse of the localToWorld matrix, or of > localToWorld is orthogonal, the transpose of localToWorld, since it will be > equal to the inverse in that case). Yes, if you use the transpose of localToWorld. Just using the inverse doesn't seem to work, most likely because of the translation (like you said, just using the inverse 3x3 will solve this). Transpose is a cheaper operation than inverting and allows the use of the full 4x4 transformation matrix without having to grab out the 3x3 part, so I'd think transpose of localToWorld would be the best choice here.  Jason Zisk  nFusion Interactive LLC 