hey andy this is the first step in creating something like the 'stage' demo from fabric engine...
https://github.com/caron/FabricArnold i am excited about this and would love to collaborate with others in making this a possibility. i agree and understand all you have outlined below. On Tue, Mar 4, 2014 at 10:49 AM, Andy Jones <andy.jo...@gmail.com> wrote: > Since the rumor/news broke (and to a certain extent, before that as > well), I've been putting some serious thought into plans for the future, > and I want to share a few thoughts, as I think this storm will be best > weathered together. Every studio is different, of course, so what works > for me right now may not work for everyone. To be clear, these are my own > speculations at this time, and NOT any kind of formal plan for my > employer. The community discussion will have a big impact on our own > internal discussions, though, so I think it is important to be part of the > dialog. > > As we all plow forward, the hope is that we will leave a trail that makes > it easier for anyone who eventually finds themselves on the same pathway. > > > -- SCENE ASSEMBLY > > For us, the biggest hole left by Softimage's demise will be lighting and > scene assembly. This, and FX, are the main areas where we currently > utilize Softimage, particularly in our NY office, but in LA as well. > > I'm going to run through some of the options I've looked at, leading up to > what I think will be a good solution at the bottom. Process of elimination > style. > > > - KATANA > > I've spent some (non-hands-on) time looking at Katana, and while it is a > solid, powerful, scaleable solution to scene assembly, I feel it is > actually too open-ended at the surface to address our needs. I'm also not > satisfied with how it presents shader networks to the end user. I > appreciate the flexibility of a nodal system at the core of an application, > but what I actually want is a simplified UI that exposes all of that > procedural power in a direct and consistent way. I could see where Katana > would work well for larger scale projects, but I have major concerns about > how it would fare in small 1-10 man operations for commercials. > > A key requirement for me in a scene aggregator is also the ability to have > an ICE-like procedural layer passing data directly to the renderer without > caching to disk. Caching is great for things with a certain data to > computational complexity ratio, but in so many cases, you're better off > either with a procedural callback, or data in memory. Simple grass > systems, feathers, hair, fur, rocks, leaves, fuzz, etc. Largely with the > help of ICE, we have graduated to an era where surfaces that need it can > have more than just high res textures and displacement. The issues above > are likely fixable in Katana, but getting a procedural FX framework is far > less likely to happen in the timeframe we'd need. > > For us, Katana being Linux only, also happens to be an issue (though one > we could work around with enough motivation). > > > - XSI > > Still the best tool for scene assembly at the moment, in my opinion. It's > important to remember that the software isn't going to stop functioning > right away. This means that we can make a decision based on 2-3 years of > lead-up time, vs making the decision based only on what is available today. > > - FABRIC ENGINE > > This takes me to Fabric Engine, which I feel is the right answer going > forward. > > The one negative thing about Fabric Engine is just that it's still really > early days. None of the software I would like to use built on Fabric > Engine actually exists yet, so there's a development cost that will be > required in order to make it happen. However, this can also be a strength, > as there's an opportunity to shape the final product in ways that are > impossible with some of the more long-established players. Even Softimage > had many things that I would have done differently in hindsight. > Streamlined offloading, lighter and more portable shaders/shader > assignments, per-renderer materials, multiple partition sets, rule-based > partition membership, to name a few. > > The timing for making a new scene assembly tool is also pretty good right > now, as USD is on the near horizon, and is aiming to provide a standardized > data format for this specific task. > > I'm also very encouraged by what we saw with the Stage demo earlier. > While it is not currently available for testing, the ease with which the > Fabric guys put that together speaks to the quality of the framework > they're building, and really shows that it should be possible to build a > standardized scene assembly tool fairly easily. > > Last, but certainly not least, any scene assembly tool built on top of > Fabric will naturally have native access to all the proceduralism of Fabric > Engine. Although with splice, you don't specifically "need" it to be > native, it does mean that there's one less SDK getting in the way of > getting raw Fabric Engine power. ALSO, the fact that Splice already exists > for Maya, Soft, and soon Houdini, means that we can start building our > procedural tools now, and benefiting from them before we even finish moving > to a Fabric scene assembler. In the meantime, both our Maya-centric LA > office and our Soft-centric NY office can continue on their existing > lighting pipelines without losing nearly as much development time as we > would if we had to re-write all of our tools when we made the change. > > >
