gdalgorithms-list

Re: [Algorithms] It looks terrible (was: Lightmap Terrain)

[Klaus H. <k_h...@os...>]

----- Original Message -----
From: Jim Offerman <j.o...@in...>
> Hey Niki,
>
> Some suggestions which might make your lightmap (and not to forget your
> terrain) look better/nicer. Maybe you have already considered these, but
> then again, you never know :-)
>
> - Perhaps you could use a lighter ambient color (instead of something
> nearing total blackness, say about 20-25% gray or something). Near black
> shadows are not really common in real life, specially not in open
terrains -
> always plenty of ambient light.

I don't use any ambient color at all. Instead I use a second directional
light source (opposite to the sun).

> - When raytracting your lightmap, you could perhaps use the corners of
each
> pixel/texel instead of the centers and then use the average of the four
> corners as the pixel's color, essentially applying a bilinear filter to
your
> light map.

I do use the pixel-corners, but I don't average them. This is sort of an
accident really. Perhaps, I should cast the rays through the center of each
pixel. Thanks for reminding me :)

> - It is just a hunch (no scientific basis, other than my own
observations),
> but it might look good if you lighten the shadow areas based on the slope
of
> the terrain, so that shadows on steep areas look darker than those on flat
> areas, which in my eyes also happens in reality. Reason for this effect
> could be that more diffuse light is being reflected on the flat areas by
the
> clouds, but again, I have no scientific basis for this assumption.

Funny! This is exactly what I did last night :) This made the lightmap look
a bit better, but I haven't tried it in 3D, yet.

Well, I think I'll bite the bullet and try some true recursive ray tracing
(with reflected rays), today. Technically this is wrong for diffuse light,
but maybe it looks better, and that's what counts.

Thanks,
Niki

>
> Jim Offerman
>
> Innovade
> - designing the designer
>
> ----- Original Message -----
> From: "Klaus Hartmann" <k_h...@os...>
> To: <gda...@li...>
> Sent: Sunday, August 27, 2000 6:32 PM
> Subject: Re: [Algorithms] It looks terrible (was: Lightmap Terrain)
>
>
> > Welcome, Ralf :)
> >
> > ----- Original Message -----
> > From: Ralf Schneider <rap...@ra...>
> > > Niki,
> > >
> > > well it do NOT look that terrible!
> > > it's a lightmap, isn't it? what du you suspect?
> >
> > What I suspect is a nice image :) See, I've actually tried this shadow
> stuff
> > in my terrain engine, and in 3D it looks far worse than the lightmap. I
> > tried this with a hybrid multifractal, though... maybe it looks better
> with
> > real world data as show in the image. Gotta try this, but it's a bit
more
> > work.
> >
> > > shadows make scenes nore realistic, not neccesarily beautiful.
> >
> > This is a good description. The unrealistic dot-product-only lit scene
(in
> > 3D) looks much better, even though it's not as realistic as the shadowed
> > version.
> >
> > >you are loosing visual information if yo add shadows to a top down view
> of
> > a heightfield. you know that already, because you are trying to avoid
it,
> by
> > using a second light source instead of ambient light (we can say the
> second
> > light is simulating the reflection of the sun at the other mountain...).
> >
> > Yes, this is quite a problem. If I use no second light source, then
> there's
> > zero shading on the faces opposite to the sun, which basically means
that
> I
> > lose all the nice features. If, on the other hand, I use a secondary
light
> > source (plus shadows), then I get artifacts as the one's in the
> upper-right
> > shadow-area of the image I posted. This looks as if I used false gays
(as
> in
> > false color). In 3D this becomes even worse.
> >
> > > take a look at some landscape/mountain top-down photos. i guess, you
> will
> > recognice you lightmap is ok!
> >
> > You should see John Ratcliff's work... I remember his moon-lightmap and
it
> > looks great. John, are you still a member of this list? Could you please
> > upload that moon-lightmap of yours again?
> >
> > Niki
> >
> >
> > _______________________________________________
> > 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] View culling example

[Klaus H. <k_h...@os...>]

That's a *very* nice sample, Michael.

However, I would prefer if you didn't name that culling method after me,
because I didn't invent it :) I also had a look at the source and saw 'tons'
of "swHartmann" variables in there... even in the plane extraction, which
was 'invented' by Gil Gribb. Also, I would prefer if you didn't mention my
e-mail address in the source code :)

So, please remove my name as well as my e-mail address from the source. Of
course, you may mention me in the header and maybe write something like
"Parts of this source code are based on Klaus Hartmann's AABB-Culling
sample", but that's enough. Don't give me too much credit for something I
didn't invent. I only reused existing algorithms, and put them into a small
sample.

Thanks,
Niki

PS: I didn't take this off-line, because I'm sure that some people on this
list will download the source. I think they should know that it wasn't me
who invented these nice algorithms.

From: Michael S. Harrison <mic...@ud...>
> As (what I hope is) a favor to the people who've helped me with the view
culling code and in an attempt to help future coders, I've taken the view
culling example from the OpenGL FAQ, Klaus Hartmann's view culling sample
and merged them both with Nate Robbin's OpenGL tutors (mostly because his
projection sample really helped me to see what was going on with the various
culling examples out there).
>
> It's available at http://lynx.inertiagames.com/~michael/OPENGLTUTORS.zip
>
> make sure you uncompress with directory re-creation
>
> run the viewcull.exe program to play with the sample
>
> - software culling is toggled with the spacebar
> - if software culling is enabled, Hartmann culling is toggled with the 'h'
key
> - if a model is selected from the screen menu (right click on the screen
space view)
>   that model will be displayed at the origin.  If it's culled, it will be
drawn untextured.
>
> NOTE that this should probably not be linked to on any web page or
generally distributed other than through word of mouth.  I haven't asked
Nate to include it "officially" as part of his tutor group but perhaps he
will if he thinks it's useful enough.
>
>
> - Michael Harrison
>   High Plains Coder,
>   United Developers / Inertia, LLC
>   Work log @ http://lynx.inertiagames.com
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>

RE: [Algorithms] Alpha Channel

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

And if you only care about on/off transparency, alpha test will also save
you on having to depth sort your trees. All the better if you are going to
have 2x-3x the number of trees. The alpha-test early-outs the z-write (hows
that for a hyper-hyphenated sentence) and so you don't have the
need-to-sort-transparent-objects problem.

The demo we showed at IDF shows this off nicely. Source code to be released
really soon. promise.

Kim Pallister

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


> -----Original Message-----
> From: Discoe, Ben [mailto:ben...@in...]
> Sent: Saturday, August 26, 2000 8:33 PM
> To: 'gda...@li...'
> Cc: vt...@eg...
> Subject: RE: [Algorithms] Alpha Channel
> 
> 
> 
> Pai-Hung,
> 
> It is indeed a difficult process to generate a good 8-bit 
> alpha channel for
> a 32-bit texture.  For nearly any photographic data source, 
> it cannot be
> done procedurally.  It requires a human artist to produce 
> usable results.
> Here is a tutorial i wrote on how to produce the alpha using 
> PhotoShop:
> http://vterrain.org/Plants/Create/
> 
> Part of why it is so difficult is that along the perimeter of 
> the shape
> (e.g. tree) there are pixels with alpha between 0 and 1, so 
> bits of the
> surrounding (non-tree) texel color will appear on the output. 
>  This is very
> difficult to fix.  No matter what color you choose (black is a common
> choice), you will get a "fringe" of that color around the 
> resulting texture
> billboard, unless you hand-edit on a nearly pixel basis.
> 
> One popular simplification is to use single-bit alpha (alpha 
> testing, not
> alpha blending).  The advantages are that the art task is 
> easier, and you
> don't have to draw the texture billboards in back-to-front 
> order, which can
> be a significant performance hit since it is faster to sort 
> by texture to
> avoid context switches.  The drawbacks are harsh, unnatural 
> aliased edges
> for your texture billboards.
> 
> In the VTP software, we currently use 8-bit alpha blending 
> for quality, but
> i'm considering switching to alpha-testing for speed.  A 
> forest may be more
> convincing with 2-3x as many trees even if the trees have 
> jittery edges.
> 
> Good luck,
> Ben
> http://vterrain.org/
> 
> > -----Original Message-----
> > From: Pai-Hung Chen [mailto:pa...@ac...]
> > Sent: Saturday, August 26, 2000 1:09 PM
> > To: gda...@li...
> > Subject: [Algorithms] Alpha Channel
> > 
> > Hi,
> > 
> > I want to use billboard in my program but cannot find a good 
> > way to create 32-bit bitmap with alpha channel of appropriate
> > values.  Basically I want to create a bitmap of tree with leaves
> > in various green colors (with alpha = 255) and all non-green
> > colors transparent (alpha = 0) so that I can use it
> > as the texture for my billboarded trees.
> 
> 
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> 

RE: [Algorithms] It looks terrible (was: Lightmap Terrain)

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

Niki,

Why are you anti-ambient lighting?

Everyone else, am I the only one that find's Ralf's email address
intriguing?

Kim Pallister

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


> -----Original Message-----
> From: Ralf Schneider [mailto:rap...@ra...]
> Sent: Sunday, August 27, 2000 8:27 AM
> To: gda...@li...
> Subject: Re: [Algorithms] It looks terrible (was: Lightmap Terrain)
> 
> 
> Niki,
> 
> well it do NOT look that terrible!
> it's a lightmap, isn't it? what du you suspect?
> shadows make scenes nore realistic, not neccesarily 
> beautiful. you are loosing visual information if yo add 
> shadows to a top down view of a heightfield. you know that 
> already, because you are trying to avoid it, by using a 
> second light source instead of ambient light (we can say the 
> second light is simulating the reflection of the sun at the 
> other mountain...).
> 
> take a look at some landscape/mountain top-down photos. i 
> guess, you will recognice you lightmap is ok!
> 
> greetings, ralf
> 
> 
> | Hi all,
> 
> | Please have a look at the following image (~310 KB):
> | http://www.thecore.de/TheCore/shadows.jpg
> 
> | This lightmap looks majorly terrible, and I'm looking for 
> ways to enhance
> | this. I use the simple dot-product approach, and I have two 
> light source.
> | One light source (sun) is to the east, and the other 
> ('anti' sun) is to the
> | west. I use two light sources, because I don't like 
> ambient. I compute the
> | light for each texel, and then I cast a ray towards the sun 
> (directional
> | light). If this ray intersect with the surface before it 
> reaches the sun,
> | then I decrease the texel's intensity by some amount. I 
> don't reflect or
> | refract rays. I figured, that reflection probably wouldn't 
> make much sense,
> | because there's only a few cases where the reflected ray 
> would hit the
> | terrain again (or am I wrong?).
> 
> | How can I make this look better? For example, is there a 
> way to have real
> | penumbrae in the shadows. Of course, I could blur the 
> image, but that just
> | wouldn't be the same.
> 
> | Any ideas? Honestly... a simple dot-product (without 
> shadows) looks more
> | than twice as good (I can upload the same scene without shadows, if
> | requested).
> | Niki
> 
> | _______________________________________________
> | GDAlgorithms-list mailing list
> | GDA...@li...
> | http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> 
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> 

[Algorithms] View culling example

[Michael S. H. <mic...@ud...>]

As (what I hope is) a favor to the people who've helped me with the view culling code and in an attempt to help future coders, I've taken the view culling example from the OpenGL FAQ, Klaus Hartmann's view culling sample and merged them both with Nate Robbin's OpenGL tutors (mostly because his projection sample really helped me to see what was going on with the various culling examples out there).

It's available at http://lynx.inertiagames.com/~michael/OPENGLTUTORS.zip

make sure you uncompress with directory re-creation

run the viewcull.exe program to play with the sample

- software culling is toggled with the spacebar
- if software culling is enabled, Hartmann culling is toggled with the 'h' key
- if a model is selected from the screen menu (right click on the screen space view)
  that model will be displayed at the origin.  If it's culled, it will be drawn untextured.

NOTE that this should probably not be linked to on any web page or generally distributed other than through word of mouth.  I haven't asked Nate to include it "officially" as part of his tutor group but perhaps he will if he thinks it's useful enough.


- Michael Harrison
  High Plains Coder, 
  United Developers / Inertia, LLC
  Work log @ http://lynx.inertiagames.com

RE: [Algorithms] Lots of problems...

[Kevin L. <lac...@in...>]

On Sat, 26 Aug 2000, dga wrote:

> >First tranlate the object to the origin. Then perform the rotation. Then
> >transform it back to where it was.
> 
> If I posconcatenate the matrix, there is no need to do the translation to
> the origin... The rotation is done before any other operation... At least, I
> think so...
> 
> >And for a stab at number four. This will depend on how smart you want
> >the
> >missle to bvehave. You could at every refresh have the missle rotate
> >itself toward the current position of its target. Find the position of
> >the
> >two and use a cross product to find the angle. Then move the missle by
> >some value in that direction. This assume a very smart missle.
> 
Sorry, yes that should be dot product.

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

-- 

RE: [Algorithms] OpenGL LockArrayEXT ... workaround

[Ignacio C. <i6...@ho...>]

Charles Bloom wrote:
> First off, the 64k limit is just because 16-bit indices are used for vertices,
> and that's a hard limit to stay for quite some time, I imagine.  As for that 2k
> vertices per buffer, that was an anomaly of old GeForce drivers, and has been
> removed.  Hey NVidia, you need to make a new document on how to optimize for T&L
> that doesn't dwell so much on the oddities of the GeForce (which really does
> have odd performance characterics which are not typical of Radeon and other
> future T&L products, like NV20 presumably).

no, you are right, i took that info from the old document, there's a new one, in which no limit was
mentioned, or if it was, i didn't notice it.


Ignacio Castano
ca...@cr...

Re: [Algorithms] It looks terrible (was: Lightmap Terrain)

[Jim O. <j.o...@in...>]

Hey Niki,

Some suggestions which might make your lightmap (and not to forget your
terrain) look better/nicer. Maybe you have already considered these, but
then again, you never know :-)

- Perhaps you could use a lighter ambient color (instead of something
nearing total blackness, say about 20-25% gray or something). Near black
shadows are not really common in real life, specially not in open terrains -
always plenty of ambient light.

- When raytracting your lightmap, you could perhaps use the corners of each
pixel/texel instead of the centers and then use the average of the four
corners as the pixel's color, essentially applying a bilinear filter to your
light map.

- It is just a hunch (no scientific basis, other than my own observations),
but it might look good if you lighten the shadow areas based on the slope of
the terrain, so that shadows on steep areas look darker than those on flat
areas, which in my eyes also happens in reality. Reason for this effect
could be that more diffuse light is being reflected on the flat areas by the
clouds, but again, I have no scientific basis for this assumption.

Jim Offerman

Innovade
- designing the designer

----- Original Message -----
From: "Klaus Hartmann" <k_h...@os...>
To: <gda...@li...>
Sent: Sunday, August 27, 2000 6:32 PM
Subject: Re: [Algorithms] It looks terrible (was: Lightmap Terrain)


> Welcome, Ralf :)
>
> ----- Original Message -----
> From: Ralf Schneider <rap...@ra...>
> > Niki,
> >
> > well it do NOT look that terrible!
> > it's a lightmap, isn't it? what du you suspect?
>
> What I suspect is a nice image :) See, I've actually tried this shadow
stuff
> in my terrain engine, and in 3D it looks far worse than the lightmap. I
> tried this with a hybrid multifractal, though... maybe it looks better
with
> real world data as show in the image. Gotta try this, but it's a bit more
> work.
>
> > shadows make scenes nore realistic, not neccesarily beautiful.
>
> This is a good description. The unrealistic dot-product-only lit scene (in
> 3D) looks much better, even though it's not as realistic as the shadowed
> version.
>
> >you are loosing visual information if yo add shadows to a top down view
of
> a heightfield. you know that already, because you are trying to avoid it,
by
> using a second light source instead of ambient light (we can say the
second
> light is simulating the reflection of the sun at the other mountain...).
>
> Yes, this is quite a problem. If I use no second light source, then
there's
> zero shading on the faces opposite to the sun, which basically means that
I
> lose all the nice features. If, on the other hand, I use a secondary light
> source (plus shadows), then I get artifacts as the one's in the
upper-right
> shadow-area of the image I posted. This looks as if I used false gays (as
in
> false color). In 3D this becomes even worse.
>
> > take a look at some landscape/mountain top-down photos. i guess, you
will
> recognice you lightmap is ok!
>
> You should see John Ratcliff's work... I remember his moon-lightmap and it
> looks great. John, are you still a member of this list? Could you please
> upload that moon-lightmap of yours again?
>
> Niki
>
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>

RE: [Algorithms] OpenGL LockArrayEXT ... workaround

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

At 10:21 PM 8/27/00 +0200, you wrote:
>I got this from nvidia site:
>
>"There is an optimal size for vertex buffers - a fact which is not intuitively obvious.
>You should aim for around 2000 vertices per buffer or for around 64K of RAM used."

First off, the 64k limit is just because 16-bit indices are used for vertices,
and that's a hard limit to stay for quite some time, I imagine.  As for that 2k
vertices per buffer, that was an anomaly of old GeForce drivers, and has been
removed.  Hey NVidia, you need to make a new document on how to optimize for T&L
that doesn't dwell so much on the oddities of the GeForce (which really does
have odd performance characterics which are not typical of Radeon and other
future T&L products, like NV20 presumably).

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

RE: [Algorithms] OpenGL LockArrayEXT ... workaround

[Ignacio C. <i6...@ho...>]

Brian Sharp wrote:
> My conference?
>
> Any information I have on Q3A is pretty much hearsay from Brian Hook.  Or
> maybe you're referring to Brian Hook, not Brian Sharp?  We're more
> different than our last names: I never worked for id. ;-)

hoops, sorry, you are completely right, i meant Brian Hook :-)

> ...
>
> I'm not really sure what the motivation would be for a driver to not
> optimize arrays over a certain size.  I mean, they could only pretransform
> a set number and treat any more as regular verts to be
> transformed.  Hmm.  Especially if it's a hardware T&L implementation, where
> you'd obviously want to have a tiered caching system in the driver already,
> capable of locked arrays on the host bigger than your hardware cache.  I'm
> confused.

yes, that's what happens on the geforce, that has a limit of 65536 vertexes, because indexes must be
lower than that.

I got this from nvidia site:

"There is an optimal size for vertex buffers - a fact which is not intuitively obvious.
You should aim for around 2000 vertices per buffer or for around 64K of RAM used."

"GeForce products require indices to not exceed 65535. If more indices are
necessary, break the object into smaller parts."


PD: i will send this message also to the OpenGL Gamedev list, so if you want to continue this
thread, do it there.


Ignacio Castano
ca...@cr...

Re: [Algorithms] Re: Lightmap Terrain (dynamic range)

[Ralf S. <rap...@ra...>]

yo may also read this article from hugo elias:

http://freespace.virgin.net/hugo.elias/graphics/x_posure.htm

- ralf

| At 02:52 PM 8/25/2000, you wrote:
|>Bottomline: the problem is exactly the same for cinema and video, so if
|>you're happy with the "sun impression" that you get on films, there is
|>no physical limitation with your CRT display that will prevent you from
|>getting teh same with 3D games.

| Very true. I for one don't really want a CRT capable of emitting energy
| ranges equal to real life. I mean, staring into the sun hurts :)

| I did a lot of work on dynamic range management for digital cameras a
| little while back. The techniques I used where based on pixel statistics
| (histograms) of the luminance values of the image in a feedback system
| (calc statistics for current frame, adjust next frames exposure time and
| digital gains to compensate). I came up with a pretty sweet system that
| would converge on an answer in very few frames, and was very resistant to
| oscillations (even with the optimizations required to be workable in cheap
| hardware).

| Adjusting gamma values will not give you the desired result however. A
| couple of reasons:
| 1. You'll get banding as you stretch or squish the range by any significant
| amount. Applying any gamma value other than 1.0 (identity) throws away bits
| of color resolution.
| 2. Going from inside to outside is a HUGE range shift ... on the order of
| ~200 Lux for a normally lit office inside to ~5000 lux for outside at noon
| in the summer on a clear day. Not something that will scale well with just
| a gamma change.

| My biggest problem is finding a good way to extract intensity information
| from the scene. The simplest method is to read the pixels back from the
| frame, calculate the statistics I've mentioned above and scale the
| lightmaps accordingly (which means everything gets a light map ... even the
| sky). Of course, reading back the frame buffer into system memory to
| perform the calculation is slow at best.

| Another possibility would be to attach intensity information to surfaces
| and accumulate the statistics on those as they're added to the scene.
| Unfortunately this doesn't give you very good information about occlusion.

| Another idea I just had would be to create low-res imposters for the items
| in the scene (people and cars would be cubes, etc) and render these with
| software into an intensity image with proper occlusion tests (zbuffer ...
| span buffer .. whatever). The result could then be used to get a coarse
| approximation of the scene intensity. With something like a span buffer you
| would never need to generate the image itself as you could calculate pixel
| statistics from the spans and still have proper occlusion.

| Tom

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

Re: [Algorithms] Alpha Channel

[Max G. <gi...@li...>]

Pai-Hung Chen wrote:

>  Is there any program capable of doing that with 32-bit bitmap
> with alpha channel?

This can be done in any reasonable program like GIMP for example (available for
Win also).

Max


--
Max Gilead (gi...@li...) http://3d.linart.krakow.pl/OfficinaArtificialis
-----------------------------------------------------------------------------
-- Duck season! Rabbit season! Duck season! Rabbit season! ELMER SEASON!!! --

Re: [Algorithms] It looks terrible (was: Lightmap Terrain)

[Johan H. <jh...@mw...>]

Hi,, have you read my previous email on radiocity in hardware? Thta should
solve most of this?
I dont really know how this comares in speed to your current method though.

Johan

[Algorithms] Building BSPs Robustly

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

A question for the BSP experts : what do you do to make
your BSP building robust (eg. numerically safe) ?
Is there an article on these issues? (still working on
that BSP article, Angel?).

Now for more detail.  Let me stick to two dimensions for
simplicity.  I'm building a 2d BSP from convex polygons.
To do that, you just take the polygon and send it down
the tree, clipping it against each plane in the tree.
Eventually you arrive at a leaf.  At that point I take
all the segments of the clipped polygon which arrives
at that leaf, and add them to the tree if and only if
the plane they create isn't already in the tree.  This
make it so that if you have a little empty leaf in
the tree and you add a polygon that covers it completely
you don't end up adding any planes, you just mark that
leaf is solid now.

Now, we run into robustness problems.  The first problem
is just with tiny segments.  Sometimes after clipping you
end up with very short segments in your leaves, that you
can't do a reliable cross product on to make a normal for
use in the plane.  I just throw out these short segments
(seems reasonable).

All of the remaining problems come from numerical errors
on the plane clipping.  This arises because when you take
a point, find the distance to a plane, and push it by
that distance, you don't end up with a point right on that
plane.

   d = plane.DistanceToPoint( point );
   point += d * plane.normal;
   d = plane.DistanceToPoint( point );

Now d is small, but not zero !  The point is slightly off
the plane in some direction.  This will always happen, no
matter how you do your plane clipping, and whether you
use floats or doubles (I use floats).

The result is that you can end up with non-convex polygons
in the leaves.  These can happen in 2 major ways (
see http://www.cbloom.com/bsp_problems.gif "):

1. "bend-ins".  This is when you have three verts that
are very nearly co-linear.  If the clipping had been perfect,
they would have been colinear.  Instead, the middle one fell
a bit to the inside of the other two, creating a very mild
star-trek-symbol shape.  I get rid of these by finding the
triangles that have very small areas and deleting their middle
vertex.

2. "fish-tails".  Take a triangle.  Duplicate one of the verts
to make it a quad with two verts right on top of eachother.
Take one of the duplicated verts and pull it across its twin
so that the segments of the quad intersect.  This makes a
segment with the wrong winding, two triangles with upside
down normals.  This is a big crisis for a BSP, because that
wrong-facing segment will make a plane facing the wrong way.
Most of the time, this will be fixed by deleting the very
short segments, but I still seem to get it once in a rare
while.  The rest of the time, I fix it by turning the segments
in to planes.  In my convention, proper planes will have
all the other verts of the polygon on its front side.  Thus,
any plane which has verts of the polygon on its back side
is simply tossed out, and its end-points are snapped together.

So, I find this all a bit scary (if I "fix" my leaf polygons
in the wrong way, I'll end up getting a BSP different than I
intended), and what's worse, I'm building these BSP's in real
time, and all this testing for convexity of the leaf polygons
is one of my biggest bottlenecks.  Help appreciated.

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

Re: [Algorithms] It looks terrible (was: Lightmap Terrain)

[Klaus H. <k_h...@os...>]

I wrote:
> ...shadow-area of the image I posted. This looks as if I used false gays
(as in
> false color).

Of course, I wanted to write "grays"... if at least I had written it with an
'e' instead of an 'a'. Sorry... I'll blame Outlook Express :)

Niki

Re: [Algorithms] It looks terrible (was: Lightmap Terrain)

[Klaus H. <k_h...@os...>]

Welcome, Ralf :)

----- Original Message -----
From: Ralf Schneider <rap...@ra...>
> Niki,
>
> well it do NOT look that terrible!
> it's a lightmap, isn't it? what du you suspect?

What I suspect is a nice image :) See, I've actually tried this shadow stuff
in my terrain engine, and in 3D it looks far worse than the lightmap. I
tried this with a hybrid multifractal, though... maybe it looks better with
real world data as show in the image. Gotta try this, but it's a bit more
work.

> shadows make scenes nore realistic, not neccesarily beautiful.

This is a good description. The unrealistic dot-product-only lit scene (in
3D) looks much better, even though it's not as realistic as the shadowed
version.

>you are loosing visual information if yo add shadows to a top down view of
a heightfield. you know that already, because you are trying to avoid it, by
using a second light source instead of ambient light (we can say the second
light is simulating the reflection of the sun at the other mountain...).

Yes, this is quite a problem. If I use no second light source, then there's
zero shading on the faces opposite to the sun, which basically means that I
lose all the nice features. If, on the other hand, I use a secondary light
source (plus shadows), then I get artifacts as the one's in the upper-right
shadow-area of the image I posted. This looks as if I used false gays (as in
false color). In 3D this becomes even worse.

> take a look at some landscape/mountain top-down photos. i guess, you will
recognice you lightmap is ok!

You should see John Ratcliff's work... I remember his moon-lightmap and it
looks great. John, are you still a member of this list? Could you please
upload that moon-lightmap of yours again?

Niki

Re: [Algorithms] It looks terrible (was: Lightmap Terrain)

[Klaus H. <k_h...@os...>]

Phil,

Yes, this is sort of like distributed ray tracing. I was hoping to avoid
this, because it's very slow as you already say. In distributed ray tracing
you basicall cast 16 different ray through the same pixels, and then average
the result. The additional features of this are (more information in
"Advanced Animation and Rendering Techniques"):
- blurred reflections
- blurred refractions
- soft shadows (penumbrae)
- depth of field (focusing)
- blur due to relative motion of the virtual camera and the scene.

As far as I understand it, it's also pretty memory intense, but maybe
there's no other option.  However, I'll try your method first, as it's easy
to incorporate into my current implementation.

Thanks,
Niki

----- Original Message -----
From: Phil Bak <ph...@de...>


> hey,
>
> i do the same thing as you except i have one directional
> light for the sun, cast the ray and then if it intersects
> don't add on the diffuse just leaving the ambient.
>
> i found i have to play with the sun's direction a lot
> to get good results - really long shadows seem to look
> a little weird for me.
>
> >For example, is there a way to have real penumbrae in the
> >shadows.
>
> this is a fudge but what i've been doing is creating 7
> lightmaps and then do something like...
>
> GenerateLightmap( lightmap0, lightlist );
> file://x jitter by 10%
> JitterLights( lightlist, 0.1, 0.0, 0.0 );
> GenerateLightmap( lightmap1, lightlist );
> JitterLights( lightlist, -0.1, 0.0, 0.0 );
> GenerateLightmap( lightmap2, lightlist );
> file://y jitter by 10%
> JitterLights( lightlist, 0.0, 0.1, 0.0 );
> GenerateLightmap( lightmap3, lightlist );
> JitterLights( lightlist, 0.0, -0.1, 0.0 );
> GenerateLightmap( lightmap4, lightlist );
> file://z jitter by 10%
> JitterLights( lightlist, 0.0, 0.0, 0.1 );
> GenerateLightmap( lightmap5, lightlist );
> JitterLights( lightlist, 0.0, 0.0, -0.1 );
> GenerateLightmap( lightmap6, lightlist );
>
> and then just average all the lightmaps into a final one.
>
> all the jitter function is doing is changing the positions
> of the lights... like i said, it's a big hack but those hard
> shadows went soft immediately and look pretty good now.
>
> the downside of course is that it takes a long time to
> generate a final lightmap.
>
> >I could blur the image, but that just wouldn't be the same.
>
> i tried this before doing the above and couldn't get
> anything decent too.
>
> regards.
>
> Phil Bak
> ICQ:11204037 Tel:01908 393837 Email:ph...@de...
Web:www.deepred.co.uk
> ---
>
> Privileged/Confidential Information may be contained in this message.  If
> you are not the addressee indicated in this message (or responsible for
> delivery of the message to such person), you may not copy or deliver this
> message to anyone.  In such case, you should destroy this message and
kindly
> notify the sender by reply email. Please advise immediately if you or your
> employer does not consent to Internet email for messages of this kind.
> Opinions, conclusions and other information in this message that do not
> relate to the official business of my firm shall be understood as neither
> given nor endorsed by it.

Re: [Algorithms] It looks terrible (was: Lightmap Terrain)

[Sam K. <sa...@ip...>]

Niki,

Here's something I've done in the past, which gets rid of the hard edge from
"just darkening by some ammount if the ray intersected" and looks pretty
good:

Cast a ray from the sun to the sample point (Instead of Sample point to
sun). (Starting at the edge of the map, or further if the terrain is tiled).

You have a running shadow height (SHeight) which is set to 0. and a (RayDy)
variable which is the y dropoff of the ray per pixel moved.

Move along the ray (in x & z) towards the sample point. At each Heightmap
pixel the ray passes over on the way do the following:

If(SHeight<HeightmapPixelVal)
{
    SHeight = HeightmapPixelVal;
}
else
{
    SHeight -= RayDy;
}

When the sample point is reached, the value in SHeight is examined, the
smaller it is the "less shadow" is here the bigger the "more shadow". This
gives lovely graduations in the shadow, and real dark areas, and subtle
lighter areas.

Another nice trick is, if you store the resulting shadow height at every
sample point to form a "shadow buffer", objects on the terrain can fall into
shadow correctly if you compare their heights to the height in the "shadow
buffer" even when they are not on the ground. This in effect is 2.5d
volumetric shadows.

Hope this helps,

sam


-----Original Message-----
From: Klaus Hartmann <k_h...@os...>
To: gda...@li...
<gda...@li...>
Date: 27 August 2000 2:48 PM
Subject: [Algorithms] It looks terrible (was: Lightmap Terrain)


>Hi all,
>
>Please have a look at the following image (~310 KB):
>http://www.thecore.de/TheCore/shadows.jpg
>
>This lightmap looks majorly terrible, and I'm looking for ways to enhance
>this. I use the simple dot-product approach, and I have two light source.
>One light source (sun) is to the east, and the other ('anti' sun) is to the
>west. I use two light sources, because I don't like ambient. I compute the
>light for each texel, and then I cast a ray towards the sun (directional
>light). If this ray intersect with the surface before it reaches the sun,
>then I decrease the texel's intensity by some amount. I don't reflect or
>refract rays. I figured, that reflection probably wouldn't make much sense,
>because there's only a few cases where the reflected ray would hit the
>terrain again (or am I wrong?).
>
>How can I make this look better? For example, is there a way to have real
>penumbrae in the shadows. Of course, I could blur the image, but that just
>wouldn't be the same.
>
>Any ideas? Honestly... a simple dot-product (without shadows) looks more
>than twice as good (I can upload the same scene without shadows, if
>requested).
>Niki
>
>_______________________________________________
>GDAlgorithms-list mailing list
>GDA...@li...
>http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

Re: [Algorithms] It looks terrible (was: Lightmap Terrain)

[Ralf S. <rap...@ra...>]

Niki,

well it do NOT look that terrible!
it's a lightmap, isn't it? what du you suspect?
shadows make scenes nore realistic, not neccesarily beautiful. you are loosing visual information if yo add shadows to a top down view of a heightfield. you know that already, because you are trying to avoid it, by using a second light source instead of ambient light (we can say the second light is simulating the reflection of the sun at the other mountain...).

take a look at some landscape/mountain top-down photos. i guess, you will recognice you lightmap is ok!

greetings, ralf


| Hi all,

| Please have a look at the following image (~310 KB):
| http://www.thecore.de/TheCore/shadows.jpg

| This lightmap looks majorly terrible, and I'm looking for ways to enhance
| this. I use the simple dot-product approach, and I have two light source.
| One light source (sun) is to the east, and the other ('anti' sun) is to the
| west. I use two light sources, because I don't like ambient. I compute the
| light for each texel, and then I cast a ray towards the sun (directional
| light). If this ray intersect with the surface before it reaches the sun,
| then I decrease the texel's intensity by some amount. I don't reflect or
| refract rays. I figured, that reflection probably wouldn't make much sense,
| because there's only a few cases where the reflected ray would hit the
| terrain again (or am I wrong?).

| How can I make this look better? For example, is there a way to have real
| penumbrae in the shadows. Of course, I could blur the image, but that just
| wouldn't be the same.

| Any ideas? Honestly... a simple dot-product (without shadows) looks more
| than twice as good (I can upload the same scene without shadows, if
| requested).
| Niki

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

RE: [Algorithms] It looks terrible (was: Lightmap Terrain)

[Phil B. <ph...@de...>]

hey,

i do the same thing as you except i have one directional
light for the sun, cast the ray and then if it intersects
don't add on the diffuse just leaving the ambient.

i found i have to play with the sun's direction a lot
to get good results - really long shadows seem to look
a little weird for me.

>For example, is there a way to have real penumbrae in the
>shadows.

this is a fudge but what i've been doing is creating 7
lightmaps and then do something like...

GenerateLightmap( lightmap0, lightlist );
//x jitter by 10%
JitterLights( lightlist, 0.1, 0.0, 0.0 );
GenerateLightmap( lightmap1, lightlist );
JitterLights( lightlist, -0.1, 0.0, 0.0 );
GenerateLightmap( lightmap2, lightlist );
//y jitter by 10%
JitterLights( lightlist, 0.0, 0.1, 0.0 );
GenerateLightmap( lightmap3, lightlist );
JitterLights( lightlist, 0.0, -0.1, 0.0 );
GenerateLightmap( lightmap4, lightlist );
//z jitter by 10%
JitterLights( lightlist, 0.0, 0.0, 0.1 );
GenerateLightmap( lightmap5, lightlist );
JitterLights( lightlist, 0.0, 0.0, -0.1 );
GenerateLightmap( lightmap6, lightlist );

and then just average all the lightmaps into a final one.

all the jitter function is doing is changing the positions
of the lights... like i said, it's a big hack but those hard
shadows went soft immediately and look pretty good now.

the downside of course is that it takes a long time to
generate a final lightmap.

>I could blur the image, but that just wouldn't be the same.

i tried this before doing the above and couldn't get
anything decent too.

regards.

Phil Bak
ICQ:11204037 Tel:01908 393837 Email:ph...@de... Web:www.deepred.co.uk
---

Privileged/Confidential Information may be contained in this message.  If
you are not the addressee indicated in this message (or responsible for
delivery of the message to such person), you may not copy or deliver this
message to anyone.  In such case, you should destroy this message and kindly
notify the sender by reply email. Please advise immediately if you or your
employer does not consent to Internet email for messages of this kind.
Opinions, conclusions and other information in this message that do not
relate to the official business of my firm shall be understood as neither
given nor endorsed by it.


-----Original Message-----
From: gda...@li...
[mailto:gda...@li...]On Behalf Of Klaus
Hartmann
Sent: 27 August 2000 14:29
To: gda...@li...
Subject: [Algorithms] It looks terrible (was: Lightmap Terrain)


Hi all,

Please have a look at the following image (~310 KB):
http://www.thecore.de/TheCore/shadows.jpg

This lightmap looks majorly terrible, and I'm looking for ways to enhance
this. I use the simple dot-product approach, and I have two light source.
One light source (sun) is to the east, and the other ('anti' sun) is to the
west. I use two light sources, because I don't like ambient. I compute the
light for each texel, and then I cast a ray towards the sun (directional
light). If this ray intersect with the surface before it reaches the sun,
then I decrease the texel's intensity by some amount. I don't reflect or
refract rays. I figured, that reflection probably wouldn't make much sense,
because there's only a few cases where the reflected ray would hit the
terrain again (or am I wrong?).

How can I make this look better? For example, is there a way to have real
penumbrae in the shadows. Of course, I could blur the image, but that just
wouldn't be the same.

Any ideas? Honestly... a simple dot-product (without shadows) looks more
than twice as good (I can upload the same scene without shadows, if
requested).
Niki

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

[Algorithms] It looks terrible (was: Lightmap Terrain)

[Klaus H. <k_h...@os...>]

Hi all,

Please have a look at the following image (~310 KB):
http://www.thecore.de/TheCore/shadows.jpg

This lightmap looks majorly terrible, and I'm looking for ways to enhance
this. I use the simple dot-product approach, and I have two light source.
One light source (sun) is to the east, and the other ('anti' sun) is to the
west. I use two light sources, because I don't like ambient. I compute the
light for each texel, and then I cast a ray towards the sun (directional
light). If this ray intersect with the surface before it reaches the sun,
then I decrease the texel's intensity by some amount. I don't reflect or
refract rays. I figured, that reflection probably wouldn't make much sense,
because there's only a few cases where the reflected ray would hit the
terrain again (or am I wrong?).

How can I make this look better? For example, is there a way to have real
penumbrae in the shadows. Of course, I could blur the image, but that just
wouldn't be the same.

Any ideas? Honestly... a simple dot-product (without shadows) looks more
than twice as good (I can upload the same scene without shadows, if
requested).
Niki

RE: [Algorithms] Alpha Channel

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

And Paint Shop Pro will do alpha channels with a bit of coaxing.

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

> -----Original Message-----
> From: Joe Barnes [mailto:jb...@av...]
> Sent: 26 August 2000 23:28
> To: gda...@li...
> Subject: RE: [Algorithms] Alpha Channel
> 
> 
> There isn't anything our artists can't do with Adobe Photoshop. 
> 
> > -----Original Message-----
> > From: gda...@li...
> > [mailto:gda...@li...]On Behalf Of
> > Pai-Hung Chen
> > Sent: Saturday, August 26, 2000 3:51 PM
> > To: gda...@li...
> > Subject: Re: [Algorithms] Alpha Channel
> > 
> > 
> > Thanks for the help.  Actually I am looking for a graphics 
> package that
> > allow me to pre-process (e.g. color-keying) the alpha info into 
> > the bitmap,
> > so that I can use it directly as alpha-translucent billboard in 
> > my program.
> > 
> > Pai-Hung Chen
> 
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> 

Re: [Algorithms] Water Effects

[Vladimir K. <vka...@si...>]

Hi All,

Also it is difficult to combine animated water grid 
with geometry based reflections (not rendered into texture).
So my ocean has flat water :)

vlad

Re: [Algorithms] Water Effects

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

Don't know if it can help, but here's a copy of an old answer to a private
mail from John Ratcliff.
Nothing to add since last time. :)

Pierre

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

-----Original Message-----
From: Pierre Terdiman [mailto:p.t...@wa...]
Sent: Monday, May 22, 2000 1:46 PM
To: John W. Ratcliff
Subject: Re: Water effect


Hi John,

I can't post the executable because it used a commercial engine for which I
simply haven't the rights. I worked on it for one year, but now I don't work
for the same company anymore, and I think they wouldn't allow me to spread
all that stuff.

Now, the demo isn't really useful since you have me instead :)))))))

My approach was easy, it was just a 3D version of the ultra-famous 2D water
effect (seen in several demos for years, and recently rediscovered in a Game
Developer article). This is not physically correct, but the result looks
nice. I tried more physically accurate methods in a school project called
Vortex, where I used an algorithm by Nick Foster and Dimitri Metaxas. The
results were just a little more exact (the rotational part of the
Navier-Stokes equation was taken into account for example), but taken as a
whole it wasn't visually better. On the other hand it took a lot of time to
compute, sure. Hence, I usually take the old demoish route. (historical
notes: I first saw that water effect in a very old DOS demo by a spannish
group called Iguana. It appears one of their members, JCAB, is a well-known
name on the algorithms & DX lists....small world).

I also have an old 2D version of that, somewhere on my site. Should be in
www.codercorner.com/Oldies.zip, but the download is quite big, and the
effect is the same as in the recent GD article, so just download it if
you're curious - and if you can run pure DOS mode programs.

The 3D version is a simple height-field computed from the 2D water picture.
I also use a bitmask texture telling me where the coasts are, and where the
water is. Using that mask in the computation makes the water bounce on the
coasts, which is quite convincing. I sometimes add an extra filter on the
computed water height-field, to smooth it. But this tends to be slow. Oh! It
should be possible to compute the whole thing using hardware texture
blending, SetRenderTarget, etc. That would be some "hardware fluid
dynamics", and it apparently looks like the recent Kim Pallister article
about procedural clouds. It looks painful to implement anyway. Never tried.

That was the modeling part. To render the water, I think the best way
nowadays is with cube-mapped refractions. I guess you already know the
NVIDIA demo showing that effect in action. (there's another one - better -
for the GeForce2, originally found on the Kano website - I can find the link
if you don't see what I'm talking about). Kim Pallister also had a demo with
bump-mapped water, which is really one of the best way to handle that part -
but of course, it just runs on G400, and I haven't such a card. Some of the
most convincing water images from Ken Musgrave & al, are just rendered with
an fBm as a bump map. Easy and efficient. Now, some really convincing water
images were produced by Arete Software, and used in some films (Titanic, 5th
Element..). Strangely enough, it looks quite easy to do. Really looks like
my 3D water mixed with a bump map (a fractal cellular noise for example, as
seen in SIGGRAPH'96, is damn convincing for water.)....Those last pointers
shouldn't be possible in realtime anyway (...well, I'm not even sure of
that, nowadays everything is possible, isn't it?)

The biggest problem I can think about, is the size of the needed water.
That's quite easy to produce convincing water on a little scale, but
producing oceans the same way is ....well, not possible.

I don't have a lot of time to continue my water-tests, but fractal mountains
and landscapes are one of my all-time favorite computer topics, and I'd be
glad to follow your quest in search of the perfect water!

Attached is a snapshot of the 3D water field, once rendered with a diffuse
and a specular texture. Note the aliasing problems. That's why I add a
smoothing filter sometimes. I saw the same effect in a PS2 game, in a
fountain. That's exactly what I said before: interacting with a particle
system, it looks really nice for a simple fountain. But it may be quite hard
to use the same effect on a very large scale, e.g. for seas, etc...

Ok, enough!


Pierre


----- Original Message -----
From: John W. Ratcliff <jra...@ve...>
To: <p.t...@wa...>
Sent: Monday, May 22, 2000 9:39 PM
Subject: Water effect


> Pierre,
>
> Are you going to post an executable demo of the water effect in your
> terrain demo?  I'm real interested in exploring different approaches to
> the problem.
>
> Thanks,
>
> John
>

RE: [Algorithms] Alpha Channel

[Discoe, B. <ben...@in...>]

Pai-Hung,

It is indeed a difficult process to generate a good 8-bit alpha channel for
a 32-bit texture.  For nearly any photographic data source, it cannot be
done procedurally.  It requires a human artist to produce usable results.
Here is a tutorial i wrote on how to produce the alpha using PhotoShop:
http://vterrain.org/Plants/Create/

Part of why it is so difficult is that along the perimeter of the shape
(e.g. tree) there are pixels with alpha between 0 and 1, so bits of the
surrounding (non-tree) texel color will appear on the output.  This is very
difficult to fix.  No matter what color you choose (black is a common
choice), you will get a "fringe" of that color around the resulting texture
billboard, unless you hand-edit on a nearly pixel basis.

One popular simplification is to use single-bit alpha (alpha testing, not
alpha blending).  The advantages are that the art task is easier, and you
don't have to draw the texture billboards in back-to-front order, which can
be a significant performance hit since it is faster to sort by texture to
avoid context switches.  The drawbacks are harsh, unnatural aliased edges
for your texture billboards.

In the VTP software, we currently use 8-bit alpha blending for quality, but
i'm considering switching to alpha-testing for speed.  A forest may be more
convincing with 2-3x as many trees even if the trees have jittery edges.

Good luck,
Ben
http://vterrain.org/

> -----Original Message-----
> From: Pai-Hung Chen [mailto:pa...@ac...]
> Sent: Saturday, August 26, 2000 1:09 PM
> To: gda...@li...
> Subject: [Algorithms] Alpha Channel
> 
> Hi,
> 
> I want to use billboard in my program but cannot find a good 
> way to create 32-bit bitmap with alpha channel of appropriate
> values.  Basically I want to create a bitmap of tree with leaves
> in various green colors (with alpha = 255) and all non-green
> colors transparent (alpha = 0) so that I can use it
> as the texture for my billboarded trees.