[pythian] Re: CODE - Lightmaps
- From: "kk" <krauspe@xxxxxxx>
- To: <pythian@xxxxxxxxxxxxx>
- Date: Thu, 4 Jul 2002 13:51:04 +0200
> Good work Kamil! It'll be nice to have lightmaps again. Sounds like I
> have some work to do though. You still want me to change the strip
> algorithm to only create planar strips, right? Is this necessary? I
> don't know exactly how you generate the lightmaps now, but I don't
> understand why it is more difficult to do this for non-planar strips.
> Anyway, it is easy to map a non-planar strip onto a plane. I have done
> this already in the Map Panels option (right-click in the Sectors page)
> and I'm sure I used it elsewhere too. You can use this to approximate
> the strip as a planar strip. Would that work in your system?
You have remembered me about my recent thoughts. I have realised that to
render lightmaps for multi-planar - regular triangle strips is near
impossible - it is very hard and a lot slower. Why?
First, we have to determine the length/rotation - the best horizontal and
vertical axis. Both create a rectangle of projected panel strip vertices.
This would be harder to do with multiplanar tristrips, but not impossible.
Next, remember that the plane normal is needed for diffuse lighting. Diffuse
light component is calculated by multiplying the diffuse light color by
diffuse material color and then by cosine of angle between the plane normal
and light ray. Now, we assume that we have a multiplanar tristrip. So we
have two or more vertices which are owned by more than one triangle. This is
the basic rule of tristrips. But the two different triangles, which own the
given vertex, may be on two different planes. This means that one vertex can
have virtually more normals. This is bad because it is still the same
position in the lightmap - but with two different planes. We may make the
average, but this will smooth the edge light. In some cases this may be more
than appriciated. But in some cases we need hard edges and this wouldn't be
nice. Also think about the case that we would have a corner of room. Its
upper part is made by one multiplanar tristrips. Its lower part is made by
two different single planar tristrips which connect in corner. The upper
part would be a soft edge (corner), the lower would be a hard corner. Bad
thing. Indeed.
But that everything isn't the point. In fact, the point is that lightmap is
not super precise and even vertices may lie between two pixels and thus
their posistion will be rounded. E.g. exact position of vertex is 154.3. It
will be changed to 154. So, if we have a corner, we are unable to precisely
specify the exact position of the corner as the lightmap is linear and
cannot be clustered because of tristrips etc etc... This simply means that
in many cases we would get bad lighting artifacts in edge areas of the
triangles in the tristrips.
There are a lot more consequences than pros. I don't think we would get much
by making a hell messy and buggy multiplanar lightmapping system. Maybe a
lot more processing time (as each time a pixel is rendered - we would need
to calculate which triangle it belongs to, to determine the plane normal for
example... and much more calculations like that) and a lot of bad artifacts
and accursations by map designers.
So, what do you think now?
> I'll look at your implementation of the layered shadered and to clean it
> up and check for problems.
Don't clean it up. Please don't even use it. It is so bad and messy and
hacky that I wouldn't even try to make something similar to it. Just rewrite
the stupid code.
> I took out the JPG implementation in this version because even with 100%
> quality JPG compression there is still a degradation of quality. It
> takes only a handlful of saves and loads before the lightmaps begin to
> look absolute crap. I know this doesn't make sense, but this is what
> happened in the Phase 1 editor. Unless there was a bug in our code, or
> I am wrong that we were using 100% quality, I suggest we stay with
> bitmaps. Now that we are storing all images in data files, we will also
> have a problem with textures and everything will look horrible.
What about to store RLE compressed (or zlib or anything else) - without any
lost in PEM file and JPG 100% quality in PCM?
Yeah and the lightmaps are prepared while building the map into PCM. So PEM
doesn't contain lightmaps right now. I am going to reenable old
lightmapping structures for editor panels ... you know: original
LightSector. - one lightmap per panel. It is very large structure, but we
are going to use like 0.5 lightmap density for preview and 20 for final
version. You may setup the compiled version lightmap density in Map
properties (object editor). Under density I mean the number of pixels per
one world unit (meter). So 10 means 10pixels per 1 meter this is one
lightmap pixel per 10cm. 5cm error is enough for our purposes (density 20).
I am also going to add some additional options and effects for lightmap
generation (for preview and also pcm) like "no shadows" (for fast rendering
of lightmaps if you want just to see like it will look like), materials
(+emmision), customized padding or additional precision settings (e.g.
special corner filter for the bad shadow artifact in some rooms especially
with lower density - maybe).
> Have you tested to see which is faster to load, JPG or bitmap?
> Sometimes the huge amount of data to be read takes longer to read than
> to decompress. I doubt this is the case with images since they are too
> small. Anyway, once we zip the data it compresses a lot which is fine
> for distribution. No sense compressing twice and losing quality and
> load times.
I don't have any problems with loading times. I load 2 meg maps in one or
two seconds...
-kk
Other related posts:
