A few questions

Solar2D Custom Shader Effects
#21

I realized, after having posted, that the setter style I used isn’t so nice for transitions. Originally, I just had the new value being returned, before realizing one could assign multiple values by doing it a different way. But I suppose that could still be done (with the other “internal” parameters) while returning the interpolation-friendly “public” value.

Anyhow, a few questions about multi-pass shaders have occurred to me.

  • Do the new effects inherit the parameters of the passes, or are they stuck with the defaults? And if the former, what happens when there’s a name conflict? In the tutorial’s example, for instance, the two blur passes’ parameters share the same names.

  • Is it safe to assume that multi-pass breaks batching? I’m thinking, for instance, if I make shaders meant exclusively to be used as shader passes, can I just avoid the hassle of trying to cram everything into four floats and go to with the more generous allotment of uniforms?

  • When an input comes from a previous pass, can it be treated like a makeshift snapshot, e.g. to play with pixels from the background?

  • If so, could the first pass be spoofed, say by providing a vertex shader that just sent all vertices way outside the content: 

    P_POSITION vec2 VertexKernel( P_POSITION vec2 position ) { position.x = -10000; return position; }

and still get that capture (without wasting as much fill)? Or is there logic to try to detect “degenerates” and early-out? (Assuming there’s even a reasonable / efficient way to do that test!)

(I can obviously try these out. It would just be nice to have them spelled out, if possible.)

  • On the earlier subject of uniforms and batching, was a UniformsGroup or AttributesGroup concept ever discussed, along the lines of the old ImageGroup? With some constraints, it seems like that could work. (I totally overthought this idea while out running tonight. :stuck_out_tongue: ) Maybe too much hassle, though.

That’s all for now!

#22

Yes, multipass shaders breaks batching, as would any change in shader program.

Also, they involve intermediate render to textures that get fed to the next shader in the graph. So if you want solid perf on a cross-platform basis, I wouldn’t rely on them heavily.

#23

Good to know, thanks.

I did have a go with these, and in the “makeshift snapshot” case it didn’t look like they’ll do what I was hoping (pick up the destination and feed it into the second pass), or if they do, it’s still probably a broken approach without being able to switch blend modes in the middle. (If I may cite your competitors for a moment, I’m looking for something like Unity’s “GrabPass”.) Anyhow, I now join the chorus along with rakoonic and some others for a snapshot paint.  :slight_smile: (That said, putting an effect on a snapshot worked like a charm!)

I realized after posting that parameters were explained further down in the multi-pass tutorial. Whoops!

One issue that did come up: Is it a no-op to redefine a graphics effect with the same (full) kernel name? It didn’t seem to cause any problems, but then I haven’t tried switching the kernel out underneath it, between calls (although that’s more of a “your own fault” error). The practical situation where this arises is where a multi-pass effect references a non-builtin shader, which can also be used on its own, so it’s not necessarily clear if the pass in questions has already been loaded. Now, a polite user is probably going to call graphics.defineEffect () immediately after require ()'ing the kernel, in which case  package.loaded  could be checked first, but we all have our bad days.  :slight_smile:

#24

Yes, it’s a no-op to redefine a graphics effect. It’s definitely a good idea to have some simple prefix to namespace your kernels.

#25

Okay, great. In that case it sounds not unreasonable to define the effect inside the kernel itself, while being  require ()'d.

Are there any snippets handy that demonstrate uniform userdata? I was all set to play with that and don’t even know how to get one started.  :D Not full-on documentation, really; even just a single definition and usage, respectively.

Lastly, on one of my machines, certain shaders (specifically, some of my time-dependent ones) don’t work. Either the shader doesn’t even seem to be applied or it gets at least halfway (the correct pixels are being discarded, for example), but the time doesn’t seem to be updating, plus the texturing is all off. And  yet, the device build works fine, as does the simulator on another machine. No errors are being shown in the console.

This machine was working until just a couple days back, and in fact most shaders (including a different time-dependent one) still work fine. The only peculiar circumstances I can come up with were (1 - doing a Git pull of the stuff I wrote on the other machine (though I do this frequently, without issues), (2 - a small Windows Update, (3 - installing the Android SDK a while beforehand. Rebooting; trying with a copy of the project; uninstalling and reinstalling Corona (both same version and newer daily build); and finally making a new duplicate effect with a different kernel name, have all turned up the same result.  :frowning:

I’d file a bug, but I’m at a loss here… Is there any sort of caching mechanism being used by the shader compiler, or something along those lines? I’m stumped.

#26

No docs on uniform data yet. We want to clean up a few things there before we expose it.

That’s weird about your machine. Sounds like your windows update is the culprit. There can be minor GL driver differences that break things in subtle ways.

#27

No luck on the machine-specific issue, alas.  :frowning:

In one of these topics I mentioned something about a GetUV () function, then soon discovered CoronaTexCoord. However, there’s not much information on it.

I was expecting that, with a rectangular display object, this would yield [0, 0], [1, 0], [0, 1], [1, 1], as per the uv parameter in the fragment kernel. However, this doesn’t seem to accord with what I’m seeing, if I’m modifying the x1 , x2 , et al. of the object in question’s rect path. It almost seemed the values might be in the [-1, +1] range, but THAT wasn’t right either.  :smiley:

Anyhow, my fragment uv values seem to be ever so slightly off, perhaps related to the above. Is there some perspective correction going on, or something to that effect, when the path is modified?

This is in the context of drawing arbitrary quads with user-provided uv values per corner.

If I pass in some reference content positions to the shader and forgo the fragment shader’s uv altogether, I can texture such quads flawlessly, with the huge proviso that it isn’t rotated. I’ve got barycentric coordinate and bilinear filtering variants to circumvent that, but in these I’m running into the above-mentioned uv-weirdness. Any insight is appreciated!

In regard to some earlier things, I’ve now got pretty decent setter- and #include-ish features working.

#28

The UV’s are standard if you have a true perpendicular rectangle.

If you modify the corner offsets to distort the rectangle into an arbitrary quad, then the UV’s in the fragment kernel will change such that the texture is sampled with perspective correction.

#29

Okay, great. I guess that explains why “distorted” rectangles looked okay.

Does this mean CoronaTexCoord is pre-multiplied by “w”? And then can one recover the “1 / w”, say in the fragment shader? (I assume it’s not automatically applied to user-defined varyings.) I guess if it is just a scale I could try to account for it via the components that would typically be 1…

#30

To follow up on that, for quads it seems like I can get away with a min(CoronaTexCoord, 1.), working on the assumption that the uv will be either 0 or w, with w >= 1). This will fall apart with more general polygons, of course.  :slight_smile:

#31

I’ve been holding off on feature requests, but now that this stuff has been opened up, I’m going to try writing one up over on the Feature Requests / Feedback page.

I don’t strictly speaking need the following info, but it would make for a tighter proposal…

Is uniform userdata duplicated between the vertex and fragment namespaces, or are both available for use?

Does Corona switch “modes” when writing a vertex userdata-based effect versus uniform userdata-based (versus userdata-free) ones? I assume vertex userdata must be an attribute, which would be dead weight for a uniform userdata effect. But maybe it’s easier on Corona’s end to not restructure the renderer logic and just ignore it? (I ask because it might suggest feature implementation hints / techniques, not to try to hijack undefined behavior.  :smiley: )

Anyhow, if I don’t hear anything, I’ll just have a lot of “If it works like this…” in the proposal.  :slight_smile:

#32

To answer my mystery question from a while back about the machine-specific problem, this was the culprit:

float PI = 4. \* atan(1.); float TWO\_PI = 2. \* PI; float PI\_OVER\_TWO = PI / 2.; float ONE\_OVER\_PI = 1. / PI; float ONE\_OVER\_TWO\_PI = .5 / PI;

My laptop’s driver did not seem to like that. This seems to work fine across the board:

float PI = 4. \* atan(1.); float TWO\_PI = 8. \* atan(1.); float PI\_OVER\_TWO = 2. \* atan(1.); float ONE\_OVER\_PI = 1. / atan(1.); float ONE\_OVER\_TWO\_PI = .5 / atan(1.);

I don’t know if this is something special about its being in the “scaffolding” section or what, but there you go. For reasons that remain shrouded in mystery, it seemed to briefly work again, then suddenly didn’t, and I ended up solving it only hours before the first Corona Geek shaders show!  :slight_smile:

In case this is still being read, I’ll sneak in a few more questions:

  • Any news on uniform userdata? I thought those might see the light of day with plugins in the picture, but their documentation still says “FORTHCOMING” in the Custom Shader Effects Guide.

  • How does the blend mode interact with multi-pass shaders? Are the passes all done as “normal” and then the blend imposed on the final result? Every now and then I experiment with them as if it were per-pass but never seem to get results.

  • I can work this one out, I suppose, but in case it’s a quick answer: in multi-pass, does the vertex shader on a given pass work with the original vertices, or is it a cumulative process?

  • To echo some of rakoonic’s questions, are snapshots-as-samplers (and / or captures) a major engineering hurdle, or just something that has gotten lost in the shuffle? They would be AWESOME, by the way.  :smiley:

#33

To answer my mystery question from a while back about the machine-specific problem, this was the culprit:

float PI = 4. \* atan(1.); float TWO\_PI = 2. \* PI; float PI\_OVER\_TWO = PI / 2.; float ONE\_OVER\_PI = 1. / PI; float ONE\_OVER\_TWO\_PI = .5 / PI;

My laptop’s driver did not seem to like that. This seems to work fine across the board:

float PI = 4. \* atan(1.); float TWO\_PI = 8. \* atan(1.); float PI\_OVER\_TWO = 2. \* atan(1.); float ONE\_OVER\_PI = 1. / atan(1.); float ONE\_OVER\_TWO\_PI = .5 / atan(1.);

I don’t know if this is something special about its being in the “scaffolding” section or what, but there you go. For reasons that remain shrouded in mystery, it seemed to briefly work again, then suddenly didn’t, and I ended up solving it only hours before the first Corona Geek shaders show!  :slight_smile:

In case this is still being read, I’ll sneak in a few more questions:

  • Any news on uniform userdata? I thought those might see the light of day with plugins in the picture, but their documentation still says “FORTHCOMING” in the Custom Shader Effects Guide.

  • How does the blend mode interact with multi-pass shaders? Are the passes all done as “normal” and then the blend imposed on the final result? Every now and then I experiment with them as if it were per-pass but never seem to get results.

  • I can work this one out, I suppose, but in case it’s a quick answer: in multi-pass, does the vertex shader on a given pass work with the original vertices, or is it a cumulative process?

  • To echo some of rakoonic’s questions, are snapshots-as-samplers (and / or captures) a major engineering hurdle, or just something that has gotten lost in the shuffle? They would be AWESOME, by the way.  :smiley: