Problem with materials loading

Hey everyone,

I made a Pull today and blender importer began to crash.

It trhows an exception while loading materials when I do this:
material.setBoolean(“Minnaert”, diffuseShader == DiffuseShader.MINNAERT);
material.setBoolean(“WardIso”, specularShader == SpecularShader.WARDISO);

It looks like some material parameters were altered.
Where can I find some info on what parameters are supported (besides reading the material definition file)?

And can someone point me how can I set these shaders now ? I will eventually find it but it will take some time …

Funny thing, I just wanted to post the exact same, just updated and traced the bug back to that as well.
-> In the MatDef loaded (the file) Minnaert is defined as boolean
-> In the loaded MaterialDefintion object its params hashmap , I don’t see it.

Mhh ok sorry, I’m the culprit
I removed these parameters.
We talked about it in the core team and agreed their use was marginal and it was generating too much clutter in the lighting shader.

Do you use them in your materials (i mean in a game) or is that for export correctness between blender and JME?

Parameters that have been removed are
Minnaert, Wardiso, LATC, HiQuality, LowQuality, HQ_Attenuation, Attenuation (as it’s always used)

Edit : Also Vtangent has been removed

They are used if blender has used them as far as i understood, but i guess they are not really necessary at all.

@Empire Phoenix said: They are used if blender has used them as far as i understood, but i guess they are not really necessary at all.

Exactly. Those two shaders can be selected in blender as the material’s shader model.
I can remove those for now if they are not widely used.
I think that loading shaders from blender will need some rethinking from my side.
I will need to read more deeply about shaders jme uses.

Just one question btw. If I created a material definition files and used them in blender importer, would the definition be stored in the jme model file or will the definition files be needed during loading ?

I think they will be needed, as else the defintions would be loaded multiple times.
Also same applies to shaders, so you need your whole material anyway.

I have commited a change so that the importer does not crash. But I will return to shaders issues as soon as possible.

@Empire Phoenix said: I think they will be needed, as else the defintions would be loaded multiple times. Also same applies to shaders, so you need your whole material anyway.

Thanks :slight_smile:

Thanks for the fast fix :slight_smile:
To be honest, I’m not to sure about having full import functionality for blender shaders.

What i would like way more, is to have a global? callback in the blender loader.
Eg whenever it tries to load a.tga I want to redirect it to a.dds. when it has a full mesh loaded to just give me hashmap of the material properties understood, and let me implement my own logic on how to map.

currently i kinda load with the blender loader, and after this i have extensive postprocessing, including a full replace of the loaded materials, to make them more compatible with the rendering. This step could be all done with that kind of callback.

The default blender material then could be emulated in a provided default callback, so it works out of the box for simple cases.

tl;dr please make a interface between your material generation and the material loading stuff.

Disclaimer : I didn’t take a look at the blender loader (only a quick try with Obj/Mtl Loader.

Empire Why not “extends” the BlenderLoader and override the code in charge of creating the material ? Else I agree with you about separation. Do you have any suggestion about the api of the interface for material generation ?

It’s a bit more complex due to the blend files complexity, basically whenever a material currently is loaded it’s assumed its a lighting.j3md or something similar.

Remove all assumptions about material, instead do a interface,
requestMaterial(Node name,URL basepath,Map<Parameters from blender shader);

eg it would be
loading asteroid1_13.blend
->
request “file://workspace/models/asteroid1_13_mesh1”: {diffusemap=./a.dds}
request asteroid1_13_mesh2: {specularmap="./b.dds"}

Then the default system would try to map to lightingMaterial as the current loader does.
But it would be replaceable with a custom logic.
Eg use MyModifiedLighting material with 1 more uniform it needs, without much work.

[java]
public interface IMaterialRequest {
public Material materialRequest(URL pathToModel,String meshname,Map<String,Object> materialKeys);
}
[/java]

@Kaelthas if you have any intrest in something like this, I would try to implement it and emulate the current logic as good as possible.

Wondering why this would be easier/better than just having a SceneGraphVisitor go over and fix the model post-load.

Well simple, in that hashmap, for example the read minaert value from blender could be in,
even if the default material does not have it anymore, a custom material could very well have it.
-> Basically ieverything readable from blender can be put there, and the materials can pick what they can use/need

@Kaelthas

What would be your opinion on how to approach this?