This implements the proposal made in the forum for "shiny" materials -
material can now determine the angle at which the most light is reflected.
Shiny materials might set this lower to approximate a "reflection" effect,
and increase the "spottiness" at the same time. To compensate for the
lack of brightness without light, "emittance" can be used.
Not sure this is the most elegant way to model this - the "proper" way
here would be to have emittance, shading and specular as three separate
light parameters instead of molding one into the other and using the third
to compensate.
Furthermore, this reorganises shaders in a major way: We reduce the
number of shader files down to three, pushing a number of possible
configurations into preprocessor. I believe this should be easier to
understand, which for the moment trumps theoretical extensibility
benefits.
In comparison to the old system, this is a downgrade - instead of being
able to set a full color mapping by gamma ramp, we now get just a value
per colour channel.
Upside is that we do not need to play around with the global gamma ramps
any more, which was arguably the wrong way to do it.
This commit will likely break everything that has been using gamma so far.
This should improve cache coherency by having all surface tiles adjacent
instead of strewn across the heap. This will also remove an indirection
in the common case of only using one tile.
With this change, an additional rectangle is stored in C4FoWRegion that
represents the area covered by the viewport in fractional floating point
coordinates. This allows the light texture to be created for an arbitrary
portion of the landscape, and the coordinate transformations for the
shaders will still work.
Also, since the additional rectangle uses floating point precision, the
computed coordinate transformations do now give the exact same result as for
the landscape pixel-by-pixel, and there should not be any offsets left.
I also hope that this change improves or fixes the single-pixel-lines of sky
that are sometimes seen at the edges of the viewport.
This allows to see the whole landscape without any areas covered by FoW
in the global viewport. Basically the ambient lighting is set to 1.0
independent of the ambient light map. In the course of this, a second
shader for the landscape has been introduced.
There were two problems with the previous transforms:
1) For inverting the Y axis for the ambient map, the total height of the
output window is needed, not only the viewport region.
2) The Y offset to only use the part of the light texture that is being
rendered to was not applied.
In order to keep the transformations more readable, a new lightweight class
C4FragTransform has been introduced which can only handle translations
and scales in x and y.
Turns out we actually can't optimise out the second texture normal
lookup - it makes a noticeable difference in-game. Also there was
possible slice collision, it might be worth warning about this kind
of stuff.
Also removed unused variable, and made error messages more consistent
in terms of whitespace.
The idea here is that we compose shaders out of "slices", which can
come from the engine ("built-in"), from files or possibly even from
models. This should allow us to more easily share the code between
different rendering shaders (e.g. for lights / normals).
TODO: Workarounds not yet implemented, so this might degrade less
gracefully.
This introduces a new texture, an ambient light map, that is generated
automatically at the beginning of the round by the sky portion of the
landscape. This basically makes everything that is close to sky visible
by default.
The shaders have been adapted so that they deploy direction-independent
lighting for the ambient component, and the current (diffuse) behaviour
for the diffuse component. This makes the shaders use an additional
texture unit that represents the ambient light. We can think about merging
this information into the light texture, but the coordinate systems are
different at the moment, so this could be performed at the stage of light
texture generation.
For meshes, the ambient material is not actually used, but instead a
diffuse light from the front is used. This makes many meshes look more
interesting, maybe also because the ambient material setting of most
meshes are not set correctly at the moment.
* added some class and method documentation, removed some superfluous comments like
void C4FoW::Update(C4Rect r)
{
// Update all lights
...
* added ASK comments that need clarification before proper documentation
The new type C4TimeMilliseconds behaves for the most part like a uint32_t but is overflow-proof in comparisons.
In some places, a 0-value (or uint_max) of the variable storing the time had the special meaning "not set yet". This has been resolved by having it as a pointer to C4TimeMilliseconds with NULL meaning that it has not been set yet.
Direct3D hasn't worked for more than a year now, and there don't seem to
be any efforts to revive it. Remove it and concentrate on better OpenGL
support.
The LandscapeRender Init() proc loads graphics from the main graphics group, which is already closed when a section is loaded. So just keep the renderer around on landscape recreation now.
Also set default to 8. This might be a pretty controversial change, but
the amounts of screenshots we have at zoom levels beyond 4 just calls for
a more high-res approach.
Pretty awkward compromise, but the array version seems to confuse a lot of
drivers, without causing an actual error. So this is probably better in
practice until better drivers are more common.
Also set default to 8. This might be a pretty controversial change, but
the amounts of screenshots we have at zoom levels beyond 4 just calls for
a more high-res approach.
Pretty awkward compromise, but the array version seems to confuse a lot of
drivers, without causing an actual error. So this is probably better in
practice until better drivers are more common.
- The light direction change isn't really consistent, as I can only give
GL the vectors at the triangle edges. So for deep rays, the light
distribution often ends up being significantly different than for short
rays.
- I *am* distorting the normal map vectors, quite badly actually. I'll leave
it for the moment, because it definetely looks best for the light vectors,
but I will have to correct that a bit once I have the time.
Some compilers are less strict about this than others, unfortunately.
The Gallium one complains with
preprocessor error: Macro names starting with "GL_" are reserved.
beliar reports that his driver doesn't support the number of fragment shader
uniforms that we're using in the landscape scaler. By making the reported limit
available to the GLSL code, it can use a workaround using a 1D texture to
transfer data.
Peter Wortmann