The Next Big Thing

Here's a better one: accumulation is done via averaging:

Thanks Vladimir for your examples. The first wariant is actually very close since I could easily change blending mode of iterations to min(darker). Still I can't get similar "erosion" effect.

I think the reason is that in Substance Designer their very core "warp" node actually use grayscale input to get a shifting vector i.e. a direction to shift the pixels to and the shifting distance itself is always a value from the slider input, same through the whole image.

Would be nice to have a node in FF that convert grayscale input to normal map so we could get XY direction.



I mean FF alredy does it during rendering ( convering height image into normal map) why not as a node in the "components"

That Iterated Distortion via Average is a most wonderful filter to use.
I have just tested it and have sent the result to the gallery, as I'm not able to add images in the forum columns for some reason.
The fact that it is painterly, floaty and dynamic at the same time opens up a host of possibilities.
I know that this seems an odd comment to make among all you very clever digital technicians.
Although I have used FF for many years I have never made even the smallest attempt at creating a filter...it seems just too daunting to me.

As an artist I am very grateful to all you fabulous filter creators,
thank you from the bottom of my heart

Thank you, I'll give it a try over the weekend...

Thanks Funktasm, that gives me hope and a little bit more courage...

Quote
Currently FF has no dedicated node for this, but here's a couple of good snippets: https://www.filterforge.com/filters/8462.html https://www.filterforge.com/filters/8536.html

Thanks Vladimir for the links. One more thing I'd like to ask is if it's possible to use "Min" math operation for the blending. I tried and looks like it doesn't work in your last "add then divide" version.

I mean the iterations of gradually fading Darker blending mode. it's what allows to do the "blur" expanding in one direction, not both.

I can do it in your first example but it works noticeably slower. Could it be optimised somehow? That minimum/darker blending is what I mostly use in Substance designer, It's what allows to make nice erosion and dripping effects. Sadly it's still pretty slow in FF even with not that many iterations.


Another big thing that makes Substance Designer very useful is real-time GPU preview with tessellation and height displacement. Whatever easier and more convenient many FF features are ( sometimes SDesigner seems like a kind of classic crazy scientists invention fr om movies) still I can see any actual final material just instantly there. In FF it takes one extra round of waiting.

Maybe not every actual per pixel calculation but rather the preview could be GPU or Cycles driven? Would love to see FF as an addon on blendermarket. Working seamlessly with Cycles nodes in Blender. Not sure if it's possible both naturally and license wise but I would definitely buy such a hybrid.


And one more thing is ability to save a part of a graph as a tool/node/group and drop it inside new graph. Would like to have an access to other filters fr om components panel.
Cpopy/paste from one filter to another is very tiresome really.

Would love Blender way at least which have special "append" menu wh ere you could import any node group from any choosen file. In fact I believe Blenders node approach is most convenient one I ever saw. Hotkeys driven. With especially helpful bypass "M" one which helps to figure out and re-collect the graph tremendously.

Quote
My suggestion to you is to have a close look at the capabilities of Genetica which also include vectors, animation, and more. Then contact the developer and talk about a merge/takeover or a buyout.

Having a Filterforge + Genetica hybrid would be kind of awesome. I think, to give FF a lot of credit, when you compare the features/nodes they have in common, the FF implementation is usually executed better and allows for more control. It's just that where they diverge, some of Genetica's differences (in comparison to FF) feel like they should be basic/standard by now, while others dip into areas that FF will probably have to go in too, but FF hasn't really started to do that yet (vector, 3d, animation, bitmap texture synthesis, etc).

Quote
Vladimir Golovin wrote: From the technical / acrhitectural POV, Filter Forge is not equipped for evolving into these areas. That's why we opted for a Turing-complete visual language with arbitrary (and custom) data types. (The GPU support will be isolated into a subset of that language).

<-Not a programmer.
So, what you're saying is, Filter Forge 2 (or whatever) is going to branch out into these areas? Will FF2 be capable of the things you envisioned in your initial idea (procedural vector creation, etc), either by default or by repurposing it and releasing it as a different program (for the extra $$ )? Are you still planning on releasing a 'playground' version to let us mess around with the new node language?

Quote
It will be called Filter Forge Forever for the public prototype stage at least it will stay that way for a while, and if it becomes successful, we'll roll it back into the Filter Forge brand.

Nice!
But some considerations.

For me the big "treasure" of Filter Forge (FF) is the current huge database with (user)filters for inspiration. It would be nice of at some point these existing filters 'll be "converted" to the new playground (FFF). The "weakest" point of FF at the moment is the performance (even with i7 CPU) that slows down the experimentation and fun factor a bit.

So I hope the new playground (FFF) 'll challenge the user to experimentation while retaining the good things of FF.

So it would be nice if FFF:
1. is at least "compatible" with the existing FF nodes (from the outside) and huge database of filters;
2. has better (GPU) performance than the current CPU driven "engine" of FF. Even if the "accuracy" of FFF is less, if the nodes and filterfiles are (from the outside) compatible with FF we can always use the current FF for 100 % accurate rendering;
3. adds standard support for stacking filters (without editing the filters) and batch rendering of filters.

Which of these 3 things 'll likely happen?

Quote
AndrewA1988 wrote: I think it'll be successful as long as you stay true to what makes FF compelling (a certain level of accessibility and a wayyyy less convoluted/absurd UI than Substance Designer/Houdini/etc)

This is really important. Sensible UI, clear mental model, immediate feedback and "you connect it and it works" approach are the things that make FF compelling, and we shouldn't lose them. We will need to find the right balance between power / expressibility and "understandability" / accessibility. This will be difficult.

Quote
AndrewA1988 wrote: I would *love* to have a custom groups section in the current FF components bar, actually *hint hint* lol.

Quote
AndrewA1988 wrote: I'm assuming a submission library of custom components/groups

This is one of the most requested features, but it still haven't clicked for me. I'm planning to explore it after I deal with the Tabs and Projects.

It isn't really about filter stacking to me. I can only speak for myself, but it's more about speed and reducing monotony. I'll try my best to make it click for you.

1. I'm new to FF (and my interests in all of this is pretty newish as well), but I'm already annoyed that I have to weigh whether or not its easier/faster to create a certain effect within the filter editor OR exit the filter editer>find the filter with the custom group that I've already put together>copy>go back to the original filter I was editing>paste. It's frustrating, and it's easy to forget an effect I've come up with or discovered because you don't have easy access (in the editor) to what you (and others) have done before.

2. Having all of your snippets readily accessible makes it easier to experiment and find a solution that works for whatever you're trying to create.

3. Having a library of ready made groups/components makes it easier for new users to benefit from what has come before. It makes novice users less so by empowering them with advanced techniques they may not be able to create on their own. It makes it easier to learn too, because you can double click, open it up, and see exactly which components that effect consists of, instead of picking apart other filters to figure out how they did x, y, or z.

4. Filter Forge's whole shindig is about sharing customized filters/effects/tools. It's about the library. It just makes sense to extend this to other areas of the program, like custom "components", hdri's, etc.

5. It makes things easier for you, because users are doing free work for you. Just searching through the forum, or digging deep into filters, you can find many cool node combinations that reveal hidden power in FF, as well as completely unique map scripts that extend FF's functionality. Wouldn't it be great if more people had access to them? Wouldn't it be great if trial users could see how powerful FF is (at a glance)?

How many people are looking to create using x effect or tool, and pass on ff because they think it's not possible? Take the substance designer slope blur example. Indigo Ray has a FF solution for that on the forum now. On the forum. We should be able to submit this stuff and have it show up as a downloadable "component" directly from the filter editor. It helps the community as a whole become better.

6. https://share.allegorithmic.com/librar...gory_id=11 Substance Designer can do it. Genetica also lets you do it. It's kind of an expected and necessary thing. Just sayin'. ;P

Hopefully I've swayed you a bit.

Quote
AndrewA1988 wrote: From that tidbit, can we assume that FFF will have all of FF’s current nodes (in some form)?

In some form, yes.

^^ I agree with that. FF shouldn't become substance designer. I do think FF should reach feature parity (and surpass them) at some point, because let's be honest, SD has lots of nice features (that'd be great to have in FF ), but it's not put together very well and it's not at all user friendly lol.

I think there's just no perfect program (feature rich, user friendly, fast, customizable, etc.) on the market yet.

P.S. I'm surprised you didn't mention having to use a different node for grayscale and color inputs as a substance designer con. That drives me crazy!

Quote
patricks wrote: some may thing this is trivial ... but its not! so pleas what ever you got in minder for the future, please keep the infinite noise we have right now

Actually, we'd like to implement both

We're certainly keeping our infinite noise and our Perlin noise implementation, but we'd also like to implement 'finiteness' -- for example, the ability to generate, process and merge finite 'bitmaps' of various sizes. This will immediately open the doors for a huge corpus of graphic algorithms that work on finite bitmaps only (e.g. anything histogram-based, global average / minimum / maximum, palette extraction et cetera et cetera).

This is where our type system will come in handy -- it's possible that we'll have a separate data type for finite bitmaps. Though I admit, it sometimes feels daunting to think about all this.

Quote
Vladimir Golovin wrote: Actually, we'd like to implement both

Great!

as long we don't loos any of the things we can do right now, it can only get better.

Greetings,
Patrick

Quote
Vladimir Golovin wrote: When it comes to procedural image generation, mere parity would not suffice. We'll need to blow past everything in existence.

I like where this is going!

I enjoy how I have no idea what I'm looking at in that screenshot.

Quote
AndrewA1988 wrote: So those window looking things. Those are functions, correct?

Yes, these are functions. More specifically, these are so-called lambdas, that is, functions that are defined in-place.

Quote
AndrewA1988 wrote: I think you need a way of hiding the internal structure behind a simpler interface

In the example above, you can easily replace the lambdas with normal (i.e. named) functions, and all their internal details will be encapsulated in their definitions, which you can place in some far-away corner of the canvas, or maybe even in a separate tab.

Ok that's far more understandable than the previous shot.

So basically pardon the cringe syntax. I don't code:

n == 0 then return 1
else return n*(factorial(n-1))

I kinda wonder if this kind of UI would benefit a lot if the numbers that are inputted are more visible in the node structure itself, basically like to debug/see/preview what the structure's doing than anticipating a result. Maybe a node to preview variables, capable of previewing tuples and lists even? I donno. Pardon my completely outsider input, I wonder if doing that is even a viable thing.

Looking at this again, it doesn't seem so scary to me. With previews, icons, etc to make it more readable at a distance, it would look very similar to a (more advanced) substance designer function graph. Even the window looking things. They look similar to SD's frames (which allow for titles and descriptions for groups of nodes).

I think it's not something to worry too much about. Some complexity is unavoidable. It's important to have access to this stuff too, so I wouldn't worry about it drifting too far away from the original problem.

BTW, substance designer doesn't even have previews for function graphs, so this will probably be way easier to use and debug.

Hello! Just wanna tell my story of proffesional work with FF. I'm working at gamedev as programmer and fx-designer. And I use FF for making fx pattern-based textures. And periodicly I add to library filter that I've created for work. Simple, like basic glowing particle, lens flare elements, gradients. And more complex - tiled smoke / fire noises, atlas with 16 variants of some particle texture. Patterns like. Tried Substance desinger, but due to more expirience with FF it became more effective for my a bit simple cases. But for 5 years I still use it.

FF is great for this purposes. It's just my usecase, but I've no alternatives, and I think, that FF can move in this direction.

As some peaople told, and I agree - subgroup's list in components would be lifesaver

What I need / want?

- More control over channel at export. Discarded transparent pixels in .tga format break my workflow a bit
- some form of physics simulation. For Bomber may be. Cycled, if possible.
- built-in tools for export animation frames in one texture.
- more pattern-nodes. Or more control over them
- IES Generator for light rays

Thank you for your work. Good luck, everyone!

I suposse and think that this is still in development along the FF 10, so I wonder if this could be possible to be released sometime 2021 or would be more for 2022?

Thanks for any possible news that you could give