stacking multiple jit.gl.slabs

Jul 27, 2012 at 4:06pm

stacking multiple jit.gl.slabs

I’ve got a chain of slabs that I like, is there any advantage processor efficiency wise to taking those shaders and compiling them down to a single slab?

#63751
Jul 27, 2012 at 5:04pm

There can be. It really depends on how big the one shader gets versus how how much your graphics card can handle. There really isn’t an exact rule.

#229937
Jul 27, 2012 at 5:14pm

It’s a suck it and see situation? Cheers.

#229938
Jul 27, 2012 at 5:23pm

Indeed.

#229939
Jul 27, 2012 at 5:25pm

sounds like a good opportunity to try out jit.gl.pix

#229940
Jul 28, 2012 at 8:08pm

Indeed it was… have to say having forced myself to sit and play with jit.gl.pix that it is a truly awesome addition to jitter. Being able to fiddle with shaders in graphical land or use codeboxes as required rather than code in textedit and then reload your slab is well wicked, you can just reroute the output to whatever bit of the patch you’re trying to understand, so quick to muck about with.

Very tasty.

#229941
Jul 28, 2012 at 11:41pm

How do you know when you’ve reached the limit your card can handle, right now I’ve got a shader that does scale bias, brightness, contrast and saturate. When I try to add more (I want a colour splitter and a ripple repos) I start by adding a [sample] but it won’t let me connect to it.

Also I start getting messages at the max window that lua isn’t happy.

Does this mean I’ve filled this shader?

#229942
Jul 30, 2012 at 5:44pm

Does this mean I’ve filled this shader?

no, it means you’re likely found a bug. Can you post the patch that causes problems?

#229943
Jul 31, 2012 at 12:32pm

It’s bigger than the sun, here is just the shader, it’s not posting any errors to the max window anymore but it still won’t let me resample the output of the first stage.

– Pasted Max Patch, click to expand. –
#229944
Jul 31, 2012 at 12:33pm

genjits

Attachments:
  1. rmpripple.genjit
#229945
Jul 31, 2012 at 3:13pm

In the gen world, the only thing you connect to the input of [sample] is an [in] operator. It won’t let you connect anything else by design. The [in] operators represent two different concepts simultaneously, which is probably what’s causing some confusion. They are:

1) The current pixel/cell being processed
2) a proxy for the entire input matrix/texture

When you connect [in] to any operator except [sample], you’re connecting the current pixel being processed to that operator (1). When you connect [in] to [sample], you’re connecting the entire input matrix to it (2). This is because [sample] can pull an arbitrary pixel from a given input. All other ops can only work with the current pixel flowing through the gen patcher.

In your genjit patches, I noticed you had [in 1] -> [sample] with a [norm] connected to the second [sample] inlet. You actually don’t need this. The following are equivalent:

– Pasted Max Patch, click to expand. –
– Pasted Max Patch, click to expand. –

If you run the two gen patchers above, you’ll see that using [sample] in this way and simply passing through [in] are the same.

If you want to chain effects like a brcosa and then a repos type displacement, you’ll have to chain separate gl.pix objects together. You can’t sample from anything except the input, so you can’t sample from the end of a processing chain like you were trying to do. The entire processed image simply isn’t available at that time.

Hope this all makes sense. If anything is confusing, please ask.

#229946
Jul 31, 2012 at 6:00pm

That makes sense (as much as anything shader related does).

#229947

You must be logged in to reply to this topic.