The Next Big Thing

Quote
Vladimir Golovin wrote: with the site redesign, as the current site is embarrassing in 2020

Site redesign? For FF? I like the FF website though

It performs and loads well, looks nice, and doesn't at all resemble this whole metro UI Windows 10 crap everyone is spamming all over these days. Big squares and rectangles of flat color with no rounded corners or gradients that are far too oversized for the elements they contain. Disgusting. Please don't go that route.

Think more like something an adobe air app would have had instead

Quote
but The Next Big Thingy is being actively developed.

Will "The Next Big Thingy" work with the existing Filter Forge filters users submitted?
So can it use from day 1 the (> 13000) existing Filter Forge filters?

Quote
FFCreator wrote: Have you tried partnering with other companies that have a lot of experience in GPU coding? E.g .: BluffTitler (Outerspace-software)

No, we haven't. Our demands are very very specific (a tile-based renderer for huge bitmaps with floating-point precision, written in Vulkan), and it's extremely unlikely to find that expertise. Speaking of BlufTitler specifically: based on their example videos, it looks like they're doing regular rasterization with native polygons and shaders, which won't help us much.

Quote
FFCreator wrote: You want shared code for rendering in Windows and MacOS?

Ideally, yes. But as of today, Macs don't support Vulkan. At this moment, we're focusing on getting the renderer up and running, so we currently disregard portability issues -- which means that our initial versions will run on Vulkan only, not on Metal.

We know about MoltenVK, but we have very strong doubts that it will work in our case right out of the box. We currently assume that it won't. Even vanilla Vulkan is difficult to get to work on officially supported hardware, and I can only imagine the levels of pain from adding another layer into the mix.

Hi Vladimir,

Nice to see that the team is striving to take Filter Forge to the next level.

I have some concerns regarding GPU acceleration for this software.

I am of the opinion that part of the charm of this software is that it can be used without requiring an expensive GPU. The fact that this program runs
only on software is what also makes it very usable imo, since it can be run anywhere.

I also believe that having to support multiple graphics cards and drivers can be very daunting and may cause alot of bugs, crashes and breaking that can take
alot of development time and resources, which in effect will lead to less time implementing and improving features.

Another problem that GPUs pose is the limited vram memory, which can cause great issues when rendering out high resolution images. I believe when it comes
to non realtime rendering, using system memory has always been a better solution as it is cheaper to afford large amounts of system memory.

I believe there are still software based solutions to improve the speed and features of the app.

Have you looked into Intel Embree? Maybe that can provide the performance optimizations necessary for sampling.

https://github.com/embree/embree

In the end I believe it is a decision between speed and accuracy. I favour accuracy, which is unfortunately the less popular side to take.

Best of luck with the development of this program

Hi Vladimir,

Thank you for responding

It's good to know that these issues were thought of and are being addressed. It gives me faith that the program is heading in a smart direction.

I am excited to see this tile based rendering system being implemented and also a turing complete node system is exciting as well.

Best of luck and I believe in you and your team!

Awesome, I will be one of the first to join the testing for this prototype.

Sounds like really complex steps to get the view updated, hopefully that can be optimized!

Quote
traycaa wrote: Just wanted to know if this tile based renderer would provide us with the benefit of resolution independence that the current sample based architecture has.

Yes. The current approach is as follows: you define a fill (technically a shader) and you can execute it on any bitmap of any resolution. You can even use the same fill / shader to fill multiple bitmaps at once.

Awesome!

Thank you for the response. Can't wait for the product!

I wouldn't mind utilising a proper sample based architecture since I have an nvidia GPU with Optix support, so it would be nice to have this option as well for people with such GPUs

I love it, what they're trying to do is crazy and exciting!

If they manage to pull this off this can end up being an extremely powerful graphics program of groundbreaking magnitudes.

They are currently implementing a system that:

- Runs on vulkan based GPU architecture.
- Uses a tile based renderer with a complex virtual memory system to support images outside the capacity of GPU memory.
- A custom turing complete node based language residing ontop of GPU that allows for powerful expression. !EXCITING STUFF!
- Resolution independence for the sharpest quality image.
- Support for vector graphics.

Vector graphics support is especially ridiculous because there isnt a single renderer out there that allows the creation of vector graphics alongside pixels while maintaining resolution independence. Most sample based 3d renderers have the ability to render out these vectors, but they cant create them on their own. 2d software may have vector and raster support, but the raster support isnt resolution independent.

So this feature is especially special since no one else has done it yet

This system is the definition of a high fidelity rendering and graphics application.

Quote
traycaa wrote: Vector graphics support is especially ridiculous because there isnt a single renderer out there that allows the creation of vector graphics alongside pixels while maintaining resolution independence.

The current plan is a separate type for Bezier splines, and some basic nodes for creation (box, circle, ellipse, arc, spline-from-points etc.) and modification (e.g. boolean, outline, and affine transforms). You can export the generated splines as is, and you should be able to rasterize them into bitmaps of arbitrary resolution (and hopefully with a GPU-based fill).

Spline nodes are executed on CPU only, but that is a good thing because this automatically guarantees that Splines will work with all our "programming" nodes -- lists, tuples, maps, filters, folds, etc. For example, you can merge multiple splines into a single boolean by putting them all into a list, then fold'ing the list into a single spline with the Boolean operation.

AWESOME!

Thank you for all this development info!

Those types also look very simple to use, like a much more conveniently designed shading language. Kind of reminding me of VEX in Houdini. Which reminds me, would be really nice to have linear algebra data types as well like Matrix, Vector, Determinant & Cross Product etc.

Quote
Vladimir Golovin wrote: Filter Forge Forever...Yes, we will absolutely release a playground version, as soon as we have something to show.

Wow, it's already been four years! This thread came back up in a search for something else, but I remember when you made that statement and I was wondering where things are with that plan. Is FFF still an up-and-coming thing, or has it slipped off into the weeds and gotten lost behind more immediate FF development?

Quote
Vladimir Golovin wrote: FFF is absolutely an up-and-coming thing, it is in active development.

That is excellent news. I understand how it is when your goal is pushed back by an unexpected amount of dev work. I have all but given up on my original plan for my art career, due to endless, frustrating setbacks. I lost most of what I'd built up, project resource-wise, because of repeated hardware failures. I'm now on my fourth computer, and have not managed to recover anything significant.

I am glad you're sticking to your plan, and look forward to it's completion. Hang in there, Vlad!

Quote
David Roberson wrote: I have all but given up on my original plan for my art career, due to endless, frustrating setbacks. I lost most of what I'd built up, project resource-wise, because of repeated hardware failures.

“It’s better to be in the arena, getting stomped by the bull, than to be up in the stands or out in the parking lot.” ― Steven Pressfield, The War of Art.

BTW, have you read this book, The War of Art? The best 10 bucks I've ever spent in my entire life. I'm on my third re-reading now. There are parts in it that deal with the "all is lost" moment -- which every artist is bound to have sometime during their career.

Quote
David Roberson wrote: have not managed to recover anything significant.

You mean the files that were stored locally on your computers?

[quote]

Hi David, Sorry to barge in on this conversation which I just happened upon. I know how frustrating stupid but simple mistakes can create a negative mindset. Don't give up on your plans, just save up to send those drives fr om your dead systems for data recovery. That way you don't need to start from scratch, but just carry on wh ere you left off... with a positive mindset. All the best.

Quote
David Roberson wrote: I'd gone to all the trouble to replicate my own work on the cloud and on external drives, I discovered that I was over budget

I'd recommend Backblaze for backup -- $6 per month, and it backs up everything. Though I'd advise to log in every month or so, and check the most recent backup date, to make sure that the backup is being performed.