Trying to get DRAFT out the door. we’ve hired someone else on Draft who is doing unit-tests and testing. Draft is the reverse of our other products, and it’s making it hard to finalize, to be frank. reminds me we have to focus on SPF [stability, performance, features - in that order] - i think that draft started on Features…everyone wanted something different, and its’ a maze of features and untested edge cases. thus, unit-tests.
speaking of DRAFT: damn! codecs! plan is 49$ or so for a AVID DNXHD codec pack. still no word on ProRes. H264 IS licensed and included iwht free-draft. but we added basic MXF support and will have more on that post 1.0 release
speaking of draft part 2- we have a secret project on the go - it will probably make you frustrated but i couldnt turn down the opportunity. i’ll share that with you if it actually works out - will know in a few weeks
krakatoa maya - we keep exposing new features [particle multiplication, some channel mods] because of hte lack of particle generation in maya. plan is to get it out to RC1 end of september - will not include magmaflow YET. anyway, krakatoa keeps getting better or more featured/fleshed out as we do more tools. it’s an interesting side effect.
Magmaflow is getting features due, in part, to Ember. Loops have showed up in an internal Genome build, and more to come. we plan on continuing to advance our magmaflow toolset…
Ember - focusing on specific aspects of ember for the next release. specifically, particle reflow
Deadline 6- should be in beta mid to end of september. target release is fall/winter so we can move onto 6.1 for Spring
once we get Krakatatoa MY and DRAFT out - we finally can get back onto our FROST roadmap among other things. there are a number of things that have been done here and there that need to get pulled back into Frost2. so any wishlist items should start coming in so we can finalise our roadmap.
we will have some resources this fall and i’m not 100% sure what we are going to do with them…more genome love? openexr support for krakatoa? prt 2.0? new product?
That’s actually exciting, and $49 is totally fine. I didn’t know DNXHD MXF would be there. We’d love to be able to convert stuff and dump it on the Avid directly for dailies. Is .mov DNxHD supported? What about x264? Don’t know where you’re getting your h264 from, but we’ve seen suboptimal results compared to x264 out of MainConcept, but there could be many factors. It’s a pain to test lossy codecs.
Frost2? Directly meshing Ember levelsets would be cool. Oh, as would passing the levelset TO Ember without meshing at all? Ellipsoidal splatting would be nice, too. View-dependent meshing would be nice too, but you might end up needing some sort of Magmaflow setup for all the crazy ideas that would entail.
PRT 2.0 would be high on our list, obviously, as I still think it’s something that gets more valuable the more KrakatoaXX permutations there are. We are hitting I/O bottlenecks that multiple streams might solve, but there’s other things we’d like to see in the spec that seem trivial but useful to us, like storing the min/max/mean values.
Guess I could push for XMesh 2.0 too, under the same rationale. Adding things like a “transform” channel would be very handy, and such changes become more valuable the more XMesh supporting applications there are.
I think OpenEXR 2.0 (for deep images/shadows) output makes the most sense for KrakatoaSR for now. Iron it out there first, as you have done with DTEX? Unless, like the current 3ds max output of the shadows (or even PRT’s), you’re bypassing the normal bitmap I/O?
.mov DNxHD is supported. we are using x264, but yes - i feel like we are struggling a little there. i think we need some good source material, good examples of properly working quicktimes from something like main concept so we can nail it. apparently there are a slew of settings to optimise the streams and deltas or somesuch. i’m not really involved directly, but plan on paying more attention soon.
if you want to help us out there, would be nice ;-0
Sorry, I phrased it wrong. The h264’s out of MainConcept’s standalone compressor were looking lousy compared to the results we were getting from x264.exe using the same bitrate. In some cases, a MC h.264 mp4 at 1200kb/s would look worse (to my personal human visual system) than an x264 mp4 at 1000kb/s. It’s that extreme. There are tons of settings though, and since it’s designed to balance ease of decode along with HVS perception of quality, it’s hard to know how anything is actually affecting it.
We pay Akamai by the TB/month, so shaving off 10-25% off our bitrates without losing quality is a big deal cost wise, so we’ve been trying to be picky about the settings (though it’s only been an issue on my plate recently). I’m not an expert yet, but it’s something we’re very interested in.
Oh I see what you mean. I’ll see what I can come up with for comparison. But if Draft supports 2 and 3 pass encoding, and all of the codec settings of x264, then the real issue will just be making some viable presets or other guidelines, right? For the most part on our side we tend to crank everything to 11, or as they say in x264-speak, “placebo”. It’s not like we’re encoding a 90 minute clip, and heck, the machines doing the encoding are pretty fast anyway.
As far as Draft is concerned, playback performance of H264 Quicktimes is #1 priority for us.
Followed by ProRes support. I’m concerned though that Apple is deliberately suppressing ProRes on Windows and that even if you can negotiate a license they’ll forbid you from releasing it for Windows/Linux which is half the appeal. Any plans to perhaps just offer some direct hooks to an ImageMagik library and leave it up to the user to ‘decide’ which imagemagik features to use?
Wooohoo, in Build 14 performance is slick. And encoding speed is really good. I would say it’s ready to roll now for us. Time to start slipping it into our pipeline everywhere.