JFASI

7th January 2006 02:31 UTC

Transparency APE Technical Problem
I thought of a plugin that would look at a pixel, and if its color is juuuust the right shade of black, it acts like as if it were transparent, i.e. it is rendered in Max mode. Otherwise it renders Replace or whatever. I would like to know this: Does AVS actually allow for each pixel to be handled like this? Can I look at every one and choose its draw mode, or can I only do that with the whole image?

DummyDDD

7th January 2006 15:33 UTC

I dont know so, but I doubt it, because then it require rquire thoose calcs to be done just before rendering anything, which I doubt can be done with an ape.
In order to do what you suggest, you would have to make a new rendermode, which is only possible through the avs source code.

Usually you can however work around not having that kind of transparancy, by first using replace (or subtractive for images) to first make a black outline of what you want to draw, and then draw what you wanted to draw (on top of something) using addictive blend.

JFASI

7th January 2006 23:16 UTC

I messed around with that for a while, and I couldn't get it to work like I wanted it. So you say no?

Grandchild

8th January 2006 17:20 UTC

"addictive" blend, lol!

that could be a name for the ape you're writing JFASI!

JFASI

8th January 2006 18:00 UTC

Assuming it could be written as an APE.

I gave it a bit of though, and I think I could do the same thing using Trans->Color Modifier to write whether the pixel is the color or not to a global megabuffer and then take it to the DM and alpha blend it using that.

Grandchild

8th January 2006 20:26 UTC

na that's not possible! [if I understand you right]

color modifier can NOT change the color of each pixel respectively to its position
e.g.

red = if(above(x,0),1,red);

or sth like that.

Knowing that, you will see that likewise, color modifier can't get the position of a pixel. It knows only its color.

So unfortunately you'll not be able to get and save the positions of all the pixels that have e.g. #010101.

I would like it very much to have such a "pixel reading" ape. It would be very useful but slow as hell, I promise.

GC

JFASI

9th January 2006 23:44 UTC

So if I go :

Frame:

nt=0

Pixel

nt=nt+1;

pix=if(band(equal(red,.1),band(equal(blue,.1),green,.1)),0,1);
assign(gmegabuff(nt),pix)//Or however the syntax works

in the color modifier, and then

Frame

nt=0

Pixel

nt=nt+1
alpha=gmegabuff(nt)

It wouldn't work? I thought it could actually do that.

jheriko

10th January 2006 01:44 UTC

Color modifier is quite clever and can do a lot of stuff, but to do more complex per pixel effects depending on, say, the pixel position, is pretty damned slow. I wrote an APE for doing this, but abandoned it as I was going to have to make quality sacrifices and effort to make it practical... mostly effort :P

As a side note it can be used to capture the framebuffer into the megabuf. If anyone else seriously wants to make an APE I would be glad to help out. Sticking the framebuffer into megabuf, perhaps as a low quality copy, is certainly possible, although without quality limits using it would automatically limit the preset to a low, just watchable speed.

I would attach the per-pixel ape, but its evil and shouldnt spread. But using I made couple of presets which were doing a few assigns and adds and an abs to render stuff at about 20-30fps, so copying data from pixels to megabuf would probably be at most that slow if there is no quality loss.

Interesting stuff tho, 'transparency'... /me laughs

JFASI

10th January 2006 03:32 UTC

Ok, then. Any tricks to get around it? Whenever you're done laughing...

PAK-9

10th January 2006 16:07 UTC

Use buffer blend noob

[Ishan]

10th January 2006 16:34 UTC

lol. PAK is like he was before :p

Tuggummi

10th January 2006 17:29 UTC

Let's calculate! (im not very good at that, but what the hell.)

Say you check the color value for each pixel, then you re-valuate the value to something else, that's times 2, right?
Now let's calculate the pixels, say, we have a screen with the size of 400x300 (a typical fullscreen resolution?) that would mean 400*300*2 (240 000) calculations per frame. And what ever complicated formula you were intending for it, that would mean you would do that almost a quarter a million times per frame. Sound fast to you? Because it sure as hell doesn't sound too fast for me :weird:



If you really want to do this, could it be possible to do it like the dynamic movement does it? As in divide the screen into a grid of points and blablabla-technicals-blablbala, so the user can decide between quality and performance.

StevenRoy

10th January 2006 21:43 UTC

For sprite-like transparency, I prefer the following "trick":

Effect list (Output=Subtractive 1)
- (Draw stuff here)
- Buffer Save
- Color Clip (Make everything white except pure black)
- Convolution Kernel (If you want black borders around the sprites)
Buffer Restore (Additive)

This is somewhat similar to DummyDDD's suggestion, but more general-purpose. It's not quite the same as a true "transparency" render mode, but it might be close enough. (Assuming you do it right.)

JFASI

10th January 2006 22:02 UTC

That's what I was looking for. Buffer Blend? I don't have it.

eheiney

11th January 2006 00:31 UTC

http://tomylobo.deviantart.com/

JFASI

11th January 2006 02:37 UTC

Window Resize APE! Very nice. The buffer blend is sexy too.

eheiney

11th January 2006 02:50 UTC

Damn, son. You've really been missing out. The window resize APE is essential to AVS artists. :D

Tuggummi

11th January 2006 06:52 UTC

Originally posted by denkensiefursich
The window resize APE is essential to AVS artists. :D

PAK-9

11th January 2006 09:12 UTC

Hack the dll resources noob

Grandchild

11th January 2006 12:19 UTC

Pak-9:

Use buffer blend noob

PAK-9

11th January 2006 13:11 UTC

It's simply point processing. i.e. The new value of each pixel is dependant upon only the current value of the pixel. Contrast this to, say, convolution where the new value of each pixel is dependant upon the current value of the pixels surrounding it (local processing)

and yes... i do mean an el set to buffer blend

JFASI

11th January 2006 15:48 UTC

And how exactly does buffer output in effect list work? It doesn't exactly save it to that buffer, does it?

Grandchild

11th January 2006 23:25 UTC

You have to save a buffer somewhere [preferably only once, when the preset is started] , and use this as an output buffer simply by selecting it in input or output blend mode.


I attached an example file that will serve two purposes:

1. Explain the use of Buffer Blend to JFASI [look into the FX lists' code] and
2. Will show a problem I have recreating a Unique Tone [or sth that puts color to grey similarly] with a CM.
Setting variable "color" = (r+b+g)/3; and then assigning this to r,b and g all the same should result in a grey image in my brain, but obviously it doesn't. [look into the CM]

GC

oh and /edit: it shows my decent gradient skills of course! :blah:

JaVS_v2.5

12th January 2006 08:35 UTC

Now, a different formula. How about using a DM? Alpha?

[Ishan]

12th January 2006 10:23 UTC

actually as a not-so-skilled avs'er i did prefer alpha a bit more than other options.




but maybe that's why i'm not-so-skilled :rolleyes:

jheriko

13th January 2006 15:44 UTC

color modifier can be used to convert a pixel to another color if it is a certain color. for instance, making all white pixels black and leaving the rest alone. the way it works though is a little bit of a mystery to me. my guesswork is that it creates a look up table for each red,green,blue. this could have 255 entries as such:

r/g/b newred newblue newgreen
0
1
2
.
.
.

the recompute every frame option will update this table per frame i think

this is just guesswork, but it seems like the fastest way to do it. the obvious way of solving the problem (to actually run the code per pixel) is not practial, it comes out really slow for anything more than 4 or 5 lines of tightly optimised code.

JFASI

14th January 2006 01:37 UTC

Yeah, color modifier is suspiciously fast... What is behind that?

ASD5A

14th January 2006 12:08 UTC

see color modifier calculates red with respect to itself and variables that change per frame.(thats the same of course for blue and green)
this means it needs too calculate a list with 256(possible red values) * 3(red , green ,blue) values per frame which is really fast.
if you wanted to do modify red with respect to itself and blue and green it would have to calculate a list with 256(possible red values) *256(possible blue values) *256(possible green values) * 3(red,green,blue) = 50331648 values which cant be fast.
thats why we cant easily do a saturation change with colormod

JFASI

14th January 2006 14:01 UTC

Amen. I was about to say.

ASD5A

14th January 2006 14:31 UTC

damn typo!!

Grandchild

14th January 2006 19:58 UTC

so I can't redo a unique tone with CM. :(

and I can't even do a channel shift!

JFASI

14th January 2006 20:53 UTC

To do unique tone, you'd need to find a way to convert rgb to shb color notation. I'm sure there's a way. I'll get to it. Tomorrow.

StevenRoy

14th January 2006 22:31 UTC

If you want a "Unique Tone" that changes color over time, you can use a white Unique Tone followed by a Color Modifier that'll scale the red, green, and blue accordingly, to turn the white into another color (or even a spectrum). You may need to wrap an Effect List around this if you need a blend mode (such as Additive).

A programmable Channel Shift can be emulated, too, but it may require some trickery with multiple Channel Shifts, plus Effect Lists and/or buffers. I've never had a reason to try this; Onbeat Random is usually good enough for me.

Regarding the transparency example I posted earlier: Yes, it is possible to do the same thing with a Buffer output mode. In fact, that's the way I used to do this kind of transparency before I discovered the "subtract-and-add" method. Now I wonder, though, which is faster? I figured that the latter would be, but I suppose I (or someone) should experiment to confirm this.

Grandchild

15th January 2006 01:26 UTC

thanks steven, but I wanted to do some further optimization:

before:
-EL{ (substr.1 out)
--Unique Tone
--EL{ (add. out)
---Invert
--}
--Multiplier x2
-}

now:
-EL{ (substr.1 out)
--Unique Tone
--Color Modifier: r = (1-r*2)*2 [for each r/g/b]
-}

desired:
-Color Modifier: r = r-(insert impossible UT code here(1-r*2)*2) [r/g/b]

:)

ASD5A

15th January 2006 14:07 UTC

in the attachment is a preset that can decrease saturation and can dynamically tint the unique tone.

Grandchild

15th January 2006 15:24 UTC

say, how many spaghetti renditions do you have?

nice preset, but the tinting isn't so special, to be honest...

JFASI

15th January 2006 16:43 UTC

It's a good technical preset. Which is all I seem to able to do at the moment :(

ASD5A

15th January 2006 18:01 UTC

i got 87 different presets handling with worms/spaghettis/strings because whenever i try out another graphical effect i do that with a worm preset.

the preset above was meant to show technical possibilities

JFASI

15th January 2006 18:44 UTC

Why? cuz there's so much wriggling and movement?

ASD5A

15th January 2006 18:57 UTC

yeah