Is it possible to have an intermediate material definition?

I have three .j3m instances of Lighting.j3md which only differ in their DiffuseMap parameter. Having them instantiate an intermediate .j3md (which would in turn “extend” Lighting.j3md) would be super nice for setting common default values (editing just one file instead of three). I could just copy the content of Lighting.j3md in a new definition where I define those default values, but that’s not very elegant, is it?
So, is this possible somehow?

I have my own j3md file too. It extends the standard Lighting.j3md, so it is not a problem I think.

That’s great!
What syntax did you use to make it extend Lighting.j3md? Seems like MaterialDef name : path { } isn’t ok according to the excpetion it raises.

I don’t think he meant ‘extend’ in the literal sense. Most likely ‘forked and added to’ as you have done.

Exactly.

One idea I had was material interfaces. Those J3MI files would define parameters, but no techniques. Material definitions would then gain the capability to implement material interfaces, thus inheriting their parameters. You could create interfaces for various pieces of functionality, like base, lighting, fog, skinning, instancing, etc. Each interface defining some sort of material behavior but not implementing it. It is then up to the material definition to ensure those parameters do something.

Too much effort in my opinion. In my game (and it is for sure a complex one) I have one ‘extended’ Lighting material definition with all necessary techniques: for standard multipass rendering (for IDE purpose) and for my own pipeline. There are maybe two or three more definitions, including GUI, none of them needs to share any technique.

I had the same problem. I solved it by switching to 3.1 alpha and breaking everything down to reusable shader nodes.

2 Likes