* Enable mipmaps for packed and generated textures
* Better handling of material flags for 2.58
* Allow loading of meshes with no vertices instead of crashing
git-svn-id: https://jmonkeyengine.googlecode.com/svn/trunk@8005 75d07b2b-3a1a-0410-a2c5-0572b91ccdca
- Added Volume texture 3D loading support to the DDSLoader
- Added a test case for texture 3D loading
- fixes a minor log issue in Material.java
git-svn-id: https://jmonkeyengine.googlecode.com/svn/trunk@8003 75d07b2b-3a1a-0410-a2c5-0572b91ccdca
Added a variant of createPhysicsTestWorld with more spheres.
Changed the size of golem in TestWalkingCharacter to fit step length.
git-svn-id: https://jmonkeyengine.googlecode.com/svn/trunk@7983 75d07b2b-3a1a-0410-a2c5-0572b91ccdca
- computed the spotDirection in view space on the java side in Material and pass it as a uniform -> vec4 spotVec disapear
- this implies to decode the cos values for falloff in the frag shader instead of the vert shader, but allows to reduce light vec from vec4 to vec3
All in all it shouldn't be that much of a performance hit, since the matrix multiplication of spotVec occur once per geometry instead of once per vertex, we could go further and compute it once per frame.
On the other hand decoding of the cos values happens once for each pixel instead of once for each vertex ( a floor a mult and a fract). I guess this should be balanced in a rich scene.
git-svn-id: https://jmonkeyengine.googlecode.com/svn/trunk@7978 75d07b2b-3a1a-0410-a2c5-0572b91ccdca
plain single thread. This gives more control over the queuing
behavior as with an ThreadPoolExecutor it is difficult to implement
blocking execute() behavior. Also, this avoids creating an
extra object per-message.
Anyway, this code now implements a blocking queue instead of
a boundless queue. It's set to 16,000 messages which should only
bottom out in the worst of cases. I was seeing it in the throughput
tests where the sockets were backing up and the queues were
consuming all of the heap until an out of memory error occurred.
Outbound messaging is only throttled this way on the client.
Servers typically wouldn't do this sort of spamming anyway.
git-svn-id: https://jmonkeyengine.googlecode.com/svn/trunk@7977 75d07b2b-3a1a-0410-a2c5-0572b91ccdca
protocol. In the wild, I've only seen this crop up in
really really odd circumstances. As it turns out, the
throughput tests eventually trigger this when testing
TCP. I've lost sleep over wondering when this was going
to bite for real so I'm glad to have what is essentially
the last known bug in message transfer fixed.
This change handles the case where so far only one
byte of the two byte message size has been read from
the network. Rare, but it can happen.
git-svn-id: https://jmonkeyengine.googlecode.com/svn/trunk@7976 75d07b2b-3a1a-0410-a2c5-0572b91ccdca
- bleder features separated between different packages
- refactoring of modifier system (each modifier now in a separate class)
- refactoring of constraints system (each constraint now in a separate class)
- no converter interface
- every helper supports versions 2.49 and 2.5+.
git-svn-id: https://jmonkeyengine.googlecode.com/svn/trunk@7953 75d07b2b-3a1a-0410-a2c5-0572b91ccdca
- Changed cloning method to clone(boolean cloneMaterial), and added a clone() method that calls clone(true). The missing clone(boolean) method was preventing the particle emitter to be correctly cloned when loading it from a j3o file yielding weird results.
git-svn-id: https://jmonkeyengine.googlecode.com/svn/trunk@7946 75d07b2b-3a1a-0410-a2c5-0572b91ccdca
- fixed setNumParticle method to correctly update the mesh buffers
- added a getMaxNumParticle that returns the max number of particles of the emitter
- changed testMovingParticles and testPointSprite to change the numParticle when hitting the space bar
git-svn-id: https://jmonkeyengine.googlecode.com/svn/trunk@7939 75d07b2b-3a1a-0410-a2c5-0572b91ccdca
* ZipLocator will now crash if the specified zip file does not exist
* Fixed crash when restarting context with pixel format changes
git-svn-id: https://jmonkeyengine.googlecode.com/svn/trunk@7914 75d07b2b-3a1a-0410-a2c5-0572b91ccdca
