* master: (94 commits)
First attempt to fix a bug reported by david_bernard_31, the size of the strings in the shader code was wrongly computed for the JOGL backend
Allows to choose between the forward compatible profile and the backward compatible profile in the JOGL backend
Displays the JOGL version instead of the NEWT version
Updates JOGL (2.3.2)
Bugfix: fix to importing blend files with linked content.
native loader: set lwjgl library path for lwjgl3
Updated lwjgl3 module to use LWJGL 3.0.0b #35 which is the current stable build.
Change duplicated docstring in FlyByCamera.unregisterInput
light : fixed pointLight v. bounding sphere unit test
light : replaced duplicated code by methods from Intersection
Removed native library jemalloc.dll for LWJGL3 as this will not be needed until 3.0.0b and after.
light : added unit tests for the new support of bounding spheres intersections (for lightFilter)
Fixed Issue #46 : The MaterialViewer will now simply ignore not available textures instead of crashing
Lights (see #362) : added light v. sphere intersection, and implementations of intersectsSphere(), second attempt
GImpactCollisionShape : fix for #188, added a call to updateBound() in native jni binding, just after creating the shape, (native createShape() method)
Bugfix: fixed a bug that caused importer to crash when the author of the blend file assigned non existing UV coordinates group name to a mesh.
Bugfix: fixed a bug that caused subdivision surface modifier to crash if at least one not connected vertex was in the mesh.
The LWJGL 3 renderer was missing a call to GLContext.createFromCurrent(), sorted now.
Changed the default app title in AppSettings to use the full name string from JmeVersion. This way no more manual changing of this will be needed for future versions. This also closes#320 which highlighted this issue. Thanks @8Keep.
Fixed#316 where some post processing effects were not working when using OPENGL_3 renderer due to an error in the fragment shader.
...
- 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
Also added a parameter to enable assertion as executable classes are only in this project anyway.
Removed the global assertion setting as it's only needed in jme-examples.
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.
