Community Fuse Effort Idea

Good idea?

Aye! I'm in!
13
100%
Nah. I'm out.
0
No votes
 
Total votes: 13

User avatar
SecondMan
Site Admin
Posts: 3341
Joined: Thu Jul 31, 2014 5:31 pm
Answers: 1
Location: Vancouver, Canada
Been thanked: 63 times
Contact:

Community Fuse Effort Idea

#1

Post by SecondMan » Sun Sep 21, 2014 12:07 am

Here's a thought.

I was reading this topic on Pigsfly: http://www.pigsfly.com/forums/index.php?showtopic=7241

And was thinking that indeed, sometimes, you come across tools like this - extremely simple, yet very useful - that are lacking from Fusion.

Now, Fuses are an immensely powerful part of Fusion. And actually surprisingly simple to get started with (although they sure can get tricky, too). But with Fusion 7's new Fuse compiler, Fuses can be faster at certain tasks than native tools (it's actually really, really awesome).

I would argue that every Fusion user should have at least a basic understanding of how they work, what you can do with them, and how you build them.

So here's the idea. Why don't we all stick our heads together, look at VFXPedia, other software, anything we ever did in custom expressions, and think of tools that could really help speed up our work, or make it more convenient, and then make these into Fuses, one at a time! We could make this a forum effort, learning good practice in Fuse coding along the way - hopefully (but likely) with some help from Eyeon. They would be consistently built, we could agree on how to name stuff so it becomes easier to read other people's work, and eventually we could compile them all in a Suck Less Fuse Pack, and make it a single must-have add-on for Fusion.

I'd certainly be up for that :)

In the meantime, we get to learn a lot. Maybe we should set op a Github for it, too, to help keep track of things. I have no idea how that works (yet), but I hear it's great :)

I've put up a poll for this. You can change your mind as we talk about this (or not) and if there's enough interest, I'd say let's get started!

User avatar
PeterLoveday
Fusioneer
Posts: 140
Joined: Sun Sep 14, 2014 6:09 pm
Answers: 5
Been thanked: 10 times

Re: Community Fuse Effort Idea

#2

Post by PeterLoveday » Sun Sep 21, 2014 12:48 am

I think this is a great idea.

While I probably can't contribute actual tools myself (for obvious reasons), I'm more than happy to be available for answering questions, and helping people out with tips, tricks, optimisation techniques, etc.

- Peter

User avatar
pingking
Fusionista
Posts: 725
Joined: Thu Aug 14, 2014 9:10 am
Been thanked: 7 times

Re: Community Fuse Effort Idea

#3

Post by pingking » Mon Sep 22, 2014 1:50 pm

do you have some specific first tasks in mind?

User avatar
Tilt
Global Moderator
Posts: 336
Joined: Sat Aug 02, 2014 4:10 am
Location: Munich, Germany
Contact:

Re: Community Fuse Effort Idea

#4

Post by Tilt » Mon Sep 22, 2014 2:18 pm

I think the clamping macro that Pieter linked to even has a Fuse equivalent already by Chad.

But I support the idea of this. The problem I see is that there's a threshold where fast, optimized code is no longer as readable as "naive" and slow code. For example, the yet undocumented pixel pointer stuff that Peter Loveday has shown me (which made my SparseColor Fuse so fast that the GPU code is no longer necessary) is a bit harder to grok than the GetPixel() calls.

It's the same with ROIDS. Once you support it, there'll be a bunch of code that might be hard to understand for newbies.

Maybe it's a good way to use this forum to build, discuss and improve the code of these Fuses. That way, somebody who wants to learn can follow the process. In a git repository you could look at the history but it might be harder to understand why something was changed. But it would be great to store the code.

User avatar
SecondMan
Site Admin
Posts: 3341
Joined: Thu Jul 31, 2014 5:31 pm
Answers: 1
Location: Vancouver, Canada
Been thanked: 63 times
Contact:

Re: Community Fuse Effort Idea

#5

Post by SecondMan » Mon Sep 22, 2014 9:49 pm

I agree - I've seen that threshold :)

That's why I would like to see a start with simple things like the clamping tool, and going through handy little macros and make them into Fuses.

Gradually we could get into ROIDS, and pixel pointer stuff, and specific use cases that may require more advanced techniques. I'd love to see some OpenCL happening, too.

For clarity we could create a subforum in Fuses and Scripting that would contain a topic per tool. First post would always contain the latest version for download and a short description, and each topic can progress as a mini workshop.

sensory jam

Re: Community Fuse Effort Idea

#6

Post by sensory jam » Wed Sep 24, 2014 11:23 am

There's a dev tool similar to Fuse in Autodesk Flame/ Smoke called Matchbox, that lingered in the background for a while until a few people in the Flame community started coding for it, and putting up tutorials...

http://fishbowl.tv

Around the same time a sharing site was created, and now it's become a really popular way for people to fill in holes in Flame's functionality.

http://logik-matchbook.org

But, the first step was definitely to get people learning about it, and everything else just takes off from there.

User avatar
pingking
Fusionista
Posts: 725
Joined: Thu Aug 14, 2014 9:10 am
Been thanked: 7 times

Re: Community Fuse Effort Idea

#7

Post by pingking » Wed Sep 24, 2014 12:46 pm

then we should start with collecting ideas for tools, discuss what is the first to take and lets do it.

sensory jam

Re: Community Fuse Effort Idea

#8

Post by sensory jam » Wed Sep 24, 2014 4:07 pm

pingking wrote:then we should start with collecting ideas for tools, discuss what is the first to take and lets do it.
VFXPedia has a small section on making Fuses, but no tutorials.
http://vfxpedia.com/index.php?title=Eye ... ting_Fuses

and also the start of a Fuse area...
http://vfxpedia.com/index.php?title=Third_Party_Fuses

Would anyone be at all into making a tutorial?

User avatar
Chad
Fusionator
Posts: 1373
Joined: Fri Aug 08, 2014 1:11 pm
Been thanked: 8 times

Re: Community Fuse Effort Idea

#9

Post by Chad » Wed Sep 24, 2014 10:00 pm

Tilt wrote:I think the clamping macro that Pieter linked to even has a Fuse equivalent already by Chad.

But I support the idea of this. The problem I see is that there's a threshold where fast, optimized code is no longer as readable as "naive" and slow code. For example, the yet undocumented pixel pointer stuff that Peter Loveday has shown me (which made my SparseColor Fuse so fast that the GPU code is no longer necessary) is a bit harder to grok than the GetPixel() calls.

It's the same with ROIDS. Once you support it, there'll be a bunch of code that might be hard to understand for newbies.

Maybe it's a good way to use this forum to build, discuss and improve the code of these Fuses. That way, somebody who wants to learn can follow the process. In a git repository you could look at the history but it might be harder to understand why something was changed. But it would be great to store the code.
Yeah, that's a huge problem, really. I think there was a tutorial for either Fuses or in the SDK where you would have a combo box for choosing a code path, and it went from simpler to more complex. Useful for learning, but not for a production tool.

Getting real documentation for Fuses would help a lot.

I'm all in favor of supporting an effort to make more Fuses, though. How about a forum for it where there's sticky post or subforum for requests/ideas and each attempted idea gets it's own post where people post their implementation, discuss features, store versions, report bugs, etc.? A moderator would need to maintain the idea list with links to the right topics and such.

Peter, while I agree that you probably can't be contributing new tools, getting you to implement requests (including fixes) in the official shipping Fuses would be great. It would improve the quality of the product and would also give us more examples to follow for our own tools. Like there's a lot of lousy stuff in there that's shipping as official stuff, and it would be nice to discuss ways to improve that. They aren't great examples of functioning production grade tools, nor are they good examples of how to make your own Fuses. I have no idea what the development team thinks of the official Fuses and how to handle them, but maybe it's something you guys could discuss and figure out which need to stay and get better and which need to be tossed because support would be too difficult.

User avatar
pingking
Fusionista
Posts: 725
Joined: Thu Aug 14, 2014 9:10 am
Been thanked: 7 times

Re: Community Fuse Effort Idea

#10

Post by pingking » Thu Sep 25, 2014 12:56 am

i know that Stefan (= Tilt) has this in his "sparse color" fuse already, but i would like to have Voroni pattern/noise generator as a fuse example.

User avatar
bfloch
Fusioneer
Posts: 87
Joined: Wed Aug 06, 2014 4:25 pm
Been thanked: 2 times

Re: Community Fuse Effort Idea

#11

Post by bfloch » Thu Sep 25, 2014 7:28 am

What's wrong with: http://vfxpedia.com/index.php?title=Eye ... tions/Fuse

sensory jam

Re: Community Fuse Effort Idea

#12

Post by sensory jam » Thu Sep 25, 2014 10:33 am

Its a nice reference area. I took another look and found this:
http://vfxpedia.com/index.php?title=Eye ... ting_Fuses

This helps a lot, but 50% of coding is figuring out how to break down and implement your idea. Bridging that gap between the reference docs and a functioning fuse would help more people get started with using them.

User avatar
Chad
Fusionator
Posts: 1373
Joined: Fri Aug 08, 2014 1:11 pm
Been thanked: 8 times

Re: Community Fuse Effort Idea

#13

Post by Chad » Thu Sep 25, 2014 11:42 am

The number of dead or missing links is a big part of it. The lack of documentation on concepts that are Fusion specific (as opposed to Lua or OpenCL or Cg specific) like precalc requests, deferred requests, ROIDS, custom data, metadata, proxy handling, etc.. Likewise there's a ton of stuff where the user needs to just "check out the SDK", which isn't wrong, but is a bit obtuse, especially when the SDK and Fuses don't have parity of features (and no breakdown of that difference is ever made).

I've struggled through making Fuses, and I would love to do more, but I'm frustrated by the lack of support and documentation. Mostly the documentation.

User avatar
Tilt
Global Moderator
Posts: 336
Joined: Sat Aug 02, 2014 4:10 am
Location: Munich, Germany
Contact:

Re: Community Fuse Effort Idea

#14

Post by Tilt » Fri Sep 26, 2014 3:35 am

Chad wrote:
The number of dead or missing links is a big part of it. The lack of documentation on concepts that are Fusion specific (as opposed to Lua or OpenCL or Cg specific) like precalc requests, deferred requests, ROIDS, custom data, metadata, proxy handling, etc.. Likewise there's a ton of stuff where the user needs to just "check out the SDK", which isn't wrong, but is a bit obtuse, especially when the SDK and Fuses don't have parity of features (and no breakdown of that difference is ever made).

I've struggled through making Fuses, and I would love to do more, but I'm frustrated by the lack of support and documentation. Mostly the documentation.
It would be a nice start if the API docs on vfxpedia looked like this: http://clique.readthedocs.org/en/latest ... index.html

Blazej, I think it was you who made the nice docs for Generation's API... that was neat and I had hoped we'll see something like that to replace the sea of missing links on vfxpedia. Maybe now with BMD there's the manpower to do it? :-)


A general message to all aspiring Fuse developers: :geek:

I have written a couple of advanced docs for Fuses while I've been building some myself (distilling the trial&error from looking at the C++ SDK as well as help from eyeon's tech support). They are about ROIDS as well as the internal request process that goes on when a Fuse is rendered. The latter has gotten a thumbs up from the eyeon devs (meaning it's correct). The ROIDS one is also correct in my opinion because I've been implementing RoI in my Fuses successfully and have gotten help and API updates from eyeon in that area.

I have documented my Fuses extensively so you can take a look at them, but you can also ask me in this forum.

Since it's hard to add documentation to the right places on vfxpedia (api pages can only be edited by eyeon) I have put the missing stuff and the missing cross-references at the bottom in the "tips" sections or linked them from the 3rd party Fuses page.

But I agree with Chad... there really needs to be a proper documentation and I think there are great tools available for this (sphinx). Mediawiki - even if the API were structured in a better way - seems to be the wrong tool.

User avatar
SecondMan
Site Admin
Posts: 3341
Joined: Thu Jul 31, 2014 5:31 pm
Answers: 1
Location: Vancouver, Canada
Been thanked: 63 times
Contact:

Re: Community Fuse Effort Idea

#15

Post by SecondMan » Thu Oct 16, 2014 4:12 pm

I guess I should just complete this thread with saying that the Community Fuse Effort has started, right here in the scripting And Fuses forum! :)

People who come here to read the forum but have not registered yet will not be able to see it yet. Since this is all about participating anyway, it's good to have a little incentive to do so...

Want in right now? You should! Just register and log in to have immediate access.

See you all there! :)