No ICE for foreseeable future except in Houdini and...

[Pooby]

I love taking risks. Its fundimental to being me.

[McNistor]

Hey Paul, it is not news for me that you're a big fan of FE since it's the closest thing to ICE as of now, but I'm curios about what 3d app will you choose to have your FE tools plugged into.
I know you'll stay with Soft for now, but when that time comes, you know... where will you go, Maya, Houdini or other? Perhaps you didn't even thought about it yet, or thought about it but didn't choose yet? Any inclinations?

[Pooby]

Whilst using Softimage for the next 2 or 3 years at least, I will assess the situation during which I will develop in Fabric to keep options open.
I do want to learn Houdini too, at least for what it brings in FX terms.

Who knows what might happen? Maybe Autdesk's controlling plans win out and Houdini users move over to Bifrost. The Foundry give up on Modo. Fabric can't compete with Bifrost and go belly up etc.

I like to think that instead. There will continue to be vibrant competitors trying to provide better, faster ways of doing things for different types of artists.
At the moment there is little apart from Sofimage for the Artist /Tool maker like me. Houdini is closest right now, but I just feel that Fabric is more aligned to what I will need in general terms.

As to what package stuff the gets rendered in, I'm open.. At the end of the day for me, Arnold in any package is just the same. Its the tools to make stuff that I'm more interested in. Maybe Fabric will have a scene layout environment for the tools to meet by then.

I have a tendency also to go against the flow, partly to keep things lively and interesting and discover new stuff that others aren't doing. I can't stomach the thought of plodding in line with everyone else using the same tools and workflows. Thats not what I come into work for every day.

[Bullit]

Yes i 'll look to Fabric but i am curious about what iamVFX thinks about a nodal interface since i agree that locations add to confusion unnecessarily. I mean if someone wants locations just make an attribute. For example an attribute should be possible to be a compound of attributes.

I think a nodal environment the first thing to setup is the language to define the parts of it.

[Pooby]

Locations are just ways of reading data from one mesh or particle to another. There is nothing particularly strange about them.
You raycast or get closest location etc.. then read whatever attribute you want at that point. Thats all they are. The interesting thing about them in ICE is that they persist.

[iamVFX]

You raycast or get closest location etc.. then read whatever attribute you want at that point. Thats all they are.

You're not reading those attributes, you're computing them. It's a big difference when we're talking about big amount of data. You may wonder how it knows where closest location of a point is, an the truth is: it doesn't, so it should find it first. How to find it is implementation-dependant - it may use kd-tree, it may use raycasting, you don't know and have no control over it. Even if you found closest point cheaply enough - say we got location as a point between three vertices - if you want get normal of that point it will fire up another function to find what normal closest point should have.

Again, you might think it's fast enough so you can don't bother, and sometimes it is with modern hardware that Fabric utilize, but there always be a limit. Specifying it as an attribute is wrong because it's a series of computationally-heavy operations that one may use inappropriately. I heard a story from a Google employe that once in a while their servers may down because someone could call a function in their code to get an "attribute" (like closest location), but what really happens underneath is a call of sort function over whole user database.

i am curious about what iamVFX thinks about a nodal interface

I wrote a post in my blog two years ago, I still think it is the way people would interact with computers more intuitively if node environment is implemented properly... I always think "how would I design such a framework with minimum amount of code to fight overcomplexity and maximum amount of possibilities to replace text-based programming languages". Look at C, such a simple and small one, but what it generated! Imagine C language in a form of nodes... I would program on that!

[Pooby]

Ok, you obviously know a lot more about this than me. I was just explaining how locations work from a user perspective when using ICE.

[McNistor]

Thanks Paul for the quick reply.

[TwinSnakes007]

You're not reading those attributes, you're computing them.

You hit the nail on the head with "you're", because you tell Fabric what it needs to do. Fabric or really KL, is just simple data types (bool, string, integer, float), everything is built up from that. Even the tools (which are just composite KL types with methods) that FabricEngine comes bundled with, such as their PolygonMesh type, is just a collection of KL code that operates on those simple datatypes, and yes PolygonMesh has a concept of "location".

How would I design such a framework with minimum amount of code to fight overcomplexity

KL and Fabric Engine is that framework embodied. You use a scripting-like language (KL) and get very high performance code that is both portable and scalable and compares favorably against C++.

Trust me, you dont want to miss this boat. Everyone is talking about Nodal GUI, Nodal GUI is childs play to these guys. What would you say to being able to run your KL code on the GPU!? Yeah, that's right, ICE style computation on the GPU! How long would that have taken Autodesk to pull off?

Future is bright with KL/FabricEngine...way too bright.

[iamVFX]

You're not reading those attributes, you're computing them.

You hit the nail on the head with "you're", because you tell Fabric what it needs to do.

Sorry, it might been my bad use of english language. I was talking to "you" as a user. I do not say what to do to Fabric guys, they know what they should or shouldn't do without someone's opinion. It is my personal opinion that interpreting locations as accessible attributes is wrong, read above why.

What would you say to being able to run your KL code on the GPU!?

I would say that you won't be able to run KL code on standard PCI bus dependant GPUs, afaik they're official partners of HSA foundation, their existing code can be able to run on APUs only, which means (in terms of use of graphics processor units) KL is vendor-locked for the time being on AMD hardware.

[TwinSnakes007]

What would you say to being able to run your KL code on the GPU!?

I would say that you won't be able to run KL code on standard PCI bus dependant GPUs, afaik they're official partners of HSA foundation, their existing code can be able to run on APUs only, which means (in terms of use of graphics processor units) KL is vendor-locked for the time being on AMD hardware.

KL is JIT compiled by LLVM

LLVM is open source:
"Jan 6, 2014: LLVM 3.4 is now available for download! LLVM is publicly available under an open source License."

...and most definitely runs on nVidia hardware thru the NVCC:
CUDA LLVM Compiler

[iamVFX]

So what? Three unrelated facts you point on should give a clue that KL can be compiled for GPU? In current state - it can not. Ask Fabric Engine representative for more detailed answer why, if you don't belive me.

[Bullit]

Isn't Locations a sort of compound of attributes?

[iamVFX]

Isn't Locations a sort of compound of attributes?

Implementation-dependant.

[TwinSnakes007]

So what? Three unrelated facts you point on should give a clue that KL can be compiled for GPU? In current state - it can not.

You may have more information than I have, but I'm simply repeating what they've already said publicly. They may be hosting a GTC session explaining how they couldnt get it to work, that's a possibility.

at GTC (NVidia's conference in a few weeks) we will be showing our KL language executing on CUDA6 without making any changes to the KL code. So we'll be showing a KL deformer running in Maya via Fabric Splice, running at some crazy speed.

Nvidia GTC Session Schedule S4657 - Porting Fabric Engine to NVIDIA Unified Memory: A Case Study

[FabricPaul]

We have KL executing on CUDA6 capable NVidia GPUs - which is most of them (nm_30 and later). Peter will be showing it next week at GTC and we will release some videos soon. It will be released as part of Fabric in the next couple of months.

Some numbers:
The Mandelbrot set Scene Graph app goes from 2.1fps to 23fps when using a K5000 for GPU compute.

That's the same KL code running highly-optimized on all CPU cores, and then running on the NVidia GPU.
**edit: note that this is an optimal case for compute. Many scenarios will not see this kind of acceleration. However, the fact is that KL gets this for free - you don't have to code specifically for CUDA, you can just test your KL and see if it's faster.

As for visual programming - we have already shown the scenegraph 2.0 video that covers the new DFG and discusses other plans. We'll show more when the time comes. Watch this space.

Thanks,

Paul