gdalgorithms-list

RE: [Algorithms] Collision detection patent

[Steve W. <Ste...@im...>]

All the more reason to research and develop your own code.

Rockn-Roll

> -----Original Message-----
> From: Michael S. Harrison [mailto:mic...@ud...]
> Sent: Tuesday, August 15, 2000 11:46 AM
> To: gda...@li...
> Subject: [Algorithms] Collision detection patent
> 
> 
> I have no idea if this is going to start an off-topic patent 
> war, but I'm interested in the reaction here on the following 
> patent.  http://www.patents.ibm.com/details?pn=US06067096__ 
> 
> I read about it in the latest Game Developer and did a bit of 
> reading through the patent claims since it appears that Mr. 
> Nagle is attempting to patent methods which have not only 
> been written about prior to his application (March, '98) but 
> actually implemented in our, and other people's engines, prior to '98.
> 
> According to GDMag, he actually intends to go after game 
> companies which infringe his patent.
> 
> Thoughts?
> 
> 
> - Michael Harrison
>   High Plains Coder, 
>   United Developers / Inertia, LLC
>   Work log @ http://lynx.inertiagames.com
> 
> 
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> 

Re: [Algorithms] pissing in the well [was: Collision detection patent]

[Kent Q. <ken...@co...>]

IANAL, but as I recall, the phrase is "obvious to a skilled practioner".
It seems clear that the USPTO strategy in recent years has been to
ignore that phrase and let the courts sort it out later.

Understand, however, that most of these cases never reach court. What
tends to happen is this:

* GreatSatan Corp. goes to the USPTO and gets a patent on the bubble
sort. 
* They include it in the list of several thousand patents they hold, and
sign a cross-licensing agreement with IBM, Microsoft, and several other
large companies.
* They find several small companies with less money than brains and
notify them they're infringing on the patent, but that they'll license
them the right to continue to use the technology for a smallish fee (a
couple of thousand dollars). Realizing that it will cost them that much
for the first phone call with a decent patent attorney, they sign the
license.
* They find a couple of medium-sized companies and extort them for large
license fees. They point out that all sorts of companies both big and
small have licensed this patent rather than fight it. If anyone puts up
a fight and starts talking about going to court with "prior art" or
"obvious" claims, they drop the fees and give away the license. 

Played properly by a big company with idle attorneys, even the most
obvious patent never goes to court, unless they have the bad luck to
find someone who is both principled and rich (rare in itself), and who
also cares enough to fight to the bitter end.

What does this mean to the free software developer? If someone thinks
the patent is being infringed, and that your work is impacting their
patent rights (if you give it away how can they sell it?), they can get
an injunction to keep you from distributing the work, and they can sue
you for damages.

On the other hand, if the patented technology is only a small portion of
what you're doing, and you're really doing it for free, you might find
some patent holders would be willing to license it for free or very
cheap.

	Kent

Jani Peltonen wrote:
> 
> As far as I remember, one of the requirements for a new patent is that the
> patented idea be non-obvious. Lot of the software patents I have seen are
> clearly obvious to someone who works in the field but how would you prove
> that in a court.
> 
> > ----------
> > From:         Akbar A.[SMTP:sye...@ea...]
> > Reply To:     gda...@li...
> > Sent:         Thursday, August 17, 2000 2:28 AM
> > To:   gda...@li...
> > Subject:      RE: [Algorithms] pissing in the well [was: Collision
> > detection patent]
> >
> > what about non-profit software or "free" software?
> > can the company's that hold patents effect us as well?
> > for ex.
> > if i release a chunk of software that uses a "patented" routine.
> > could that company in theory target _ME_ in court?
> > how does patent infringement court cases even work in the software field.
> > Big Corporate Company versus small independent developer?
> > are these even heard of?
> > what about countersealing by saying that the patent is "logical" or was
> > going to come anyways?
> >
> >
> 
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

-- 
-----------------------------------------------------------------------
Kent Quirk                   | CogniToy: Intelligent toys...
Game Architect               |           for intelligent minds.
ken...@co...      | http://www.cognitoy.com/     
_____________________________|_________________________________________

Re: [Algorithms] UTM mapping

[Jeff L. <je...@di...>]

Wayne,

The UTM is a standard map projection.  If you want to map a UTM texture to a sphere for example, calculate UV coordinates based on the mapping function.

http://mathworld.wolfram.com/MercatorProjection.html

Has the math behind variations of Mercator projection including UTM.

I happen to have just finished an article on mapping coordinates last month so the info was handy.  I didn't use transverse Mercator though.
The cool thing about using Mercator projections is there is a bunch of free source images from Nasa.  The earth with no clouds is a great one http://svs.gsfc.nasa.gov/imagewall/hologlobe/earth_noclouds.html.  There are also images of many other planets.

-Jeff

At 10:54 AM 8/17/2000 +0100, you wrote:
>Does anyone know where I can get some information on reading Universal
>Transverse Mercator (UTM) data for 3D/2D display. I'm starting off with the
>Binary Terrain (BT) format that I picked up from www.vterrain.org.
>Unfortunately I can't find any info on what the data actually is (it doesn't
>appear to be a simple heightmap). Any info would be appreciated :)
>
>Wayney
>
>
>_______________________________________________
>GDAlgorithms-list mailing list
>GDA...@li...
>http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

Re: [Algorithms] Using RAPID within a rigid body simulator

[Pierre T. <p.t...@wa...>]

I'm glad to see it works! Exactly what I wanted to see confirmed, thanks.


> No, I successfully postprocess RAPID's output to do that.  Specifically, I
> need a vertex-face pair or an edge-edge pair to be used as contacts.
RAPID

Agreed, those are the usual suspects.


> gives you intersecting triangle pairs, but if you look at where those
> triangles were one step earlyer (before they intersected) you can do some
> distance computations to find which of their features (verticed and edges)
> were the closest at that point, which gives the vertex face and edge
pairs.

This is what I was expecting to do, since this is the method used in
Q-Collide as well. I was actually wondering what kind of distance
computation would be the best here. I mean, while I'm at it I guess I can
use Johnson's distance subalgorithm on two triangles reported by RAPID as
intersecting in the next frame. But maybe there's no need for such a tool,
and simpler distance computations can be used. Would you mind sharing some
details there? (..oh... wouldn't this code be included in Source Commander
? - I think that was the name of the project IIRC. I'll check that.)


> The rigid body simulation itself typically doesn't need to track closest
> points, unless they are really close, as above.  Permanent closest point
> tracking between objects is usually used to speed up the collision
detector
> (temporal coherence).

I don't follow you there. To me, permanent closest point tracking (as used
in I-Collide for example) is only used to waste CPU time :) Because most of
the time you just don't need them: you just need them when there's a
collision. Makes sense ?

Pierre

Re: [Algorithms] Using RAPID within a rigid body simulator

[Adam M. <amo...@dp...>]

No, I successfully postprocess RAPID's output to do that.  Specifically, I
need a vertex-face pair or an edge-edge pair to be used as contacts.  RAPID
gives you intersecting triangle pairs, but if you look at where those
triangles were one step earlyer (before they intersected) you can do some
distance computations to find which of their features (verticed and edges)
were the closest at that point, which gives the vertex face and edge pairs.

The rigid body simulation itself typically doesn't need to track closest
points, unless they are really close, as above.  Permanent closest point
tracking between objects is usually used to speed up the collision detector
(temporal coherence).

--
--Adam Moravanszky
http://www.n.ethz.ch/student/adammo



>example, say I'm just using OBBs, as with RAPID. RAPID will detect
>collisions, but won't give me a distance or a pair of closest points. Does
>it mean it can't be used efficiently within a rigid body simulator ?
>
>I think I'm missing something there.
>
>Pierre

Re: [Algorithms] Collision detection patent

[Pierre T. <p.t...@wa...>]

Let me copy here a recent post to comp.graphics.algorithms from Hong Lip
Lim. Worth reading.

===========================================

Re: Siggraph'2000 authors take my research result as their own (long)

In an earlier posting, Mr. Jones mentioned that  it was common
to have "parallel discovery" by independent teams.  I am afraid
Mr. Jones has missed the point.  I never question whether the
authors have discovered the technique on their own, although it
is strange that my technique can be reinvented after so many
years and published in a high caliber conference.  Whether
there is a parallel  discovery is a non-issue here.  The issues
have always been, and remain to be: (1) improper citing of
an earlier reference that covers many basic aspects of their work.
(2) the lack of mentioning of certain attributes of my earlier
approach which, in my opinion, are important to the next levels
of occlusion culling.

I have already talked about both issues in detail in my earlier
postings.  I do not want to delve into further technical details about
the second issue here.  Concerning the first issue: in the old days,
a paper accepted in a conference or journal would be read by very
few people (mostly the reviewers) before it was formally published
during the conference.  However, today the papers are posted
everywhere on the Internet.  The authors can bask in the glory by
promulgating their achievements early and widely.  However, they do
run the small risk of being detected by the irate author of a certain
early and forgotten paper who finds that his work has been copied.
The latter does not have any other option than to protest to the
former if he/she is worth the salt of a researcher.   After the authors
of the later paper have been informed of the earlier work before
the conference, they can no more hide under the excuse of
independent/parallel discovery.  Since they have chosen to publich
their paper prematurely and have benefited from such an action, it is
only fair that they have to either change the paper substantially,
or to withdraw it before the conference when its duplicity has
been pointed out.  This is exactly what the authors of the Siggraph
paper should do.  I have listed in detail in my earlier postings what I felt
the authors of the Siggraph paper have not done or have not done
enough in rectifying the deficiencies of their paper.

Mr. Jones' has quoted the case involving Leibnitz and Newton.
The severity between the two cases are very different as Newton was
totally unaware of Leibnitz work when he published his work.  Even
though it has never been doubted that Newton has independently
discovered his theory, Mr. Jones must be aware that the favoritism
towards Newton is often seen as one of the greatest injustice in the
history of scientific research.   Newton is undoubtedly one of the most
prominent figures in Science. It is also true that even now Calculus
have still been commonly and incorrectly regarded as being invented by
Newton.  However, what has been done by a prominent person and taken
as truth by many people does not necessarily imply that it must be
correct.  Surely Mr. Jone's heart belongs to Liebnitz and not Newton?

Still on the topic of parallel discovery, I have full proof to show that I
had independently discovered occlusion culling and developed my
full technique before the publication of Prof. Teller's first occlusion
culling technique in Siggraph'91.   Prof. Teller's technique at that
time was limited to isothetic surfaces.  On the other hand a technique
similar to mine just appeared in Siggraph'2000.  I should say that there
is at least some difference in maturity of technology between the two.
Should I went on to publish my paper without a single mention of
Prof. Teller's work?  When I prepared my paper in late 1991 I did
considered this possibility.  However, since Prof. Teller's paper had
already been published and I had read it before I submitted my paper,
I decided that I had to follow the standard rules of research and therefore
I went on to cite his work in my paper.  By doing so my original
discovery looked like also-runs to all readers who didn't know the
inside story, which might have contributed to the cold-shoulder I received
for my paper.  While the authors of other conferences have to honestly
abide by and endure the strict rules of academic publication, why should
some authors of a particular conference be exempted from the regulations?
Why should they be even allowed to use parallel discovery as an excuse
when this is not the case?

Mr. Jones mentioned that the authors of the Siggraph paper would
likely to work even more closely with me to address the situation
if they were not so preoccupied defending their reputations from
my accusations.   The unfolding of events was totally different from
what Mr. Jones has speculated.    What really happened
was that after the discovery of that the to-be published Siggraph
paper was very similar to my earlier paper, I had emailed to these
authors and the Siggraph paper committee.  However, the response
from Siggraph and the authors has turned from initially positive to one
that was very strange.   It appeared as if the people involved have
all at once toed the party line and united in ignoring my request. It was
only after the authors and Siggraph had totally ignored my repeated
pleas to find a solution and proceeded to publish their paper totally
unchanged that I had to air the grievance.  Therefore, saying that
the authors ignore me because I have attack them is putting the
cart before the horse.

Mr. Jones feels that the word plagiarism is overly strong.  As a
technical person myself, I have done detail analysis on this matter
and some research on plagiarism.  I knew that the use of the word
would ruffle many feathers and I myself never take pleasure in
using it.  Unfortunately, all the evidence and the definition of the word
just point to the current case as plagiarism.   If Mr. Jones disapproves
of my charge, he should provide counter-evidence and alternative
definition of plagiarism to show that it is invalid.  However, Mr. Jones
most likely can't even quote Siggraph's own official regulations to
support that.  As far as I know, the "not published previously in
SIGGRAPH" policy has never been publicly admitted by Siggraph.

Mr. Jones mentioned that the authors of the Siggraph paper
have themselves entered into the victim list of Siggraph.  This
sounds as if there have been a witch hunt and some holding
of kangaroo court.  If Mr. Jones feels that these authors are
innocent, he should provide more detail about what has
happened and why and how the authors have been victimized.

Thanks to Mr. Jones for telling publicly what has already been
an open secret, that the effective acceptance rule in Siggraph is
"not published previously in SIGGRAPH."   Unfortunately,
Siggraph always states in its call-for-paper that one condition for
its acceptance of papers is totally new and unpublished material.
As Mr. Jones has correctly noted, most people believe that Siggraph
papers are the final words in computer graphics.  If Siggraph can
officially and publicly admit that their effective aceptance rule, then
everybody would know that Siggraph proceedings could not be
treated as ordinary academic references.  The alternative would
be for Siggraph to eschew its secret rules and to adhere to the
universally accepted publication standard.  Needless to say,
the latter is a healthier policy.

Mr. Jones proposed that I should write directly to Siggraph and ACM.
From my dealing with Siggraph, I am very doubtful how much can I
achieve from my letter.  I am probably at the top of Siggraph's shoot-
at-sight list.  Nevertheless I am willing to give it a try.  Mr. Jones and
everyone who has an interest in this matter can also email to me
(hon...@ya...) their views towards Siggraph's publication
policy. I will include their opinions and send them to Siggraph and
ACM.  Please also state if you want your identity be kept confidential.

RE: [Algorithms] UTM mapping

[Norman V. <nh...@ca...>]

Wayne Coles writes:
>
>Does anyone know where I can get some information on reading Universal
>Transverse Mercator (UTM) data for 3D/2D display. I'm starting off with the
>Binary Terrain (BT) format that I picked up from www.vterrain.org.
>Unfortunately I can't find any info on what the data actually is (it
doesn't
>appear to be a simple heightmap). Any info would be appreciated :)

Maybe this will help
http://www.vterrain.org/Projections/index.html

Norman

Re: [Algorithms] Collision detection patent

[Tom H. <to...@3d...>]

At 12:25 PM 8/15/2000, you wrote:
>This is my (and my company's) opinion only though I believe that the 
>editorial staff of Game Developer shares my views.
>
>I know John and was quite disappointed with his decision to go this 
>route.  I tried to urge him to compete in the commercial arena.  If he 
>really has some unique ideas that make penalty method simulations so much 
>more stable, he should come up with a licensable system that could compete 
>with MathEngine and Havok or just sell his idea to them.  I have seen his 
>Falling Bodies and as a non-realtime simulator for animation work it seems 
>to work as advertised but that package at least in not ready to compete 
>with the physics engines out there.
>
>His take on his patent is "It's quite broad; it covers most spring/damper 
>("penalty method") simulations that handle collisions and joints" and he 
>will be watching upcoming games for infringement.  Going after game 
>companies directly is just foolish and biting the hand that he hopes would 
>feed him.  I don't really know how serious he is about this but it sounds 
>like he may be.  Then again it could be just trying to build up IP for VC 
>money or ...?  Game developers that have developed their own physics 
>systems are obviously no happy about this attitude either.
>
>If anyone here either gets a notice from John saying their engine is in 
>violation or is worried about it.  Contact me, I will assist in 
>documenting prior art and providing other contacts for more info.  I 
>disagree with John and believe that plenty of well documented prior art exists.
>
>Also I would currently urge everyone to avoid buying John's Falling Bodies 
>or licensing any technology from him unless he declares a non-aggressive 
>patent policy.  I feel the same way about all such patents and if anyone 
>knows of any other aggressive software enforcements, please let me know.

I don't mind patents so much, I mean there has to be some way to protect 
genuine intellectual property. What I hate are bogus patents that are a 
nuisance to the community and stifle development of small developers. 
Threats of the nature this John Nagle make the problems even worse. What 
really inflames me is that even though the patent is obviously bogus to 
those "in the know", the fact remains that the patent exists and if the 
company that owns the patent has money and feels like getting in the news 
they can push it in court with minimal energy. The little guy won't have 
the funds to defend themselves so they're just screwed.

Now, tonight I had a thought that might be quite useful. It seems to me 
that if a non-profit organization was formed with funding from game 
companies that went out and proactively challenged these kinds of patents. 
It would also have a public web page that listed the status of the many 
different patents relevant to the game industry. Patents for which a 
non-aggressive stance had been taken by the owner would be listed, as well 
as ones which were currently in litigation, those that had been deemed 
"bogus" by experts but not by the courts, and those that are in fact valid 
and for which the company is pursuing those who violate their IP. This is 
all rather off the cuff so I don't really even know the feasibility of such 
a thing, but if it is indeed feasible, I can definitely see many game 
development houses being interested in contributing. I'm just a small fry, 
but I know I'd give money, especially if it could some how be considered a 
charitable donation for tax purposes. The way I see it, my taxes paid to 
the US government aren't giving me adequate service in this area, so in 
effect I'd be taking money away from them and giving it to someone else to 
fix their mistakes :)

Also, I don't know if its the same guy or not, but the scenes are almost 
identical so I'm assuming it is. I talked to someone who was working on 
this stuff back around 1995. At that time he was still wrapping up the 
demos and had MPEGs that look to be using the exact same models (untextured 
at the time) as the ones shown on the web page. He was working on making it 
into a plug-in for Softimage, which I'm assuming became Falling Bodies. I 
don't really understand the intricacies of what he's done, or what he's 
patented (I loathe reading patents ... especially after seeing how lawyers 
have taken things I've written and turned into patent submissions that even 
I had trouble following ... don't worry .. they weren't game related), but 
it remains to be seen if what he has is just a good implementation of 
existing methods, or if it is in fact a new twist on old tech that 
constitutes a new invention. I mean, if he's trying to patent collision 
detection and physically based simulation in general then he's cracked 
(unfortunately, patents must be made very general, otherwise they won't be 
approved .. its a very weird process). If he's trying to patent some key 
processes that make the act of physically based simulation better, or at 
least different, than what has been done before, and if he's the first to 
invent those specific processes then I think he has a valid claim and 
something worth protecting. I'll even go out on a limb and say that if the 
scope of his legal actions are limited to other peoples implementations 
that implement the exact same processes that he describes, then I think 
he's within his rights to do so. However, I don't see how it is 
realistically possible to be so selective ... I mean, the only thing you 
can really do is say, "Oh wow .. their stuff looks good, they must be using 
our methods .. better sue them and find out for sure". Its an ugly ugly 
mess that really needs a much better solution than patents.

Tom

RE: [Algorithms] pissing in the well [was: Collision detection pa tent]

[Jani P. <ja...@ar...>]

As far as I remember, one of the requirements for a new patent is that the
patented idea be non-obvious. Lot of the software patents I have seen are
clearly obvious to someone who works in the field but how would you prove
that in a court.

> ----------
> From: 	Akbar A.[SMTP:sye...@ea...]
> Reply To: 	gda...@li...
> Sent: 	Thursday, August 17, 2000 2:28 AM
> To: 	gda...@li...
> Subject: 	RE: [Algorithms] pissing in the well [was: Collision
> detection patent]
> 
> what about non-profit software or "free" software?
> can the company's that hold patents effect us as well?
> for ex.
> if i release a chunk of software that uses a "patented" routine.
> could that company in theory target _ME_ in court?
> how does patent infringement court cases even work in the software field.
> Big Corporate Company versus small independent developer?
> are these even heard of?
> what about countersealing by saying that the patent is "logical" or was
> going to come anyways?
> 
> 

[Algorithms] UTM mapping

[Wayne C. <W....@re...>]

Does anyone know where I can get some information on reading Universal
Transverse Mercator (UTM) data for 3D/2D display. I'm starting off with the
Binary Terrain (BT) format that I picked up from www.vterrain.org.
Unfortunately I can't find any info on what the data actually is (it doesn't
appear to be a simple heightmap). Any info would be appreciated :)

Wayney

[Algorithms] Using RAPID within a rigid body simulator

[Pierre T. <p.t...@wa...>]

In rigid body simulations, one needs a correct estimation of the distance
and contact points between two bodies, in order to:
- backup the simulator in search of the exact collision time
- compute an accurate collision response

If you followed the recent GJK thread, you know this algorithm works well
for such tasks. But what about other collision detection methods? For
example, say I'm just using OBBs, as with RAPID. RAPID will detect
collisions, but won't give me a distance or a pair of closest points. Does
it mean it can't be used efficiently within a rigid body simulator ?

I think I'm missing something there.

Pierre

RE: [Algorithms] VIPM Strips

[Tom F. <to...@mu...>]

Hmmmm... interesting. And got me thinking.

I have a bit of a knee-jerk response to strips, because of their
worse-than-list vertex caching (up to twice as bad). However, since normal
VIPM pretty much destroys the vertex cache anyway, this argument doesn't
hold much water!

I think the fundamental difference this approach takes is abandoning the
attempt to ditch collapsed tris as early as possible, which is what forces
the re-ordering of the tris that destroys the vertex cache performance of
"standard" VIPM. And thinking about it, that's fair enough. This still bins
tris, but by making them degenerate, rather than have them fall off the end
of the list and not feeding them to the chip at all. So you still incur the
cost of sending the indices, but not the clipping, setup costs, etc
associated with a triangle.

But of course the bandwidth cost of the indices is tiny compared to the
bandwidth of the vertices, and if by sending (say) double the number of
indices, you can reduce the number of vertex resends (i.e. how well the
vertex cache is working) by even a small amount, you win! The rejection of
degenerate tris is lightning-fast (done right at the front-end I would
assume - three 16-bit compares), and in parallel with all the "expensive"
stuff, so doubling the number of times it does that is not going to affect
performance in any measurable way I would guess.

So having stated that I dislike strips, I see no reason not to switch the
algorithm back to using indexed lists. Arrange your lists optimally for
cache use, and do as the algorithm below says - make the binned ones
degenerate, and move the others, just like a normal VIPM rout. The only
difference from the routine that Charles has in his tutorial is that you
don't reduce the number of tris, and when generating the change list, you
need to include an index change that makes the binned triangle degenerate.
Wow - that's pretty easy, and vertex cache efficiency is nicely maintained
all the way through the collapses.

A few points that need mulling over:

(1) Using indexed lists, you need to make more index changes per collapse
than for strips. Three times as many, I think - not 100% sure. This means
slightly larger collapse information, slightly more of a cache hit. However,
the collapse info is linear, and so very cache-friendly, and since the aim
is to be vertex-cache friendly with our tris, the indices that need changing
are likely to be close together as well, or at least in just two parts of
the index list, so again fairly cache-friendly (remember - it's stepping
outside the cache _once_ that hurts - subsequent accesses to that area are
very cheap). So actually not much more expensive than strips I think. And
better vertex cache performance (using the "fractal gasket" traversal method
that I still can't figure out for arbitrary meshes).

(2) Once a tri has been made degenerate, does it need to be involved in
further collapses? For example, once a tri 1,2,3 has been made into 1,1,3,
do we need to update it when a subsequent collapse bins vertex 3? On some
hardware, the degenerate rejection may be done right up-front on the
indices, and that triangle never makes it any further, so even though it
references vertex 3, because no non-degenerate tri ever references it,
vertex 3 is never loaded. However, some hardware may not do the rejection
until after the vertex cache fetch, which means that vertex 3 gets fetched,
and possible T&L'd, even though it is then never used. If the latter, then
you may be better off doing slightly more index edits to "fix"
already-degenerate tris so that they only reference used vertices, and
having more collapse info. Tricky - I can't decide which option has the
worse worst-case performance. Maybe having both versions and runtime testing
at load time would be the best option.

Compared to "my" two-part method, I think it's a lot simpler. The more I
think about the two-part scheme, the more I spot gotchas, and tris that need
including in the "slow" pool, the more fragmented the remaining "static"
tris get (more fragmentation = less vertex-cache coherency).

The advantage that my two-part method retains is the ability to share lots
of the index data between instances of objects, which will be a definate
advantage in some cases. But it is more complex, and my feeling is that it
will achieve poorer vertex caching than this new method.


Can I just mention that I love this stuff? It's changing so fast, and there
are so many ideas being thrown into the melting-pot. And it just takes one
idea (in this case "why do we need to not send the tri? Can't we just make
it degenerate?") to make us rethink things and get a better variation of the
algorithm kicked off. Thanks Charles.

Tom Forsyth - Muckyfoot bloke.
Whizzing and pasting and pooting through the day.

> -----Original Message-----
> From: Charles Bloom [mailto:cb...@cb...]
> Sent: 17 August 2000 07:20
> To: gda...@li...
> Cc: cb...@su...
> Subject: [Algorithms] VIPM Strips
> 
> 
> 
> I just read the paper "Skip Strips" by El-Sana et.al.
> which seems to be a much-overlooked work on VDPM.  I
> found it as part of the course notes in the simplification
> course on the Siggraph 2k CD.
> 
> It's an interesting read, though quite archaic.
> They make some clever data structures to speed up the
> inherently slow algorithm of VDPM.
> 
> Anyway, it gave me ideas about how to strip VIPM.  In
> fact, it's so easy, it's ridiculous.  Generate your
> vertices in collapse order.  Create an optimal Indexed
> Triangle Strip over those vertices, using duplicated
> vertex indices to make it one single strip over the
> entire mesh.  When you do a collapse, do it just like
> normal VIPM, except that rather than changing indices
> in a list of indexed triangles, you're changing them
> in a list of indexed strips; it's just the same operation: 
> 	IndexList[ vsplit->changeIndex ] = newVertIndex;
> You also can't reduce the number of triangles by two,
> because the two collapsed triangles may not be at the
> end of the list, and their verts are needed to continue
> the strip on either side.
> 
> After you collapse some number of verts, you switch down
> to a new strip which is optimized on that number of
> verts.  This takes a cue from Tom Forsyth, and something
> like power-of-2 sets of triangle strips are recommended.
> For example, a mesh with 5000 triangles at full LOD might
> have strip lists for {5000,3000,2000,1000,500,250,125}
> triangles.
> 
> Now note that the memory usage of this scheme is almost
> identical to that of normal VIPM (!!).  If you use power-
> of-2 triangle strip list changes, then you only duplicate
> the number of indices stored, and by using strips instead
> of lists, you roughly half the storage needed.
> 
> The disadvantage of this scheme is obvious : your triangle
> count stays the same until you swap down to a shorter strip.
> In that sence, it's a lot like discrete LOD.  The difference
> is that you're still doing collapses one by one, and reducing the
> vertex count one by one, and virtually eliminating popping.
> 
> Finally, what's the advantage?  I'm not sure.  This method
> is surely faster than conventional VIPM.  On the other hand,
> I'm not sure it compares terribly well to Tom's idea of
> stripped prefixes and tri-list suffixes.
> 
> -------------------------------------------------------
> Charles Bloom    cb...@cb...    http://www.cbloom.com

Re: [Algorithms] GJK

[Pierre T. <p.t...@wa...>]

Ok, I have my very first version running - and my head hurts.

Pretty basic for the moment, but it seems to work. The computed distance
does not look very accurate nonetheless. For example I saw it reported as
0.000261 altough the two objects obviously collided. Duno if it's normal. I
skipped the backup procedure (I actually *forgot* about it) but my basic
tests worked anyway. I think Gino was right when he discarded it. Running
time is correct, provided you use hill-climbing. If you don't.... *grin*, if
you don't, just forget it. (ok, unless your meshes have few triangles). I
used Rabbitz' subroutine for Johnson's algorithm, so that I could build the
Gilbert part on a working basis. Now I'm going to recode that one my way.

I think some day I'll also pack all my notes in a ppt file for interested
people.

Pierre

Re: [Algorithms] Checking normals against an halfplane

[Andreas <and...@st...>]

Pierre Terdiman wrote:
> 
> Your name reminds me of something.... you wrote a thesis about ROAM, don't
> you ? :)

That's me...

> This method seems to work. Unfortunately I don't feel like computing the
> convex hull of the vertex cloud before starting the real work. BTW what is
> the fastest known algorithm to compute a convex hull? Should be quickhull I
> think, but I don't remember, is it O(n*lg n) ?

I have heard that quickhull is the fastest, and that its average
time complexity is O(n*lg n), but O(n^2) in worst case.

> Point 2) looks slow as well. Is there any fast method to check a vertex is
> inside a convex polytope? I can see how to do that in O(n) time, nothing
> really better.

I don't think we can do any better than linear time either, but
that's quite ok considering the problem.

Step 3 computed the normal of the plane, given that such a plane
exist. I realized that it can do wrong sometimes. I tried to
find the central point as fast as possible, but it fails
sometimes. You need to find a better algorithm for this.

--Andreas

> 
> Pierre
> 
> ----- Original Message -----
> From: Andreas Ögren <and...@st...>
> To: <gda...@li...>
> Sent: Wednesday, August 16, 2000 9:35 AM
> Subject: Re: [Algorithms] Checking normals against an halfplane
> 
> > I haven't encountered that problem earlier, so I don't know if
> > the following (high-level) algorithm is the fastest (or even
> > correct). But consider doing something like:
> >
> > 1. Find the convex hull of all normals (considered as points).
> > 2. Check if the origin is within this convex hull. If so, there
> > is no such plane.
> > 3. Compute the normal of the plane as the vector from the origin
> > to the average point of all points at the edge of the convex
> > hull. If the special case that the average point is zero, just
> > compute the cross product of two normals at the convex hull
> > edge.
> >
> > --Andreas
> >
> > Pierre Terdiman wrote:
> > >
> > > Ok, another little algorithm I'm fighting with.
> > >
> > > Say I have a set of N normals, centered at the origin, in random
> directions.
> > > The goal is to:
> > > 1) check all of them lie on the same side of a plane passing through the
> > > origin
> > > 2) find such a plane
> > >
> > > That plane is unknown when the routine is called. I must determine
> whether
> > > such a plane can exist (this is not always the case). Needless to say,
> it
> > > must be done in a quick way.
> > >
> > > I don't expect a light-speed algorithm to exist, but I know you people
> > > sometimes come up with amazing solutions. Hence, worth trying.
> > >
> > > Pierre
> > >
> > > _______________________________________________
> > > GDAlgorithms-list mailing list
> > > GDA...@li...
> > > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> >
> > _______________________________________________
> > GDAlgorithms-list mailing list
> > GDA...@li...
> > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> 
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

[Algorithms] VIPM Strips

[Charles B. <cb...@cb...>]

I just read the paper "Skip Strips" by El-Sana et.al.
which seems to be a much-overlooked work on VDPM.  I
found it as part of the course notes in the simplification
course on the Siggraph 2k CD.

It's an interesting read, though quite archaic.
They make some clever data structures to speed up the
inherently slow algorithm of VDPM.

Anyway, it gave me ideas about how to strip VIPM.  In
fact, it's so easy, it's ridiculous.  Generate your
vertices in collapse order.  Create an optimal Indexed
Triangle Strip over those vertices, using duplicated
vertex indices to make it one single strip over the
entire mesh.  When you do a collapse, do it just like
normal VIPM, except that rather than changing indices
in a list of indexed triangles, you're changing them
in a list of indexed strips; it's just the same operation: 
	IndexList[ vsplit->changeIndex ] = newVertIndex;
You also can't reduce the number of triangles by two,
because the two collapsed triangles may not be at the
end of the list, and their verts are needed to continue
the strip on either side.

After you collapse some number of verts, you switch down
to a new strip which is optimized on that number of
verts.  This takes a cue from Tom Forsyth, and something
like power-of-2 sets of triangle strips are recommended.
For example, a mesh with 5000 triangles at full LOD might
have strip lists for {5000,3000,2000,1000,500,250,125}
triangles.

Now note that the memory usage of this scheme is almost
identical to that of normal VIPM (!!).  If you use power-
of-2 triangle strip list changes, then you only duplicate
the number of indices stored, and by using strips instead
of lists, you roughly half the storage needed.

The disadvantage of this scheme is obvious : your triangle
count stays the same until you swap down to a shorter strip.
In that sence, it's a lot like discrete LOD.  The difference
is that you're still doing collapses one by one, and reducing the
vertex count one by one, and virtually eliminating popping.

Finally, what's the advantage?  I'm not sure.  This method
is surely faster than conventional VIPM.  On the other hand,
I'm not sure it compares terribly well to Tom's idea of
stripped prefixes and tri-list suffixes.

-------------------------------------------------------
Charles Bloom    cb...@cb...    http://www.cbloom.com

RE: [Algorithms] pissing in the well [was: Collision detection patent]

[Akbar A. <sye...@ea...>]

what about non-profit software or "free" software?
can the company's that hold patents effect us as well?
for ex.
if i release a chunk of software that uses a "patented" routine.
could that company in theory target _ME_ in court?
how does patent infringement court cases even work in the software field.
Big Corporate Company versus small independent developer?
are these even heard of?
what about countersealing by saying that the patent is "logical" or was
going to come anyways?

suppose i _DO_ release that software with the patented routines, could they
sue me?

i have heard some people getting worried about company's taking there homes,
cars, etc..
is this _really_ possible ?

thanks,
akbar A.

"We want technology for the sake of the story, not for its own sake. When
you look back, say 10 years from now, current technology will seem quaint"
Pixars' Edwin Catmull.

RE: [Algorithms] pissing in the well [was: Collision detection pa tent]

[Lipson, P. <Pet...@br...>]

Nope, it was for PoliceTrainer (tm) - which was a spinoff of Hard Drivin.
But the patented technology referred to here was the training component, not
the driving engine itself. As far as I know, no police depts actually
-bought- any...

Peter

> -----Original Message-----
> From: Pallister, Kim [mailto:kim...@in...]
> Sent: Wednesday, August 16, 2000 4:36 PM
> To: gda...@li...
> Subject: RE: [Algorithms] pissing in the well [was: Collision 
> detection
> pa tent]
> 
> 
> And the first one must be for Hard Drivin'
> 
> Just my 2c worth taking you through 
> arcade-game-patent-nostalgia journey.
> 
> Kim Pallister
> 
> We will find a way or we will make one.
>                      - Hannibal
> 
> 
> > -----Original Message-----
> > From: Tom Forsyth [mailto:to...@mu...]
> > Sent: Wednesday, August 16, 2000 4:18 AM
> > To: gda...@li...
> > Subject: RE: [Algorithms] pissing in the well [was: Collision 
> > detection
> > pa tent]
> > 
> > 
> > That second one is for Gauntlet of course. A great game, but 
> > patentable?
> > Then again, these are the people who patented the concept of 
> > a register that
> > scrolls the screen left by the value you write into it.
> > 
> > Tom Forsyth - Muckyfoot bloke.
> > Whizzing and pasting and pooting through the day.
> > 
> > > -----Original Message-----
> > > From: Sam McGrath [mailto:sa...@dn...]
> > > Sent: 16 August 2000 11:49
> > > To: gda...@li...
> > > Subject: Re: [Algorithms] pissing in the well [was: Collision 
> > > detection
> > > pa tent]
> > > 
> > > 
> > > At 11:13 AM 8/16/2000 +0100, you wrote:
> > > >> A practical example is Atari's patent on 'ghost cars' in 
> > > racing games,
> > > >which is still actively enforced.
> > > >
> > > >I never knew they patented that!  Amazing... and scary.  
> > > Does anyone have a
> > > >link to this one?
> > > 
> > > I found this on the US Patent page:
> > > 
> > > http://patents.uspto.gov/cgi-bin/ifetch4?ENG+PATBIB-1976-2000+
> > 0+972113+4+3+3
> > 18762+OF+98+291+51+atari
> > 
> > Not only that, but there's some other atari patents on there 
> > which I find
> > pretty hard to believe.  Look at this one:
> > 
> > http://patents.uspto.gov/cgi-bin/ifetch4?ENG+PATBIB-1976-2000+
> 0+972113+4+4+7
> 4061+OF+69+291+51+atari
> 
> Any other examples of wacky patents??
> 
> -Sam
> ______________________
> Sam McGrath
> sa...@dn...
> http://www.dnai.com/~sammy
> ICQ 5151160
> 
> 
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> 
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> 
> 
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> 

RE: [Algorithms] pissing in the well [was: Collision detection p a tent]

[Pallister, K. <kim...@in...>]

Thank you. I needed a laugh. I reminded of the old air force training films
you'd see with the guy in the centrigufe. Hee hee.

Kim Pallister

We will find a way or we will make one.
                     - Hannibal


> -----Original Message-----
> From: Pierre Terdiman [mailto:p.t...@wa...]
> Sent: Wednesday, August 16, 2000 1:38 PM
> To: gda...@li...
> Subject: Re: [Algorithms] pissing in the well [was: Collision 
> detection
> pa tent]
> 
> 
> While we're at it, you missed the best ever......
> http://www.swin.edu.au/astronomy/pbourke/fun/patent/index.html
> 
> So far my favorite.
> 
> Pierre
> 
> ----- Original Message -----
> From: Steven Clynes <sc...@ti...>
> To: <gda...@li...>
> Sent: Wednesday, August 16, 2000 10:21 PM
> Subject: Re: [Algorithms] pissing in the well [was: Collision 
> detection pa
> tent]
> 
> 
> > For a really big list of ridiculous patents check this page!!!
> >
> > http://www.invention.com/
> >
> > First time I saw this page I thought it was a joke, then, 
> as I read more
> > of the patants, I realized it was for real!!!
> >
> > Then I found myself getting more and more angry at the whole patent
> > issue.!!!
> >
> > Regards,
> > Steve
> >
> > All opinions expressed are my own, not that of my employer.
> >
> > --
> > Steve Clynes
> > sc...@ti...
> > "Everyone has a photographic memory. Some don't have film."
> >
> > _______________________________________________
> > GDAlgorithms-list mailing list
> > GDA...@li...
> > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> 
> 
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> 

RE: [Algorithms] pissing in the well [was: Collision detection pa tent]

[Pallister, K. <kim...@in...>]

And then he scrolls down the page and sees that it states the reference to
hard drivin'

Doh!

Kim Pallister

We will find a way or we will make one.
                     - Hannibal


> -----Original Message-----
> From: Tom Forsyth [mailto:to...@mu...]
> Sent: Wednesday, August 16, 2000 4:18 AM
> To: gda...@li...
> Subject: RE: [Algorithms] pissing in the well [was: Collision 
> detection
> pa tent]
> 
> 
> That second one is for Gauntlet of course. A great game, but 
> patentable?
> Then again, these are the people who patented the concept of 
> a register that
> scrolls the screen left by the value you write into it.
> 
> Tom Forsyth - Muckyfoot bloke.
> Whizzing and pasting and pooting through the day.
> 
> > -----Original Message-----
> > From: Sam McGrath [mailto:sa...@dn...]
> > Sent: 16 August 2000 11:49
> > To: gda...@li...
> > Subject: Re: [Algorithms] pissing in the well [was: Collision 
> > detection
> > pa tent]
> > 
> > 
> > At 11:13 AM 8/16/2000 +0100, you wrote:
> > >> A practical example is Atari's patent on 'ghost cars' in 
> > racing games,
> > >which is still actively enforced.
> > >
> > >I never knew they patented that!  Amazing... and scary.  
> > Does anyone have a
> > >link to this one?
> > 
> > I found this on the US Patent page:
> > 
> > http://patents.uspto.gov/cgi-bin/ifetch4?ENG+PATBIB-1976-2000+
> 0+972113+4+3+3
> 18762+OF+98+291+51+atari
> 
> Not only that, but there's some other atari patents on there 
> which I find
> pretty hard to believe.  Look at this one:
> 
> http://patents.uspto.gov/cgi-bin/ifetch4?ENG+PATBIB-1976-2000+
0+972113+4+4+7
4061+OF+69+291+51+atari

Any other examples of wacky patents??

-Sam
______________________
Sam McGrath
sa...@dn...
http://www.dnai.com/~sammy
ICQ 5151160


_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

RE: [Algorithms] pissing in the well [was: Collision detection pa tent]

[Pallister, K. <kim...@in...>]

And the first one must be for Hard Drivin'

Just my 2c worth taking you through arcade-game-patent-nostalgia journey.

Kim Pallister

We will find a way or we will make one.
                     - Hannibal


> -----Original Message-----
> From: Tom Forsyth [mailto:to...@mu...]
> Sent: Wednesday, August 16, 2000 4:18 AM
> To: gda...@li...
> Subject: RE: [Algorithms] pissing in the well [was: Collision 
> detection
> pa tent]
> 
> 
> That second one is for Gauntlet of course. A great game, but 
> patentable?
> Then again, these are the people who patented the concept of 
> a register that
> scrolls the screen left by the value you write into it.
> 
> Tom Forsyth - Muckyfoot bloke.
> Whizzing and pasting and pooting through the day.
> 
> > -----Original Message-----
> > From: Sam McGrath [mailto:sa...@dn...]
> > Sent: 16 August 2000 11:49
> > To: gda...@li...
> > Subject: Re: [Algorithms] pissing in the well [was: Collision 
> > detection
> > pa tent]
> > 
> > 
> > At 11:13 AM 8/16/2000 +0100, you wrote:
> > >> A practical example is Atari's patent on 'ghost cars' in 
> > racing games,
> > >which is still actively enforced.
> > >
> > >I never knew they patented that!  Amazing... and scary.  
> > Does anyone have a
> > >link to this one?
> > 
> > I found this on the US Patent page:
> > 
> > http://patents.uspto.gov/cgi-bin/ifetch4?ENG+PATBIB-1976-2000+
> 0+972113+4+3+3
> 18762+OF+98+291+51+atari
> 
> Not only that, but there's some other atari patents on there 
> which I find
> pretty hard to believe.  Look at this one:
> 
> http://patents.uspto.gov/cgi-bin/ifetch4?ENG+PATBIB-1976-2000+
0+972113+4+4+7
4061+OF+69+291+51+atari

Any other examples of wacky patents??

-Sam
______________________
Sam McGrath
sa...@dn...
http://www.dnai.com/~sammy
ICQ 5151160


_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

RE: [Algorithms] XGDC conference

[Jeff L. <je...@di...>]

Agree with your list and will add two more.

Faires and Burden, "Numerical Methods"

Engeln, "Numerical Algorithms with C"

Both very good discussions and coverage of the topic.

-Jeff

At 11:11 AM 8/16/2000 -0400, you wrote:
>Here are a few of the references that I use:
>
>"Computational Dynamics" by Ahmed Shabana is a decent book on, well,
>computational rigid-body dynamics with full discussion on many many joint
>constraints but not collision detection. It has a fair discussion of
>numerical methods, but it does not analyze the error terms sufficiently.
>
>"Computational Geometry: Algorithms and Applications" by M. de Berg et al.
>This book has some decent discussions on the development of robust geometric
>algorithms that handle degenerate cases well. Although I use the book as
>background, I haven't really tested their algorithms.
>
>One my favorite references on numerical methods is:
>
>"Computational Fluid Mechanics and Heat Transfer" by Tannehill, Anderson,
>and Pletcher. The order of the authors is random for each edition (there are
>two so far). This will be one of my references for the papers I'll be
>preparing.
>
>I know this sounds like a strange reference, but it has one of the best
>discussions I know of on the fundamental nature of numerical errors in
>discrete integration schemes for differential equations. Chapters 2 and 3
>are introductions to DE's (especially PDE's due to the nature of the
>material of the topic of the book), and have nothing really to do with
>fluids. Chapter 4 analyzes truncation error in a bit more detail, and
>studies the stability issues of a laundry list of equations, using a variety
>of different difference formulas.
>
>There is some discussion in the book about how to deal with discontinuities.
>In fluids, discontinuities are shock waves, contact surfaces (two regions of
>fluid that move at different velocities at a common boundary in an inviscid
>flow----such as the interface between water and air at the ocean). But some
>of the rules apply elsewhere, including when you have cracks in a rigid or
>nonrigid body, and when there are collisions in a dynamics problem. The
>trick is detecting the discontinuities in an automated and robust manner.
>Obviously, it is hard to detect collisions in a robust manner while keeping
>time steps large enough for games. (Well, even without dealing with time
>steps). In fluids, shock capture methods are pretty good at finding
>discontinuities, but as with using penalty methods in dynamics there tends
>to be a general mushiness/springiness with oscillations at the
>discontinuity---second order accurate methods are required to come close to
>tightly modeling the discontinuity. Shock fitting methods actually model the
>geometry of the shock explicitly, and this is similar to restarting the
>integration of a dynamics problem at the point of collision. Much nicer if
>you can do it fast enough, harder to code. And you still have the problem of
>intersecting the geometries. (In fluids, the geometry problem involves
>moving the shock geometry until the flow properties on both sides satisfy
>the "Rankine-Hugoniot" equations----required to satisfy the second law of
>thermodynamics for physically consistent shocks. Enough of this tangent!)
>
>Graham Rhodes
>
> > -----Original Message-----
> > From: gda...@li...
> > [mailto:gda...@li...]On Behalf Of Jamie
> > Fowlston
> > Sent: Wednesday, August 16, 2000 4:55 AM
> > To: gda...@li...
> > Subject: Re: [Algorithms] XGDC conference
> >
> >
> > Can you recommend any books on the topic? I avoided the numerical methods
> > lectures while at university, and so far it's been the most
> > useful thing I could
> > have done there....
> >
> > Jamie
> >
> >
> > "Graham S. Rhodes" wrote:
> >
> > > Wow,
> > >
> > > Lots of attendees here! I appreciate the feedback folks. Starting to get
> > > excited. I'm planning to propose a talk on predicting and
> > managing numerical
> > > error for stable physics simulation for games. The XGDC topic list on
> > > xgames3d.com has me listed with a title of "Advanced Physics
> > Programming,"
> > > but really the idea is to introduce formal techniques for analyzing the
> > > errors introduced by numerical techniques, the way that the errors
> > > propogate(sometimes leading to instability and blow-ups), and
> > how to control
> > > the errors by designing or selecting the right solution scheme.
> > Sounds a bit
> > > boring, but just about everything I've seen related to game physics
> > > simulation has skipped over this, and it is essential to
> > achieving the most
> > > robust physics simulations.
> > >
> > > I'm also going to submit at least one proposal to GDC on a
> > related matter.
> > > By the time GDC rolls around hopefully I'll have some more interesting
> > > examples, such as tricky collision detection examples.
> > >
> > > Graham Rhodes
> > >
> > > _______________________________________________
> > > GDAlgorithms-list mailing list
> > > GDA...@li...
> > > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> >
> >
> > _______________________________________________
> > GDAlgorithms-list mailing list
> > GDA...@li...
> > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> >
>
>
>_______________________________________________
>GDAlgorithms-list mailing list
>GDA...@li...
>http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

Re: [Algorithms] pissing in the well [was: Collision detection pa tent]

[jason w. <jas...@po...>]

Actually, it's a matter of both with RSA. The encryption export laws have
shown to be a non-issue with open source projects, as you can simply provide
a server in norway or elsewhere for international downloads.

There is however some restrictions on the reference implimentation of RSA
that are about to expire as we speak.

So if you need to use RSA in your games, check out the FreeBSD and OpenBSD
projects, they both have found a legal path to using the rsa or independent
implimentations. In a few monhts, it won't be an issue.

Re: [Algorithms] pissing in the well [was: Collision detection pa tent]

[Pierre T. <p.t...@wa...>]

While we're at it, you missed the best ever......
http://www.swin.edu.au/astronomy/pbourke/fun/patent/index.html

So far my favorite.

Pierre

----- Original Message -----
From: Steven Clynes <sc...@ti...>
To: <gda...@li...>
Sent: Wednesday, August 16, 2000 10:21 PM
Subject: Re: [Algorithms] pissing in the well [was: Collision detection pa
tent]


> For a really big list of ridiculous patents check this page!!!
>
> http://www.invention.com/
>
> First time I saw this page I thought it was a joke, then, as I read more
> of the patants, I realized it was for real!!!
>
> Then I found myself getting more and more angry at the whole patent
> issue.!!!
>
> Regards,
> Steve
>
> All opinions expressed are my own, not that of my employer.
>
> --
> Steve Clynes
> sc...@ti...
> "Everyone has a photographic memory. Some don't have film."
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

Re: [Algorithms] pissing in the well [was: Collision detection pa tent]

[Steven C. <sc...@ti...>]

For a really big list of ridiculous patents check this page!!!

http://www.invention.com/

First time I saw this page I thought it was a joke, then, as I read more
of the patants, I realized it was for real!!!

Then I found myself getting more and more angry at the whole patent
issue.!!!

Regards,
Steve

All opinions expressed are my own, not that of my employer.

-- 
Steve Clynes
sc...@ti...
"Everyone has a photographic memory. Some don't have film."

RE: [Algorithms] pissing in the well [was: Collision detection patent]

[Scott L. <va...@be...>]

Sadly, Mr. Nagle wins either way with this patent controversy.  He either
erects a roadblock to physics simulation in every major arena in which it
is exploited or he gets a ton of free publicity for himself and animats.com
which leads to job offers and sales of his products.  he may get both.  Either
way, he won the moment the patent was accepted.

Scott "There's no such thing as bad publicity" Le Grand