gdalgorithms-list

RE: [Algorithms] 256 colour palette

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

On Wed, 30 Aug 2000, Tom Nettleship wrote:

> > From: Akbar A. [mailto:sye...@ea...]
> > 
> > >since the human eye see R & G better than Blue.
> > more at green
> 
> True. But, as I stated earlier, this can be a bad thing (tm) as
> you don't get a pure grey ramp... just lots of icky slightly
> off greys in your palette, so its worth avoiding.

Suppose you have one extra bit of Green - compared to
Red and Blue....you just have to set up the colour
lookup table such that even numbered green inputs
have the same output as the corresponding R and B
entries.

Hence, R=8, G=16, B=8 would be an exact grey, but
       R=8, G=15, B=8 would be a purplish grey and
       R=8, G=17, B=8 would be a greenish grey.

Then, so long as your greys have identical numbers for
Red and Blue and even numbered Greens, you'll get perfect
greys with the in between green values used for non-grey-scale
colours.

The (slight) lossage here is that you can't quite get
maximum brightness Red or Blue entries.

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] 256 colour palette

[Brian M. <bma...@ra...>]

	One trick if you are using a palette and generating shades in order to
light the graphics is to use human assistance. For Privateer 2 a piece of
code did an initial color match to try get the nearest color from the
palette for that color at that intensity. The results from this we're that
great though. What I did next was to save this shade table out as a bitmap.
This let you see what the ramps for each color. Then came the clever bit. I
got the texture artist, Phil, to touch up the shade table bitmap to produce
shades that were better to him. The results weren't the correct shades - but
the final output looked much better. Phil didn't mind doing the table
either - to him being able to see how his textures were mangled was great.
	All that matters with graphics is getting the effect you want.
-Brian.

RE: [Algorithms] Unattainable effects?

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

> The limits of the display technology are not being reached in consumer
> devices.  A direct laser-on-retina display is perfectly capable of
> making you squint...but we just aren't getting those in 
> consumer devices.

I'm sure there'd be some sort of restriction placed on such a device, no?

> NOT realistic.
> Not that it's not realistic graphically - it is.  The problem is that
> in the real world there are things you can do to reduce that effect
> (various physical exercises that push blood back into your brain) that
> don't work in the simulator because we can't easily detect how well
> the pilot is doing them.

Perhaps some sort of 'probe' peripheral device is called for? :-)

Sorry couldn't resist. I'll be quiet now.

Re: [Algorithms] 256 colour palette

[Gil G. <gg...@ma...>]

> build the palette first and give it to your artists.

Our artists would kill us. Have the artists make the palette. Thankfully we
will never use palettes again....they just suck.

-Gil



> You can't get good looking colors AND a wide range of colors in 256
> colors. You have to decide what tradeoffs you're willing to make.
>
> The Quake 1 palette had, IIRC, about 16 shades each of brown, green, and
> grey, and many fewer of other colors. That's partly why the game was so
> effective -- they did "dark" very well.
>
> I have to echo the thoughts of someone else in this thread -- if you
> know in advance you need one palette for the whole game, build the
> palette first and give it to your artists. They'll do a much better job
> than if you try to cut 24-bit art down after the fact.
>
> Kent
>
>
> Matthew Davies wrote:
> >
> > Hi,
> >
> > Sorry, I may have not been clear.
> >
> > I don't need to convert a 24-bit image to 256 colours using
quantisation.  I
> > need to have a consistent single palette which doesn't restrict me too
much
> > to the colours I can have in my textures.  For example, DOOM used a 256
> > colour palette to display all its graphics.
> >
> > One idea is to have 32 different colours and 8 shades of them.  I could
> > design my textures in those 32 colours and 32 of a darker shade.
> >
> > But I just wondered if anyone had a generic palette that they knew
worked
> > well.
> >
> > Best regards,
> > Matt.
> >
> > > -----Original Message-----
> > > From: Tom Nettleship [mailto:to...@ar...]
> > > Sent: Wednesday, August 30, 2000 10:47
> > > To: 'gda...@li...'
> > > Subject: RE: [Algorithms] 256 colour palette
> > >
> > >
> > > The problem you're referring to is commonly called quantization. Doing
> > > a web search on that might glean some results.
> > >
> > > The two main algorithms people often use are called 'Median Cut' and
> > > 'Octree Quantization'. Both of these are efficient, and produce good
> > > results.
> > >
> > > Get hold of a copy of Graphics Gems 1... this has a paper describing
> > > how to implement Octree Quantization, and also (i think) source code,
> > > though there may be some bugs in it.
> > >
> > > Tom Nettleship
> > >
> > > P.S. I turned this mail into plain text from the HTML you
> > > sent... please
> > > don't
> > > send HTML posts to mailing lists; people using some mail readers can't
> > > decipher
> > > them.
> > >
> > > > From: Matthew Davies [mailto:MD...@ac...]
> > > >
> > > > Hi,
> > > >
> > > > Can any of you guys give me some hints on choosing a decent
> > > 256 colour
> > > > palette so that I can get a nice > spread of colours.  I
> > > need it for a
> > > simple
> > > > 3d game so basically I need to cover common colours and
> > > shades thereof.
> > > >
> > > > Do any of you have experience in this area.  I've had it so
> > > easy with
> > > 24-bit graphics up until now!  :-)
> > > _______________________________________________
> > > 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
>
> --
> -----------------------------------------------------------------------
> Kent Quirk                   | CogniToy: Intelligent toys...
> Game Architect               |           for intelligent minds.
> ken...@co...      | http://www.cognitoy.com/
> _____________________________|_________________________________________
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

RE: [Algorithms] octree and HSR

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

>1. How can I check if line intersects a cube?
>2. How can I check if triangle and cube intersect?
>3. How do I compute the view frustrum? (I think I need those eight
points)
>4. How can I check if the view frustrum and a cube intersect? (or if the
cube is inside the view frustrum)

use www.google.com it's your friend.
also www.realtimerendering.com if you don't have the book i suggest you get
it.
there is also dave eberly's book which is coming out soon, it should have
some good stuff in it (relating to "tech" / "math" techniques)
also check the comp.graphics.algoritms faq.
iirc it' has all that you asked


>And then these hard ones:
first get the first ones done, then work on the hard ones. a lot of work has
been done on oct-trees.
iirc ati has released a terrain demo and it uses a hybrid of an octree?
look for the radeon sdk at www.ati.com
again, www.google.com
also check www.flipcode.com

>Don't tell me about those great books like Graphics Gems
hmm, i suppose you don't have the means to get the series. a lot of it does
not apply to the "3d programmers", it is a "graphics gems". it has a few
good articles that apply to us ;)
I recommend you to realtime rendering. this is a very good book and it goes
over the majority of the techniques that we use in rtr. also watt and watt
"advanced animation and rendering techniques". the one by "foley" is
"supposed" to be good but i always preferred watt and watt.


anyways, i'm sure you'll get a reply or a "how to", but i think it's better
if you "teach a person to fish, instead of giving him a fish" ;)

peace.
akbar A.


isn't it ironic, in the paper "A Characterization of Ten Hidden-Surface
Algorithms", by sutherland, sproull and schumacker that we use the eleventh
algorithm ;)
makes you really think


-----Original Message-----
From: gda...@li...
[mailto:gda...@li...]On Behalf Of
Jaakko Westerholm
Sent: Wednesday, August 30, 2000 9:53 AM
To: alg...@3d...
Subject: [Algorithms] octree and HSR


Hi everyone!

I have these few questions about octrees and hiddens surface removal.

First the simple questions:
1. How can I check if line intersects a cube?
2. How can I check if triangle and cube intersect?
3. How do I compute the view frustrum? (I think I need those eight   points)
4. How can I check if the view frustrum and a cube intersect? (or if the
cube is inside the view frustrum)

And then these hard ones:

1. Is it possible to know if one of nodes (or cubes) of the octree
is possible to see from certain point? for example if it was behind a wall.

2. Can I use trianlge strips with octrees? If a strip goes through several
nodes and for example only one node is visible should I clip the strip?

I would also be interested of good sites.. Don't tell me about those great
books like Graphics Gems you have cause I can only read them in my dreams!
=)

--Jaakko W--





---JAAKKO---
Get your Free E-mail at http://bosti.zzn.com
___________________________________________________________________
Hae oma Web-perusteinen sähköposti palvelusi http://www.zzn.com:sta
_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

RE: [Algorithms] 256 colour palette

[Tom N. <to...@ar...>]

> From: Akbar A. [mailto:sye...@ea...]
> 
> >since the human eye see R & G better than Blue.
> more at green

True. But, as I stated earlier, this can be a bad thing (tm) as
you don't get a pure grey ramp... just lots of icky slightly
off greys in your palette, so its worth avoiding.

TomN

RE: [Algorithms] Unattainable effects?

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

>A direct laser-on-retina display is perfectly capable of
>making you squint
i don't want to sound foolish but i barely trust my self into looking into
the sun (sometimes i just do it to "see" ;)
but, trusting a programmer to control let alone software :|

is it just me or is this tech very dangerous?



peace.
akbar A.


isn't it ironic, in the paper "A Characterization of Ten Hidden-Surface
Algorithms", by sutherland, sproull and schumacker that we use the eleventh
algorithm ;)
makes you really think


-----Original Message-----
From: gda...@li...
[mailto:gda...@li...]On Behalf Of
Stephen J Baker
Sent: Wednesday, August 30, 2000 10:10 AM
To: gda...@li...
Subject: RE: [Algorithms] Unattainable effects?


On Wed, 30 Aug 2000, Pallister, Kim wrote:

> Well, performance limitations get overcome, but there are some 'hard
limits'
> of the display technology (and input devices, etc, for that matter).

The limits of the display technology are not being reached in consumer
devices.  A direct laser-on-retina display is perfectly capable of
making you squint...but we just aren't getting those in consumer devices.

> That being said, I think the
> gamma-correct-overexpose-when-emerging-to-daylight type tricks are cool.
As
> with flight sims fading to black when you pull too many G's, it gets the
> point across.

Although our flight sims have 'G-LOC' (g-induced Loss Of Consciousness)
simulation (because the military buyers insist on it). We are told that
pilots almost always turn it off when training because it's NOT realistic.
Not that it's not realistic graphically - it is.  The problem is that
in the real world there are things you can do to reduce that effect
(various physical exercises that push blood back into your brain) that
don't work in the simulator because we can't easily detect how well
the pilot is doing them.

The point is that you shouldn't impose an effect (like glare) that
you could react to in the real world (by for example by shielding
your eyes with your hand) - unless your possible reaction to it is
also simulated (eg with a head tracker and a 'digi-glove').

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

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

RE: [Algorithms] 256 colour palette

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

>And seperate levels
>could use entirely different palettes and we'd swap them in.
that's one thing i hate about consoles :|
you are stuck to *themes*
i'm sure all to many of you have run into these problems.



peace.
akbar A.


isn't it ironic, in the paper "A Characterization of Ten Hidden-Surface
Algorithms", by sutherland, sproull and schumacker that we use the eleventh
algorithm ;)
makes you really think


-----Original Message-----
From: gda...@li...
[mailto:gda...@li...]On Behalf Of Jason
Zisk
Sent: Wednesday, August 30, 2000 9:45 AM
To: gda...@li...
Subject: Re: [Algorithms] 256 colour palette


Very cool.  :)  What we did for a previous game was let the artists make all
the artwork in 24bit then use Debabilizer to create a 64-shade
"superpalette" and map them all to it.  It worked out nicely because this
game had very little artwork overall (probably not even 100 textures, and
most were similiar in color because of the theme).  The rest of the palette
entries were just shades of those 64.  Things that were not going to be
shaded could use the full palette for quantization.  And seperate levels
could use entirely different palettes and we'd swap them in.

Obviously using less base colors gets you more shades but we found 4 shades
of each color to be enough for our purposes.

- Jason Zisk
- nFusion Interactive LLC


----- Original Message -----
From: "Matthew Davies" <MD...@ac...>
To: <gda...@li...>
Sent: Wednesday, August 30, 2000 7:28 AM
Subject: RE: [Algorithms] 256 colour palette


> Doing a ray-casting engine for the Gameboy Advance in my spare time.  I'm
> using its 256 colour bitmap mode.
>
> Matt.
>
>
> > -----Original Message-----
> > From: Martin Fuller [mailto:mf...@ac...]
> > Sent: Wednesday, August 30, 2000 11:50
> > To: 'gda...@li...'
> > Subject: RE: [Algorithms] 256 colour palette
> >
> >
> > Doom used 16 shades of 16 colours if I remember correctly.
> > IMO this was a
> > good balance. You could see each shade but it was a payoff
> > for the number of
> > colours. I'd be tempted to do some sort of dynamic palette
> > changing. For
> > example given a PVS:
> >
> > ROOM A can see ROOM B <> ROOM B can see ROOM A
> > ROOM B can see ROOM C <> ROOM C can see ROOM B
> >
> > (Note ROOM A and C cannot see eachother and you cannot be
> > stood in ROOM B
> > and see both ROOM A and ROOM C)
> >
> > ROOM B referenced 208 pallete entries
> > ROOM A has a different remaining 48 pallete entires to ROOM C.
> >
> > So while the number of colours you need to reference never
> > exceeds 256 you
> > can have more colours than that on the map. You have to have
> > low colour
> > 'insulating' Rooms / corridors. It also means that agents /
> > fx can only
> > reference the bottom 208 pallete entires. Makes building your
> > maps a little
> > more tricky but might be worth it.
> >
> > What platform is this for?
> > Cheers,
> > Martin
> >
> >
> >
> > -----Original Message-----
> > From: Matthew Davies [mailto:MD...@ac...]
> > Sent: 30 August 2000 03:12
> > To: 'gda...@li...'
> > Subject: RE: [Algorithms] 256 colour palette
> >
> >
> > Hi,
> >
> > Sorry, I may have not been clear.
> >
> > I don't need to convert a 24-bit image to 256 colours using
> > quantisation.  I
> > need to have a consistent single palette which doesn't
> > restrict me too much
> > to the colours I can have in my textures.  For example, DOOM
> > used a 256
> > colour palette to display all its graphics.
> >
> > One idea is to have 32 different colours and 8 shades of
> > them.  I could
> > design my textures in those 32 colours and 32 of a darker shade.
> >
> > But I just wondered if anyone had a generic palette that they
> > knew worked
> > well.
> >
> > Best regards,
> > Matt.
> >
> > > -----Original Message-----
> > > From: Tom Nettleship [mailto:to...@ar...]
> > > Sent: Wednesday, August 30, 2000 10:47
> > > To: 'gda...@li...'
> > > Subject: RE: [Algorithms] 256 colour palette
> > >
> > >
> > > The problem you're referring to is commonly called
> > quantization. Doing
> > > a web search on that might glean some results.
> > >
> > > The two main algorithms people often use are called 'Median Cut' and
> > > 'Octree Quantization'. Both of these are efficient, and produce good
> > > results.
> > >
> > > Get hold of a copy of Graphics Gems 1... this has a paper describing
> > > how to implement Octree Quantization, and also (i think)
> > source code,
> > > though there may be some bugs in it.
> > >
> > > Tom Nettleship
> > >
> > > P.S. I turned this mail into plain text from the HTML you
> > > sent... please
> > > don't
> > > send HTML posts to mailing lists; people using some mail
> > readers can't
> > > decipher
> > > them.
> > >
> > > > From: Matthew Davies [mailto:MD...@ac...]
> > > >
> > > > Hi,
> > > >
> > > > Can any of you guys give me some hints on choosing a decent
> > > 256 colour
> > > > palette so that I can get a nice > spread of colours.  I
> > > need it for a
> > > simple
> > > > 3d game so basically I need to cover common colours and
> > > shades thereof.
> > > >
> > > > Do any of you have experience in this area.  I've had it so
> > > easy with
> > > 24-bit graphics up until now!  :-)
> > > _______________________________________________
> > > 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
> >
> _______________________________________________
> 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] 256 colour palette

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

>since the human eye see R & G better than Blue.
more at green


peace.
akbar A.


isn't it ironic, in the paper "A Characterization of Ten Hidden-Surface
Algorithms", by sutherland, sproull and schumacker that we use the eleventh
algorithm ;)
makes you really think


-----Original Message-----
From: gda...@li...
[mailto:gda...@li...]On Behalf Of
Lionel Fumery
Sent: Wednesday, August 30, 2000 6:37 AM
To: gda...@li...
Subject: Re: [Algorithms] 256 colour palette


Another thing, you can give more importance to Red and Green components,
since the human eye see R & G better than Blue.

LiF.


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

RE: [Algorithms] 256 colour palette

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

>Can any of you guys give me some hints on choosing a decent 256 colour
palette so that I >can get a nice spread of colours.  I need it for a simple
3d game so basically I need to >over common colours and shades thereof.


what's up with the fancy html e-mail ;)
someone body from ensemble studios wrote about there problems and how they
got around the color restriction they had.
check there web site. there's a ppt up.
also gdmag had an article written by an ensemble guy as well.

i'm not sure how a 3d pallete/game versus a 2d pallete/game is going to work
out. imho your going to more worreid about getting your shading right
instead of showing the "vibrance" of the few colors you have ;)


peace.
akbar A.


isn't it ironic, in the paper "A Characterization of Ten Hidden-Surface
Algorithms", by sutherland, sproull and schumacker that we use the eleventh
algorithm ;)
makes you really think

-----Original Message-----
From: gda...@li...
[mailto:gda...@li...]On Behalf Of Brian
Marshall
Sent: Wednesday, August 30, 2000 4:36 AM
To: gda...@li...
Subject: RE: [Algorithms] 256 colour palette


    This is going to depend on how you are going to use the colors - match
offline, or generate shading etc at runtime.
For runtime you should find examples in the Windows OpenGL code (in the
Visual C++ docs) for producing a palette for effectively 3/3/2 color depth
from a palette. This does leave a few free entries (normally used for
Windows) that you can use for huds etc. The results are pretty horrible
though....
    If you can generate a big 24 bit image containing the colors you know
you are going to need then I'd suggest doing that and generating a palette
from that to use. (I'd recommend Wu's version from Graphics Gems. Much
better IMHO than Octree etc.)
    Could be worse - I still have memories from color clash on the
Spectrum... getting to 16 colors in bitplanes on the Atari ST was heaven :-)

-Brian.
-----Original Message-----
From: gda...@li...
[mailto:gda...@li...]On Behalf Of Matthew
Davies
Sent: Wednesday, August 30, 2000 9:40 AM
To: Algorithms List (E-mail)
Subject: [Algorithms] 256 colour palette


Hi,

Can any of you guys give me some hints on choosing a decent 256 colour
palette so that I can get a nice spread of colours.  I need it for a simple
3d game so basically I need to cover common colours and shades thereof.

Do any of you have experience in this area.  I've had it so easy with 24-bit
graphics up until now!  :-)

Thanks in advance for any help that you might provide.

Cheers!
Matt Davies
Programmer
Acclaim Studios, Cheltenham
+44 (0) 1242 533682
ICQ: 78711743

Re: [Algorithms] 256 colour palette

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

You can't get good looking colors AND a wide range of colors in 256
colors. You have to decide what tradeoffs you're willing to make.

The Quake 1 palette had, IIRC, about 16 shades each of brown, green, and
grey, and many fewer of other colors. That's partly why the game was so
effective -- they did "dark" very well.

I have to echo the thoughts of someone else in this thread -- if you
know in advance you need one palette for the whole game, build the
palette first and give it to your artists. They'll do a much better job
than if you try to cut 24-bit art down after the fact.

	Kent


Matthew Davies wrote:
> 
> Hi,
> 
> Sorry, I may have not been clear.
> 
> I don't need to convert a 24-bit image to 256 colours using quantisation.  I
> need to have a consistent single palette which doesn't restrict me too much
> to the colours I can have in my textures.  For example, DOOM used a 256
> colour palette to display all its graphics.
> 
> One idea is to have 32 different colours and 8 shades of them.  I could
> design my textures in those 32 colours and 32 of a darker shade.
> 
> But I just wondered if anyone had a generic palette that they knew worked
> well.
> 
> Best regards,
> Matt.
> 
> > -----Original Message-----
> > From: Tom Nettleship [mailto:to...@ar...]
> > Sent: Wednesday, August 30, 2000 10:47
> > To: 'gda...@li...'
> > Subject: RE: [Algorithms] 256 colour palette
> >
> >
> > The problem you're referring to is commonly called quantization. Doing
> > a web search on that might glean some results.
> >
> > The two main algorithms people often use are called 'Median Cut' and
> > 'Octree Quantization'. Both of these are efficient, and produce good
> > results.
> >
> > Get hold of a copy of Graphics Gems 1... this has a paper describing
> > how to implement Octree Quantization, and also (i think) source code,
> > though there may be some bugs in it.
> >
> > Tom Nettleship
> >
> > P.S. I turned this mail into plain text from the HTML you
> > sent... please
> > don't
> > send HTML posts to mailing lists; people using some mail readers can't
> > decipher
> > them.
> >
> > > From: Matthew Davies [mailto:MD...@ac...]
> > >
> > > Hi,
> > >
> > > Can any of you guys give me some hints on choosing a decent
> > 256 colour
> > > palette so that I can get a nice > spread of colours.  I
> > need it for a
> > simple
> > > 3d game so basically I need to cover common colours and
> > shades thereof.
> > >
> > > Do any of you have experience in this area.  I've had it so
> > easy with
> > 24-bit graphics up until now!  :-)
> > _______________________________________________
> > 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

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

[Algorithms] (apology) Overprotective spam filter

[Steve L. <sp...@nc...>]

Gentlefolk:

I think my spam filter just bounced a piece of mail meant for this mailing
list.

If you receive any nastygrams from me, please accept my sincere apologies.
It was the result of a misplaced `procmail' rule.  The error has been 
corrected.

							spl

RE: [Algorithms] Unattainable effects?

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

On Wed, 30 Aug 2000, Pallister, Kim wrote:

> Well, performance limitations get overcome, but there are some 'hard limits'
> of the display technology (and input devices, etc, for that matter).
 
The limits of the display technology are not being reached in consumer
devices.  A direct laser-on-retina display is perfectly capable of
making you squint...but we just aren't getting those in consumer devices.

> That being said, I think the
> gamma-correct-overexpose-when-emerging-to-daylight type tricks are cool. As
> with flight sims fading to black when you pull too many G's, it gets the
> point across.
 
Although our flight sims have 'G-LOC' (g-induced Loss Of Consciousness)
simulation (because the military buyers insist on it). We are told that
pilots almost always turn it off when training because it's NOT realistic.
Not that it's not realistic graphically - it is.  The problem is that
in the real world there are things you can do to reduce that effect
(various physical exercises that push blood back into your brain) that
don't work in the simulator because we can't easily detect how well
the pilot is doing them.

The point is that you shouldn't impose an effect (like glare) that
you could react to in the real world (by for example by shielding
your eyes with your hand) - unless your possible reaction to it is
also simulated (eg with a head tracker and a 'digi-glove').

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

[Algorithms] octree and HSR

[Jaakko W. <za...@bo...>]

Hi everyone!

I have these few questions about octrees and hiddens surface removal.

First the simple questions:
1. How can I check if line intersects a cube?
2. How can I check if triangle and cube intersect?
3. How do I compute the view frustrum? (I think I need those eight   points)
4. How can I check if the view frustrum and a cube intersect? (or if the cube is inside the view frustrum)

And then these hard ones:

1. Is it possible to know if one of nodes (or cubes) of the octree
is possible to see from certain point? for example if it was behind a wall.

2. Can I use trianlge strips with octrees? If a strip goes through several nodes and for example only one node is visible should I clip the strip?

I would also be interested of good sites.. Don't tell me about those great books like Graphics Gems you have cause I can only read them in my dreams! =)

--Jaakko W--    
         




---JAAKKO--- 
Get your Free E-mail at http://bosti.zzn.com
___________________________________________________________________
Hae oma Web-perusteinen sähköposti palvelusi http://www.zzn.com:sta

RE: [Algorithms] Unattainable effects?

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

If you do oversaturate well, you can actually get the user to squint, blink
and look away, especially if they are concentrating on the game (nice big
CRT, fairly dark room, etc - exactly the situation that a real gamer likes).
The point being that the retina oversaturates as well, and the brain is
well-trained to very quickly make the connection "I see
oversaturation"->"squint before your eyes sizzle".

The fact that everything has turned into white because the app/CRT is doing
it doesn't change the fact that the brain is seeing oversaturation, and the
only place it normally sees it is in bright daylight - we're not really
evolved to look at limited-gamut objects, so any oversaturation is assumed
to be in the retina.

I have certainly experienced this in flight sims that saturate to white +
big white lens-flare. But then maybe I just don't get out enough :-)

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

> -----Original Message-----
> From: Pallister, Kim [mailto:kim...@in...]
> Sent: 30 August 2000 15:32
> To: gda...@li...
> Subject: RE: [Algorithms] Unattainable effects?
> 
> 
> Well, performance limitations get overcome, but there are 
> some 'hard limits'
> of the display technology (and input devices, etc, for that matter).
> 
> You can gamma-correct and add lens flares to your hearts 
> content, but you
> are not going to get the user to squint and sheild his eyes 
> with his hands,
> not on a CRT anyway. I think that's what they meant.
> 
> That being said, I think the
> gamma-correct-overexpose-when-emerging-to-daylight type 
> tricks are cool. As
> with flight sims fading to black when you pull too many G's, 
> it gets the
> point across.
> 
> Kim Pallister
> 
> We will find a way or we will make one.
>                      - Hannibal
> 
> 
> > -----Original Message-----
> > From: Michael S. Harrison [mailto:mic...@ud...]
> > Sent: Friday, August 25, 2000 12:06 PM
> > To: gda...@li...
> > Subject: [Algorithms] Unattainable effects?
> > 
> > 
> > 
> > "...it may be hopeless to simulate them realistically on a 
> > computer screen"
> > 
> > b**lsh*t
> > 
> > :-)
> > 
> > And there will never be more than five computers in the 
> > entire world.  (check your computer history if you don't 
> > recognize that statement).
> > 
> > I completely agree with you that the effects you mention are 
> > important to realistic simulation of our world, and they will 
> > be possible someday.  With the way that technology is 
> > progressing, that day may not be more than a few years 
> (decade?) away.
> > 
> > It's possible to do those effects now, as long as you don't 
> > want interactive frame rates.  The frame rates will continue 
> > to go up though, and with them, the effects to bring the 
> > rates right back down. :-)
> > 
> > At 10:22 AM 8/25/00, you wrote:
> > 
> > >The more I look at real outdoor environments (eg. life) the
> > >more I feel that it may be hopeless to simulate them realistically
> > >on a computer screen.  The problem is the sun.  The sun is so
> > >bright, and so strongly affects our experience outdoors, that you
> > >can't make a realistic outdoor enviroment without a blindingly
> > >bright sun, sharp specular reflections on water and cars, etc.
> > >These are very bright, very high frequency effects that are very
> > >very hard to model.  Also, back-lighting by the sun, such as the
> > >halo around an opaque object, or the glow of the sun through a
> > >tree's leaves (take a look at that, it's amazing, and happens
> > >quite often).  
> > >
> > >IMHO this is orders of magnitude more important to visual realism
> > >than radiosity on landscapes.  Diffuse lighting looks reasonable
> > >with just the parrallel light from the sun (properly shadowed,
> > >of course, perhaps with a slower-than-Lambertian angle dependence)
> > >and ambient.
> > >
> > >-------------------------------------------------------
> > >Charles Bloom    cb...@cb...    http://www.cbloom.com
> > >
> > >_______________________________________________
> > >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] 256 colour palette

[Jason Z. <zi...@n-...>]

Very cool.  :)  What we did for a previous game was let the artists make all
the artwork in 24bit then use Debabilizer to create a 64-shade
"superpalette" and map them all to it.  It worked out nicely because this
game had very little artwork overall (probably not even 100 textures, and
most were similiar in color because of the theme).  The rest of the palette
entries were just shades of those 64.  Things that were not going to be
shaded could use the full palette for quantization.  And seperate levels
could use entirely different palettes and we'd swap them in.

Obviously using less base colors gets you more shades but we found 4 shades
of each color to be enough for our purposes.

- Jason Zisk
- nFusion Interactive LLC


----- Original Message -----
From: "Matthew Davies" <MD...@ac...>
To: <gda...@li...>
Sent: Wednesday, August 30, 2000 7:28 AM
Subject: RE: [Algorithms] 256 colour palette


> Doing a ray-casting engine for the Gameboy Advance in my spare time.  I'm
> using its 256 colour bitmap mode.
>
> Matt.
>
>
> > -----Original Message-----
> > From: Martin Fuller [mailto:mf...@ac...]
> > Sent: Wednesday, August 30, 2000 11:50
> > To: 'gda...@li...'
> > Subject: RE: [Algorithms] 256 colour palette
> >
> >
> > Doom used 16 shades of 16 colours if I remember correctly.
> > IMO this was a
> > good balance. You could see each shade but it was a payoff
> > for the number of
> > colours. I'd be tempted to do some sort of dynamic palette
> > changing. For
> > example given a PVS:
> >
> > ROOM A can see ROOM B <> ROOM B can see ROOM A
> > ROOM B can see ROOM C <> ROOM C can see ROOM B
> >
> > (Note ROOM A and C cannot see eachother and you cannot be
> > stood in ROOM B
> > and see both ROOM A and ROOM C)
> >
> > ROOM B referenced 208 pallete entries
> > ROOM A has a different remaining 48 pallete entires to ROOM C.
> >
> > So while the number of colours you need to reference never
> > exceeds 256 you
> > can have more colours than that on the map. You have to have
> > low colour
> > 'insulating' Rooms / corridors. It also means that agents /
> > fx can only
> > reference the bottom 208 pallete entires. Makes building your
> > maps a little
> > more tricky but might be worth it.
> >
> > What platform is this for?
> > Cheers,
> > Martin
> >
> >
> >
> > -----Original Message-----
> > From: Matthew Davies [mailto:MD...@ac...]
> > Sent: 30 August 2000 03:12
> > To: 'gda...@li...'
> > Subject: RE: [Algorithms] 256 colour palette
> >
> >
> > Hi,
> >
> > Sorry, I may have not been clear.
> >
> > I don't need to convert a 24-bit image to 256 colours using
> > quantisation.  I
> > need to have a consistent single palette which doesn't
> > restrict me too much
> > to the colours I can have in my textures.  For example, DOOM
> > used a 256
> > colour palette to display all its graphics.
> >
> > One idea is to have 32 different colours and 8 shades of
> > them.  I could
> > design my textures in those 32 colours and 32 of a darker shade.
> >
> > But I just wondered if anyone had a generic palette that they
> > knew worked
> > well.
> >
> > Best regards,
> > Matt.
> >
> > > -----Original Message-----
> > > From: Tom Nettleship [mailto:to...@ar...]
> > > Sent: Wednesday, August 30, 2000 10:47
> > > To: 'gda...@li...'
> > > Subject: RE: [Algorithms] 256 colour palette
> > >
> > >
> > > The problem you're referring to is commonly called
> > quantization. Doing
> > > a web search on that might glean some results.
> > >
> > > The two main algorithms people often use are called 'Median Cut' and
> > > 'Octree Quantization'. Both of these are efficient, and produce good
> > > results.
> > >
> > > Get hold of a copy of Graphics Gems 1... this has a paper describing
> > > how to implement Octree Quantization, and also (i think)
> > source code,
> > > though there may be some bugs in it.
> > >
> > > Tom Nettleship
> > >
> > > P.S. I turned this mail into plain text from the HTML you
> > > sent... please
> > > don't
> > > send HTML posts to mailing lists; people using some mail
> > readers can't
> > > decipher
> > > them.
> > >
> > > > From: Matthew Davies [mailto:MD...@ac...]
> > > >
> > > > Hi,
> > > >
> > > > Can any of you guys give me some hints on choosing a decent
> > > 256 colour
> > > > palette so that I can get a nice > spread of colours.  I
> > > need it for a
> > > simple
> > > > 3d game so basically I need to cover common colours and
> > > shades thereof.
> > > >
> > > > Do any of you have experience in this area.  I've had it so
> > > easy with
> > > 24-bit graphics up until now!  :-)
> > > _______________________________________________
> > > 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
> >
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

RE: [Algorithms] Unattainable effects?

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

Well, performance limitations get overcome, but there are some 'hard limits'
of the display technology (and input devices, etc, for that matter).

You can gamma-correct and add lens flares to your hearts content, but you
are not going to get the user to squint and sheild his eyes with his hands,
not on a CRT anyway. I think that's what they meant.

That being said, I think the
gamma-correct-overexpose-when-emerging-to-daylight type tricks are cool. As
with flight sims fading to black when you pull too many G's, it gets the
point across.

Kim Pallister

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


> -----Original Message-----
> From: Michael S. Harrison [mailto:mic...@ud...]
> Sent: Friday, August 25, 2000 12:06 PM
> To: gda...@li...
> Subject: [Algorithms] Unattainable effects?
> 
> 
> 
> "...it may be hopeless to simulate them realistically on a 
> computer screen"
> 
> b**lsh*t
> 
> :-)
> 
> And there will never be more than five computers in the 
> entire world.  (check your computer history if you don't 
> recognize that statement).
> 
> I completely agree with you that the effects you mention are 
> important to realistic simulation of our world, and they will 
> be possible someday.  With the way that technology is 
> progressing, that day may not be more than a few years (decade?) away.
> 
> It's possible to do those effects now, as long as you don't 
> want interactive frame rates.  The frame rates will continue 
> to go up though, and with them, the effects to bring the 
> rates right back down. :-)
> 
> At 10:22 AM 8/25/00, you wrote:
> 
> >The more I look at real outdoor environments (eg. life) the
> >more I feel that it may be hopeless to simulate them realistically
> >on a computer screen.  The problem is the sun.  The sun is so
> >bright, and so strongly affects our experience outdoors, that you
> >can't make a realistic outdoor enviroment without a blindingly
> >bright sun, sharp specular reflections on water and cars, etc.
> >These are very bright, very high frequency effects that are very
> >very hard to model.  Also, back-lighting by the sun, such as the
> >halo around an opaque object, or the glow of the sun through a
> >tree's leaves (take a look at that, it's amazing, and happens
> >quite often).  
> >
> >IMHO this is orders of magnitude more important to visual realism
> >than radiosity on landscapes.  Diffuse lighting looks reasonable
> >with just the parrallel light from the sun (properly shadowed,
> >of course, perhaps with a slower-than-Lambertian angle dependence)
> >and ambient.
> >
> >-------------------------------------------------------
> >Charles Bloom    cb...@cb...    http://www.cbloom.com
> >
> >_______________________________________________
> >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] Nearest point on plane for 2D IK

[Serge C. <co...@po...>]

Hi,

T'es perdu? C'est toi qui emcombre la mail-list avec des questions de blaireaux. Si tu veux
revenir fair un stage au SEA, tu quand meme le bienvenu.
For info look in Graphics Gems p388: Intersection of a Ray with a sphere.
Serge Couvet

David Kornmann wrote:

> Hi,
>
> I am looking for an algorithm to compute the intersecting point P between a ray and
> a sphere. I know the center C and the radius R of the sphere, the origin O of the ray
> and its direction V. Basically I need to find the closest intersection from O.
>
> But that's not all: In addition to this, IF the ray does not intersect or is tangent to the
> sphere, I need to know the tangential point with the sphere.
>
> Does anybody know a fast and accurate solution to this problem? maybe a good web
> site or some code would greatly help!...
>
> Thanks,
>
> David Kornmann.
> --
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

RE: [Algorithms] 256 colour palette

[Sasha P. <sa...@pr...>]

Hi everybody,

I thought maybe somebody can clarify the terms "quantization" and
"dithering", I often see them used as synonyms, while I always understood
them as quite different things. I want to know what other people think...

For me, quantization is just a replacement of one color (N-bit, e.g. 16 or
24-bit) with another color, from a smaller set (e.g. from 256 colors).
Dithering is a much more complex process, which, in addition to replacing a
pixel with nearest color, also performs _modifications_ of nearby pixels, to
give you smooth image.

For example, if you take the same 6-6-6 palette and do a quantization and,
say, error diffusion dithering, you will get different images, in first
image you will see the bad results of decreased number of colors, while the
dithered image will look much, much better.

Comments on these two terms, anyone?

Sasha.

> -----Original Message-----
> From: Tom Nettleship [mailto:to...@ar...]
> Sent: Wednesday, August 30, 2000 11:47 AM
> To: 'gda...@li...'
> Subject: RE: [Algorithms] 256 colour palette
> 
> 
> The problem you're referring to is commonly called quantization. Doing
> a web search on that might glean some results.
> 
> The two main algorithms people often use are called 'Median Cut' and
> 'Octree Quantization'. Both of these are efficient, and produce good
> results.
> 
> Get hold of a copy of Graphics Gems 1... this has a paper describing
> how to implement Octree Quantization, and also (i think) source code,
> though there may be some bugs in it.
> 
> Tom Nettleship
> 
> P.S. I turned this mail into plain text from the HTML you 
> sent... please
> don't
> send HTML posts to mailing lists; people using some mail readers can't
> decipher
> them.
> 
> > From: Matthew Davies [mailto:MD...@ac...]
> > 
> > Hi,
> > 
> > Can any of you guys give me some hints on choosing a decent 
> 256 colour
> > palette so that I can get a nice > spread of colours.  I 
> need it for a
> simple
> > 3d game so basically I need to cover common colours and 
> shades thereof.  
> >  
> > Do any of you have experience in this area.  I've had it so 
> easy with
> 24-bit graphics up until now!  :-)
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> 

Re: [Algorithms] 256 colour palette

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

Another thing, you can give more importance to Red and Green components,
since the human eye see R & G better than Blue.

LiF.

RE: [Algorithms] 256 colour palette

[Matthew D. <MD...@ac...>]

Doing a ray-casting engine for the Gameboy Advance in my spare time.  I'm
using its 256 colour bitmap mode.

Matt.


> -----Original Message-----
> From: Martin Fuller [mailto:mf...@ac...]
> Sent: Wednesday, August 30, 2000 11:50
> To: 'gda...@li...'
> Subject: RE: [Algorithms] 256 colour palette
> 
> 
> Doom used 16 shades of 16 colours if I remember correctly. 
> IMO this was a
> good balance. You could see each shade but it was a payoff 
> for the number of
> colours. I'd be tempted to do some sort of dynamic palette 
> changing. For
> example given a PVS:
> 
> ROOM A can see ROOM B <> ROOM B can see ROOM A
> ROOM B can see ROOM C <> ROOM C can see ROOM B
> 
> (Note ROOM A and C cannot see eachother and you cannot be 
> stood in ROOM B
> and see both ROOM A and ROOM C)
> 
> ROOM B referenced 208 pallete entries
> ROOM A has a different remaining 48 pallete entires to ROOM C.
> 
> So while the number of colours you need to reference never 
> exceeds 256 you
> can have more colours than that on the map. You have to have 
> low colour
> 'insulating' Rooms / corridors. It also means that agents / 
> fx can only
> reference the bottom 208 pallete entires. Makes building your 
> maps a little
> more tricky but might be worth it. 
> 
> What platform is this for?
> Cheers,
> Martin
> 
> 
> 
> -----Original Message-----
> From: Matthew Davies [mailto:MD...@ac...]
> Sent: 30 August 2000 03:12
> To: 'gda...@li...'
> Subject: RE: [Algorithms] 256 colour palette
> 
> 
> Hi,
> 
> Sorry, I may have not been clear.
> 
> I don't need to convert a 24-bit image to 256 colours using 
> quantisation.  I
> need to have a consistent single palette which doesn't 
> restrict me too much
> to the colours I can have in my textures.  For example, DOOM 
> used a 256
> colour palette to display all its graphics.
> 
> One idea is to have 32 different colours and 8 shades of 
> them.  I could
> design my textures in those 32 colours and 32 of a darker shade.
> 
> But I just wondered if anyone had a generic palette that they 
> knew worked
> well.
> 
> Best regards,
> Matt.
> 
> > -----Original Message-----
> > From: Tom Nettleship [mailto:to...@ar...]
> > Sent: Wednesday, August 30, 2000 10:47
> > To: 'gda...@li...'
> > Subject: RE: [Algorithms] 256 colour palette
> > 
> > 
> > The problem you're referring to is commonly called 
> quantization. Doing
> > a web search on that might glean some results.
> > 
> > The two main algorithms people often use are called 'Median Cut' and
> > 'Octree Quantization'. Both of these are efficient, and produce good
> > results.
> > 
> > Get hold of a copy of Graphics Gems 1... this has a paper describing
> > how to implement Octree Quantization, and also (i think) 
> source code,
> > though there may be some bugs in it.
> > 
> > Tom Nettleship
> > 
> > P.S. I turned this mail into plain text from the HTML you 
> > sent... please
> > don't
> > send HTML posts to mailing lists; people using some mail 
> readers can't
> > decipher
> > them.
> > 
> > > From: Matthew Davies [mailto:MD...@ac...]
> > > 
> > > Hi,
> > > 
> > > Can any of you guys give me some hints on choosing a decent 
> > 256 colour
> > > palette so that I can get a nice > spread of colours.  I 
> > need it for a
> > simple
> > > 3d game so basically I need to cover common colours and 
> > shades thereof.  
> > >  
> > > Do any of you have experience in this area.  I've had it so 
> > easy with
> > 24-bit graphics up until now!  :-)
> > _______________________________________________
> > 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] 256 colour palette

[Martin G. <bz...@wi...>]

NeuQuant works in two passes (as every image quantizer). First it generates
the target palette (this is what you need) and then it quantizes the image
with it. The palettes NeuQuant produces are far, far better than Median Cut or
Octree's best results. The algorithm itself is not at all slow, Ivan :), and
with a proper implementation it can match the standard schemes. I've tried it
myself.

Martin

-----Original Message-----
From: Ivan-Assen Ivanov <as...@ha...>
To: gda...@li...
<gda...@li...>
Date: 30 Àâãóñò 2000 ã. 13:05
Subject: Re: [Algorithms] 256 colour palette


>Try Neuquant - a simple Kohonen NN based method.
>http://www.ozemail.com.au/~dekker/NEUQUANT.HTML
>there you will find sources (ANSI C, yuck), the paper itself is not available
on the
>Web, but the source is pretty straightforward and easy to rewrite in a
simpler
>manner. A bit slow, but perfectly passable for offline use. Produces much,
much
>better results than the other two methods I tried - Heckbert quantization and
>a simple elimination of the closest colors.
>
>
>
>_______________________________________________
>GDAlgorithms-list mailing list
>GDA...@li...
>http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>

RE: [Algorithms] 256 colour palette

[Tom N. <to...@ar...>]

> From: Jason Barstow [mailto:jba...@ig...]
> This works well where you start with 24bit art;
> but if your final game is 8bit only then, as you say, it 
> might be better
> to specify a fixed palette to prevent the artists getting 
> carried away.

I would add that it is also a good idea to provide the artists with
a palette up-front, as they can produce FAR better results using
that palette than you ever will quantising 24bit art after-the-fact.
(It is amazing what a talented old-skool texture artist can do with
very few colours.)

Another issue... if you decide to go for a regular palette, make sure
you use equal numbers of bits for each gun (such as the 666 scheme
mentioned in another post). Its tempting to use the extra palette entries
to slightly improve resolution on one axis (e.g. 676) but this means you
don't get a 'pure' greyscale ramp... you get a bunch of almost-greys
instead, and this can look very ugly, especially when lighting gets factored
in ontop of the base textures.

TomN

RE: [Algorithms] 256 colour palette

[Giovanni B. <ba...@pr...>]

I don't know if this works well or if there is a better way, I've no
experience here.

I'd think about drawing each texture normally, then putting all them
together in a big 24bit image and quantize them all in a single pass.
After that, when you have your final palette, you can manually retouch the
textures that suffered too much from the quantization, if needed.

---
Giovanni Bajo
Lead Programmer

Protonic Interactive
www.protonic.net

a brand of Prograph Research S.r.l.
www.prograph.it


> -----Original Message-----
> From: gda...@li...
> [mailto:gda...@li...]On Behalf Of
> Matthew Davies
> Sent: Wednesday, August 30, 2000 12:12 PM
> To: 'gda...@li...'
> Subject: RE: [Algorithms] 256 colour palette
>
>
> Hi,
>
> Sorry, I may have not been clear.
>
> I don't need to convert a 24-bit image to 256 colours using
> quantisation.  I
> need to have a consistent single palette which doesn't restrict
> me too much
> to the colours I can have in my textures.  For example, DOOM used a 256
> colour palette to display all its graphics.
>
> One idea is to have 32 different colours and 8 shades of them.  I could
> design my textures in those 32 colours and 32 of a darker shade.
>
> But I just wondered if anyone had a generic palette that they knew worked
> well.
>
> Best regards,
> Matt.
>
> > -----Original Message-----
> > From: Tom Nettleship [mailto:to...@ar...]
> > Sent: Wednesday, August 30, 2000 10:47
> > To: 'gda...@li...'
> > Subject: RE: [Algorithms] 256 colour palette
> >
> >
> > The problem you're referring to is commonly called quantization. Doing
> > a web search on that might glean some results.
> >
> > The two main algorithms people often use are called 'Median Cut' and
> > 'Octree Quantization'. Both of these are efficient, and produce good
> > results.
> >
> > Get hold of a copy of Graphics Gems 1... this has a paper describing
> > how to implement Octree Quantization, and also (i think) source code,
> > though there may be some bugs in it.
> >
> > Tom Nettleship
> >
> > P.S. I turned this mail into plain text from the HTML you
> > sent... please
> > don't
> > send HTML posts to mailing lists; people using some mail readers can't
> > decipher
> > them.
> >
> > > From: Matthew Davies [mailto:MD...@ac...]
> > >
> > > Hi,
> > >
> > > Can any of you guys give me some hints on choosing a decent
> > 256 colour
> > > palette so that I can get a nice > spread of colours.  I
> > need it for a
> > simple
> > > 3d game so basically I need to cover common colours and
> > shades thereof.
> > >
> > > Do any of you have experience in this area.  I've had it so
> > easy with
> > 24-bit graphics up until now!  :-)
> > _______________________________________________
> > 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] 256 colour palette

[Martin F. <mf...@ac...>]

Doom used 16 shades of 16 colours if I remember correctly. IMO this was a
good balance. You could see each shade but it was a payoff for the number of
colours. I'd be tempted to do some sort of dynamic palette changing. For
example given a PVS:

ROOM A can see ROOM B <> ROOM B can see ROOM A
ROOM B can see ROOM C <> ROOM C can see ROOM B

(Note ROOM A and C cannot see eachother and you cannot be stood in ROOM B
and see both ROOM A and ROOM C)

ROOM B referenced 208 pallete entries
ROOM A has a different remaining 48 pallete entires to ROOM C.

So while the number of colours you need to reference never exceeds 256 you
can have more colours than that on the map. You have to have low colour
'insulating' Rooms / corridors. It also means that agents / fx can only
reference the bottom 208 pallete entires. Makes building your maps a little
more tricky but might be worth it. 

What platform is this for?
Cheers,
Martin



-----Original Message-----
From: Matthew Davies [mailto:MD...@ac...]
Sent: 30 August 2000 03:12
To: 'gda...@li...'
Subject: RE: [Algorithms] 256 colour palette


Hi,

Sorry, I may have not been clear.

I don't need to convert a 24-bit image to 256 colours using quantisation.  I
need to have a consistent single palette which doesn't restrict me too much
to the colours I can have in my textures.  For example, DOOM used a 256
colour palette to display all its graphics.

One idea is to have 32 different colours and 8 shades of them.  I could
design my textures in those 32 colours and 32 of a darker shade.

But I just wondered if anyone had a generic palette that they knew worked
well.

Best regards,
Matt.

> -----Original Message-----
> From: Tom Nettleship [mailto:to...@ar...]
> Sent: Wednesday, August 30, 2000 10:47
> To: 'gda...@li...'
> Subject: RE: [Algorithms] 256 colour palette
> 
> 
> The problem you're referring to is commonly called quantization. Doing
> a web search on that might glean some results.
> 
> The two main algorithms people often use are called 'Median Cut' and
> 'Octree Quantization'. Both of these are efficient, and produce good
> results.
> 
> Get hold of a copy of Graphics Gems 1... this has a paper describing
> how to implement Octree Quantization, and also (i think) source code,
> though there may be some bugs in it.
> 
> Tom Nettleship
> 
> P.S. I turned this mail into plain text from the HTML you 
> sent... please
> don't
> send HTML posts to mailing lists; people using some mail readers can't
> decipher
> them.
> 
> > From: Matthew Davies [mailto:MD...@ac...]
> > 
> > Hi,
> > 
> > Can any of you guys give me some hints on choosing a decent 
> 256 colour
> > palette so that I can get a nice > spread of colours.  I 
> need it for a
> simple
> > 3d game so basically I need to cover common colours and 
> shades thereof.  
> >  
> > Do any of you have experience in this area.  I've had it so 
> easy with
> 24-bit graphics up until now!  :-)
> _______________________________________________
> 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