The texture loads, and the material in the inspector is recognized as having this texture, but it just renders as black. What simple thing am I not doing?
Basically, you should also set metallic and roughness.
1 Like
That’s a bit of a shortcut you took there, didn’t you? 
@rascheln
It’s one way to do it but only one of’em (and it doesn’t really provide an answer towards how pbr works).
Among other options you can add an emissive texture and push the level of emissive, which will emit a texture and a color ‘against the light’ and ‘environment’. Using a black color emissive and no texture, will (obviously) not emit anything.
In essence, a pbr material works with an environment. It captures, reflects and refracts part of the environment according to its parameter (one of which is metallic/roughness). Then, lights only add to the environment (and light adds to light). No environment, no true pbr material. Like no money, no candy
When using pbr without emissive, the first thing you should have is ‘an environment’ (else there’s no use for pbr materials). Also note that by default, any material exported from blender is a pbr material. Where BJS also offers different classes of material which might be more suitable to a scene.
4 Likes
I believe an emissive texture would end up being physically inaccurate in a PBR workflow 
I also had an environment using an HDRCubeTexture in the scene where this wasn’t working. Additionally, I was using a BJS example scene which ALSO was populating an albedoTexture, which ALSO was not working: https://playground.babylonjs.com/#RY8LDL#32
Also, the default scene has a light on it. Would PBR not already be responding?
Thanks @tanpopo that makes sense! I do remember encountering a similar problem in Blender where materials would appear black if either metallicity or roughness wasn’t set right.
Indeed. Unless it has an emissive property (such as ‘uranium’). But on the other hand, a pbr material with no environment is by definition physically inaccurate (unless the environment is a ‘black hole’ ) …although this assumption cannot be verified as of just now 
Jokes apart, I was assuming from your initial post that you might not know about PBR. My apologies: Looks like this was incorrect. And then, yes, I assume that setting nothing in the metallic channel will likely result in a material being just plain black. So, probably @tanpopo 's answer wasn’t a shortcut, but rather straight to the point 
Looks like this PG is broken. There’s a missing link that brakes the render.
Yes, PBR will respond to light. As you can see in your PG, it already does. All I was saying is that with light only and no env, PBR is not of much interest (and will be inaccurate anyways).
1 Like
Yeah! That makes sense. Generally, the use of PBR materials is for when you can have HDRI based lighting. At least, that’s what I’ve been doing. Additionally, lots of client materials end up being PBR-based, so it tends to speed up the process. Luckily, for us, that part doesn’t eat into crucial frame time.
Have there been any performance tests to compare PBRMaterial and StandardMaterial? I’d be curious to give those a look.
Likely, but I’m not an expert. Though, I’d rather believe that the impact on performance would probably come from the env and the lights and probably not so much from the material itself.
For the expert and true answer cc @Evgeni_Popov or @RaananW . Meanwhile, have a great day 
PBR materials will be slower than standard materials because there are more calculations. I don’t think we have any numbers, however, you should test in your own case.
However, it is usually the javascript side that is the limiting factor in the web, so it may not be so much of an issue for the GPU side. The JS side of PBR materials will also be a bit slower than their standard counterpart due to the increased complexity of these materials, but if you are able to freeze the materials, both PBR and standard materials run at a comparable speed on the JS side.
1 Like