Fragment shader fails with additional uniform

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

This topic contains 8 replies, has 3 voices, and was last updated by  DruggedBunny 1 day, 21 hours ago.

Viewing 9 posts - 1 through 9 (of 9 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.

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

You must be logged in to reply to this topic.