Boude

I tried a 10000x10000, PDN froze, but with 5000x5000 it worked. First it started finishing (took time), then it started initializing (also longer then normal), but the rendering process took only a split second. Done with the blur effect from above on some clouds. My guess is I was too impatient with the 10000x10000. I wonder what happens in the finishing and initiating parts of the effect rendering cycle and how does my effect come in? Maybe I should move some code around to do the rendering at the correct time, note: it is an Effect, not PropertyBasedEffect. By the way, I want to take in no way credit for the rendering of the image and the compiling of the code, that's all OpenGL. All I did was call a couple of methods.

@Rick: As I said to EER, the request was only made under the assumption there were no more errors. As Cookies pointed out that assumption was wrong. Hence the request is no longer valid. @Cookies: The new version wasn't supposed to help with the crash. Did you use anything specific? Or just run it a couple of times with simple code? BTW, sorry I used "Cookie" instead of using "Cookies", I didn't notice. Edit: The fragment shader stuff works differently then PDN with what's up and what's down. In OpenGL the coordinates (0, 0) are located on the left bottom. In PDN (0, 0) is the left top. Do you think I should flip the image to make (0, 0) the left top (going for the PDN standard) or keep it this way and sticking to the familiarity GLSL programmers (might) enjoy?

@EER: Yes, the request was only made under the assumption there were no major bugs. @Cookie: Could you send me the error log from PDN (if any) from when it crashed? Fixed the source flipping issue, I flipped the source, because OpenGL needs it to be flipped, the only problem is I never flipped it back. So the second render time it was flipped again and the third time another time etc. So basically all I had to do was flip the source twice per render.

Request for this thread to be moved to the other plugins, please. Thanks in advance.

Hello again everybody, This is my third plugin, I hope you'll all enjoy it. This uses OpenGL to increase speed and the OpenTK to simplify things for me. Thanks go to Madjik, I couldn't have done this (not that I'm finished) without using his GenTree source as general structure. The plugin can be found under Advanced > OpenPDN. As the description states this plugin brings GLSL to PDN. GLSL is a C-based language used to write shaders. In my plugin I supply the user with the width, height and source of the surface. These are accessible in code through WIDTH, HEIGHT and SRC. WIDTH and HEIGHT are both int and SRC is a sampler2D. Some example code: void main(void) { float x = float(gl_FragCoord.x) / float(WIDTH); float y = float(gl_FragCoord.y) / float(HEIGHT); vec4 src = texture2D(SRC, vec2(x, y)); float xx = gl_FragCoord.x; float yy = gl_FragCoord.y; gl_FragColor = vec4(xx / float(WIDTH * 3), yy / float(HEIGHT * 3), 0, 1) + src; } Something more complicated (it's a blur effect): const int radius = 10; void main(void) { float xAb = float(gl_FragCoord.x); float yAb = float(gl_FragCoord.y); vec4 color = vec4(0, 0, 0, 0); int amount = 0; for (int x = int(xAb - radius); x <= int(xAb + radius); x++) { if ((x > 0) && (x < WIDTH)) { for (int y = int(yAb - radius); y <= int(yAb + radius); y++) { if ((y > 0) && (y < HEIGHT)) { float xRel = float(x) / float(WIDTH); float yRel = float(y) / float(HEIGHT); float dis = pow(pow(x - xAb, 2) + pow(y - yAb, 2), 0.5); if (dis <= radius) { float disInv = radius - dis; vec4 current = texture2D(SRC, vec2(xRel, yRel)); for (int i = 0; i < int(disInv); i++){ color += current; amount++; } } } } } } gl_FragColor = color / amount; } And here is a motion blur: float angle = 0; const int length = 10; const float step = 1; //WARNING: do not make this 0, an infinite loop on your GPU is NOT a good thing (my PC showed a blue screen and resetted itself) void main(void) { float xAb = gl_FragCoord.x; float yAb = gl_FragCoord.y; vec4 color; int amount = 0; for (int i = 0; i * step < length; i++) { float x = sin(angle) * i * step; float y = cos(angle) * i * step; float disAdj = length - pow(pow(x, 2) + pow(y, 2), 0.5); x += xAb; y += yAb; if ((x >= 0) && (x < WIDTH) && (y >= 0) && (y < HEIGHT)) { color += texture2D(SRC, vec2(x / WIDTH, y / HEIGHT)) * disAdj; amount += int(disAdj); } } gl_FragColor = color / amount; } Note: for this to work, you have to have the OpenTK.dll and the OpenTK.GLControl.dll in the Effects folder. (Included in the .zip file) Download Please send me your errors. Update: Fixed error where PDN crashes the second time one startes OpenPDN. (Or so I think) Update: Source image is now available. See example code for usage. Note when using texture2D() the coordinates are from 0 to 1. Update: Simple blur effect added. (Another update in which I coded the radius slightly softer.) Update: Real-time rendering works and I changed from a GameWindow (in my project I used one named "DrawWindow") to a GLControl, which means the window opening and closing is gone for good. Let us now remember the DrawWindow, rest in peace. Update: Fixed source flipping issue (which was detected by Cookie, thanks) Up next: some standard functions to do stuff (motion blur, maybe a fractal, Gaussian blur) and some blending operations, maybe a way to save functions. And possibly syntax-highlighting (and other UI stuff), for now Visual Studio 2010 has a decent GLSL highlighter.

After some messing around with my code, I found that a perspective blur wasn't possible (not without a huge workaround). The result isn't as good as you might expect. So you'll have to do with the current version.

Thanks guys, this plugin is only a logical "spin-off" of zoom blur. So requests are logical, I can remember at least one other (negative zoom blur). @cj: This plugin is pretty much exactly what you asked for, so great minds think the same. While thinking about this, I had this idea: what if the plugin would blur in perspective (like atmospheric perspective, objects (read: "pixels") close to the vanishing point are blurred more then objects further away, of course this would be optional. So what do you think?

@Cookies: Thanks for pointing that out. Will fix it on next update. After some research and another mind destroying one hour trip in the tube, I came across something one might call a bug (no errors, don't worry). On next update distance from pixel in the "step loop" will affect how much they affect the colour of "current pixel". In plain common English, it will look better. Also possible new icon (instead of blank bitmap) and I increase the possibility of updating this weekend (now assumption worthy). Even more, when I'm explaining stuff the plugin does, I notice to use certain words to describe aspects of the plugin, some of these are now described in the main post (top of page 1). Edit: Forget weekend, updated now. Updates: point now set correctly added alpha multiplier, for less lossy alpha increase better render method, old one still included, but no longer updated

Ok guys, thanks for your great response. I might add some functions this weekend, if I have nothing better to do. (Surprisingly I also have a life) @n d: Source added, even some comments (lucky guy). I don't know how experienced you're with C#, so if you've any questions, feel free to ask. I actually copied half my code from MadJik's codelab to indirectUI (somewhere in plugin development), so you might want to take a sneak peak there as well.

Thanks guys, this plugin was the reason I started learning C#. I missed it, so now we're united. If anyone has any functions, he would look to see implemented in the plugin, feel free to ask. BTW, if anyone would like a look at the source, feel free to ask. Note: no comments.

PointBlur.zip Latest version: 1.4.9 Hello everyone, I'm back. Not with some easy to make image. No, I've got something you might actually use: Point Blur. Point Blur is a simple effect, doing the reverse of Zoom Blur. Whereas Zoom Blur blurs away from a certain point, Point Blur blurs to this point, hence Point Blur. A couple of therms used in replies: Point: the pixel, user defined, that's the centre of the point blur. Current pixel: a plugin steps through each pixel, the "current pixel" is the pixel, he is calculating the colour for. Step loop: the loop used to step through the pixels between current pixel and point. A glance under the hood, requires some knowledge of mathematics: Point Blur works by averaging the colours of the pixels in the line of that pixel and the point chosen. For example: Current Pixel = 0,0 (Coordinates (X,Y)) Point Chosen = 3,0 Pixel 1,0 = Black Pixel 2,0 = White Current Pixel is the average of the colours of the pixels in the line of itself and the point chosen (1,0 and 2,0), so it will be gray. Not all pixels are so simple, but with some application of trigonometric functions, it works. The new render method uses the distance from the current pixel to affect the colour; longer distance, less effect on current pixel. Enjoy. Source:

I have to admit, you're getting better and better dpy. Also don't be afraid of adding plug-ins to your pack. It's your pack, so you should be allowed to advertise your own plug-ins.

I'm sorry about the delay, I still had it on my to-do-list though. Things (Borderlands and Dragon Age: Origins) got in between. I'm glad you have learned to do anti-aliasing, maybe you should enter The Next Bill Gates. I tried it and it doesn't anti-alias the entire edge, some parts are left out and don't get anti-aliased, maybe it's got something to do with the condition for the anti-alias. But overall great result.

Thank you.

Thanks, I would be honoured. I already have a simple blur working so I guess this should be do-able.