I was going to throw up a few artfully-revealing screenshots of Fusion 6.1, to give people something to talk about, but now it looks like I won't have to. With NAB fast approaching, Marketing is going to take all the fun out of things, real soon now it seems.
Posts
Just tell us when it will be released! We can wait a few days to see what's in it.
ReplyDeleteThe answer is obvious - "When it's ready."
ReplyDeleteNow that Marketing has gone crazy, can you tell us some more about the specific features.
ReplyDeleteI would love to hear details about:
- Renderman / Render SDK
- GPU OpenCL
- Python integration
In brief (because I only wrote the OpenCL stuff):
ReplyDeleteRenderman - there's an SDK example plugin renderer that wraps a renderman dll; traverses the scene describing geometry, lights and textures, renders it to disk and reads back the result. There's also a RIB file exporter, though I don't know how complete this is.
OpenCL - the framework lets you compile OpenCL kernels on-the-fly and run them over uploaded buffers & Fusion images, from native plugins or fuses. Support within Fusion tools TBD (i.e. where it makes best sense). OpenCL Images are supported (for filtered reads), and limited OpenGL interop. nVidia 196.xx+ drivers, GeForce 8xxx & later, limited support for ATi's GPU and CPU drivers (until they support more OpenCL features).
Python - Use Python (v3.1) scripts as well as Lua in the Console, and as comp & tool scripts within the UI, with upgraded language support.
Thanks for the insights.
ReplyDeleteAnd once again: Great work. You know you guys and girls made a whole bunch of adults happy like a child.
Daniel,
ReplyDeleteFusion 6.1 looks awesome (and I cant wait to get my hands on it), but very quiet on Generation updates? Any news there?
So we can expect OpenCL samples in a new SDK release?
ReplyDeleteWill specs on the particle file format be released?
The particle file format will not be released. It's purely a caching mechanism, including internal particle state values, and references to particle tools (or an ID anyway) in the chain, all to avoid re-rendering of particle states.
ReplyDeleteIf you wish to load in some arbitrary set of particles, generated elsewhere, you should be looking at something like a particle fuse, eg. http://vfxpedia.com/images/ParticleEmitterTest.Fuse
Nick, can't speak for Generation updates, sorry.
ReplyDeleteAh, ok, so by the same process we could make a particle fuse that saved particles out... Yeah, that makes sense.
ReplyDeleteThe update looks awesome!
ReplyDeleteI know it has been asked and that you guys can#t give a solid time frame yet, but could you tell us at least a ball park time frame of when we can expect to get fusion 6.1?
Just another question:
ReplyDeleteCan we use the default python installation or at least configure Fusions interpreter so it uses modules from the main installation.
Would be kind of tedious to keep two python environments up to date.
Hopefully this way two apps with python (3.1) could communicate directly. Like fusion with Royal Render 6 or blender.
Maybe you can show examples how to setup such an environment.
I mean in future, once the storm is over.
Still it seems quite hard to let two different python versions communicate, at least if the code is not compatible (c modules). Any ideas? In worst case one should be able pickle data. But my efforts to start Peyeon2.5 with a command line 2.5 interpreter from 2.6 failed. Somehow the fusion connection is not made. From commandline it works. Most likely because of a wrong configured environment. Will look into it.
Although a 2.6 build of PeyeonScript would be much nicer, but I guess it is out of question now that 3.1 has been announced for fusion 6.1
My thoughts are that a lot of apps still use either 2.5 or 2.6 and not all modules are ported to 3.1 yet. 3.1 is still way to go. But for an independent environment 2.6 seems the best solution, since it is easy to go to 2.5 and 3.1 from there.
I know I won't find an ideal solution for all apps and most of the code is compatible. Still got to make the best of it.
Thanks anyhow for the python support! I mean even PeyeonScript is better than Lua. Not that lua is too bad, but python is just much stronger IMO and even more: becoming a standard.
Keep it up eyeon!