Fragment shader fails with additional uniform

About Monkey 2 Forums Monkey 2 Programming Help Fragment shader fails with additional uniform

This topic contains 11 replies, has 3 voices, and was last updated by  DruggedBunny 2 months, 3 weeks ago.

Viewing 12 posts - 1 through 12 (of 12 total)
  • Author
    Posts
  • #14369

    DruggedBunny
    Participant

    I’m trying to produce a minimal sample for experimenting with fragment shaders, at the moment just darkening the existing pixels.

    I’ve stripped down BloomShader to the bare minimum and it works fine, but as soon as I add my own uniform, I end up with a white screen (grey with the 0.1 * rgb shader applied).

    What am I doing wrong here? Shader and code below, but runnable version attached…

    *** Note the two ENABLE_ME comments! This is when it fails… ****

    [/crayon] [/crayon]
    Attachments:
    1. glsl.zip
    #14372

    Mark Sibly
    Keymaster

    Hi,

    You should leave the ctor arg to new UniformBlock as 3. Why did you change this to 4? With it set to 4 I get a runtime error trying to bind SourceTexture.

    This arg refers to the ‘type’ of uniform block being created, where ‘3’ means ‘material’ uniforms, so they get a ‘m_’ prefix. Other uniform types include ‘render’ which have an ‘r_’ prefix and instance which has an ‘i_’ prefix etc. There is no real logic to these I’m just making them up as I go. It’s highly likely there will end up being lighting and scene uniform block types too with “l_” and “s_” prefixes (maybe) and all these uniform block types will eventually get enumed preventing lots of confusion here. The base class of PostEffect should probably be the one creating the uniform block anyway, but the PostEffect system is way underdeveoped and I’m really just experimenting with the shaders right now so it’s likely to stay this way for a while.

    Anyway, leaving ctor uniform block type as 3 and SetFloat mousepos enabled I can run the demo and get the same dodgy greenish cube, but shader isn’t using mouse pos yet so that’s what I’d expect.

    #14373

    DruggedBunny
    Participant

    Hi Mark, I was kinda guessing that it related to the number of uniforms in the block! As in, for each SetFloat, SetVec3f, etc, I’d need another entry in the ‘block’. Obviously misunderstood this!

    Number 3 happened to tie in with:

    [/crayon]

    Setting to 3 does indeed work! (Yes, dodgy green cube/no mouse position is expected at this point.)

    Thanks for the explanation.

    #14374

    DruggedBunny
    Participant

    That’s what I was after! Working nicely.

    [/crayon] [/crayon]
    #14375

    DruggedBunny
    Participant

    EDIT: Skip this and cut to the chase, below!

    This appears to be a general GLSL query, rather than MX2-specific, so anyone with some background welcome, doesn’t have to be Mark!

    I’m trying to get an old greyscale shader working, whereby an integer Mode uniform is passed to set the greyscale algorithm used.

    This used to work (in OpenB3D):

    [/crayon]

    Note the break lines.

    … but now it seems as if it always exits the switch at the first break, regardless of the value of m_Mode!

    For example, this always exits at case 0 (no greyscale applied) if I enable the break within that case, even if m_Mode is set to 1 or above (ie. it shouldn’t even hit case 0):

    [/crayon]

    Yet without the break, it seems to end up at the last breaking case (the final case if there is no earlier break). So with no breaks enabled, the screen always ends up red (per the last line there), even if m_Mode is < 3.

    Example is attached — anyone got any idea what’s going wrong here? Is it some later GLSL spec that works differently?? How do I get it to just select a path based on m_Mode?

    Note that m_Mode is set by this line (0-3, where 0 is normal RGB), and it can then be changed via -/+ on the main keyboard:

    [/crayon]

    Help!

    Attachments:
    1. greyscale.zip
    #14383

    DruggedBunny
    Participant

    It seems my m_Mode value isn’t being received by the shader… what am I doing wrong here?

    Even explicitly calling…

    [/crayon]

    … results in m_Mode apparently being zero. This still produces a black screen instead of the magenta I’d expect:

    [/crayon]

    Runnable version attached…

    Attachments:
    1. uniformzero.zip
    #14385

    DruggedBunny
    Participant

    EDIT: To see that fail more clearly, amend the shader check to:

    [/crayon]

    … which results in magenta, even though m_Mode should be 1, it is in fact 0.

    I assume I’m doing something stupid!

    #14389

    SekaiChi
    Participant

    This gives an error for me, but maybe that gives a away a clue for you or someone else

    “GL_VERSION=2.1 ATI 10.4.14
    Renderer is using deferred rendering”

    #14392

    DruggedBunny
    Participant

    I don’t think that’s an error, I get that too, it’s just mojo3d printing out version info while WIP, I believe.

    #14421

    DruggedBunny
    Participant

    I’m still stuck on this — trying to set an int in the shader, in the existing uniform block, it’s always 0 on the GLSL side. (Have tried checking for both m_Mode and i_Mode!)

    I’ve been trying to add another UniformBlock, but I get the impression that’s not the way to handle it. (Am I right in thinking you just have to set the largest data type that’s going to be passed?)

    Tried a new UniformBlock using both types 1 (scalar) and 9 (int), but scalar causes textures not to be found (think because it effectively replaces the existing block ?), while int just crashes when I try to call SetInt.

    (Assume scalar is same as float?)

    So I’m back to what I posted above (see code), which just passes 0 all the time!

    #14428

    Mark Sibly
    Keymaster

    Looks like a bug in mx2’s handling of int uniforms – possible fix now pushed to develop.

    Also, you never seem to use debug mode! I know it’s a bit rough, but many of your issues always cause some kind of debug error for me which makes them quite easy to find…

    #14437

    DruggedBunny
    Participant

    I don’t generally use Debug because it usually crashes Ted to desktop on ‘7, depending on what you click. (I admit I’m a Print debugger that uses Debug rarely anyway.)

    I’ll try remember to use it before posting bug reports!

    Will give SetInt a whirl today, many thanks.

    By the way, the debug crash error was traced by Ferdi to some degree (but see later comment from same):

    Is your Ted2Go crashing in Window 7 when debugging?

    I’d come to a similar conclusion on an epic 6-hour debugger-debug session, but it seemed to be failing in the underlying C++ call for WriteStdIn, and as far as I could tell was being called correctly, so sort of lost the trail at that, and I knew you didn’t have 7 to be able to follow it up.

Viewing 12 posts - 1 through 12 (of 12 total)

You must be logged in to reply to this topic.