gdalgorithms-list

RE: [Algorithms] portal engines in outdoor environments

[John R. <jra...@ve...>]

In my game the player is almost always on the ground.  I'm just going to do
a precomputed visiblity solution on a hash grid against the ground.
Meaning, wherever you are standing it has precomputed what objects, nodes,
etc. can be seen from that position.  I've done it before, works fine.

John

-----Original Message-----
From: Charles Bloom [mailto:cb...@cb...]
Sent: Friday, August 18, 2000 12:26 PM
To: gda...@li...
Subject: [Algorithms] portal engines in outdoor environments



.. is a hopeless proposition, I think.  I'd just like you
guys to check my reasoning before I give up.  Consider,
for example, a building placed on a landscape.  The goal
is to construct portals so that when you stand on one
side of the building, you can't see the other.  If the
player is constrained to stay on the ground, this is
easy enough, it's really a 2d occlusion problem, and you
need 8 portals (two * 4 faces of a square in 2d; two portals
cuz you need one on each side of a face of the square,
parrallel to that face) which splits the universe into 9
zones (8 outside and one inside the occluding cube).

However, if we have a plain cube in 3d and the player can
go anywhere around it, we need 48 portals !! (8 for each of
the 6 faces on the cube).  Now if you have two cubes near
eachother, you need massive numbers of portals, and they
must all not intersect with eachother or other geometry.
This quickly becomes unworkable.

I think something like a "real-time" occcluder (shadow volumes,
etc.) is the only hope for outdoors.

--------------------------------------
Charles Bloom           www.cbloom.com


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

Re: [Algorithms] N-body processing

[Dave E. <eb...@ma...>]

From: "Matthew MacLaurin" <ma...@me...>
To: <gda...@li...>
Sent: Friday, August 18, 2000 1:02 PM
Subject: RE: [Algorithms] N-body processing

> Hey! Check out the swept sphere stuff at UNC! It's the newest thing I've
> seen in a while for fast proximities and N-Body sim. Even more interesting
> is what they're using it for -- it appears ideally suited to huge poly
> counts. I posted the link last week.

I put swept sphere stuff into NetImmerse when UNC was
starting to look into the topic as an alternative to using
OBBs in a tree.  I had asked Stefan Gottschalk at his
dissertation defense if he had considered such bounding
volumes, but he indicated 'no'.  They work out quite well
because they rely on squared-distance calculations that
turn out to be less expensive (on average) to calculate
than the separating axes, especially so in situations of
close proximity.

Code for building trees of spheres (points a specified
distance from a point), capsules (points a specified
distance from a line segment), and lozenges (points a
specified distance from a rectangle) is at my site, the
MgcContainment.html page.   I eventually plan on
putting the code at my site for the collision detection,
but it may take a couple of months.

--
Dave Eberly
eb...@ma...
http://www.magic-software.com

Re: [Algorithms] Bezier Triangle Rendering

[Dave E. <eb...@ma...>]

> Dave Eberly wrote:
> > 
> > I have source code for tessellation by recursive subdivision
> > of quadratic or cubic Bezier triangles, rectangles, or
> > cylinders at http://www.magic-software.com/MgcSurface.html 
> > 
> 
> Thanks anyway Dave.  Just FYI, I liked your old site
> better since it included papers and references on it
> as opposed to source with book purchase.  But I can't
> dog you for trying to make a living.

I just found out about this list group and my post to
your request was my first.  What a great introduction!
(sarcasm intended)

FYI, the only difference between my 'old' and 'new' site
is that there is more free stuff now.  The papers and
references are still available.  The link I mentioned is to
*free* source code.  Did you check the file preambles?

The book is a separate issue.  The source code that
comes with the book includes a lot of the free stuff at
my web site, but it also has code that may only be
used for non-commercial purposes.  That 'restricted'
code will not be available at my web site.

I am quite saddened that folks would think that
$60 for a meaty book with source code is too
expensive.  The money I make from the book pays
my bills so that I can continue to post *free* stuff at
my web site.  Let's hope enough people have a
different attitude than yours :)

--
Dave Eberly
eb...@ma...
http://www.magic-software.com

RE: [Algorithms] portal engines in outdoor environments

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

I agree - it's a nightmare case for geometric occlusion. Delayed Z-visiblity
is our only hope. A shame we've been waiting two DX versions for it, and
it's going to miss this one as well.  Grrrrrrr. So while we have fancy
vertex shaders that nothing on Earth supports, we don't have API support for
something that even crusty old hardware like Permedia2 and Voodoo1 supports.
Life... don't talk to me about life. :-)

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

> -----Original Message-----
> From: Charles Bloom [mailto:cb...@cb...]
> Sent: 18 August 2000 18:26
> To: gda...@li...
> Subject: [Algorithms] portal engines in outdoor environments
> 
> 
> 
> .. is a hopeless proposition, I think.  I'd just like you
> guys to check my reasoning before I give up.  Consider,
> for example, a building placed on a landscape.  The goal
> is to construct portals so that when you stand on one
> side of the building, you can't see the other.  If the
> player is constrained to stay on the ground, this is
> easy enough, it's really a 2d occlusion problem, and you
> need 8 portals (two * 4 faces of a square in 2d; two portals
> cuz you need one on each side of a face of the square,
> parrallel to that face) which splits the universe into 9
> zones (8 outside and one inside the occluding cube).
> 
> However, if we have a plain cube in 3d and the player can
> go anywhere around it, we need 48 portals !! (8 for each of
> the 6 faces on the cube).  Now if you have two cubes near
> eachother, you need massive numbers of portals, and they
> must all not intersect with eachother or other geometry.
> This quickly becomes unworkable.
> 
> I think something like a "real-time" occcluder (shadow volumes,
> etc.) is the only hope for outdoors.
> 
> --------------------------------------
> Charles Bloom           www.cbloom.com

[Algorithms] portal engines in outdoor environments

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

.. is a hopeless proposition, I think.  I'd just like you
guys to check my reasoning before I give up.  Consider,
for example, a building placed on a landscape.  The goal
is to construct portals so that when you stand on one
side of the building, you can't see the other.  If the
player is constrained to stay on the ground, this is
easy enough, it's really a 2d occlusion problem, and you
need 8 portals (two * 4 faces of a square in 2d; two portals
cuz you need one on each side of a face of the square,
parrallel to that face) which splits the universe into 9
zones (8 outside and one inside the occluding cube).

However, if we have a plain cube in 3d and the player can
go anywhere around it, we need 48 portals !! (8 for each of
the 6 faces on the cube).  Now if you have two cubes near
eachother, you need massive numbers of portals, and they
must all not intersect with eachother or other geometry.
This quickly becomes unworkable.

I think something like a "real-time" occcluder (shadow volumes,
etc.) is the only hope for outdoors.

--------------------------------------
Charles Bloom           www.cbloom.com

Re: [Algorithms] Bezier Triangle Rendering

[Dave S. <Dav...@sd...>]

Angel Popov wrote:
> 
> > I can compute points on a Bezier Triangle,
> > but I'm having a tough time coming up with
> > a good tessellator for it.  Are there any
> > references that has a demonstration of this?
> 
> Here's a paper about bezier triangles:
> http://www.dgp.toronto.edu/people/jcr/papers/thesis.ps.gz

This kinda stuff is great! Thanks Angel.
(I knew there was a deCastelJau derivation of Triangular
patches but I wasn't going to derive it. :-)

Dave Eberly wrote:
> 
> I have source code for tessellation by recursive subdivision
> of quadratic or cubic Bezier triangles, rectangles, or
> cylinders at http://www.magic-software.com/MgcSurface.html 
> 

Thanks anyway Dave.  Just FYI, I liked your old site
better since it included papers and references on it
as opposed to source with book purchase.  But I can't
dog you for trying to make a living.

As to Tom Forsyth' quick solution, do you have any
textured screen shots?  Just curious as to what 
that parameterization does to texture mapping.

Thanks all,
-DaveS

RE: [Algorithms] N-body processing

[Matthew M. <ma...@me...>]

Hey! Check out the swept sphere stuff at UNC! It's the newest thing I've
seen in a while for fast proximities and N-Body sim. Even more interesting
is what they're using it for -- it appears ideally suited to huge poly
counts. I posted the link last week.



> -----Original Message-----
> From: gda...@li...
> [mailto:gda...@li...]On Behalf Of Adam
> Moravanszky
> Sent: Friday, August 18, 2000 4:00 AM
> To: gda...@li...
> Subject: Re: [Algorithms] N-body processing
>
>
> Don't call it stupid, I do that!  But of course I have at most tens of
> bodies, not hundreds.  What you may want is a storage format for a sparse
> matrix.  Sparse matrices are an important construct used a lot by sci
> computation people, so there is no need for you to invent anything new.
>
> --
> --Adam Moravanszky
> http://www.n.ethz.ch/student/adammo
>
> >The most obvious and stupid solution would be something like an array of
> N*N
> >structures, with N = the number of objects in the simulation. Of course,
> >this is absolutely out of question. My standard test sets N =
> 1024, to give
> >you some ideas.
> >
> >I'm curious about the solutions you people could imagine.
> Something with an
> >hash-table maybe, but then what would be a good hash-key? This
> also can be
> >seen as the reference/owner problem one can have with shared
> >materials/textures/etc, since an (owner, ref) couple is nothing
> more than a
> >pair of colliding/touching/linked/related entities. I don't think I have
> any
> >brilliant ideas for the moment, but I'm curious about yours....
> >
> >Cheers,
> >
> >Pierre
>
>
>
>
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>

[Algorithms] Poly LOD

[Michael T. <mi...@st...>]

I'm about to implement a run-time polygon reduction feature into our engine.
I've been looking at Stan Melax's article in GameDev 11/98 "A Simple, Fast
and Effective Polygon Reduction Algorithm".  It's a simple edge-collapse
method.  Has anyone had any experience with this method?  Any ideas about
handling texture coordinates?

Thanks,
Mike

Re: [Algorithms] ENOUGH ABOUT THE PATENTS, PLEASE

[Stephen J B. <sj...@li...>]

On Thu, 17 Aug 2000, Matthew MacLaurin wrote:

> Can we stop talking about ghost cars, centrifugal *ahem* devices, and
> whatnot? We've got a bad noise problem here. This is not a political forum.
 
I agree.

> And please do NOT "list any current patents on 3d character animation that
> they know about." COME ON!
 
I disagree.

We often talk about algorithms and why they may or may not be applicable
to some particular application.

Knowing that some algorithm isn't usable because it's patented is
just as important as knowing that it isn't usable because it's too
slow or generates some nasty artifacts or something.

Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

Re: [Algorithms] N-body processing

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

Don't call it stupid, I do that!  But of course I have at most tens of
bodies, not hundreds.  What you may want is a storage format for a sparse
matrix.  Sparse matrices are an important construct used a lot by sci
computation people, so there is no need for you to invent anything new.

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

>The most obvious and stupid solution would be something like an array of
N*N
>structures, with N = the number of objects in the simulation. Of course,
>this is absolutely out of question. My standard test sets N = 1024, to give
>you some ideas.
>
>I'm curious about the solutions you people could imagine. Something with an
>hash-table maybe, but then what would be a good hash-key? This also can be
>seen as the reference/owner problem one can have with shared
>materials/textures/etc, since an (owner, ref) couple is nothing more than a
>pair of colliding/touching/linked/related entities. I don't think I have
any
>brilliant ideas for the moment, but I'm curious about yours....
>
>Cheers,
>
>Pierre

Re: RE: [Algorithms] Network & byte order.

[Joerg >H. P. <pl...@Ha...>]

 >
 > for impl details see \"network programming for microsoft windows\"
 > by ohlund and jones.
 > i know the name is kind of odd for a book that discuss portabilty but it
 > does.
 
Isn\'t there a defined standard for data on the net?
I think it was made by Sun for theire ancient rpc archicture and is called NDR - network data representation?

This should help on floats as well....

- J 

Re: [Algorithms] LightMaps

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

I'm also planning to add a little lightmapper in Flexporter, so that you can
get a lightmapped scene out of MAX in just one click. But for the moment I
have some difficulties with the bilinear filtering, which creates those
nasty lines between triangles. Yeah, I'm really not the lightmap expert :)
The best way to wipe them out would be to use a planar-mapping approach to
compute the UVs, but I used the strips approach we discussed before - read
the last threads again. I could also tweak the UVs a bit, but it would
destroy all the benefits of strips. Hence, I think I must rewrite the whole
thing using a planar mapping approach, as most people seem to do. But I
still don't know how to handle weird cases such as the torus one we already
talked about. All in all, if someone knows where I could find decent
lightmapping code, just tell me. This is really not something exciting to
write. And since this is really not the first time someone ask that
question, I actually wonder why there isn't a standard lightmapping solution
we could all use instead of individually rewriting the same boring code ?
Maybe there are some issues I can't think of, duno...

Pierre

----- Original Message -----
From: Akbar A. <sye...@ea...>
To: <gda...@li...>
Sent: Friday, August 18, 2000 6:07 AM
Subject: RE: [Algorithms] LightMaps


> http://www.lightscape.com/
> some people have said they have had problems with this.
> you could right your own radiosity util.
> lightmap res is usually much lower.
>
>
> peace.
> 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.
>
>
> -----Original Message-----
> From: gda...@li...
> [mailto:gda...@li...]On Behalf Of
> SHA...@ao...
> Sent: Wednesday, August 16, 2000 3:16 PM
> To: alg...@3d...
> Subject: [Algorithms] LightMaps
>
>
> Hi,
>
> I want to introduce static light maps, is there any utility out there
which
> will precompute the lightmap textures out there if I give it a bunch of
> lights and triangles to play with?
>
> Also, is it necessary for every tri to have it's own lightmap texture or
is
> it better to just stick to a few basic lightmaps and put them all into one
> texture?
>
> Regards,
>
> John.
>
>
> _______________________________________________
> 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] Network & byte order.

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

On a related note.....

I once had a very bad surprise with floats as well - this is not a problem
limited to byte order. I was saving floating point values to a binary file
on a PC, and using the said binary file on a DEC Alpha. I always got
immediate violent crashes until I figured out the Alpha was not using IEEE
floats, but a nasty hybrid format where the last 16 bits of the mantissa are
actually the 16 most significant bits (due to historical compatibility
reasons when they switched from 16bits to 32bits floats). In other words,
this was not a byte order but a word order problem regarding floating point
values :)

Pierre

RE: [Algorithms] Network & byte order.

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

>Anybody can tell us what platforms are little-endian, or big-endian?
it's kind of hard targetting all platforms but here they are, for all it's
worth.
intel and dec processors are little-endian
sun,sgi adn motoral proccesors are big-endian.
no secret.

for impl details see "network programming for microsoft windows"
by ohlund and jones.
i know the name is kind of odd for a book that discuss portabilty but it
does.


peace.
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.


-----Original Message-----
From: gda...@li...
[mailto:gda...@li...]On Behalf Of
Lionel Fumery
Sent: Friday, August 18, 2000 5:30 AM
To: Algorithms
Subject: [Algorithms] Network & byte order.


Hello,

(I hope my question is not too much OT)

We are designing our network libraries, for our next games. We would like to
produce cross-platfom games, with misc processors targets.

In the case of multi-platform network game, we wonder if we have to consider
the byte-ordering of the platforms... Intel is little-endian, whereas Apple
(Motorola) is beg-endian.
Anybody can tell us what platforms are little-endian, or big-endian?

If all our target-platforms are little-endian, we could avoid this
byte-swaping and then keep some CPU time for something else...

Thank you for any advice !

Lionel.


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

Re: [Algorithms] Network & byte order.

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

Lionel Fumery wrote:
> We are designing our network libraries, for our next games. We would like to
> produce cross-platfom games, with misc processors targets.
> 
> In the case of multi-platform network game, we wonder if we have to consider
> the byte-ordering of the platforms... Intel is little-endian, whereas Apple
> (Motorola) is beg-endian.
> Anybody can tell us what platforms are little-endian, or big-endian?
> 
> If all our target-platforms are little-endian, we could avoid this
> byte-swaping and then keep some CPU time for something else...

Compared to the time spent on the network, the amount of time you'll
spend byte-swapping is so microscopic as to be invisible.

General rule of thumb:
Don't expect to write a multibyte value as a stream of binary bytes on
one platform and expect to read it in on another and have it work.
Define your formats in a way that's independent of byte order. Either
use a text value (XML, for example) or if you need to keep the data at
minimal size (and in modem-based networking you usually do) then define
your data formats at the byte level.

Don't say:

"The header consists of a 4-byte unsigned int packet ID."

say:

"The first 4 bytes of the header are a packet ID, sent as a four byte
integer, least-significant byte first."

Then it's unambiguous what you're doing.

With that said, I just found some comments in the header of one of the
files on our file format (called CHUFF) in MindRover. They were written
by Nat Goodspeed, who works here:

------------------------------------
WARNING!  For efficiency reasons, the read/write implementations for
types
such as 'bin4' are implemented by directly examining the storage used
for the
native-type variable.  This is fast, but is inherently
platform-sensitive.
CHUFF data types are little-endian by definition (so that we can have
some
hope of exchanging files between different platforms).  Therefore, when
you
port this implementation to a big-endian machine, make SURE you define
'HIBYTE1ST' as one of the compiler's command-line switches!

Our byte-swapping big-endian implementations assume that it's still
cheaper to
make a single I/O method call for the full size of the value, exchanging
bytes
using temporary variables in memory, than it is to break out separate
I/O
operations for each byte.  That may not be entirely true.  But one
advantage
of this scheme is that on input, we can still test for EOF on a single
call,
rather than having to test separately for each byte.

There are two different philosophical approaches to implementing a
cross-platform binary format, that is, one such as ours, in which (for
instance) bin4 must be read and written as little-endian, regardless of
the
byte order in which the platform on which we're running normally stores
its
binary integers.

Convert on Use
--------------
One approach is to implement a family of classes that literally define
the way
the storage will be used.  For instance, bin4 could be defined as a
class
which always contains a little-endian binary integer value.  We would
then
define conversions to and from ordinary binary integers, arithmetic and
logical operations, etc., so that any operation on a bin4 object results
in a
little-endian value in memory.

The advantage of this strategy is that such fields can apparently be
composed
into structs that describe the actual byte stream.  In theory you can
then
instantiate such a struct, populate some or all of its fields and just
write
it out -- or, conversely, read the struct in its entirety (or even just
map
the struct onto part of a previously-read buffer) and then just
reference some
of its fields.

In practice, this is complicated considerably by the need to worry about
platform-dependent struct alignment requirements.  But you can still
build it,
even though you sometimes end up having to define the actual data as an
array
of bytes to bypass automatic compiler alignment.

With this approach, you need to spend considerable development time on
each
individual field type; it must support the full suite of arithmetic and
logical operations you intend to use.  Those operations are, of course,
somewhat more expensive than operations on the corresponding native
type.  But
this can still be a win if:

(a) there are very many more cross-platform structs than there are field
types.  The whole rationale for this approach is that you do NOT need to
implement read/write methods for each different struct; composing such
fields
into structs should then permit the structs to be transparently used on
a byte
stream.

(b) there are very many more fields in a typical cross-platform struct
than
you actually use.  (In such a case, you might consider redesigning your
protocol, since it appears to be wasteful of space!)  But if you have to
live
with a protocol definition like that, the tradeoff might work in your
favor:
with these fields, you pay for the conversion each time you use them,
but you
don't have to pay for converting fields that you don't use at all.

(c) for some reason, you need random access to parts of a buffer.  For
instance, you are filling a transmission buffer with such structs, but
the
protocol requires a header struct that describes how many other structs
follow
it, and it would be expensive or impossible to determine that number in
advance.  If you have a pointer to the header struct in the buffer, you
can
simply patch the count field on the fly.

Convert on I/O
--------------
The other approach is to define fields that store values much like
native C++
types, so that it's reasonably easy and cheap to perform arithmetic and
logical
operations on them, but each field knows how to serialize and
deserialize
itself to a data stream.

Since the conversion of each field to and from a byte stream is
explicit, you
have explicit control over such things as alignment, rather than
worrying
about what the compiler might be doing behind your back.  This approach
also
allows you to use C++ classes with virtual functions, which you can't do
with
a convert-on-use mechanism since the VFT pointer is part of the storage
occupied by each class object.

The drawback is that for each struct or class you intend to write to, or
receive from, a cross-platform data stream, you must implement specific
read/write methods that enumerate all the (persistent) fields in that
struct
or class.  These methods must be maintained every time you change the
set of
fields in the struct/class.

This can be a win if:

(a) there are relatively few predefined structs in the protocol. 
Implementing
a small set of read/write methods can be easier than implementing all
the
support methods for each convert-on-use field type.

(b) you access the fields in your structs much more often than you
de/serialize
them from/to the data stream.  You only pay for conversion at the time
you
actually read or write the fields, rather than every time you touch one
of
them.

(c) your protocol allows you to write header information and proceed,
rather
than needing to go back and revisit the header to fix up one or more of
its
fields.  That is, either protocol headers don't need to make assertions
about
the data that follows, or it's relatively easy to derive that
forward-looking
information.

I was going to say something about dynamic composition -- the case when
you
want to read or write individual fields in an order determined at
runtime
rather than at compile time -- but actually, I think that would probably
work
out equally well either way.

In any case, we use the convert-on-I/O approach.  bin4 and friends store
data
very much like C long int, etc., but they know how to read and write
themselves from/to a data stream.

However, for internal purposes, we find it useful to borrow a
convert-on-use
notion:  within this file, we implement a LittleEndian type that always
maintains data in little-endian form.

--------------------------

Hope this helps.

	Kent

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

Re: [Algorithms] Bezier Triangle Rendering

[Dave E. <eb...@ma...>]

----- Original Message ----- 
From: "Dave Smith" <Dav...@sd...>
To: <gda...@li...>
Sent: Wednesday, August 16, 2000 11:06 AM
Subject: [Algorithms] Bezier Triangle Rendering


> I can compute points on a Bezier Triangle,
> but I'm having a tough time coming up with
> a good tessellator for it.  Are there any
> references that has a demonstration of this?
> 
> I'm currently looking at fixed subdivision for 
> the quadratic case, but because its not bi-quadratic 
> in the square sense, like bezier patches, it's harder 
> to come up with an easy algo for producing the parameter
> space points.
> 
> Any ideas or pointers would be much appreciated,

I have source code for tessellation by recursive subdivision
of quadratic or cubic Bezier triangles, rectangles, or
cylinders at http://www.magic-software.com/MgcSurface.html 

--
Dave Eberly
eb...@ma...
http://www.magic-software.com

[Algorithms] Network & byte order.

[Lionel F. <li...@mi...>]

Hello,

(I hope my question is not too much OT)

We are designing our network libraries, for our next games. We would like to
produce cross-platfom games, with misc processors targets.

In the case of multi-platform network game, we wonder if we have to consider
the byte-ordering of the platforms... Intel is little-endian, whereas Apple
(Motorola) is beg-endian.
Anybody can tell us what platforms are little-endian, or big-endian?

If all our target-platforms are little-endian, we could avoid this
byte-swaping and then keep some CPU time for something else...

Thank you for any advice !

Lionel.

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

[Robert D. <RD...@ac...>]

Not sure about the other companies, but before Atari hit problems and had to
sell up they took $50 Million from Sega for patent infringment.  I wouldn't
be surprised if they've enforced others too.


> -----Original Message-----
> From: Nicolas Serres [mailto:nic...@ch...]
> Sent: 17 August 2000 22:42
> To: gda...@li...
> Subject: Re: [Algorithms] pissing in the well [was: Collision 
> detection
> pa tent]
> 
> 
> I played Sega Rally 2 a lot last summer, when we (some 
> coders) decided to
> sacrifice hour holidays not to be late for the dreamcast 
> version of our
> game, and our wonderful paranoid management left on vacation 
> to some sunny
> place without giving us the keys of where the devkits were 
> stored... Hmmm
> I'm glad we all left this company.. At least this improved my 
> sega rally 2
> skills and I can tell you that in my japanese version, there 
> were definitely
> ghost cars (althought they were opaque). Did it stay in us/european
> versions?
> 
> I don't know what attitude got hasbro with sega, as it is a 
> very different
> company because they are also the ones you require approval 
> from them, and
> major buisness partners.. Did they ever sue nintendo, sega or 
> sony, who
> obviously did infringe some of their "claimed" patents ??? 
> I'm curious if
> they also sue those major console companies for their 
> first-party titles.
> 
> IIRC, sgi has many patents on character animation (and 
> probably lots of
> other 3d stuff too)..What's their attitude towards game developers?
> 
> Nicolas
> 
> ----- Original Message -----
> From: "Tom Forsyth" <to...@mu...>
> To: <gda...@li...>
> Sent: Thursday, August 17, 2000 11:06 PM
> Subject: RE: [Algorithms] pissing in the well [was: Collision 
> detection pa
> tent]
> 
> 
> > I seem to remember TOCA had a ghost-car mode in it. Did 
> they license it,
> or
> > just put their foot down and say "go on - sue us then".
> >
> > Tom Forsyth - Muckyfoot bloke.
> > Whizzing and pasting and pooting through the day.
> 
> 
> 
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> 

RE: [Algorithms] 3d Lines Intersection

[Matthew C. <MC...@ig...>]

Hi 

I just recieved the following virus warning this morning and it looks like
its
from a message from this list. It won't cause us any problems but I just
thought
I should let you know incase you were unaware of it.

>>

The Star Scanning System discovered a potential virus
or unauthorised code in a message sent to you. 
The original message was diverted into the virus holding
pen (id 651537_966551211) and will be held for 10 days before 
being destroyed.

------------------------------------------------
To help identify the message:

The message was titled 'RE: [Algorithms] pissing in the well [was: Collision
detection pa tent]'
The message date was Thu, 17 Aug 2000 16:37:03 -0700
The message identifier was
<LPB...@ea...>
The message was detected on server mail-server-10.star.net.uk
The message sender was 
    gda...@li...
    sye...@ea...
    gda...@li...

------------------------------------------------

##==>>>> VIRUS POSSIBLE IN FILE: "./651537_1MT_message.txt"
##==>>>> VIRUS ID: CVDL X97M/Divi-f
##==>>>>  Number of files read:                 1
##==>>>>  Number of possible virus infections:  1

Matthew Craig
Programmer
Intelligent Games.

Email: mc...@ig...  Internet: www.igl.co.uk
Phone +44 20 7386 3000  Fax +44 20 7386 0404
IG House, Palliser Road, London W14  9EB,  UK
This email may contain confidential information and is only for the intended
recipient.  Unauthorised review or use of any confidential information in
this message is prohibited. If you received this in error, please contact
the sender and delete it from any computer.

RE: [Algorithms] GJK

[John M. <j.m...@re...>]

Pierre Terdiman writes:

>Hill-climbing...
>Talking about cycling...

Hill climbing?  Cycling?  Did I get on the wrong list by mistake? :-)

John

Re: [Algorithms] Bezier Triangle Rendering

[Angel P. <ju...@bi...>]

> I can compute points on a Bezier Triangle,
> but I'm having a tough time coming up with
> a good tessellator for it.  Are there any
> references that has a demonstration of this?

Here's a paper about bezier triangles:
http://www.dgp.toronto.edu/people/jcr/papers/thesis.ps.gz

You can find a program (with source ) that renders
triangular bezier patches at
http://www.witchlord.com/projects.asp

RE: [Algorithms] LightMaps

[Jaimi M. <ja...@al...>]

Just write your own lighting, either radiosity or direct
lighting (both usually look fine with tweaking). Usually
it's best to make your lightmaps really small - the bilinear
filtering will smooth it out quite nicely - so you can pack
many of them into a lower number of texture pages. Try to
group them together in the order you'll end up rendering
them, so you have a minimum of texture changes.

We've talked about this at least 8000 times on this list,
you may want to check the archives if you need more info.

Jaimi
-----Original Message-----
From: gda...@li...
[mailto:gda...@li...]On Behalf Of
SHA...@ao...
Sent: Wednesday, August 16, 2000 3:16 PM
To: alg...@3d...
Subject: [Algorithms] LightMaps


Hi,

I want to introduce static light maps, is there any utility out there which
will precompute the lightmap textures out there if I give it a bunch of
lights and triangles to play with?

Also, is it necessary for every tri to have it's own lightmap texture or is
it better to just stick to a few basic lightmaps and put them all into one
texture?

Regards,

John.


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

RE: [Algorithms] Bezier Triangle Rendering

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

I just use this one for my triangles:


      +
     / \
    /   \
   +-----+
  / \   / \
 /   \ /   \
+-----+-----+

If you turn your tris into imaginary right-angled tris by picking any two
edges as "major" edges, then use coordinates based on those two, then the
vertices are found at exactly the same positions as a square tesselation of
a square patch. You just have to make sure you split the "squares" along the
correct diagonal:

+
|\
| \
+--+
|\ |\
| \| \
+--+--+
|\ |\ |\
| \| \| \
+--+--+--+

(i.e. if you pick the wrong diagonal, you get this monstrosity:)

+
|\
| \
+--+
| /|\
|/ | \
+--+--+
| /| /|\
|/ |/ | \
+--+--+--+



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

> -----Original Message-----
> From: Dave Smith [mailto:Dav...@sd...]
> Sent: 16 August 2000 16:07
> To: gda...@li...
> Subject: [Algorithms] Bezier Triangle Rendering
> 
> 
> I can compute points on a Bezier Triangle,
> but I'm having a tough time coming up with
> a good tessellator for it.  Are there any
> references that has a demonstration of this?
> 
> I'm currently looking at fixed subdivision for 
> the quadratic case, but because its not bi-quadratic 
> in the square sense, like bezier patches, it's harder 
> to come up with an easy algo for producing the parameter
> space points.
> 
> Any ideas or pointers would be much appreciated,
> Thanks,
> -DaveS
> 
> ps.
> 
> Conor, that sure was a "wacky" patent. :-P
> 
> 
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> 

RE: [Algorithms] LightMaps

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

http://www.lightscape.com/
some people have said they have had problems with this.
you could right your own radiosity util.
lightmap res is usually much lower.


peace.
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.


-----Original Message-----
From: gda...@li...
[mailto:gda...@li...]On Behalf Of
SHA...@ao...
Sent: Wednesday, August 16, 2000 3:16 PM
To: alg...@3d...
Subject: [Algorithms] LightMaps


Hi,

I want to introduce static light maps, is there any utility out there which
will precompute the lightmap textures out there if I give it a bunch of
lights and triangles to play with?

Also, is it necessary for every tri to have it's own lightmap texture or is
it better to just stick to a few basic lightmaps and put them all into one
texture?

Regards,

John.


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

RE: [Algorithms] Directory search without recursion?

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

> -----Original Message-----
> From: Patrick E. Hughes [mailto:hu...@tr...]
>
> <question>
> Where in heck did recursion get such a bad rap?
> </question>
> 

The original poster indicated programming since TurboPascal 1.0 when
recursion did not exist...as was with other languages at that time such as
GWBasic.  However, it could still be done in GWBasic or by creating an
assembler function in MASM, but the concequences were stack management since
every call to the procedure pushes the return address and flags onto the
stack.  It required that the program keep track of it's calls and execute a
return statement for every call like this:

public loopcount
public callitself

Sub Main()
loopcount=0
callitself=0
GoSub Recursive
End

Sub Recursive()
 GoSub dostuff	'will return with callitself = 1 or callitself=0
 if callitself=1 then
  loopcount=loopcount+1
  GoSub Recursive
 end if
 
For loopcounter=1 To loopcount
 Return
Next

Return
End Sub

I think later Return(count) was added for a short period of time that
allowed count number of parameters to be popped off the stack (compiled
directly into the Ret i assembly instruction) ...but was actually
implemented for languages that called other languages with different calling
conventions of far addresses and near address thus needing to clear the
stack...otherwise you'd have to set sp=bp when finished...and other such
lunatic coding.

As you can see it was scary stuff back then...especially when you had to
allocate stack space and suffered serious damage and unpredictable results
if the stack moved into data or code segments.


R&R