Yes… but it must update the scene graph objects by looking at the physics objects. In a fully decoupled environment this is not thread safe.
Parallel mode gets around this by keeping everything in lockstep so you know there is a memory barrier before accessing the physics objects position.
You can actually add rigidbodies from outside the physics loop, but the threads will synchronize for a moment and it might cause your game to stutter, i had to do it since some jme code relies on the assumption that you can do it, but for greather performances you should call it from either collision prePhysicsTick or physicsTick. Every other set method related to physics should be called only from the physics loop. PR #868 fixes the already existing enqueue method for the physics space.
You may be right, i think there is some parallelism involved already, since not all rigidbodies touch each other, but the only documentation i’ve found is a post on bullet forum, so i might try this aswell.
Reading motion states doesn’t seem to be an issue, It shouldn’t be hard to make this fully thread safe by changing the RigidBodyMotionState to read the transforms from the physics thread and apply them lated in the update loop, i might do this at some point, but i’ve been using this code for months and never had any issue in this regard.
Threads, especially on multicore systems, can have their own copy of memory state. Without a specific memory barrier, one thread may see stale data while another thread happily changes those values. This is why it’s not safe to even read unprotected values if you expect timely updates (timely as in not randomly 1-2 seconds in the future, for example).
This was why double-checked locking was such an issue. Operations can be reordered and the ‘synchronize’ keyword only creates a memory barrier at the start and not the end.
It is likely that memory barriers may happen anyway but it’s best not to rely on it if you care that your view of your scene reflects the state of the physics objects with any accuracy.
(Edit: it’s also unnecessary but to fully decouple the physics would require a change in architecture over the simple synched naive approach that exists in JME.)
Giving the terrain some PBR treatment. Still needs tri planar mapping and some fixes, but mostly works so far. I know there are some terrain PBR shaders laying around here on the hub, but none of them work out of the box for 3.2.1 (as mine doesn’t for current master), so I gave up and made my own. Setting the material parameter names to the same names the stock terrain material uses also gives me compatibility with sdk’s terrain editor 
I’ve been working on a new (and hopefully final) draft for the primary enemy in my game currently, the ‘Plagued Monkey’. I have also been working to create a skeletal version of each creature in my game .
I’m nearly done with the monkey skeleton, and I managed to put all of the bones into a texture atlas, so hopefully it should be easier to assemble the next creature’s skeleton with the bones I’ve already made. He still need a pelvis, hands and shoulders, but I got bored and wore myself out sculpting, copying, and pasting bones in blender for so long and need to take a break from blender for a while…
.
When an ‘afflicted’ enemy or creature dies, it will dissolve into purple “Arcane Energy” (this rewards the player with a currency), and leave behind its corpse which can be resurrected by enemy necromancers (if the skeleton is fully intact still) - or the player can collect the bones and take them to an altar, where they can summon a boss version of the skeletal monkey / creature. Leaving the corpse lay too long without destroying or collecting it will also cause the ground underneath to become dead and plagued over time.
Cool, though I’m still super irked by your odd animations and lack of shadows (not even drop shadows?). It seems to me that your characters only do animations when input is made, even if they’re pushed in a direction. Wouldn’t it make more sense to bind movement animations to actual physical movement? If you’re pushed back you generally do a short backpedal in the real world, and not just float backwards like a statue.
I appreciate the input - the animations definitely need some work. I’ve kind of been procrastinating and neglecting my animation practice more than i should, some animations are altogether not there and some just look funky, so I guess I’m starting to get use to how un-natural the animations look. But it sounds like that may be a good task to work on next.
I must not have noticed I had shadows off before taking the video, I had found an error that sometimes occurs when shadows are on and the scene loads that I’m still investigating, so I usually have shadows off until i take videos, but this time I forgot to turn them back on.
I like the loch ness monseter looking thing swimming by in the background.
Regarding shadows… is it real JME shadows that give you trouble sometimes? Maybe my drop shadows would be a decent fallback when those shadows are disabled? (Or if it’s a problem with the drop shadows them I’m curious to know the issue, too.)
Thanks! 
And yes it is the DirectionalLightShadowFilter, I think I will post my error in a new thread shortly since it seems to actually happen when the Light Probe is done rendering.
I have not used the drop shadows yet other than a few times with your trees, and I didn’t have any issues then. But I’ve been thinking I should add them as an alternate shadow option in the settings, since the JME shadows seems to lower the FPS a lot more
Wait you actually managed to get that thing to work on occasion? What about the DirectionalLightShadowRenderer?
Whaaaaaaaaaat. This is PBR? Really? How? Sounds to me like you’re throwing away lots of performance since it looks a lot like unshaded materials in that gif anyway.
Also don’t ever render a light probe at runtime, that’s just bad practice and will get you lots of problems, from graphical glitches to never-terminating threads if the game crashes during the generation period. Load up, generate, export to j3md, use that. Easier to do with the SDK I’m told, but there’s a code-only way as well, described by nehon somewhere on the forum.
I think I actually ran into problems with the Renderer in the past, and switched to the filter, but I can’t remember exactly.
I agree it definitely could look better for PBR. I’m still working on getting the PBR terrain working with normal maps and tri-planar, so I hope I can get that to look a little better eventually. I also find that it’s harder to make the PBR effects as noticeable with items that aren’t as shiney. And I’ve especially noticed that It can be difficult to make the PBR effects stand out when its night or a dark scene (a dark sky and dark Directional light in my case). But I plan to play around some more with the lighting so the the generated environment map isn’t as dark at when the sky and light is darker. If I use a bright sky box as opposed to Sky Control at dusk (which is the case in my scene) then it seems as though the lighting from the Probe reflects much more noticibly, but then it also doesn’t look like night anymore
This sounds like a good idea, I forgot that I’ve been doing it the bad way. I’ve just been sticking to one probe per scene until I go further with the level design, but eventually I should definitely pre-generate an accurate probe for each finished area
What version of the engine are you using? I intend to release the terrain material from a couple posts up once it’s done, but it only works in 3.2.1-stable from the versions I tested.
I’m also using 3.2.1 stable, I haven’t had a chance to test it on any master branches yet.
I’m specifically having trouble getting the normal mapping to work without losing the lighting / dimming from the original normal buffer, but I can get it to at least look alright when I use only normal maps with the pre-grenerated test light probe (as opposed to my dim and barely noticeable lightprobe in my gif from above). But it still looks odd that triangles facing away from the directional light are lit the same as triangles facing the same light, so I definitely need to fix that somehow.
Have you generated tangents and binomials ?
I tried to generate the tangents for my terrains in the SDK, but iI think that the results appeared to be the same on a TerrainPatch with generated tangents vs a patch that doesn’t have them generated. Although there is a chance I had something else messed up in my terrain shader the last time I tested generating the tangents, so maybe I should try again…
The issue does seem to stand out when I try to use the ‘tbnMat’ value the same way that it is used in the PBRLighting.frag shader- if I use the same exact code, it seems to get rid of the normal maps, so maybe I should play around with generating the tangents some more since it sounds like that may be where I went wrong - thanks.
I guess the terrain materials may generate the tangents and binormals on the fly? It’s certainly wasteful to keep them in the mesh because for height map terrain they are trivial to calculate.
I’ve been speculating this but wasn’t sure, since generating tangents on a terrain patch never seems to have the same effect as it does on a typical model. Generating the tangents usually makes a drastic difference on my standard models with normal maps, but I never noticed much change with the terrain - even when I was using the standard lighting as opposed to PBR
this is EPIC
font size = 1 
BTW who made it
I’m not sure… it wasn’t me. Though somewhere around here I have the ASCII art version of Xzibit with his “Yo Dawg” face that I wanted to build into some kind of error that was logged when you try to instantiate more than one Application in your application.