- This topic has 19 replies, 6 voices, and was last updated 15 years, 2 months ago by .
-
Posts
-
Hi,
does anybody know, when the first package for toxik will be released?
Greetz Nanuk
I’ve been told by someone at discreet they are expecting to have version 1.1 ready by IBC. I don’t know what extras it’ll have but lets hope it’s got a decent paint module!
Version 1.1 was shown at SMPTE Sydney.
It did not have a paint module, nor was it Linux – which I believe are the two big things people want…It does have a new improved GUI and we’ll cover it in depth in an upcoming podcast and story.
But we welcome hearing your views…
Just what would make you more interested in looking at Toxik?
– Single user license?
– Paint?
– Linux?
– More keyers?Reply here in this forum – we are not AME – but I am sure we can pass on your points and even your direct questions – if you have any – when we interview the guys in the next short while.
Mike
nanuk wrote:And what do you think about the future of the app? in germany it is anounced as some kind of “shake killer”. what do big companies think about it. you know companies that handle blockbuster like weta, ilm, mpc and so on. Are there any statements?The app certainly appears targeted towards the film market — large, collaborative installations dealing with high resolution imagery. There is also integrated support for HDRi and OpenEXR which is obviously critical for this market. The app has been optimized for dealing with large imagery.
Eventually…who knows…but I’m sure that technology from toxik will ripple into flame/smoke and vice versa — in fact, it already has. It seems as though all products are going to be around for a while — flame/smoke are such stable, robust, and full featured products. Even at the NAB Autodesk Users group, they showed some tech demo stuff of inferno dealing with float images…
Hi,
We had a look at Toxik 1.0 release and although I was quite aware that there would still be a lot of rough edges, I was expecting a little more meat around the bone. I don’t know about the new stuff that will make it into version 1.1 and beyond, but as of version 1.0, here is a list of showstoppers for us. (By the way, if we did get Toxik, it could have been used in a large-ish team (10-20 compositors), on 2K or HD feature-film work. So we “fit the profile” so to speak).
1. Permissions and users management.
The whole collaborative environement isn’t quite ready for prime-time because it’s lacking UNIX-style permissions for footage and compositions. As of 1.0, everybody can move, rename and delete anything in the (facility wide!) library.2.Chroma keyers.
Discreet should move the 3D keyer, master keyer and “regular” keyer to Toxik ASAP. The “diamond keyer” cannot be used seriously for a wide wide range of keying jobs.3. Garbage masks.
Flame has them. Smoke has them. Combustion has them. Why did they reinvent the wheel for Toxik? Toxik needs tracer-style tangent softness and multiple shapes per gmask nodes and host of other tweaks for it’s gmasks to be taken seriously.4. Deformation tools
Toxik needs bicubics, extended bicubics, warper and deform type tools.5. Paint.
Toxik needs a decent paint system, vector-based or otherwise.6. Plug-ins.
As of version 1.0, no commercial plug-ins are available for Toxik. We need Sapphire, Furnace, Speedsix, RevisionFX and all the other stuff to deliver shots! Come on AME, surprise us with AfterEffects plug-in compatibility like Digital Fusion did!7. Curves.
Even though the color corrector is probably one of the more mature tools in Toxik 1.0, it is mysteriously lacking curves, an essential part of a balanced breakfast!8. File Format compatibility
No support for QuickTime and Softimage .PIC files.9. Frame index slipping.
Toxik should steal a page out of Shake’s book and automatically slip clips according to their frame index. (For instance an image sequence numbered myclip.0050.sgi to myclip.0100.sgi would start at frame 50 in the composition, not frame 1).10. Macros.
Shake wouldn’t be on anybody’s radar if it weren’t for it’s macros. Don’t have the *right* tool built-in? No problem I’ll make it myself. Toxik needs macros pronto.11. Cache (framestore) management.
Toxik 1.0 doesn’t tell you if a clip is cached to local disk or not, nor does it let you cache a clip if it has already been imported to library without specifying “import/cache”.— Xavier
nanuk wrote:I fully agree with you Xavier! What do you think about the workflow in the program. With it´s´libraries desktops, working in a compostion?Greetz Nanuk
Nanuk,
I didn’t fall in love with the whole folder/desktop/composition metaphor. But maybe I’m just too used to the FFI way of working.
Basically, after a few days of playing with Toxik, we stopped using desktops altogether. The main reason is because you cannot put any kind of container inside the desktop (the word reel comes to mind!). Even worse, you can’t put desktops inside a folder hierarchy. Also, being an inferno guy, having smoke-style desktops with loose clips everywhere makes me want to take a shower a curled up in a ball like Ace Ventura did when he realized the sargeant was packing an extra weapon.
So we just ended up not using desktops at all and building hierarchies like this:
Folder (… for the scene)
Folder (… for the shot)
Folder (… for the elements)
Clip
Clip
…
Folder (… for the compositions)
Composition
Composition
…We just used the browser to get to our clips/compositions. Since the desktop has no redeeming features (like editing, or reels) we didn’t feel we lost anything by not using the desktop.
Actually, once we started working like that, I was glad I could finally see the *entire* clip names for once, instead of truncated names like the FFI desktop. Plus you can turn on the thumbnails for easy visual access. And everything is nice and tidy, sorted alphabetically, etc…
As for working inside a composition “container” instead of rendering a clip, I liked the idea at first, because I thought I could build one composition, then keep adding versions to it and being able to switch back and forth between setups AND results of the different versions of the same comp. It’s been a few months since I played with Toxik, so I don’t remember the specifics, but it didn’t work exactly as I had hoped; a bit too complicated for my taste. Plus Toxik kept adding ridiculous suffixes to my versions like mycomp_200508051134.sgi or something like that. I would have liked mycomp_v1.sgi, followed by mycomp_v2.sgi etc…
Anyways, these details can be ironed out by AME, but …
This what I understood before Toxik came out:
“OK guys, Toxik is really meant as a collaboration tool, with powerful versioning and clip/setup sharing between artists. However, this is version 1, so all the cool tools you need to deliver shots aren’t there yet. Be patient, we’re discreet, we have the cool tools, they’ll make it in there soon.”
In that light, I was expecting *stellar* collaboration, versionning and media/setup sharing with bullet proof users and permissions handling (but no cool tools). After all, if the R&D didn’t go into the image processing, it must have gone into the workflow.
But instead of being blown away, what I got is the weird feeling in my stomach that the problem of working with “that guy” (you know, the guy who pollutes your framestore with hundreds of loose clips, that has entire reels of untitled clips, that overwrote one of your desktops by mistake — sorry dude! — etc…), well just got bumped to a facility wide problem! It’s “that guy” that will be the demise of Toxik unless AME makes it A LOT MORE dummy proof than it is right now.
For what it’s worth, I like Toxik’s design spec much better that FFI’s for the type of job I do daily, mainly:
RGBA architecture (hooray no double clips!)
Floating-point support (welcome to the 21 century!)
Local high-speed storage handled out of the box (no scripts to create local proxies)
Full screen from disk player (flipbooks are so 1999!)
Clips contain the setups that created them.
Windows based. (I hate windows, but I have to admit that switching to other popular apps without switching boxes is cool)
Designed with high-rez, high bit depth images in mind.
100% node based — no mismatch between desktop tools and “batch” tools.But I do wonder, by the time Toxik is ready for prime-time, where will Digital Fusion (an underestimated contender, IMHO), Shake and Nuke be?
I guess I’m eager to see how big a change will be 1.1 vs. 1.0 to see the pace of development of Toxik. If it’s fast enough, they might have a chance to get a chunk of the high-end feature-film market. If it’s too slow, Shake will stay the popular kid in school for a little while longer.
Anybody knows what made it into 1.1 that wasn’t there in 1.0?
— Xavier
nanuk wrote:What a post! Thank you Xavier.I didn´t realized danger of “that guy”. But you are right. I thought, there are the different users to handle that. Like Admin and so on. And that you can configure users and their rights. Our reseller told me, that you can even build a user, that only handles the data. Like an assistant. But I didn´t get into that deep enought i guess.
Since there are users already, and one of them is called “Administrator”, I’m sure proper permissions will make it into Toxik very soon. So my point about “that guy” will be moot soon. I was just a bit uneasy when I realized that Toxik, who prides itself with collaboration features, didn’t have permissions built-in from day 1.
Xavier
Really good points, Xavier. You mention the fact that this is a 1.0 product — I trust that many of these issues will be ironed out for the next major release whenever that is. I think that next release will be the critical one, imho. I feel as though the underlying architecture is reallly there.
(By the way, I’m planning on doing some stories/podcasts on some of this technology and what went into the development of Toxik — stay tuned).
This paradigm is really new for Autodesk and the artists. The workflow where you’re not saving setups, etc — but every change you make is automatically saved and tracked is both wonderful and frightening. You now have to save *before* working…because once you change stuff, the original is gone. So I think that the 1.0 release is great to be able to start using and providing *real* feedback (as you’ve done) to Autodesk.
Xavier wrote:11. Cache (framestore) management.
Toxik 1.0 doesn’t tell you if a clip is cached to local disk or not, nor does it let you cache a clip if it has already been imported to library without specifying “import/cache”.Actually, when you first play or access an imported clip, it is automatically cached to your local framestore — so in essence you don’t need to Import/Cache if you don’t want to. You could simply Import and have it cache when you first access the clip. Caching also seems to be handled quite effectively in its auto mode (using last access times, etc to determine whether to clear your cache). I’m not saying that manual controls would not be useful or a good addition to the software…just that the current scheme does work quite well.
Xavier wrote:Basically, after a few days of playing with Toxik, we stopped using desktops altogether. The main reason is because you cannot put any kind of container inside the desktop (the word reel comes to mind!). Even worse, you can’t put desktops inside a folder hierarchy. Also, being an inferno guy, having smoke-style desktops with loose clips everywhere makes me want to take a shower a curled up in a ball like Ace Ventura did when he realized the sargeant was packing an extra weapon.– XavierPersonally, I really like the desktop metaphor of flame and fire — even without the reels ;-). It is one thing I truly miss when working with other applications. I like being able to rearrange in an order I want (not just alpha or in folders — finals on one “reel” or “area”(fire), versions in another, sources on another, etc). But I fully agree with you that the lack of gestural editing and other features makes the desktop less useful. I’d even like the ability to zoom out on the desktop. I think/hope these things will make it into the software to bring this utility to the desktop. There was just a lot to bite off in 1.0
Xavier wrote:In that light, I was expecting *stellar* collaboration, versionning and media/setup sharing with bullet proof users and permissions handling (but no cool tools). After all, if the R&D didn’t go into the image processing, it must have gone into the workflow.You very clearly placed collaboration in reference to the overall product development, but I still think collaboration fits into the “1.0 version” explanation. I’ve got to imagine there is a ton to bite off in the initial release and difficult decisions to make regarding what to concentrate on. Right now, I’d rather see them bringing more creative tools/nodes, better workflow to the product vs. impetmenting permissions. Even more of an issue…I would much rather have wide open permissions than a hastily or abbreviated set of permissions that cause you to hit your head against a wall when working on projects.
Eventually, a well-thought out or fully robust set of permissions is critical. Right now, without a full creative toolset,I think you can get by without this, but once the tools are there — absolutely not.
I would also venture to say that you could have a permissions system which is more user-friendly than unix. This might also involve the ability to hide the process tree, hide older/test versions, lock certain nodes but not others, etc etc. And then how do you handle this permission granting?
Anyway…still a lot of questions.
John,
About permissions vs. creative tools: Right now Toxik is a shiny new toolbox, but with very little tools in there! So yes, adding creative tools should be a no-brainer. I mean no curves, regrain/degrain, limited gmasks, no decent keyers, no paint and no plug-ins. Yes, I think all of this is very important to get Toxik off the ground.
But these tools are already there in some shape or form in FFI, Fusion, Combustion, Shake or others. So why should I get Toxik then? AME says: collaboration. In my mind, permissions are as critical as paint or keyers.
About the UNIX permissions model: UNIX permissions have a bad wrap because the output of “ls -l” is definitely not user friendly, and few artists know how to use chmod and chown.
But the model is actually quite simple. Every file is owned by somebody, and every file has 3 sets of read/write permissions. One for the owner of the file, one for the people belonging to the same group of users as the owner (say, compositors, supervsiors, assistants, IO people, etc…) and one for everybody else.
Only people with “write” access can change the permissions, or change the owner of the file. You want to hide clips to other people, just turn off “read” access. I have yet to see a more elegant approach to permissions.
To “grant” permissions, simply give read/write access to the owner of the file, and read only access to everybody else, until the owner says otherwise (through a popup in the library perhaps). Of course, users belonging to the “Administrator” group act as God and can do whatever they want.
Having wide open permissions might be fun for a small team of carefully selected artists, but it becomes a huge liability with a team of 50 people with, huh, varying levels of profesionalism (let’s call it that for now). 🙂
About framestore cache management: lets agree to disagree on that one. Having to sit through slow network playback just to cache a clip is not my idea of fun. Especially coming from FFI, where everything is “cached” all the time. There should be a way to trigger caching in the background, even if the clip is already in the Library. Plus when you move a clip while it is being “import/cached” it breaks the cache. Plus when you render a composition (typically to network) it’s not cached automatically, plus there’s no way to see at a glance what clips are cached which aren’t in the library. To me, caching in Toxik 1.0 is quite crude and I feel it still needs attention devoted to it.
— Xavier
Xavier wrote:John,About permissions
About framestore cache management: lets agree to disagree on that one.
— Xavier
Actually, I think I might not have been very clear in my posts….I actually at the base level very much agree with you….you might have misunderstood as I was trying to put some of the items in perspective of the development.
Regarding caching, I was simply pointing out the feature that caching happens when you play or access a remote clip…that there are user-transparent caching operations happening at this point in time (in case you didn’t know — I didn’t know this for the longest time and it helped me a lot to understand what was happening in the app — and also helped me speed up my imports). As I pointed out, this area could definitely use a more robust and manual options for caching (like can Burn handle the various proxies you might have defined for your project?).
And I’m well familiar with unix permissions having done sysadmin work and such for a fairly large group of users — I simply feel as though there should be more of a granular level of permissions availalbe and not simply a composition permission based upon a user or group. And maybe, even, having the individual artist allowed to define certain permissions groups. For instance, having the ability to lock all nodes but one a in comp — allowing a roto artist to only be able to change a mask node and nothing else (to allow them to see an in-context view as opposed to a standalone view). Or allowing one person to only see a selected published result and another a different one, etc… I think that r-w-x applied on a smaller level would be fine. The database structure would most certainly allow this.
For me, the reason it is is acceptable at this point (especially when balancing tool development vs. infrastructure) is due to the limited toolset — you wouldn’t have to worry as much about a large group of artists screwing things up. Because in a large workgroup you’ll certainly need permissions.
And I’m curious how (not knowing much at all about Windows) Windows users mangement might effect this….
I think it’d be great to see toxik available as a standalone product. I know at the moment the collaborative side of it is what people are talking about. However assuming a decent toolset comes along (i’m sure that’s just a matter of time) Toxik would make a great windows based alterntative to shake. Toxik’s ability to play real time of hard disk + the touch UI already means it could win over shake in terms of interactivity and speed. At the moment we’re limited to using shake & combustion running on a mac as support stations to inferno. It wouldn’t be worth buying 5 licenses as we only need one or two support machines per suite 1 or 2 standalone toxik licenses could clearly be a better option to shake running on a mac in the future.
I’m afraid I’d have to agree with Guest, I know the big deal with Toxik is collaboration, however I would find it very difficult indeed to get everybody to change their way of working re databases etc. The toolset should definitely be the number one prority in my book, as it is aimed at film work, I could not seriously do a shot with it in its present form, (certainly not a complicated one) Also, the issue of buying 5 seats plus the compulsory support puts the startup price too high for a box that can’t emulate even Shake in its current form, a standalone box would be a helluva lot easier for me to get into my place and once there, people can then play with it and I think that’s how to generate the interest in it. I also agree that there are too many good tools in Inferno to not try and put them in V1, I could live without paint, but not without a decent keyer.
- You must be logged in to reply to this topic.