Why an "Universal" Material/Scene system is still not mainstream?

(DDB) #1


after seing this video

im wondering why an universal between every 3d application material format is still not adopted in the industry ? why can’t we still not save a material from vray and import it to redshift or blender ? or can we already ?

im quite confuse about the whole import export process of 3d apps, im still using the olds regulars FBX or OBJ import and need to redo the whole materials every times from scratch, this seems so wrong. am i missing somthing ? or there’s nothing in the mainstream yet ?

(LordRaven) #2

Well the problem is that each renderer uses a different system to define materials. Just look at Blender Internal and Cylces. (Thank god EEVEE works with Cycles materials!)
Each renderer offers different options of what you can do. Even if both systems uses nodes they are often still incompatible. Base nodes like texture, diffuse, glossy and mix are available in all systems, but specific ones like procedural texture types, AO, hair (and especially their parameters) etc are usually tailored a specific renderer.
On top of that values might have different ranges, so 2.5 might mean 2,5% percent or 250%.
It would be great if such a system would exist, but I think it’s very problematic because each renderer has it’s specific stuff that is only available there. What would happen to those node types/values if you try to import into a system where those nodes/values don’t exist?

As a practical example: I made an Cycles to Unreal Engine material exporter. I got the basic stuff to work but for more complex materials I quickly ran into problems. (Different way of setting up normal maps, different node types)

(DDB) #3

everything could be bake into channels and every values could be converted from software to other, i think its no big deal, every shadings of 3d packages work the same nowadays.

(xrg) #4

I don’t know the technicalities of why there isn’t a standard there, but it reminds me of this XKCD comic.


(LordRaven) #5

If you bake everything into channels, then you loose all parameters.
And that would only work texture based materials that have been applied.
This would not work for procedural materials (which are the difficult ones).
So this approach is not useful at all.

(DDB) #6

if you are using procedural. not everyone use procedural material, its quite a specific niche

(sozap) #7

Working only with procedural material is quite extreme, but it’s common to use procedural textures here and there. You can use a cloud texture to mix two titleable images for instance.

There are other attempt to make an universal format for material : http://www.materialx.org/

I think it’s really a non-trivial tasks, but at some point it will append. For years exporting geometry from one software to another was really complicated ( for animated meshs) now it gets simpler and we have different format suited for different needs ( .mdd , .fbx , .abc) .

With PBR, render engines gets more standardized and you can get the same results using different software ( redshift , cycles , arnold ) . So it gets simpler to make a standard at least for basics materials.

There are a lot of render engine and applications , you don’t work the same way if you are into realtime , animation or VFX so maybe we’ll see different exange format like for exporting geometry.

All that said, as every software as his specifics there will never be an universal 1 to 1 export format.

(Romanji) #8

Disneys Principled shader is a good way to easily transport materials from render to render if you have it all (baked/painted) in the channels.
I have created assets with textures from Substance/Mari and used them with Cycles, Arnold, Renderman, Appleseed and Clarisse. They all look very, very similar. Like 98+ % similar.
Without looking at the named files i can’t differentiate between them.
Vray and Redshift have the Disney shader too so i assume they can be thrown in the group. Octane probably too.
The only hassle is to actually create the shaders and manually connect the textures. But with UDIM’s this is less annoying than it could be.

For the future i think USD exchange format can take care of shader creation in different programs when importing into another DCC. For Procedurals what about OSL? Can’t it be used to exchange procedural shaders inbetween DCC programs?