SimpleLight : issue with normal/specular textures

About Monkey 2 › Forums › Monkey 2 Development › SimpleLight : issue with normal/specular textures

Tagged: , , , ,

This topic contains 9 replies, has 4 voices, and was last updated by  chaduke 2 years, 1 month ago.

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • December 22, 2016 at 12:48 pm #5983

    Pepa
    Participant

    This is my first post here. Ex-user of Blitz3d, Blitzmax, Monkey, 3d modeler by the way. Casual programmer, of course.

    I think I have find a issue in the banana SimpleLight. I have compiled for desktop, I can’t try to emscripten for now.

    Normal map don’t work, it seems “to float”, not scaled, not matched with the diffuse texture’s scale transformations (rotation works fine). Please see the pictures.

    There are some artefacts too but it’s not the big problem for me, i don’t want to use shadow casters, but it’s a problem too.

    On my tests, I have an issue with a render to texture. In an Image canvas, i have drawed some images with a single light, when i attempt to draw my image canvas into a image who’s finally drawed in the backbuffer, the normal/specular don’t match with the transformations of the images rendered into the icanvas, exactly like the SimpleLight banana. I have finded this issue when I have wanted to test the lights.

    In the demo, the matrix transformation of scales and positions seems to be at the problem’s origin. The texture specular and normal seems to be at top of all (even the diffuse texture who’s appear in black like a bitmask), just near of the viewport’s plan, like a ghost layer (i won’t say “sprite”… ). I did some tests, I swear this is true. It’s just the scale and the world coords who’s multiplied with something somewhere. I have take a look already, but Mojo and the bump shader are like correct.

    However, this feature look very impressive. I hope I will can use this soon to continue all of my tests. I *ook* a XFX Geforce 9600GT by the way (yes I know… ). But it work very well, I think… Anyway, I believe I’m the only bro who’s have this problem. That’s shame of me, but I’m very confident in Mark. This is a fantastic langage, near of maxscript sometimes. I want to play with it, but I begins to test very rudimentaries features before to do more.

    Attachments:

    1. Problem-SimpleLight-banana-01.jpg

    2. Problem-SimpleLight-banana-02.jpg

    December 22, 2016 at 6:16 pm #5989

    Pepa
    Participant

    I have finded something interesting. When the window is resized, the buffer of diffuse+lightmap is resized. In my exemple, if I maximize the window, then the buffer is close to match, but not, because the top of the window. I use Windows7 with classic mode, but I don’t think this problem is of this fact.

    This is a *simple* light version of my code, and for me, this works but not. When I draw directly or not in the canvas.

    You must knows that the banana SimpleLight works but not too.

    December 22, 2016 at 7:57 pm #5990

    Mark Sibly
    Keymaster

    Regarding the first post above: Are the images from the ‘simplelight’ banana output? have you made any changes to the source code?

    Have you updated video drivers recently? If not, can you try that?

    December 23, 2016 at 6:09 am #5997

    Pepa
    Participant

    Thank you for your interest in regards to my strange problem…

    None of the code/gfx is modified in SimpleLight banana. I prefere works on my exemple now, more elemental, without canvas transformations. See my code. It’s a large problem. Shadow caster tested on the the tile4, it works, no issue. I can continue to verify your code but without you, it can take very long time.

    My driver is updated, I’m on 342.01. But maybe the problem concern DirectX11. According the release notes of 342.xx,

    driver version 197.45 and Windows Vista (with available patch) support DirectX 11. But only NVIDIA graphics cards based on the Fermi architecture released in 2010 support DirectX 11. So your system must have one of these cards installed in order to take advantage of DirectX 11 performance.

    So, I will continues some verifications.

    I have done screenshoots of this problem. It’s a very big jpg, sorry, but you can see better. I give you my gfx too, Tile1/Tile2/Tile3 are other 64×64 png like Tile4.png, but they’re correct because : #1 I have a pro formation so I can match with the production imperatives #2 My issue concern all tests, all bananas who’s uses light functionnality, like Simplelight.

    I’m SURE that the matrix of the light buffer is wrong regarding the canvas, by and large for my hardware. But the render operations works well. The buffers are just not overlapped. This seems to be the same problem I encountered on one of my works a long time ago. The vertex buffer is not adjusted with the canvas. This fact involve malfunctions with the window scale, no matter that the app is fullscreen or in the window mode.

    For the next step, I will install the android’s sdk. Since I’m the only one who’s have this problem, I must continues the tests on the other targets.

    I lurks the community from many years but I know nobodies. I still can not speak better in English since this days. Merry thingmas to all.

    Attachments:

    1. Tile4.png

    2. Tile4_NORMALS.png

    3. Tile4_SPECULAR.png

    1. Lighting-Issue-B.7z
    January 31, 2017 at 5:52 pm #6897

    Pepa
    Participant

    Finded.

    In Mojo.Canvas :

    Method BeginLighting()
    DebugAssert( Not _lighting,”Already lighting” )
    If _lighting Return

    _lighting=True

    If Not _gbuffers[0]

    Local gbufferSize:=New Vec2i( 1920,1080 )
    Local gbufferScale:=New Vec2f( 1 )/Cast<Vec2f>( gbufferSize )

    _gbuffers[0]=New Texture( gbufferSize.x,gbufferSize.y,PixelFormat.RGBA32,TextureFlags.Dynamic )
    _gbuffers[1]=New Texture( gbufferSize.x,gbufferSize.y,PixelFormat.RGBA32,TextureFlags.Dynamic )

    _uniforms.SetVector( “mx2_GBufferScale”,gbufferScale )
    _uniforms.SetTexture( “mx2_GBuffer0”,_gbuffers[0] )
    _uniforms.SetTexture( “mx2_GBuffer1”,_gbuffers[1] )

    Endif

     

     

    The problem is “Local gbufferSize:=New Vec2i( 1920,1080 )”

     

    If I use 1920×1080 full screen, normal lighting is correctly rendered.

    So, this thing need a hack.

     

    Low resolution such 480×270 is really important to me. But I don’t understand why nobody haven’t reported this issue. Bizarre.

    Mark should take a look at that.

    January 31, 2017 at 9:55 pm #6899

    Mark Sibly
    Keymaster

    1920,1080 is supposed to be ‘worse’ case buffer size – not as elegant as it could be but it should still work. The idea here is that I want to share a single offscreen ‘gbuffer’ texture between potentially many canvases. This should probably default to device size and have a user modifiable ‘max’ size (and there are probably better was to try and computer it automagically).

    But it does work here with simplelight etc. which use 640,480 windows and can be resizable (here anyway).

    Can you email me a zip of your example project (blitzmunter at gmail dot com)? I can’t see any source code here…

    February 1, 2017 at 8:50 am #6904

    Pepa
    Participant

    It’s the same code that I posted as #5989

     

    Namespace myapp
    #Import “<std>”
    #Import “<mojo>”
    #Import “assets/Tile1.png”
    #Import “assets/Tile2.png”
    #Import “assets/Tile3.png”
    #Import “assets/Tile4.png”
    #Import “assets/Tile4_NORMALS.png”
    #Import “assets/Tile4_SPECULAR.png”
    #Import “assets/pointlight_light.png”
    Using std..
    Using mojo..

    Global WSX:Int = 1280
    Global WSY:Int = 720

    Class MyWindow Extends Window
    Field Tile1:Image
    Field Tile2:Image
    Field Tile3:Image
    Field Tile4:Image
    Field light:Image
    Field pos:=New Vec2f

    Method New()
    Super.New(“Test”,WSX,WSY,WindowFlags.Resizable)
    Mouse.PointerVisible = False
    Style.BackgroundColor=Color.Black
    Tile1=Image.Load(“asset::Tile1.png”)
    Tile2=Image.Load(“asset::Tile2.png”)
    Tile3=Image.Load(“asset::Tile3.png”)
    Tile4=Image.LoadBump( “asset::Tile4.png”,”asset::Tile4_NORMALS.png”,”asset::Tile4_SPECULAR.png”,8.5,false )
    light=Image.LoadLight( “asset::pointlight_light.png” )
    light.Handle=New Vec2f( .5,.5 )
    light.Scale=New Vec2f( 5,5 )
    pos=New Vec2f(1,1)
    End

    Method OnUpdate()
    Local spd:int = 2
    If Keyboard.KeyDown( Key.Right )
    pos.x=(pos.x+spd)
    end
    If Keyboard.KeyDown( Key.Left )
    pos.x=(pos.x-spd)
    end
    If Keyboard.KeyDown( Key.Down )
    pos.y=(pos.y+spd)
    End
    If Keyboard.KeyDown( Key.Up )
    pos.y=(pos.y-spd)
    end
    End

    Method OnRender( canvas:Canvas ) Override
    App.RequestRender()
    OnUpdate()
    canvas.TextureFilteringEnabled = false
    For Local y:= 1 Until (480) Step 64
    For Local x:= 1 Until (640) Step 64
    canvas.DrawImage( Tile1,x-(pos.x*1.1),y-(pos.y*1.1))
    Next
    Next
    For Local y:= 1 Until (480) Step 64
    For Local x:= 1 Until (640) Step 64
    canvas.DrawImage( Tile2,x-pos.x*1.3,y-(pos.y*1.3))
    Next
    Next
    For Local y:= 1 Until (480) Step 64
    For Local x:= 1 Until (640) Step 64
    canvas.DrawImage( Tile3,x-pos.x*1.5,y-(pos.y*1.5))
    Next
    Next
    canvas.BeginLighting()
    For Local y:= 1 Until (480) Step 64
    For Local x:= 1 Until (512) Step 64
    canvas.DrawImage( Tile4,x-pos.x*1.7,y-(pos.y*1.7))’,pos.x/10,pos.y/10)
    Next
    Next
    canvas.AddLight(light,Mouse.X,Mouse.Y )
    canvas.EndLighting()
    canvas.Flush()
    End
    End

    Function Main()
    New AppInstance
    New MyWindow
    App.Run()
    End

     

    With :

    Global WSX:Int = 1920
    Global WSY:Int = 1080
    Super.New(“Test”,WSX,WSY,WindowFlags.Fullscreen)

    It’s works.

     

    If I change the buffer’s resolution in mojo and recompile all, that’s works but not.

    February 4, 2017 at 11:56 pm #6954

    arpie
    Participant

    @pepa, I can’t offer any advice about your lighting issue but am intrigued by your style of English.  I am British, living in France so can sympathise with anybody trying to write in a second language.  Do you mind me asking what is your native language?  I hasten to add that your English is excellent and I have understood everything you have written apart from one thing :

    The only thing I didn’t understand is what do you mean by ‘works but not’?  Do you mean it compiles and runs but the output isn’t what you intended?  Do you mean it mostly works but has a small glitch?  Do you simply mean it doesn’t work?

    Good luck finding the solution!

    February 6, 2017 at 5:00 am #6965

    Pepa
    Participant

    @arpie

    Thank you, is sometimes difficult, I have learned with coding, so I think I speech like a robot.

    “works but not” mean that the code is compiled but the result is not that it’s supposed to do. I say something like that in french (“ça marche mais pas”) but even in french, nobody understands me. In my mind, it’s like “x = not x”, but you shoudn’t take it formally. Except mistake I believe that it’s from Michael Abrash but I would not like credit him for a stupid thing. Otherwise, the french langage is too complicated, that rotting our head. The subjects and the adjectives is logic-inversed. But explain that to the french peoples…

    I think that the problem is relied to my hardware. But it’s updated, restarted, monkey2 reinstalled. Like Mark says himself, a size-fixed gbuffer is not elegant, plus I works to much on markovian processes for to investigate more forward and not smart enough to understand the mark’s code in every detail, since I don’t write for opengl, originally. However I believe I understand why Mark have coded in that way. From this problem I have listened a lot, that’s very good for me.

    February 23, 2017 at 4:49 pm #7265

    chaduke
    Participant

    I guessed French as soon as I read your post.  Both my parents speak French and although I’m not fluent I’ve spent lots of time translating French to English or the opposite, mostly with music lyrics (cajun music).

  • Author
    Posts
Viewing 10 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic.