Beta 5.0 Stage 2 Teaser?

I had a dream about an erosion node.

my dream was hardware accelerated

Lol, I'm with Sphinx on hardware acceleration In general any sort of improvement in the way FF utilizes hardware would be highly welcome. I've been doing a lot of testing lately now that I figured out how to run multiple instances of the Command Renderer and have since discovered that, although FF can use multiple CPU's, if allowed it'll use all 32 of my cores, It's peak efficiency is almost always with 2 cores. It does render quicker with more cores but that's not the only measure to determine efficiency and peak efficiency is almost always 2 cores. The only real exception is when the filter benefits from running on a single core, heavy on blurs and such

I had a dream about 64-bitness... or was it bitmap scripts?

Yes, Vladimir is very busy and doesn't really have time for the forums. Cool things are under active development

Well considering that this is for BETA STAGE 2, so it would have to been happening soon, I would not expect nothing complex that would require very much work to do.

My dream is to have a bomber component with even more controls on the particles result that are not possible in FF even joining many FF components to the bomber, for example having :

1 - non-overlapping feature

2 - alpha map for particles position directly inside bomber

3 - particles layers inside the bomber

4 - spacing value (so you can specify how much empty space and separation between particles even if they are overlapping)

Quote
xirja I had a dream about an erosion node.

OH Yes! This would be really great if there could be an erosion node that could have different options and features, that would be very helpful and useful.

Quote
Grimbly Lol, I'm with Sphinx on hardware acceleration smile:) In general any sort of improvement in the way FF utilizes hardware would be highly welcome

YES, YES, YES, YES, YES, YES!!!!!PLEASE!

I also agree much that if the GPU hardware acceleration would be really the best things, OR if it is not possible, at least any way that could make faster renderings.

mori, in regards to adding to adding there is no hope to be integrated inside FF

Quote
GMM Sorry, no plans to add animation/AE support in the nearest future, though it still remains on our list.

Although CFandM have given in this thread some possible suggestion that makes it possible right now to have animations with FF 4.0

Quote
mori What would be possible could be seen on apps like Artmatic

I think and that it could be more helpful if you give some examples screenshots, speficic website page or a video showing what you want and refering to, as the link given goes to the main page of the software

Good things come to those who wait.
What would be nice is if we could be told what we are waiting for. What additions or improvements are the developers working on?
Do we have to be surprised?

Got ya! I can understand that logic.

Quote
Is it just me, or have the devs been in super-silent mode since the release of FF4? Communications here have died down quite a bit, it seems.

Dilla and everyone, I plan to become a bit more talkative, in relatively near future (though not right now yet, need to resolve some things first.)

Quote
my dream was hardware accelerated

Sphinx, we're exploring GPUs again (for a different project), but I can confirm that exact porting of Filter Forge in its present form to a GPU is unfeasible. A realistic way of doing hardware accelerated rendering would be to start from scratch and develop a new, hardware-friendly architecture, not bound by the legacy of the CPU codebase.

One thing that would be cool is the ability to load a UV mapped 3D mesh and render on it the same way you do in Substance.

Quote
Totte One thing that would be cool is the ability to load a UV mapped 3D mesh and render on it the same way you do in Substance.

+100

YES!!! This would be really cool and make FF stand above and change much how you can things in FF, but I do no think this will happen in FF 5.0

Quote
Vladimnir Golovin Quote Also adding to Bomber the chance not to overlap the particles Speaking of the Bomber, we do plan a very powerful, very general feature for it in FF5.0, but it isn't related to particle spacing or collision.

Thanks very much Vladimir for answering and take the time to do it, as the communication is really lacking and all is kept in tight secret and there is no news about anything new

This is a very good and bad news

It is a very good news that the bomber will be updated with more features and make it even more powerful, as this is one of the best components (at least for me) from FF, and I like very much that the bomber is going to be made better and will be waiting to see what do you mean with very powerful, very general feature.

BAD NEWS OF NON-OVERLAPPING IN BOMBER COMPONENT

But then the bad news is that it seems that there will not be any way to avoid the overlapping of the particles made by the bomber so you could make a tight graphic particles composition, and the arrangement would be done automatically,

BOMBER WITH OVERLAPPING BUT WITH SPACING CONTROL FROM CENTER OF PARTICLE TO CENTER OF NEAREST PARTICLE?

Also the bad news is that there will be not either a spacing slider to be able to control the spacing between the particles generated by bomber, so the particles could be separated by a defined distance to the next nearest particle.

I may understand that maybe making non-overlapping could be difficult, but maybe having a slider distance control from the center of the particle to the center of the nearest particle would be maybe easier and would not take into account the shape or size of the particle. If it could be possible to have this, it could be controlled better the spacing between particles even if some of them may be overlapping. Better this than nothing.

Quote
Vlad wrote: Sphinx, we're exploring GPUs again (for a different project), but I can confirm that exact porting of Filter Forge in its present form to a GPU is unfeasible. A realistic way of doing hardware accelerated rendering would be to start from scratch and develop a new, hardware-friendly architecture, not bound by the legacy of the CPU codebase.

You could perhaps introduce an isolated set of HW accellerated components, which when running in "pure" HW setups is parsed completely into shader logic. These may take inputs from the outside "soft" network, and may render to a special surface/renderer/rasterizer/texture component and this would in turn allow connections to traditional FF components.