I am on Linux.
Might be a related issue
New addon is under heavy development and there are some serious bugs reported. Check below
I think it’s better to stick with the old exporter for the moment.
I am on Linux.
Might be a related issue
New addon is under heavy development and there are some serious bugs reported. Check below
I think it’s better to stick with the old exporter for the moment.
I’m on Linux: Ubuntu 18.10
Good catch, I was reporting my situation on a totally different but related report.
I setup blender to split out the RG on the composite roughness image and it actually exports now.
It renames the image though.
original name: rgb-compose.png
renamed: rgb-composerrgb-compose.png
Edit: The recomposed image is empty, that’s the problem.
However, jme now throws an exception,
An Exception has occured when trying to load asset pbrtest-io
com.jme3.asset.AssetLoadException: An error occurred loading Textures/PBR/Box/pbrtest-io.gltf
at com.jme3.scene.plugins.gltf.GltfLoader.loadFromStream(GltfLoader.java:150)
at com.jme3.scene.plugins.gltf.GltfLoader.load(GltfLoader.java:78)
at com.jme3.asset.DesktopAssetManager.loadLocatedAsset(DesktopAssetManager.java:259)
at com.jme3.asset.DesktopAssetManager.loadAsset(DesktopAssetManager.java:373)
at com.jme3.asset.DesktopAssetManager.loadModel(DesktopAssetManager.java:416)
at com.jme3.gde.core.assets.SpatialAssetDataObject.loadAsset(SpatialAssetDataObject.java:94)
at com.jme3.gde.core.assets.actions.ConvertModel$1.run(ConvertModel.java:65)
at java.lang.Thread.run(Thread.java:748)
Caused by: com.jme3.asset.AssetLoadException: An exception has occured while loading asset: Textures/PBR/Box/rgb-composergb-compose.png
at com.jme3.asset.DesktopAssetManager.loadLocatedAsset(DesktopAssetManager.java:261)
at com.jme3.asset.DesktopAssetManager.loadAsset(DesktopAssetManager.java:373)
at com.jme3.asset.DesktopAssetManager.loadTexture(DesktopAssetManager.java:390)
at com.jme3.scene.plugins.gltf.GltfLoader.readImage(GltfLoader.java:706)
at com.jme3.scene.plugins.gltf.GltfLoader.readTexture(GltfLoader.java:664)
at com.jme3.scene.plugins.gltf.GltfLoader.readTexture(GltfLoader.java:648)
at com.jme3.scene.plugins.gltf.GltfLoader.readMaterial(GltfLoader.java:579)
at com.jme3.scene.plugins.gltf.GltfLoader.readMeshPrimitives(GltfLoader.java:407)
at com.jme3.scene.plugins.gltf.GltfLoader.readNode(GltfLoader.java:217)
at com.jme3.scene.plugins.gltf.GltfLoader.readChild(GltfLoader.java:266)
at com.jme3.scene.plugins.gltf.GltfLoader.readScenes(GltfLoader.java:183)
at com.jme3.scene.plugins.gltf.GltfLoader.loadFromStream(GltfLoader.java:127)
... 7 more
Caused by: javax.imageio.IIOException: Error reading PNG image data
at com.sun.imageio.plugins.png.PNGImageReader.readImage(PNGImageReader.java:1345)
at com.sun.imageio.plugins.png.PNGImageReader.read(PNGImageReader.java:1614)
at javax.imageio.ImageIO.read(ImageIO.java:1448)
at javax.imageio.ImageIO.read(ImageIO.java:1352)
at com.jme3.texture.plugins.AWTLoader.load(AWTLoader.java:179)
at com.jme3.texture.plugins.AWTLoader.load(AWTLoader.java:192)
at com.jme3.asset.DesktopAssetManager.loadLocatedAsset(DesktopAssetManager.java:259)
... 18 more
Caused by: java.io.EOFException
at java.io.DataInputStream.readFully(DataInputStream.java:197)
at com.sun.imageio.plugins.png.PNGImageReader.decodePass(PNGImageReader.java:1119)
at com.sun.imageio.plugins.png.PNGImageReader.decodeImage(PNGImageReader.java:1223)
at com.sun.imageio.plugins.png.PNGImageReader.readImage(PNGImageReader.java:1338)
... 24 more
I take it jme doesn’t account for composed PNG images?
Ok, so this script wont work, same things as reported on github happens so its back to the old scripts.
I still have some observations and more questions about shadows.
I can’t seem to get the shadows to lighten up on the model. Settings for shadows in the materials doesn’t seem to affect anything.
Also, I notice that if a face is only partially hit by light, the entire face seems to be placed in shadows, is that normal?
I am using an extreme bump map for this testing and I also notice that if the light does not come from directly overhead, then the bump maps do not really work. This places all sides of the box in shadow whereas the top is only lit. The normals do pop though.
Manually pasting the image into the asset folder does work…
For some reasons the Mapping Node is exported but all the values are rested.
that result the texture scaling and rotation to be rested, a way to get around that is to scale/rotate the UV Map
Adding an environment cam and probe to the scene rather than just attaching a light probe and or light to the spatial node in the SDK fixed the shadows darkness problem.
I must be missing a step when using the probes and SDK. The shadows are about 3x darker when going the SDK route.
It is really cool seeing the reflection of things on surfaces. Amazingly Wicked.
In this image,
you can see where the grout lines on the unlit side of the column are shadows.
What is the recommended way to even out the lighting and shadows?
Use triangulated directional lighting? or just let it be?
There is no parameter for adjustment in the material definition for AO. For that mater there’s no map slot for the AO map itself. It uses the LightMap slot. So even though you adjust it on the shader in blender, it does not get applied to the shader in jme. Its an all or nothing situation from the map itself. This makes the workflow for adjusting the shadow details a pain in the ass really.
I don’t know shaders enough to add the parameter and map slot or even why its not there in the first place.
On a side note, I also discovered that you have to redo the socket link in Blender if you change anything on the maps that are linked. Reloading the maps has no affect.
Edit: You can scroll in and out after reloading the maps to get the shader to reset. Looks like that’s a Blender bug.
Hello,
is there some way you preview gltf(or glb) format in JME? is this possible in IDE?
also in blender i get odd shadowing when linking normalMap like @oualid screenshot.
i wanted to check PBR in action, but not sure why i cant even see good effect in blender. Linking normalMap like in node screenshot i get dark shading(not telling that i see seams on textures if using principled BSDF). Please note my UV based texture have 10 pixels margin.
looks like normalMap is breaking everything mostly anyway
overall i dont see any super effect. please help me get it look nice
btw. if someone would have error like in screenshot, then make sure all “image texture” nodes have image assigned.
i think i fixed some of it.
i had color based texture, needed to change to non-color as i understand. btw. i dont want do metallic character but wanted to see how it will work. for character i belive i will just need setup very low metallic param, thats all.
looks better, but anyway i get sometimes little off shading.
also see on screenshots, the seams are much more visible. Any solution for this?
I don’t do it like that .
ow you are missing to chose the uv map in Normal Map node
blender is smart, when i dont select UVMap then it take one from current model. i tried select now to be sure and no effect.
edit:
i filled all skin with similar color then generated normal map, seems partially remove problem. but i still dont know how to get rid of seams, see the one near neck.
i understand that this is different texture location, but is there some clever way of get rid of seams even after filling texture between UV with some average color.
also idk why there are other non UV related seams visibled SO MUCH(faces are set as smooth, i see its about tris, but why so much). see screenshot.
i would like not to add more faces to fix it, so if there is some solution, would be nice. I also tried rotating inner quad edge, but if i merge into face again, blender recalculate rotation again to this one.
In your earlier image of the normal map, we could clearly see borders all around the skin… so of course you will see seams because those borders are inside the visible surface.
We can’t see your later one but I suspect you could still see borders in your normal map if you posted it… they just maybe aren’t as prominent.
Hand painting normal maps in this way is probably the hardest way… but to do it right you need to paint borders that are smooth with the rest.
thanks, or maybe i will try bake normalmap via blender, but again it will create borders, but i think there might be possibility blender to create margin fo this too.
it was odd for me because i generated maps from albedo with 10 pixels margin, thats much, still seams are visible even with 10 pixels margin. i will investigate further what is the best way.
i think just blender have some issue, but will need verify it. Screenshots show that material preview and cycle render are much different in some area. In preview there is black area, when in cycle render there is not(or at least dont look like there would be).
Note: there is a difference between a “border” meaning where one color is next to another color and a “border” where the normal map has a big giant bump in it.
Your normal map had a big giant bump border. Your new one has a smaller bump border.
very strange.
you could try converting quads to tris, although the model is quads (from what I can see) some are not flat, not sure how blender deals with that, but it may be doing some magic.
how is your scene lit?
check off the basic stuff, all the normals are correct, no faces accidentally inverted?
“some average color” should be 0.5 0.5 1.0.
Something I have noticed, but can’t really pin down, tangents and binormals are generated based off the direction a UV island is pointing. So in your UV layout, the arms are sideways, if you were to rotate them 90° in the UV layout, I believe different tans and bis will be generated. So you could try rotating your islands, probably won’t do anything, but worth a shot.
the last screenshot with marked dark place is just texture, no normal maps or other.
thats why i said it looks like it might be only in blender.
btw. i understand what pspeed said and its correct, i already fixed it by filling gaps and lowering normalmap contrast. about texture seams, normally there are no seams if only texture, but generated normals / metalness will always generate some “difference” in texture so its not same for “seam border” for both separate UV coords.
anyway the screenshot issue i think is only blender, not shader based, so will erify later
^^ very important takeaway.