(June 2019) Monthly WIP & Screenshot Thread

What about new month WIP? :slight_smile:

here some lipsync upgrade + character upgrade since last time :slight_smile:

still much to do:

  • more customization elements (invisible here anyway, but eye color/iris / hair / eyebrow / etc are customizable)
  • eye follow/move (i had errors when eyes had own proper origins so need use bones i think)
  • eyebrow moving.
  • better hair shader
  • better clothes and more of them
  • male version
  • maybe something more
    will skip some work for later anyway.

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 {

        Defines {

            // 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;
    varying vec2 texCoord;

  uniform sampler2D m_EmissiveMap;

  uniform vec4 m_Emissive;

void main()
        #if defined(NEED_TEXCOORD1) 
           gl_FragColor = texture2D(m_EmissiveMap, texCoord1);
           gl_FragColor = texture2D(m_EmissiveMap, texCoord);
        #ifdef HAS_EMISSIVE
            gl_FragColor =  m_Emissive;
            gl_FragColor = vec4(0.0);

And this is the result :


I think it is much better now! :smiley:

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 :slightly_smiling_face:

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. :slightly_smiling_face:


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 :grinning:

1 Like

indeed, looks great :slight_smile:

btw. hope this much fps drops are from other factors.

1 Like

Looks great :slight_smile:


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.

1 Like

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.

1 Like

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.

1 Like

@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.

1 Like

It’s is using morph animation. It can be done by baking a softbody simulation in blender.

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.

1 Like