This topic contains 12 replies, has 3 voices, and was last updated by 
Ethernaut
1 year, 9 months ago.
-
Posts
-
Just started playing with Mojo3D. Very cool! Super easy to use so far. All examples run at 60fps in full screen on my laptop, with the exception of the pbr spheres example, which is much slower.
One little problem I noticed with the PBR material: I can’t get rid of the default reflection. I tried setting the metalness to 0, roughness to 1, the scene’s ambient light to black and no other light in the scene, but I still get a reflection, like this:
It’s an orange donut, but I expect it to be completely dark in those conditions. Am I forgetting something?
Cheers.
Possibly an ambient light?
EDIT: Looks like _scene.AmbientLight is what you’d need to zero-out.
Ambient light is zero. No other light sources.
This is due to the default SkyTexture, which effectively ’emits’ light (so SkyTexture is really kind of an ‘ambient specular’ map). The material’s specular reflection factor here is derived from its metalness, but this is never quite 0 because everything is shiny:
http://filmicworlds.com/blog/everything-is-shiny/
http://filmicworlds.com/blog/everything-has-fresnel/There are at least a couple of solutions here: you could use a ‘black’ SkyTexture which would totally eliminate any ‘ambient specular’ component (and totally eliminate any specular reflection effects – like in a completely dark room). I guess I could also add an ‘AmbientSpecular’ factor too that you could set to Black to do the same thing.
But I suspect what you really want is a custom type of non-pbr material that can be fudged however you want, without elimintaing specular reflections from the entire scene? I will probably be doing something like this myself soon as not everyone wants ‘realistic’ PBR style lighting – lots of people will no doubt just want matte/old school materials.
Also, I need a *better* default SkyTexture – the current one is too obviously a ‘sky/desert’ scene! If anyone has anything (in skybox format…) please let me know. I think a plain color gradient from sky to dirt might look best, but in skybox format.
Had a bit more of a play with this, and you can indeed disable the ambient specular lighting like this:
1234Local pixmap:=New Pixmap( 4,3 )pixmap.Clear( Color.Black )Scene.GetCurrent().EnvTexture=New Texture( pixmap,TextureFlags.Cubemap )This creates a 1×1 black cubemap and assigns it to the scene’s EnvTexture (not SkyTexture, my bad).
This will disable specular env reflections too though, pretty much as if you taped black paper over the windows (not recommended)!
Thanks Mark! That does the trick. It’s nice that I can set the environment for the whole scene, instead of per material.
I absolutely agree with the “everything is shiny” approach, but as someone with 20 years of CG experience, something seems a little off to me. Shouldn’t the roughness affect how “blurry” the environment seems?
But the main thing is how intense the reflection looks like, it’s almost as if the gamma is off somewhere, as you can see in the image I sent. Do the textures use the same gamma curve as the renderer? Can we control that somehow?
Anyway, I don’t mean to sound negative, I’m really enjoying Mojo3D so far!
Cheers.Shouldn’t the roughness affect how “blurry” the environment seems?
The ‘roughness’ controls which miplevel of the env cubemap is fetched when doing the reflection effect – higher roughness=blurrier mipmap used. But I agree your highlight looks wrong – there should probably be some filtering going on, it looks a bit too ‘binary’ to me.
There are other complications though. There’s no easy way to tell what miplevel the GPU would pick (which I need to know too) so that gets encoded in the cubemap alpha channel. But even then, GPU can apparently pick a mip level<0, but I have no way of knowing if it did as it gets clamped to 0. So there’s some dodgy add/sub hackery going on around that which affects output at the limits of ‘roughness’, some of which may just not be solvable in plain gles20 glsl.
Can you post the exact code you used to get your result?
Here’s a simplified code that does the same thing:
12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455#Import "<std>"#Import "<mojo>"#Import "<mojo3d>"Using std..Using mojo..Using mojo3d..Function Main()New AppInstanceNew GameApp.Run()EndClass Game Extends WindowField donut:ModelField mainCam:CameraField keyLight:LightField scene:SceneConst degToRad :Double = Pi / 180.0Method New()Super.New( "Test", 1066, 600 )'Scenescene = Scene.GetCurrent()scene.ClearColor = Color.Blackscene.AmbientLight = Color.Black'CameramainCam = New CameramainCam.Near = 0.1mainCam.Far = 100mainCam.Move( 0, 5, -5 )mainCam.Rotate( 45 * degToRad, 0, 0 )' 'Default Light' keyLight = New Light' keyLight.RotateX( 45 * degToRad )'Donutdonut = Model.CreateTorus( 2, .5, 48, 24, New PbrMaterial( Color.Black, 0.0, 1.0 ) )EndMethod OnRender( canvas:Canvas ) OverrideRequestRender()donut.Rotate( 0.03, 0.01, 0.01 )scene.Render( canvas, mainCam )canvas.DrawText( "Width="+Width+", Height="+Height+", FPS="+App.FPS,0,0 )EndEndThis time I tried using a material with the color set to Color.Black, and it looks surprisingly like light grey when the light is on, instead of the black matte look I was expecting, which is why I think something is wrong with the gamma. Same thing with the bg colors: setting the background to (0.2, 0.2, 0.2) looks like a medium grey, instead of dark grey.
This is what it looks like with clearcolor ( 0.2, 0.2, 0.2 ), a Color.Black material and no lights:
Since it’s all physically based and we’re using non-float, non-hdr textures, shouldn’t we do something with either the input or the output gamma? Like this: https://renderman.pixar.com/view/LinearWorkflow
With the light off it looks like the image I posted before.
Cheers!Texel colors are assumed to be ‘sRGB’, so they are raised to the power of 2.2 (ie: converted to linear RGB) immediately after being sampled from textures in shaders (see: material.glsl). Color constants (like ClearColor) however are assumed to already be linear RGB.
All shader/rendering math is performed in linear RGB, and converted back to sRGB by a final ‘copy’ blit (see: copy.glsl). In theory anyway, I could have very easily messed something up here!
ClearColor of 0.2 is actually the same as drawing a 2d rect in Pow( 0.2,1.0/2.2 ) as it gets converted from linear->sRGB by the final copy blit. Just tried this in mojo2d and it looks similar to what you’ve posted above, ie:
Local t:=Pow( 0.2,1.0/2.2 ) ‘about 0.48!
canvas.Color=New Color( t,t,t )
canvas.DrawRect( Rect )Linear color are much lighter than what we’re used to I think, so the ‘minimum specular factor’ of .04 is actually quite a bit lighter than we’d instinctively think, ie: everything is *very* shiny! I could be wrong (I only vaguely know what I’m doing here!) but I still think the problem is mainly to do with the env texture.
There’s this:
https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_seamless_cube_map.txt
This would I think affect cube map sampling at high roughness levels, as without it (ie: current situation) samples at the coarsest mip levels (ie: 1×1 cubemap faces) will not be filtered in anyway, you’ll just get a single color per cube face sample, ie: one of 6 colors giving a crappy ‘toon shading’ effect. This looks to me a bit like what might be going on, hard to tell though!
That looks like what I’m seeing, I don’t see the original environment image reflected in the donut, just a sharp, 1×1 version of it seemingly without filtering. But that paper seems to indicate it as resolved?
As for the gamma, I think what’s confusing me is not the fact that it’s linear (which is absolutely the way to go!), but the fact that I’m getting inconsistent results depending on where I use the values.
I made a texture in Photoshop with values from 0.1 to 0.5, brought it in as a sprite, and it looks in Mojo3d exactly like what it should! But drawing a rect in Mojo with Color(0.2, 0.2, 0.2) and using the same color as the scene.ClearColor gives me different results, which feels unintuitive. Here’s a screenshot:
Shouldn’t a gamma curve be applied to the Color class before rendering in Mojo3d (so it’s always assumed to be sRGB gamma), so it matches a texture with the same values?
Cheers!
This is actually looking more like a precision issue than anything to do with cubemap seams (ignoring ClearColor for now). As far as I can tell, angle lib always does seamless cubemaps if you use linear filtering on cubemaps. I may have to turn them on on apple/linux though, which explains a few other glitches.
Try changing this in deferredrenderer.monkey2…
Const MRT_COLOR_FORMAT:=PixelFormat.RGBA8
…to…
Const MRT_COLOR_FORMAT:=PixelFormat.RGBA32F
Here, this vastly improves the quality of the image, so the math must just be running out of bits somewhere. Will have a closer look at this later.
ClearColor being in ‘linear color space’ and stuff like canvas color etc being in ‘monitor color space’ is indeed an issue, but I’ll tackle this a bit later. For now, if you need to set any mojo3d color like ClearColor to an sRGB (ie: ‘photoshop’) color, you’ll need to convert it to a linear color first, eg:
1234Function ToLinearColor:Color( color:Color )Return New Color( Pow( color.r,2.2 ),Pow( color.g,2.2 ),Pow( color.b,2.2 ) )EndThanks Mark! Keep up the good work.
You must be logged in to reply to this topic.