some Fabric updates: crowds and lighting/offline rendering

[FabricPaul]

Hi everyone - it's been a while since we shared any updates. I'm excited to tell you about two modules that we are working on:

Stage: "Stage is a scene assembly, lighting and shader authoring system. It provides a tight relationship between your offline renderer and our realtime renderer. At this time we are integrating SolidAngle’s Arnold renderer, but Stage is designed to support any offline renderer that provides an API, such as ChaosGroup’s VRay or Pixar’s Renderman."
Video: https://vimeo.com/60192623
More info: http://fabricengine.com/creation-modules/stage/

Horde: "Horde is a flexible crowd system that enables artistic control over large numbers of agents using an intuitive painting interface."
Video: https://vimeo.com/61358674
More info: http://fabricengine.com/creation-modules/horde/

Both modules are in early access programs where we are seeking commercial studios to work with us to develop them - you can PM me if this is something that applies to you.

Thanks,

Paul

[McNistor]

This is really great.
Making big progress you guys.

Message removed since I'm happy that the OP read my message.

[PeterCGS]

Horde looks amazing! Im very excited what you guys are doing, and hope to dip into creation myself this year. Great great work!

[Pooby]

This is really great.
Making big progress you guys.


I'll have to go off-topic a little here. It would have been nice to demo a scene without those trophies on the wall. Trophy hunting is a barbaric, pointless and archaic practice that serves nothing except feeding some sick individual's need to kill. It is (or should be) as appalling as killing a human being for pleasure (as opposed to self-defense or the need to eat in the case of hunting). You wouldn't show off a scene that depicts rape or murder, would you now?

I'm sure you have witnessed far more murders in CGI than you think

[FabricPaul]

If we allow the ethical considerations of some people (there are many people that enjoy trophy hunting) to come into our choice of demo content, then we'd better not depict meat, guns, women, cars, environmental destruction, violence or religious symbols either. Anyway - happy to discuss this in another thread, but I would appreciate keeping this one to the news about Stage and Horde.

Thanks for the kind words

Paul

[luceric]

[wmv][/wmv]stage demo is fine (although the URL to the web page is wrong), but the presentation shows stuff we already expect (yes, of course you can add a set and set parameters, or change a shader to red) but doesn't answer the scalability questions the way a Katana demo does. The problem isn't whether there is a deferred rendering engine, it's how the user can manage large number of materials and shaders, large number of objects, assets that will change during productions or may not have been created, etc. If you're going to a separate app for lighting, it's probably because of these reasons, otherwise the lighting will be done directly in maya.

[Letterbox]

[wmv][/wmv]stage demo is fine (although the URL to the web page is wrong), but the presentation shows stuff we already expect (yes, of course you can add a set and set parameters, or change a shader to red) but doesn't answer the scalability questions the way a Katana demo does. The problem isn't whether there is a deferred rendering engine, it's how the user can manage large number of materials and shaders, large number of objects, assets that will change during productions or may not have been created, etc. If you're going to a separate app for lighting, it's probably because of these reasons, otherwise the lighting will be done directly in maya.

You may be right in some of your comments, but Maya or no, I'm pretty sure if I can count on anyone to get it done, and get it done right, timeously, and in an efficient way for the user, it's Paul and the team.

[FabricPaul]

Hi Luc-Eric,

I think you missed the point of the demo - "Stage is at an early alpha and we are seeking studios that want to support and influence development. If you would like early access to this module, and are interested in working with us to develop it further, then blah blah blah". We're aware of the needs around scene/asset/complexity management - but we're also not convinced that we should be handling all of it ourselves, and certainly not without extensive input from customers.

I disagree that the problem isn't around the relationship and reliability of the preview renderer and the offline renderer - it's clear from the customer interest that we're getting (we released the Stage info on 3DPro and our own list a few weeks ago) that it is absolutely what they are concerned about. Asset/complexity management are also concerns for them, but it's not what is driving their interest in Stage.

Paul

p.s. what URL are you referring to?

[druitre]

Wow, just spent time watching all the content on the Fabric site. Very exciting stuff. Looks like they are doing just about everything right.

I also don't know why they felt the need to use one of Pooby's assets, the man is a sick individual, driven by a need to kill. Pity.

(sorry, couldn't resist)

[laluneverte]

the presentation shows stuff we already expect (yes, of course you can add a set and set parameters, or change a shader to red) but doesn't answer the scalability questions the way a Katana demo does. The problem isn't whether there is a deferred rendering engine, it's how the user can manage large number of materials and shaders, large number of objects, assets that will change during productions or may not have been created, etc. If you're going to a separate app for lighting, it's probably because of these reasons, otherwise the lighting will be done directly in maya.

Fair enough - the demo doesn't answer scalability questions. Of course it does demo procedural UI as well as procedural shader assignments as well as the 'recipe' idea. Given that this is still an early alpha of the product, I can assure you that our memory efficiency is very good, Maya or Softimage both use several times the memory Stage uses just for loading the assets. We don't replicate the memory for the offline renderer, but rather attach to memory from that 'world', and integrate deeply with our dependency graph. Also, since we don't manage the 'objects' such as meshes or lights as real objects, but rather elements of a long list we can deal with very complex assets. We call storing of lots of objects within a single node 'slicing'. This technique also allows us to perform parsing of data (and IO depending on serial read limited hardware) in parallel. The asset I am showing in the Stage demo loads in about 3 seconds on my machine (I7 standard workstation), which is importing from Alembic. To open the same asset as a native Softimage scene file this already takes 10 seconds, importing an Alembic file takes around 3 times longer than that. Inside Maya the asset loads from Maya binary in about 24 seconds on the same machine. Our slicing technology is also allowing us to offload and reload data efficiently, however that's not shown in the video as you noticed.

The nice thing really is that all of this performance is not because of a particularly smart way of implementing Stage, but because our framework Creation Platform has been built purely for performance. It's not Maya's or Softimage's fault they can't compete here, our framework is just very modern and is able to utilize current hardware to its full potential. If you don't believe it just get onto the beta. It is very convincing. ;)

[luceric]

thanks for your reply, it is a good and informed one.

Softimage's scalability isn't good (often disastrous), but it does share memory with mental ray with geometry callbacks. Softimage is the reason mental ray has these APIs. I think the other two do this as well now, but I'm not sure...

in the case of maya, the new OpenData asset system does support loading geometry directly to the GPU without actually loading a copy in ram, and those assets can be directly stored in alembic. You can optionally define an asset with alternate representations for GPU and render archives format (ex: rib). no need for any maya scene files or maya DG geometry to back them up.

but my comment was more about this "recipe" idea a la katana. this demo doesn't really show it. it loads an entire scene and assigns things traditionally. And what happens with the UI if your scene is non trivial and have hundreds of materials. I suspect the low level procedural tree of fabric could make complexity go through the roof (size of the node graph; writing your own rules, shaders, etc)

How are the shaders actually bound to geometry. In katana you bind them by name matching, regular expression, bounding boxes, other rules. The scene isn't actually loaded until you expliticitly ask to view something in the viewport, and even then it starts only with the bounding box. The final shader assignment with actually happen in the geometry shader on the render farm, one whatever the scene ends up being at that point. katana integrates with Arnold and has real time shader preview as well.

[laluneverte]

but my comment was more about this "recipe" idea a la katana. this demo doesn't really show it. it loads an entire scene and assigns things traditionally. And what happens with the UI if your scene is non trivial and have hundreds of materials. I suspect the low level procedural tree of fabric could make complexity go through the roof.

Our low level graph doesn't change at all, there's a very limited number of nodes used. The UI shows graphs for shaders, but we never store any graph really. We use a list with list item to list item connections. This allows to scale very well. Essentially for shader editing the approach is that the UI presents a familiar approach, while the processing and management is done in a different way. I have tested the system with 25k materials and it performs at the same speed as with 5 materials. Like I said, the idea here is that we don't treat shaders as a graph. The user still has access to graph based editing though.

How are the shaders actually bound to geometry. In katana you bind them by name matching, regular expression, other rules. The scene isn't actually loaded until you expliticitly ask to view something in the viewport, and even then it starts only with the bounding box. The final shader assignment with actually happen in the geometry shader on the render farm, one whatever the scene ends up being at that point. katana integrates with Arnold and has real time shader preview as well.

We don't do it in the demo, but since our geometry refers to a 'location', which can be a single file or just a part of the file we can reserve place for thousands of geometries without actually loading them, and only store representative geometry such as a bounding box, for example. Then we can load the geometry if requested, either by the offline renderer or by the user. Again, this doesn't add any complexity to the scene since it just replaces a geometry slice. this also allows us to perform memory management, and offload unrequired data again and therefore manage scenes which are larger than the available system memory. Also we bind shaders to geometries or facesets simply by referencing indices. Our geometry instance combines an index of a shader, an index of a geometry and an index of a transform out of the list containers to show it in the realtime renderer, or show it in the offline renderer. The shader assignments are done using regex matching. In the demo I use patterns matching a single object, a group of objects or a hierarchical layer. In the future we will extend this to support more complex queries, such as meta data flags or volume logic (aka all tree assets flagged as oaks in the volume of forestA).

[nuverian]

I've seen these posts for fabric modules from time to time and..they are really great stuff. But one question remains strong.
Will these modules be available for independant license at some point, or these modules will follow the Solid Angle paradigm?

[FabricPaul]

We're considering making some modules into standalone products, but I can't give you a timeline for this. Stage is a logical candidate for a standalone product, but we want to get it right as a module first. When providing something as a product (vs an extension to a framework) there is a higher expectation on what it can do out of the box - particularly for workflow and UI. The best way for us to get that right is to build it with some customers first.

The core framework is maturing now, and we will release it as a v1.0 this year - it's beta status is really reflective of the need for improved documentation, tutorials etc that we are going to take on soon. Flora is in beta and will move to a 1.0 this year as well (as a module).

Does that answer your question?

[cheeseburger]

Hi FabricPaul,
Just wanted to say ... Awsesome !
I know some things aren't finished, but you guys give me great confidence that all of the crumples will be ironed out.
Finaly some really fast systems to manage some really important jobs.

Well done Guys !

[FabricPaul]

Thanks for the kind words - both products are at an early stage, so watch this space