implementing objects will still be able to keep a regular public
clone() method that may do their own selective deep cloning. This
allows explicit demarcation between the normal 'user' facing clone()
and the two step cloning process used by Cloner.
Specifically, this will let Spatial continue to have a clone() method
that operates as it does today... with its new guts essentially calling
a properly configured Cloner.
However, this is not ideal, as this code will trigger a recompilation of the shader on each pass, in case there is more than 1 lighting pass.
Another way could be to multiply the indirect lighting contribution by the Ambient light color in the shader, and always perform the indirect lighting code (even without light probe).
As in the second pass ambient light is forced to 0, the indirect lighting contribution would be nullified. However we'd have to force ambient light to 0 if there are no light probe.
This would also have the nice side effect of having a way to dim or boost indirect lighting with the ambient light color.
same JVM. a) this makes a good example of self-hosted style
LAN multiplayer games, and b) it causes the serialization bug
to show up so I can fix it. (Already fixed it and that commit
will be next... it's almost like TDD.)
to make a more complete example. It should now be relatively
well behaved through all normal shutdown paths.
Modified the server to gracefully close the client connections
when shutting down rather than just letting the sockets die.
- Introduced a new Light type : LightProbes that are lights holding Image based Lighting information that are sent to the shader. For now, only the closest LightProbe from a geometry is sent to the shader. This will be enhanced later as it's obviously not the best way to handle this.
- Added a LightProbeFactory for easy creation and rendering of LightPorbes and associated maps. The maps generation process can also be monitored through a Listener class.
- Added various utility classses for debuging purpose.
- Added a new test case for environment with multiple LightProbes.
- Adapted the previous test case to the new system.
Added a stress test for unshadedNodes.
Changed the name of the texture parameter to textureMap in TextureFetch shaderNode as it was conflicting with the texture function used to fetch a texel from a a texture in glsl 1.5
Added a stress test for unshadedNodes.
Changed the name of the texture parameter to textureMap in TextureFetch shaderNode as it was conflicting with the texture function used to fetch a texel from a a texture in glsl 1.5
This commit updates Nifty to version 1.4.1 and makes all
the necessary changes to the JME-Nifty integration to be
compatible with this version of Nifty (manily support of multiple
texture atlases in the batch renderer and some minor changes
like the removal of some *Null classes).
Most User code should still be able to compile with this change.
However, the NiftyJmeDisplay constructor that requires the
width and height of the texture atlas has been deprecated in
favour of the newly added static factory methods:
NiftyJmeDisplay.newNiftyJmeDisplay(). The new methods
add support for the Nifty BatchRenderConfiguration class that
allow further configuration of some rendering details.
The testcase jme3test.niftygui.TestNiftyGui has been modified
to use the new methods and seems to render fine for me.
Most of Nifty 1.4.1 should be compatible with old versions of
Nifty. However some compile-time incompatibilities might
exists to old 1.3.x code. Additionally some internal mechanism
have been modified with 1.4 so there might be additional runtime
incompatibilities as well.
Nehon
Dokthar
Paul Speed
john01dav
Daniel Johansson
Kirill Vainer
iwgeric
Alrik
michael
void