When will Octane be ready for VFX work?

[riggles]

I was wondering what the road map looks like for giving Octane the flexibility needed for use in VFX type work?

I had a job over the weekend (long weekend) where I was hired to create an environment for use in a car commercial pitch. The scene was a snowy winter forest and the vehicle drives along a winding road and then suddenly brakes to avoid a collision. Full CG, and there were 5 different camera angles because this was a run-and-gun job and they'd figure out later what they wanted to use. I had Thurs night to Sun to get something worthy of presenting the concept to their client.

I really wanted to use Octane because I could preview faster than MODO, plus I like the simplified shader setup. However, I quickly ran into numerous road blocks and limitations. Such as:

- No multi-UV support. Couldn't paint different road/slush detail maps.
- No UV offsets for tiled hi-res texture maps. Ditto.
- No procedural displacement.
- No displacement shader blending.
- No displacement and bump together.
- Limited gradient support. I needed to use the angle from world up-vector to face normal to drive a white diffuse color overlay to quickly put white on the top of distance surfaces. No such gradient drivers exist.
- No proxies support. I needed to work on assets while the animator was doing his car/camera rig/animation. Plus it was a forest with a number of different trees and I needed to keep the scene as light as possible.
- No particles. Wanted to preview with falling snow.
- No environment fog. It's a snowy day, after all. There's a volumetric fog hack for Octane, but who wants to animate that hack for 5 different moving cameras?
- No volumes. I needed blobby surfaces with displacement to quickly get snow clumps on things that were closer to camera in the lock-off shot.

So I used MODO's renderer. It had almost everything I needed (proxies and replicators break render blobs, sadly). I didn't include render passes in my list because OTOY said it's coming eventually, not that it helped me over the weekend.

I'm not some big film VFX artist, but I can imagine just from this one brief project alone that any number of the things above and more are needed in many productions. Lack of support would and, I assume already has, removed Octane from the rendering equation for many studios.

It's too bad because I really wanted to use Octane. I want to use it on everything. But for the type of work I just had to do, it's clearly not there yet. I didn't create this post to start a belly-aching thread of all the things Octane doesn't do. It's just a realistic appraisal of my recent experience. So, back to my post title question. What's the plan for getting Octane ready for the versatility and feature set needed in VFX work?

[Goldorak]

I think the short answer is that it's all more or less on the roadmap.

If you look at the delta in features between 1.5 and 2.0, it will give you an sense of the pace of development between versions. We're not slowing down.

[riggles]

Thanks for replying Goldorak.

I wasn't hoping to get a confidential powerpoint slide showing the whole game plan, obviously. My post title was just the question going thru my head verbatim. And yes, the step from 1.5 to 2.0 was quite a big one, and the rest of the 2.x features announced will be very welcome as well.

I'm glad you mentioned that you're not slowing down. Over the last number of months OTOY has announced development of a number of things: partnership w/ Mozilla and Autodesk using Amazon EC2, ORBX app streaming on any device, now x.io, a cloud rendering service, holographic rendering—all things currently in development—not to mention continued Brigade development, plugins for basically every DCC app with the help of 3rd party developers, and of course, all the 2.0/2.x features in Octane. Phew~ that's a lot! And after the SIGGRAPH announcements it made me think that you all are a very smart and very talented team who just might be getting pulled in too many directions at once.

I could be totally off, but that's the impression I got. So after this past weekend, I started to wonder where this is all going and when.

[As a side note: I remember mentioning something about developing a MotionBuilder plugin after GTC this year, and I was glad to see something announced last week. Very smart move, Octane is already a great fit for previz in my opinion.]

[Goldorak]

Thanks for replying Goldorak.

I wasn't hoping to get a confidential powerpoint slide showing the whole game plan, obviously. My post title was just the question going thru my head verbatim. And yes, the step from 1.5 to 2.0 was quite a big one, and the rest of the 2.x features announced will be very welcome as well.

I'm glad you mentioned that you're not slowing down. Over the last number of months OTOY has announced development of a number of things: partnership w/ Mozilla and Autodesk using Amazon EC2, ORBX app streaming on any device, now x.io, a cloud rendering service, holographic rendering—all things currently in development—not to mention continued Brigade development, plugins for basically every DCC app with the help of 3rd party developers, and of course, all the 2.0/2.x features in Octane. Phew~ that's a lot! And after the SIGGRAPH announcements it made me think that you all are a very smart and very talented team who just might be getting pulled in too many directions at once.

I could be totally off, but that's the impression I got. So after this past weekend, I started to wonder where this is all going and when.

[As a side note: I remember mentioning something about developing a MotionBuilder plugin after GTC this year, and I was glad to see something announced last week. Very smart move, Octane is already a great fit for previz in my opinion.]

There are a number of different development teams within the company working in parallel to OR. This includes: LightStage, Brigade, x.io (which is led by the very talented team who joined OTOY in January) and the ORBX codec team. We are all working on different aspects of the rendering and cloud pipeline. The team in Auckland is fully dedicated to Octane Render. None of the other OTOY efforts have ever slowed OR development.

You will see synergy between these different teams, starting with x.io support for Octane Render CE as it's first app, and dual OR/Brigade plug-ins down the line (for UE4 and MB first in all likelihood). The x.io billing and deployment model is a big advancement over what we launched on AWS last year - per minute vs. per hour, version control, multi-region support, app sandboxing, file storage from Dropbox, GDrive, etc.

[riggles]

Thanks for expounding on the team breakdown and what's coming next with OTOY. I'm glad the OR team is just the OR team. I'll just have to wait and see where the roadmap for Octane leads.

[Karba]

- No multi-UV support. Couldn't paint different road/slush detail maps.
- No UV offsets for tiled hi-res texture maps. Ditto.
- No procedural displacement.
- No displacement shader blending.
- No displacement and bump together.
- Limited gradient support. I needed to use the angle from world up-vector to face normal to drive a white diffuse color overlay to quickly put white on the top of distance surfaces. No such gradient drivers exist.
- No proxies support. I needed to work on assets while the animator was doing his car/camera rig/animation. Plus it was a forest with a number of different trees and I needed to keep the scene as light as possible.
- No particles. Wanted to preview with falling snow.
- No environment fog. It's a snowy day, after all. There's a volumetric fog hack for Octane, but who wants to animate that hack for 5 different moving cameras?
- No volumes. I needed blobby surfaces with displacement to quickly get snow clumps on things that were closer to camera in the lock-off shot.

- No multi-UV support. Couldn't paint different road/slush detail maps.
Almost nobody wants multi-UV support. That is what the vote shows. http://render.otoy.com/forum/viewtopic.php?f=9&t=37045 But we will add it at some point.

- No UV offsets for tiled hi-res texture maps. Ditto.
What do you mean? There is a transformation node with offset settings

- No procedural displacement.
- No displacement shader blending.
We did the best what we could. CUDA programming doesn't allow much.

- No displacement and bump together.
What is the point of using bump with displacement? displacement can replace bump completely.

- Limited gradient support. I needed to use the angle from world up-vector to face normal to drive a white diffuse color overlay to quickly put white on the top of distance surfaces. No such gradient drivers exist.
We will add more procedural textures in the future.

- No proxies support. I needed to work on assets while the animator was doing his car/camera rig/animation. Plus it was a forest with a number of different trees and I needed to keep the scene as light as possible.
I will add it soon.

- No particles. Wanted to preview with falling snow.
I will add it, maybe not very soon, but still soon.

- No environment fog. It's a snowy day, after all. There's a volumetric fog hack for Octane, but who wants to animate that hack for 5 different moving cameras?
Can't you link a small sphere to the camera in 3dsmax? No point to animate it.

- No volumes. I needed blobby surfaces with displacement to quickly get snow clumps on things that were closer to camera in the lock-off shot.
The same as particles.

[gordonrobb]

- No multi-UV support. Couldn't paint different road/slush detail maps.
Almost nobody wants multi-UV support. That is what the vote shows. http://render.otoy.com/forum/viewtopic.php?f=9&t=37045 But we will add it at some point.

The vote shows that most people have 3 things they want more, not that they don't want it.

- No procedural displacement.
- No displacement shader blending.
We did the best what we could. CUDA programming doesn't allow much.

Some of the plugins have solutions for this. Isn't there way to do the same in Standalone?

- No displacement and bump together.
What is the point of using bump with displacement? displacement can replace bump completely.

The point is that if you have a displacement map that doesn;t have the finest details, you need to add them with a bump. Perhaps if we could blend the bump map (either procedural or texture) with the displacement map, there would be no reason for both. But until then, there is definitely a need for both. Almost all existing assets from Zbrush for example have displacement that goes to one level of detial, with the finer details added as either normal or bump. At the moment, these cannot be used in standalone.

- Limited gradient support. I needed to use the angle from world up-vector to face normal to drive a white diffuse color overlay to quickly put white on the top of distance surfaces. No such gradient drivers exist.
We will add more procedural textures in the future.

Gradient that works like this is key. To be able to base it on things like slope, bump/displacement height, angle of incidence is one of the only things I haven't managed to do texture wise. And it's something that's key.

[Karba]

Some of the plugins have solutions for this. Isn't there way to do the same in Standalone?

do you mean octane plugins?

if yes, they bake procedural texture to regular image and use it, so no way to use procedural texture in 3d space.
and of course they can't blend displacement from 2 materials.

[itsallgoode9]

No displacement and bump together.
What is the point of using bump with displacement? displacement can replace bump completely.

using a bump with a displacement, you can tile things at different rates, which is really helpful. and gives you alot more control.

as an example, if i'm working on a high res bottle label, I would have a displacment to create any embossing in the text, while I would tile a bump map image to create the texture of the paper. I can adjust how fine or course the texture of the paper is interactively rather than adjusting in large displacement in photoshop, saving, reimporting etc. Major pain in the ass to work with like that.


Basically, use displacement for non tiling distortion and use bump for tiling high frequency detail.

There are PLENTY of reasons to use both at the same time.

[riggles]

Thank you for replying as well Karba.

- No multi-UV support. Couldn't paint different road/slush detail maps.
Almost nobody wants multi-UV support. That is what the vote shows. http://render.otoy.com/forum/viewtopic.php?f=9&t=37045 But we will add it at some point.

It didn't rank high in that poll no, but that poll is worth examining a bit more. Multi-UV support was more requested than network rendering, and that was deemed important enough to implement already. Also, when HDRI+Daylight mixing is #4 on the list, that tells me there are were a lot of archviz voters, not necessarily VFX people. I think the poll is a good representation of what your current users are wanting, not what features are needed for VFX work.

- No UV offsets for tiled hi-res texture maps. Ditto.
What do you mean? There is a transformation node with offset settings

Sorry, worded that funny. Tiled UVs such as UDIM or manually ofsetting UV space so that multiple texture maps can be used for single mesh UV. This is how MARI artists sometimes output their textures so you have multiple hi-res textures tiled across a surface.

- No procedural displacement.
- No displacement shader blending.
We did the best what we could. CUDA programming doesn't allow much.

Well, if you did the best you could, I can't really ask for more than that.

- No displacement and bump together.
What is the point of using bump with displacement? displacement can replace bump completely.

Like was mentioned, it's needed for building up finer levels of detail that don't need full displacement and are more efficient to render. This is useful both for larger scale scenes and especially for micro detail on character close-ups.

- Limited gradient support. I needed to use the angle from world up-vector to face normal to drive a white diffuse color overlay to quickly put white on the top of distance surfaces. No such gradient drivers exist.
We will add more procedural textures in the future.

Great, thank you.

- No proxies support. I needed to work on assets while the animator was doing his car/camera rig/animation. Plus it was a forest with a number of different trees and I needed to keep the scene as light as possible.
I will add it soon.

Also excellent.

- No particles. Wanted to preview with falling snow.
I will add it, maybe not very soon, but still soon.

Things are looking up.

- No environment fog. It's a snowy day, after all. There's a volumetric fog hack for Octane, but who wants to animate that hack for 5 different moving cameras?
Can't you link a small sphere to the camera in 3dsmax? No point to animate it.

Yes, I could, but that would kill render times since the area that really needs fog calculated is just the area around the camera frustum. Unless I'm mistaken, would not end up being a practical solution.

- No volumes. I needed blobby surfaces with displacement to quickly get snow clumps on things that were closer to camera in the lock-off shot.
The same as particles.

Very nice.

Well, I'm glad to see a number of these things coming down the pike. Some of them are real deal-breakers, and it will good to get past them.