Warning: Can't synchronize with the repository (Couldn't open Subversion repository /home/crystal/scm/crystal: SubversionException: ("Expected FS format between '1' and '3'; found format '4'", 160043)). Look in the Trac log for more information.

snippets from a mail discussion: quoted text is jorrit, normal thebolt

- 'Better lighting to fix such problems:'.

The new lighter should be able to not have such problems in lightmapping. Both because it will not treat polygons individually when packing them on map, and that it will use (or rather be able to at least) use vertex normals instead of face normals).

As for timing, it all depends on priorities... I have quite a few ideas how to do it, but it takes some time to implement. Some of it is pretty straight-forward and could probably be unloaded onto someone else (any volunteers?:)

- 'In many cases our chars are lit in a dark area': This refers to the problem that software lighting of meshes doesn't consider that the mesh may not be reachable from the light....

Single-ray shadows could work.

Another way could be use of precomputed "light-probes"; either simple

scalar light-fields (a single light value per point) or more

complicated ones with direction-value pairs per point.

Real dynamic (hw) lighting is also an alternative..

- 'thebolt named this as normal parallax mapping with per pixel specularity, whatever it is, looks great. Consider that the stone is geometrically flat, and quite low poly.': This is simple parallax mapping which we support. Only problem is that it is currently hard to use for PS since they have very big levels with lots of lights and the hardware renderloops don't scale well to such big environments. I suppose one way to solve this will be the new lightmaps in combination with hardware lighting for a limited set of lights (i.e. you can exclude lights from being used for hardware lighting so you could only mark a few important lights there). Or are there other options here?

This requires (partly) hardware lighting at least, yes. The biggest issue-solver atm i think is not being able to use some lights only for static and some for dynamic, but rather the ability to set stuff to use N "most important" lights per mesh.

More or less requires the new realtime part (ie render manager); not as much the lighter.