SDK Scene Editor display glitch

I just installed the most recent 3.3 version of the SDK, and I’m noticing that random models appear to have distorted texture coordinates when opened in the scene editor.

When I run my game though, they are thankfully rendered properly (phew :sweat_smile:) so it must be something specific to the scene editor. It’s only happening with 2 of my models that I’ve found so far.

Here’s a screenshot showing the same model in game at run time, compared to in the SDK, both running the same version of 3.3

The model uses a forked version of PBRLighting, but the issue peresists even when I switched it to use the stock PBR shader, so it doesn’t appear to be a shader bug.

I wasn’t sure if I should open an issue for this in the SDK github repo, but thought I’d at least make a post in case anyone else runs into the problem while upgrading and mistakenly think their models are corrupt.

Side note: I’m also really liking the new updates to the SDK, especially the buttons for applying the default light probe to the open scene in the scene editor and also making it the sky box :slightly_smiling_face:

1 Like

Try a custom light probe first.
The only thing that I could imagine is that like it’s some radius/positioning issue here affecting the lighting.
And since this wasn’t part of 3.2, it wasn’t bugged there basically.

1 Like

It still happens without a light probe. It is specifically the emissive map and metallicRoughnessMap that are appearing to render with distorted texture coordinates.

Its also not a fragment shader bug or a bug with the tex coord buffers, even though it would seem like that is the case, but I can rule that out since they aren’t distorted at run-time. I am entirely lost on what may be causing this in the scene editor but not when I run the app. But I thought I should make this post to document it nonetheless.

1 Like

Maybe the textures are flipped in the SDK?

1 Like

I think they are getting flipped, despite not being flagged so in the material file. But if I do flip/unflip it in the material file, it doesn’t correct itself. Additionally, opening the model or the material in the sdk gives this error that I must not have noticed before:

com.jme3.asset.AssetNotFoundException: odels/rockTower/towerBrick/ (Flipped)
    at com.jme3.asset.DesktopAssetManager.loadAsset(
    at com.jme3.asset.DesktopAssetManager.loadTexture(
    at com.jme3.gde.core.scene.SceneApplication.update(
    at com.jme3.system.lwjgl.LwjglAbstractDisplay.runLoop(
    at com.jme3.system.lwjgl.LwjglCanvas.runLoop(
at java.base/

The texture it’s looking for definitely exists, and this same material doesn’t throw this error when the model renders properly in game. I notice that it is cutting off the first and last letter of my asset path based on the error message ("odels/rockTower/towerBrick/"). I wonder if this is part of (or contributing to) the glitchy behavior in the scene editor?

Just to confirm that my material file has the proper spelling of the supposedly incorrect assetPath, here is the material file:

Material MyMaterial : MatDefs/shaders/rockTowerPBR.j3md {
    MaterialParameters {
        Glossiness : 1.0
        EmissivePower : 1.0
        BaseColor : 0.64000005 0.64000005 0.64000005 1.0
        ParallaxHeight : 0.05
        BackfaceShadows : false
        NormalType : -1.0
        Emissive : 0.4 0.0 0.6 1.0
        EmissiveIntensity : 2.3999999
        BaseColorMap : Models/rockTower/towerBrick/stoneAlbedo_.jpg
        SteepParallax : false
        PackedNormalParallax : false
        UseSpecGloss : false
        Specular : 1.0 1.0 1.0 1.0
        RoughnessMap : Models/rockTower/towerBrick/stoneRough.jpg
        NormalMap : Models/rockTower/towerBrick/stoneNRML.png
        MetallicMap : Models/rockTower/towerBrick/stoneMetallic.jpg
        Metallic : 0.95000005
        EmissiveMap : Models/rockTower/towerBrick/stoneEmissive.jpg
    AdditionalRenderState {
      PointSprite On
      FaceCull Back
      AlphaTestFalloff 0.0
      DepthWrite On
      ColorWrite On
      PolyOffset 0.0 0.0
      DepthTest On
      Blend Off
      Wireframe Off

Could be.

Whatever is causing the image to get flipped probably won’t be fixed by messing with materials because the material is just going to use the same buggy loader. In my imagination, it’s somehow ignoring the flip flag and loading it the default way… no matter what the material says. Your post only adds evidence to this wild guess.

Edit: note that the SDK does use its own asset manager implementation so it’s possible something wonky is going on in there.

1 Like

I have also noticed this exception. I found out, if you change

RoughnessMap : Models/rockTower/towerBrick/stoneRough.jpg


RoughnessMap : “Models/rockTower/towerBrick/stoneRough.jpg”

with quotation marks, it works fine. But don’t ask me what happens behind the scenes in the SDK. Maybe the SDK assumes the first and last letter to be quotation marks and cuts them by default.


Thanks, I added the quotes as you suggested and those exceptions no longer get thrown.

Unfortunately the distorted texture coordinates still persists. But at least it is only a visual bug that goes away at run-time, so it is not a dire problem.

Edit: Since fixing the asset paths with quoatations, the material preview window has now started to display the mini-texture icons properly, and I just noticed that my textures are appearing distorted in the texture browser window, so I think that further backs up Paul’s statement that it is something wrong with the SDK’s asset manager implementation, and is not exclusive to the scene editor as I initially thought in my OP.

The bottom image is how the texture really looks, but the SDK appears to be doing some type of diagonal flip in the texture preview window.

I remember some PR about the Parsing of Materials and changing some default values.
Since I can’t imagine the SDK doing anything special here, I’d think this might be a version mismatch of some sort.

Another thing to factor in is that the SDK uses the Material File Writer, that probably noone else uses.

1 Like