Jump to content


Photo

Api/sdk Documentation


  • Please log in to reply
16 replies to this topic

#1 redoddity

redoddity

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 190 posts

Posted 22 July 2014 - 04:48 AM

Hey folks,

does anyone know if there's some proper documentation on the API/SDK for Fusion?
Right now i'm trying to do some plugin writing but gave up as i could not make head or tails from the current SDK (a replacement OpenGL 3D renderer in this case), and the samples are not that helpful in this regard.

I'm looking for something like, well, you know, 'the other company', has done for their nodal compositor. The SDK/API documentation for that is well done, good enough that even someone like me understands it and can work with it.
Right now i'm hunting more though headers and searching for comments in code to hopefully get some understanding as to how it's supposed to work, than doing any actual coding.

It's stuff like this that must have added to the success of 'the other company'.

Any info would be appreciated.

cheers,

Sven

#2 SecondMan

SecondMan

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 1,797 posts

Posted 22 July 2014 - 12:45 PM

Go through their tech support. They're just now guiding me through my first steps in fuses and they're absolutely terrific. Patient, thorough advice and examples.

(Meanwhile I'm hoping that more documentation is in progress as well of course.)

#3 ChadCapeland

ChadCapeland

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 1,975 posts

Posted 22 July 2014 - 01:25 PM

Would be nice if these things ended up in the documentation, yes.

#4 Tilt

Tilt

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 2,137 posts

Posted 23 July 2014 - 12:04 AM

I've also received lots of help from their tech support when writing Fuses but the general undertone has always been that the headers, samples and the pdf are actually the documentation.

I've tried to get some info about the latest Fuse functions which are not based on the c++ SDK... but didn't have any luck yet which is quite annoying.

#5 ChadCapeland

ChadCapeland

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 1,975 posts

Posted 24 July 2014 - 11:05 AM

Yeah, that's also the problem. There's stuff in the SDK that isn't available for Fuses (like custom bitmaps in the tool controls) and vice versa (colormatrix). So you can say "oh, just look in the SDK" but they only partially overlap. And remember, a lot of Fuses are written with SciTe or Notepad++, not a full blown IDE that actually reads the SDK.

Plus there's lots of neat OpenCL and LUA stuff that aren't really documented, but would be very helpful to users.

#6 SecondMan

SecondMan

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 1,797 posts

Posted 24 July 2014 - 12:38 PM

It would also mean that people would see that making Fuses, writing scripts, or even creating Macros with detailed interfaces isn't all that hard. It just looks hard, until you find some clear docs and a little guidance and then you're off and running in no time. It's so damn powerful as well.

#7 Tilt

Tilt

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 2,137 posts

Posted 24 July 2014 - 12:42 PM

So maybe we need a new home for the sdk docs that are on vfxpedia in addition to the forum :-)

I've always documented my Fuses extensively so they serve as tutorials because I couldn't extend the pages on vfxpedia properly (locked or unintuitive hierarchies of pages).

#8 SecondMan

SecondMan

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 1,797 posts

Posted 24 July 2014 - 12:47 PM

I've always documented my Fuses extensively so they serve as tutorials because I couldn't extend the pages on vfxpedia properly (locked or unintuitive hierarchies of pages).


Thank you for that! :)

#9 redoddity

redoddity

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 190 posts

Posted 25 July 2014 - 05:08 AM

Me documenting my fuses is done for a more selfish reason, so i know what on earth i was doing or thinking when i wrote it and need to come back and figure out why the fuse goes boink.

#10 Tilt

Tilt

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 2,137 posts

Posted 29 July 2014 - 01:24 AM

This would make a neat renderer for Fusion :)

http://madebyevan.co...l-path-tracing/

#11 SecondMan

SecondMan

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 1,797 posts

Posted 29 July 2014 - 12:35 PM

That's pretty impressive. Although it crashes my browser on Table And Chair. :)

#12 redoddity

redoddity

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 190 posts

Posted 29 July 2014 - 04:34 PM

Right now i've written a deferred renderer that uses the albedo/diffuse, wpp and normal output of the default render3d. Actually, multiple render3ds, one extra for roughness metalness channels and one for normal channels with bump information, this is done because the default normal pass of Fusion's render3d doesn't output the shader bump/normal maps to the normal channels (no idea whether or not this is by design or an oversight.)

It's completely backwards workflow wise, but it just as a proof of concept, as we use Fusion more for texture work than Photoshop on Unreal and Unity projects, and when using PBR shaders it's quite easy to get a preview of what the model with shading would look like in realtime.

So far it does point lights (lambertian lighting model with BlinnPhong highlights), reflection with roughness (simulating using reflection mipmaps for the different roughness values) and fresnel, and simple irridiance map (blurred hdr environment map) for indirect illumination.

Problem now is that it's simply an OpenCL Fuse, and i much rather be able to have a plugin that i can feed the actual shader code we use in games (or a close derivative of it, rather than completely unreusable opencl 'shader' code.)

#13 ChadCapeland

ChadCapeland

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 1,975 posts

Posted 29 July 2014 - 06:26 PM

The normal shader can be overridden for OpenGL and can output the bumpmapped normals. GenericShader3D can also do that. Oh, and speaking of which, you could actually do the deferred rendering with GenericShader3D, which is nice because then you can interact with the regular lights and such. There's a lot of nice stuff you can do with OpenCL that you can't easily do with OpenGL as we have it in Renderer3D though.

We used GenericShader3D to write Unity shaders, too, which is nice because you can play around with the input maps SO much easier than you can in Unity. With Fusion 7, flushing the shader cache is now possible, so it could be almost as easy to write the shaders themselves. You don't get multi-pass or custom sorting though.

#14 redoddity

redoddity

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 190 posts

Posted 30 July 2014 - 05:29 AM

Yeah, been playing with the GenericShader, but i got stuck at a certain point, not sure what the reason was though, probably couldn't find how to access certain stuff, or a limit on the available image inputs.

#15 Pilalitos

Pilalitos

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 791 posts

Posted 30 July 2014 - 08:02 AM

This would make a neat renderer for Fusion :)

http://madebyevan.co...l-path-tracing/


Holly cow!!!




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users