Sharing Noise

Another one for today... techno noise! Or something heh.

Technical Notes: We can easily slap down a couple noise patterns and blend them together but what should be important is the overall unified appearance. Cascading noise patterns might produce something cool, but it can also produce "messy things". To fix this, we can clip certain areas of noise to contain certain textural qualities. In this case, I added something that appears like a circuit board to a limited area by clipping. Clipping is accomplished via the threshold component, and it'll render much faster than using the blend mode with opacity plugged in with a desired mask.

Also in the tree is a small segment dedicated to producing shading. In this case, I wanted a "AO look" or the appearance of ambient occlusion, without enabling ambient occlusion in the rendering. The darkened corners and edges is a simple and yet effective way of producing the sense of depth in a single image. The look was created simply by passing the base noise pattern (with whatever applied) through a chain of highpass and hardlight blend mode. In this case, I stop there, but it normally should be multiplied on a appropriate pass intended for diffuse (color), or blended in some way. The point being you can figure that part yourself. On that note, this of course isn't the way AO is rendered, it's just the feeling I'm going for. If you ever compare render times with AO enabled, this will definitely go faster. WAY FASTER.

It should note that complexity does affect the highpass filter, and parameters should be carefully adjusted to suit the final image. This method does produce ugly results!



SharingNoise002.ffxml

Cool, good and interesting idea.

Although it would be difficult to control the noise in FF as there is still not included a knob to control the volume of the noise

For those that do not know, this is for Graphical Noise

For example is explained in the wikipedia Perlin Noise and other kind of Noise at the end of the article

You should tell that all this filters are for FF 4.0

Quote
Skybase SR, you'll find something that you can use at some point. A couple days ago somebody asked about making random-appearing tiles. I thought I'd do something a bit creative with them. Maybe a bit of Piet Mondrian?

WOW!! I found it now with awesome Mondrian style filter you have done, I love you for making this, since that thread that had the tip of using two tiles component linked together I have been thinking about this same thing of filling squares with colors but could not do it, and now I have seen how you have done it right, interesting and very useful, thanks very much for making this, love it much.

Also thanks for explaining the technical part that is useful and interesting too.

Although I like it much, after you have done it, I had the idea to convert it into textured filled tiles instead of plain colors, but it does not work because the elevation gradient kills the image, so there could be an alternative to this to fill the mondrian squares with images? Or would be difficult to make?

I was thinking to myself "Oh that'll be a great challenge thread!" but then again... I don't think its fair that I'd be holding stuff back so here's what I came up with. lol let it be understood that errrm... I prefer for others to do more deeper exploration with these snippets.



Technical Notes: Despite what it appears it's not so complicated, in fact it may be slightly inefficient. So if somebody can figure another way around all the issues I'm having maybe this will work nicer. Either way there are two main components to this: the tile generation and the image placement.

Given what SpaceRay typically does, I thought I'd just go with the "SpaceRay thing to do" which is fill the image up with multiple images like a mixer. In this case, I guess the idea was to fill each area up with something, like an image. To create this, I first needed coordinate values of what the tile nodes are doing. Since they jumble the image, I can feed a simple assembly of an X and Y gradient (blue = 1), and use that to look up the table. Once the gradients are processed, I can extract the coordinate values and hook them up to individual X and Y inputs of the lookup node. So I went with 5 images since that number evens out pretty well.

Once done, I then created the same thing of tile components but with this one producing a luminance value. After rounding the values and evenly distributing each one, I can then use the If component to get specific values of each block and fill it with the images from the lookup components.

Values in this case were pretty simple: starting at 100, 75, 50, 25, and 0. (That's why there are 5 images. We can change it to 3 or 7 or whatever other number depending on the granularity input of the round component.)

Edit: Disabled anti-alias for speed. We really don't need anti-aliasing when we got straight lines. When curved, it'll look nicer, but not in this case.



Note: suddenly this filter is worthy of upload to the library. Probably will do once processed.

SharingNoise 003 - Images.ffxml

I was surprised to learn there was no Mondrian filter in the library! This could have definitely been a mini-challenge.

I tried it with Bricks to get rid of the rigid tiles base. With offset and a step curve you can make the offsets more regulated so the lines don't end up right next to each other, and it looks mondrianishly mathematical that way, too.

Mondrian Bricks.ffxml

Filter.

Random Lines Seamless.ffxml

From whence one may develop such wondrous weirdness.

ThreeDee like the snippets you have put, cool and weird, well done, thanks for sharing.

Quote
Skybase Note: suddenly this filter is worthy of upload to the library. Probably will do once processed.

This would be a good idea as this is very good and well done.

I would suggest that you make available some controls to MOVE the images inside the shapes, so if the shapes does not fit right when they are positioned, you could customize it in a better way

Here I have made a version of your filter with offset controls on each image, but there is something wrong and does not work right always, it appears some white and blacks bars when moving too much.

I have put 12 presets 6 with plain colors and 6 with images. Preset 8 is the same as 9, the only difference is that 9 has been moved to inside to fit better the images than what is seen in 8

SharingNoise 003 - Images with controls.ffxml

Some new noise, using three techniques:
1. Each octave (layer) uses a different seed (variation), and they are "screen" blended so it doesn't clip (no blank areas).
2. Bezier curves for the noise profiles.
3. A small-scale, high-roughness perlin blended in at the end for that extra touch.

(made in FF 4)

It anoise me.ffxml

Quote
I would suggest that you make available some controls to MOVE the images inside the shapes, so if the shapes does not fit right when they are positioned, you could customize it in a better way

We could probably have a "control freak" version. But given how the images are thrown around already it's honestly easier dealt by offsetting the coordinate gradients. This kinda means we'd have a single set of x and y slider that deals with all the images, thus removing the need for offset nodes per image input.

And more noise!





Technical Notes: This noise was created using a bomber. Very simply put, the bomber has the capability to produce all sorts of noise patterns, and it does it with quite a load of control. In this case I have an input that appears like a bunch of circles with textures of lines running through it. The basic idea here for me was to create something that looks "wrinkly" so that's what those are about. The bomber then feeds out a black and white representation, which is fed into a noise distortion.

So this noise pattern is actually kinda slow when it comes to render. Maybe not as practical. But it still shows off the bomber's capability when producing unique patterns.

SharingNoise 004.ffxml

Quote
Looping comes with a price: speed

Somethings things are worth the price they demand.

I'm often surprised by comments where a filter is deemed somehow unworthy because it's slow.

Now, that could very well be the case. But it can also be the case that if the output cannot be achieved any other way and if that's the desired goal, then the time it takes may well be happily granted.

True story with only modest relevance: I do software research. I take code and look for ways to improve it. The goal is usually not an improvement in percentages but in multiples.

Six or seven years ago I had a project where the goal was a 22x speed increase (only a somewhat arbitrary choice - the computation was taking 1h50 on a single core and they wanted it to be 5 minutes). Because of the nature of the computation, parallelization was not a viable option.

It eventually took six months and went through increasingly aggressive attempts to squeeze speed -- ending up involving working directly with CPU engineers at Intel sweating individual CPU cycles (not instructions, mind, but cycles) in order to maximize the efficiency of the CPU pipeline's throughput.

I didn't reach 22x and the project was deemed a failure as only 7x was achieved and the results were not used (mostly because of some regression testing which came out different because of changes to how the computation took place. The differences were not significant but using them would have required enormous effort to validate the differing results).

They chose to keep using the slow(er) way. The value of the (original) output trumped the speed issue.

Anyway, as I warned you, the story is only semi-relevant. However, the choice of speed versus output is always there.

Of course for a given output, faster is preferred.

However, depending on the output, it's easily imagined that waiting is often better than not being able to produce the output at all.

I'm seeing loops in that light.

Casual Pixels, that's a great little story. Back in college when I was doing all sorts of 3D stuff using Maya and MentalRay, I realized a bunch of crowds were claiming MentalRay was a slow render engine. In my head I typically think "well what could I do better?" so my immediate response was make MentalRay run at the speed of light. The process of speeding renders up takes a bit of care of the scene, optimization, and tinkering unnecessary settings. There is always "a happy ground" where the rendered output looks beautiful while the render speeds are acceptable.

So imagine a fairly complicated scene rendering at 1920x1200 on a relatively fast 8 core computer. Render times hang around 1 hour. So we can tinker the obvious render settings, bake certain maps like AO (paint AO in manually too), optimize lights and shaders, remove unnecessary geometry, and reduce polys where acceptable, get cleaver, do stuff in post. We can potentially get the render times down to 10 minutes maybe.

But this requires a ton of technical skill, and to be fair, not everybody understands them. And I really just wish people would understand that this sort of "speed optimization" don't happen over a night. It's not always the software's fault, it's partially our fault that some of the things go slow. It's the same with FilterForge, the same with Modo's renderer, the same with Vray, and anything that "renders" a scene. The point is whatever happens, there's always ways to optimize it to the best of our ability. Beyond a certain point we just can't reduce things any further and that's where I basically want to be.

---
SpaceRay, glad you're finding stuff out in FilterForge. When you import your imagery via the color control there's a menu called Placement. In it, there are several options for how the image should tile. I set mine to repeat and that solves problems. The filter was designed around squares, but it handles any ratio absolutely fine. Here's a small test I did with multiple ratios! In the library version most of those problems will go away. I added options to make life easier, also made sure you don't run into that issue in the first place.

The image doesn't show what other features I added in lol just to keep it "exciting".

Hey great idea!! I´ll see if I have some good ones to share!

This noise generates the surface like rocks or ores when using this noise to the height output.



Rocky Noise.ffxml

Inujima Rocky Noise

This is very beautiful and well done and like it much, BUT I am having a weird problem, the texture is shown very well when using the reduced 600x600 size BUT when I put the "Actual Size" that is with 2000x2000 I get a much different thing, much darker and nothing compared with what is shown in 600x600

I will put an example of what happens

To make this example I choose Preset 2 and then go to New Image and choose the 2000x2000 size and then choose to see the reduced preview that will give the 600x600 image that is shown below here

It is the problem caused by difference of bitmap cache sizes. It happens when using small radius blur and more.

Try this.

Rocky Noise v1.1.ffxml

Inujima... that is just so sweet.

SpaceRay: You'll love what you can get out of just doing some of what's inside of that filter. It's so fun mixing stuff.

And... to the noise pattern!


I developed this a while ago for my own purposes but it turns out I never used it. This is a bit more complicated than the rest of what's on this thread. It's much more involved but let me try to decipher what's happening.

The base noise pattern includes A combination of multiple perlin noise patterns and a chaffs pattern. These create the color and the bump map to produce what you're looking at. Patterns are developed and combined carefully to formulate a complex appearance of weathered, rough adobe.

There's a gunk generator which you can feed any black/white hight map which it'll generate "dripping patterns" of moss, rust, or anything of that nature. These elements are all combined to produce a complex texture.

In the end, I rejected this myself for being too rough.

[Technical notes]
The gunk generator is actually the coolest part. It simply generates natural patterns of wear from all sorts of gunk. The internals work like this: we have two derivative components with the height map data feeding into them. One represents a mask for gunk that drips from the top of objects (the stuff that gets caught in the bumps), the second derivative represents a mask for the gunk that gets collected on the bottom side of a anything that protrudes. We then feed the masks into smudge which sends the pattern melting downwards. To add a bit of realism a simple refraction node was used to simulate the smudge "crawling around" the protrusions.

SharingNoise 007.ffxml

Really cool thread! I'm going to have to check these filters out as soon as I can

Here's an experiment I did using the bomber and some Perlin noise. I'm thinking I should adjust the hard edges on the shapes but here is is anyway.

The image:

I've made some changes, so disregard the first one I posted. It was one I did sometime ago and I found some stuff I needed to fix. The idea was to get simple abstract shapes that appear to glow and have movement over a somewhat textured background. It's a simple filter compared to the ones in the thread but I didn't intend for it to be anything fancy.

Here's the an updated image.

Very nice effects, Tepearley. As is, the Shape Rotation control has no effect on the output, but I realize this is a work in the making.

Crapadilla should submit something here.

An invitation!! Lol

These 2 are interesting to me at your noise lab thread.

pg 1 about 5 down from top "pumice"

pg 5 at bottom of page "acme galore"