What about new month WIP? 
here some lipsync upgrade + character upgrade since last time
still much to do:
I noticed that BloomFilter has no effect on PBR materials, but I can’t say if that’s by design or what. This is what a bunch of cubes with emissive colors look like with PBRLighting:
Without some glow, it doesn’t look like what I would expect of an “emissive” object. Anyway, looking inside jME’s .j3md files I found that, unlike Lighting.j3md, the Glow technique on PBRLighting.j3md does not define HAS_GLOWMAP and HAS_GLOWCOLOR, so I decided to play with it.
Technique Glow {
VertexShader GLSL100 GLSL150: Common/MatDefs/Misc/Unshaded.vert
FragmentShader GLSL100 GLSL150: MatDefs/Emissive.frag
WorldParameters {
WorldViewProjectionMatrix
ViewProjectionMatrix
ViewMatrix
}
Defines {
NEED_TEXCOORD1
// I added the next 2 lines to my PBRLighting.j3md
HAS_EMISSIVEMAP : EmissiveMap
HAS_EMISSIVE : Emissive
NUM_BONES : NumberOfBones
INSTANCING : UseInstancing
NUM_MORPH_TARGETS: NumberOfMorphTargets
NUM_TARGETS_BUFFERS: NumberOfTargetsBuffers
}
}
Since PBRLighting.j3md has no GlowMap or GlowColor, I changed it to EmissiveMap and Emissive respectively. I also created an Emissive.frag file as follows (which is basically Glow.frag only replacing GLOW with EMISSIVE):
#import "Common/ShaderLib/GLSLCompat.glsllib"
#if defined(NEED_TEXCOORD1)
varying vec2 texCoord1;
#else
varying vec2 texCoord;
#endif
#ifdef HAS_EMISSIVEMAP
uniform sampler2D m_EmissiveMap;
#endif
#ifdef HAS_EMISSIVE
uniform vec4 m_Emissive;
#endif
void main()
{
#ifdef HAS_EMISSIVEMAP
#if defined(NEED_TEXCOORD1)
gl_FragColor = texture2D(m_EmissiveMap, texCoord1);
#else
gl_FragColor = texture2D(m_EmissiveMap, texCoord);
#endif
#else
#ifdef HAS_EMISSIVE
gl_FragColor = m_Emissive;
#else
gl_FragColor = vec4(0.0);
#endif
#endif
}
And this is the result :
I think it is much better now! 
By the way, I’m using here @Apollo’s MipmapBloomFilter, which I think looks better than the regular BloomFilter.
Old project, maybe I’ll do a rebuild with some smarter(?) design decisions. Converted to build w/Gradle, added JavaFX integration just to see if they’d work well (so far so good). And tweaked some parameters for no particular reason.
Hopefully this will embed properly…
Homegrown quadtree terrain with native Bullet physics. I do want to try JBullet to see how well that works. Maybe I can do a half-ass performance “benchmark”.
@fba nice job 
I think glow and emissive should mean the same thing.
Might be Nehon forget to adapt it for PBR otherwise I do not see a reason why BloomFilter should not be used in PBR?
@RiccardoBlb any thought?
Any chance for a PR?
@fba @Ali_RS i think that is by purpose, the glow technique is not really the best way to render glow since it needs to render the scene again with a different material. A better approach is to output to a floating point texture and then have a post processing pass that extracts colors above 1 (or any other value depending on the developer choice) and use the extracted colors for bloom.
This is the direction PBRLighting is going with the Emissive param, note: you need to use GlowMode.Scene in the BloomFilter.
Just tested BloomFilter with GlowMode.Scene and it worked. 
It works, but you can’t use glow maps though (or emissive maps).
Hmm, In my example I am already using an emissive map:
Some time ago I asked @nehon why the PBR material has no glow technique and he answered that we are supposed to use the GlowMode.scene mode of the BloomFIlter. Not sure why, maybe he can explain it if he sees that he’s been tagged. I always end up just forking the PBR shader and adding it back manually.
EDIT: PBR bloom not working · Issue #854 · jMonkeyEngine/jmonkeyengine · GitHub
On a semi related note, one of these days I should really get around to making the stock BloomFilter mipmapped.
Thanks, guys!
I’m going with GlowMode.Scene now!
More progress on soft-body physics. As promised, a skirt!
Just Awesome 
indeed, looks great 
btw. hope this much fps drops are from other factors.
Looks great
There’s room for further efficiency improvements, such as disabling shadows and assertions. However, I found clothing physics challenging to simulate: even small errors caused body parts to poke through in a distracting fashion. When walking in place, Puppet’s knees move about 1cm per frame, whereas real fabric is around 1 mm thick.
I disabled Vsync (for smoother kinematics) and increased the skirt’s collision margin to 10 cm. Even then, I never got Puppet’s “run” animation to work well with the skirt. One trick I didn’t try: making parts of the model invisible.
did you try look at Nehon work? (if he have somewhere sourcecode) i seen in Monkanim he had skirt simulation too. Maybe he had some different approach. I understand physics work in own thread right? so it cant be synchronized with animation directly? (i mean move physics before render but after movements)
making parts of the model invisible
sure it will work, even if i got almost perfect animation rig weights for cloth, sometimes were issues, when hidden via “discard texture” or “alpha map” whatever say, i created hidden areas to avoid it for 100%.
so there is always solution for it. no need worry much, i would worry about FPS more.
In the video, the skirt reacts to collision from character legs, it might be too much for a runtime simulation. Is there a way to disable it so it does not check collision with body parts, just reacting to anchor movements (which is moving by armature) and wind might be enough for a game I guess.
@oxplay2 this is a totally different problem, this is a simulated cloth. There is an actual physical simulation running for every vertex or group of vertices, you can’t have both extreme accuracy and high framerate. Sure if you could detach the physics thread from the update loop it would slow down only the physics and you would get a good framerate, but this comes with another set of issues.
It’s is using morph animation. It can be done by baking a softbody simulation in blender.
Edit:
Here is the how-to, it will work using gltf pipeline in JME
Edit 2:
The thing is doing this for each character and for each animation in Blender could be time-consuming unless you know Python API and write some script in Blender to do this automatically.
I guess having an option in Minie to bake the soft body to Morph track in JME will be nice.
Disabling collisions is easy. One solution would be to set the skirt’s kinetic hardness to 0:
skirtPsb.getSoftConfig().set(Sbcp.KineticHardness, 0f);
Anchoring the hem to Puppet’s knees is harder but doable.
I imagine making the result look good would be a lot of work.