Which feature do you need the most?

[Goldorak]

Would love to get Aperture in Spherical/Cube Camera, if that request has been decided on...

Just curious, but what if we added this the forthcoming imager SDK/modules as a post process step for pano renders? How important is it in your renders that DOF be baked into the render target? With deep pixel EXR panos we'd have enough information to make it look good I think. DOF outside of think lens model is not really well defined, so this seems like a useful initial option before we look into other ones.

[FrankPooleFloating]

If it is going to produce DOF that is superior to PS Lens Blur, and everything happens in Octane, then I would be thrilled. Would I be able to set Focal Depth?

[Goldorak]

If it is going to produce DOF that is superior to PS Lens Blur, and everything happens in Octane, then I would be thrilled. Would I be able to set Focal Depth?

I have to check and see with the dev team to get confirmation, but I think it would look better.

[fatrobotsneedlove]

The toon shading system and other postFX features shown in OctaneImager are all ready and done (this was a live screen-grab of the feature working in a custom app we made for GTC)

Any chance we can get that until 3.1 gets released

In fact there is. Some of the initial 3.1 features, including Imager SDK, are moving fast enough to be considered for an interim 3.0.x update. As I have posted elsewhere, we have a full 3.0 build working on AMD (via our cross compiler), so that isn't technically waiting on 3.1 either, but drivers are huge issue we can't work around yet - AMD has to solve or else we can't release and support this no matter the version (they know about this and working on it last I checked). The most complex feature head in the 3.x roadmap is OSL, and it is at the core of 3.1 release. It requires a lot more testing than prior features. We'll move up any 3.x features into 3.0 if they are ready sooner and don't depend on OSL. Imager SDK tools is a likely candidate.

Excellent

[fatrobotsneedlove]

Would love to get Aperture in Spherical/Cube Camera, if that request has been decided on...

Just curious, but what if we added this the forthcoming imager SDK/modules as a post process step for pano renders? How important is it in your renders that DOF be baked into the render target? With deep pixel EXR panos we'd have enough information to make it look good I think. DOF outside of think lens model is not really well defined, so this seems like a useful initial option before we look into other ones.

Wait, so something like peregrine Bokeh in octane imager? That'd be amazing. Currently a bit of a pain for me since deep is so heavy to pull into nuke and octane doesn't output antialiased z-depth.

[Goldorak]

Would love to get Aperture in Spherical/Cube Camera, if that request has been decided on...

Just curious, but what if we added this the forthcoming imager SDK/modules as a post process step for pano renders? How important is it in your renders that DOF be baked into the render target? With deep pixel EXR panos we'd have enough information to make it look good I think. DOF outside of think lens model is not really well defined, so this seems like a useful initial option before we look into other ones.

Wait, so something like peregrine Bokeh in octane imager? That'd be amazing. Currently a bit of a pain for me since deep is so heavy to pull into nuke and octane doesn't output antialiased z-depth.

There should be no AA using the info channel Z depth pass. Make sure distributed RT is off. I often render 1 sample at much higher res to get a clean result, with opacity threshold at the lowest value above 0 to get non-blended edges for transparent materials. I haven't personally tried full deep pixel in our imager stack yet, but that is planned and will also make post DOF effects look nicer. There is a new coverage 8x8 mask mode just added to EXR deep pixel format which we may support once we test it further.

[calus]

There is a new coverage 8x8 mask mode just added to EXR deep pixel format which we may support once we test it further.

Are you talking about openDCX ?

I thought this was not included in OpenEXR still,
dreamworks says "If community feedback is positive, DreamWorks will work with OpenEXR to find a suitable implementation and then lobby for inclusion in the OpenEXR standard."

Or was it a part of it/something similar which was already included in openEXR 2.2 ?

[Goldorak]

There is a new coverage 8x8 mask mode just added to EXR deep pixel format which we may support once we test it further.

Are you talking about openDCX ?

I thought this was not included in OpenEXR still,
dreamworks says "If community feedback is positive, DreamWorks will work with OpenEXR to find a suitable implementation and then lobby for inclusion in the OpenEXR standard."

Or was it a part of it/something similar which was already included in openEXR 2.2 ?

It's post 2.2 , and I should have written that it was proposed for the spec, rather than added. The format requires a 64-bit value for this type of mask (last I checked 32-bit int was max in EXR, but this was a while back). We want coverage AOVs anyway for post work. We could begin to test this by supporting a generic 16-bit 4x4 mask AOV packed into 4 channels which could work even for PNG16 output to contain this dataset in line with the mask data being proposed for this.

This is still being reviewed internally.

[Refracty]

Could you please add the JPG format to the save options.
It is a small feature but super important if you need to deliver 50 jpgs per day.
Actions in photoshops take to much time...

[adriendupagne]

Vertex. weight maps

obv