Fabric 1.12: GPU Compute, Splice Rendering, Characters

[Bullit]

and that's the also vague category of "the Technical Artist", someone who isn't primarily technical in nature, but is willing to get his/her hands dirty ("icy"?) when the need arrives.

That is precisely what should be, and i didn't say for lack of words.

[FXDude]

Also, needless to say that developers mostly or almost exclusively working on code, can just as much qualify as 'artists in their respective fields' :]

[Pooby]

Also, needless to say that developers mostly or almost exclusively working on code, can just as much qualify as 'artists in their respective fields' :]

Agree. At the end of the day, its just people doing stuff. Labels aren't helpful.

What irks me is the 'I'm an artist therefore I shouldnt have to do anything complicated' attitude.

[Hirazi Blue]

What irks me is the 'I'm an artist therefore I shouldnt have to do anything complicated' attitude.

I think the main problem isn't the "I shouldn't" part at all, the main problem still appears to be to strongly held belief, "I'm an artist, I'm incapable of doing anything technical". Coding (and such) and especially the prospect of having to learn it, can be scary. And that's too easily overlooked by those who feel at ease with it.
;)

[Bullit]

People are different. Some need a strong sensory(mostly visual) feedback - or more correctly a short lag in that feedback, others don't, that is, i think one difference between the "artist" and the "technical". Another is that typrewriting code is physically different than moving things around: typing number and characters vs pushing, moving, cutting.

So no i don't think it is an artificial difference.

[iamVFX]

People are different. Some need a strong sensory(mostly visual) feedback - or more correctly a short lag in that feedback, others don't

[quote="Alan Kay, "Doing With Images Makes Symbols"."]Jacques Hadamard, the famous French mathematician, in the late stages of his life, decided to poll his 99 buddies, who made up together the 100 great mathematicians and physicists on the earth, and he asked them, "How do you do your thing?" They were all personal friends of his, so they wrote back depositions. Only a few, out of the hundred, claimed to use mathematical symbology at all. Quite a surprise. All of them said they did it mostly in imagery or figurative terms. An amazing 30% or so, including Einstein, were down here in the mudpies [doing]. Einstein's deposition said, "I have sensations of a kinesthetic or muscular type." Einstein could feel the abstract spaces he was dealing with, in the muscles of his arms and his fingers...

The sad part of [the doing -> images -> symbols] diagram is that every child in the United States is taught math and physics through this [symbolic] channel. The channel that almost no adult creative mathematician or physicist uses to do it.[/quote]

[Bullit]

If someone is conceptualizing it is evident that it must come first than any notation.

[McNistor]

Not really keen on disagreeing with most (if not all) around here, but I think "I can be both an artist and a TD/coder" is really a false (and also a bit naive in its hopefulness) belief.
Sure, we can play with meanings and nuances all we want, but at the end of the day if one wants to be a very good TD/coder or an artist (which makes them competitive) then you can either be an artist or a coder, but not both. Some people can be neither, it's true even though it's kind of a tabu nowadays to say such a thing.
I don't think you live enough in order to study and hone your skills to a such degree that you'll do both very successfully - you either need two lives or two brains.

[FXDude]

I don't think you live enough in order to study and hone your skills to a such degree that you'll do both very successfully - you either need two lives or two brains.

Or two halves ;]

They may be more rare, but there are certainly a good few with great (trained) eyes *and* great (trained) analytical/technical skills,
particularly in our field, and most of anyone doing 3d needs to develop at least somewhat both (without necessarily code) even if mostly one.

But while becoming very good on both.. ( or having as many people who's job is mostly typing instructions on their keyboards as there are people who's job is mostly pushing pixels/vertices with their mice/wacom pens) ..can really accomplish wonders ,
the only thing SI users may know better is how complicated things don't have to be. (including very technical SI users)

[FabricPaul]

Hi guys - I have been reading the thread, just didn't manage to reply yet.

Fabric 1.x - targeted at R&D and TDs. 1.x is a platform for building tools, the goal has been to provide the performance capabilities of C++ and GPU compute in a dynamic environment that is more like Python. Then we've been building systems on top of that core performance to make customization, extension and integration as easy as possible. Those systems are starting to mature now, allowing us to start thinking about other areas.

Fabric 2.x - on top of the R&D/TD crowd, this product cycle will be moving towards the 'technical artist' zone with the visual programming system and the development of deeper functionality. However, it's still a platform - Fabric is a tool for building tools, not a complete DCC application. If you can use ICE, then you'll be able to use our visual programming system.

The key point of a platform is that other people can use it - including 3rd party developers. Our hope/expectation is that these guys will start building standalone applications with Fabric that will be complete artist tools. The fact is that we're a small company and for us to try and build a competitor to Maya/Max/Softimage is crazy - we're talking decades of development on workflow and design, along with $millions in costs to do that work. We're talking to a few 3rd party devs that are keen to work with us, and we should see something from them later in the year.

DCCs like Maya are the backbone of pipelines that have years of custom development around them - even with an outright replacement that is demonstrably better in some important regard, you will struggle to displace an incumbent. It's not likely to succeed, and tbh it's not something studios are interested in.

Our approach is to integrate with these existing pipelines - either through the Splice 'universal plugin' approach, or through the standalone framework being used to build niche applications (asset viewers, virtual production tools etc) that use industry standards like Alembic or FBX. Over time these tools will become richer and broader in their possibilities, and we'll integrate into more DCCs. This is what studios are most interested in, and it's what we believe is the correct path.

TL;DR - Fabric is targeted at people that build tools. Fabric 2.0 will offer a visual programming approach for doing this, but it's still a platform, not a complete DCC. We're working with 3rd party developers that will be making tools for artists.

[Manticor]

Any idea how long the splice max version is going to be?
Were still on XSI 7 here so cant use it but were up to date with 3DS Max

[FabricPaul]

Hi there - we're giving an alpha build to some max customers later this month (hopefully) and we'll be showing it at our user group at Sigg.

[Manticor]

Great to hear .Looking forward to seeing a preview of it

[NNois]

@paul
Hi, this is great news, have you any estimate of how long it will take to get a splice for the other platforms especially for houdini ?

[FabricPaul]

We will start on Splice for Houdini once we release FE2.0 (Autumn 2014), and I'd expect the work to take 1-2 months - our goal is to have this available by the end of the year, but without attempting to do the work we can't be sure how long it will take. Ideally, we will do this work with a customer so that we tick the right boxes for Houdini users.

In terms of other platforms, I know one developer that is working on Splice for C4D, and he will make that work available if it all goes well - in which case we'd probably take it on and support it. We're thinking about Modo but it's a resource issue - I'm going to try and meet up with Brad at Sigg and see what can be done. I wouldn't expect anything until after the Houdini version is available though.

[MauricioPC]

We will start on Splice for Houdini once we release FE2.0 (Autumn 2014), and I'd expect the work to take 1-2 months - our goal is to have this available by the end of the year, but without attempting to do the work we can't be sure how long it will take. Ideally, we will do this work with a customer so that we tick the right boxes for Houdini users.

In terms of other platforms, I know one developer that is working on Splice for C4D, and he will make that work available if it all goes well - in which case we'd probably take it on and support it. We're thinking about Modo but it's a resource issue - I'm going to try and meet up with Brad at Sigg and see what can be done. I wouldn't expect anything until after the Houdini version is available though.

Hey Paul, I've seen some cool videos of FE implementation in 3ds Max (viewport renderer). Given that people here often complain about 3ds Max being old code and stuff, how "easy" it is to implement FE with Max? I've heard Max SDK is very open and documented.

I ask you because for the studios, it's easy to understand why a robust platform for creation of tools is so important, but I guess that for the one-man army, FE can also be very important as it'll help improve areas of the software that may be lacking (in Max I can say referencing, animation).