OpenEXR Integration with Renderelements in newer builds

[instinct]

Hey there,

in Max8 we get OpenEXR BitmapIO. We also get Vray to fully integrate with Max's RenderElements. But the OpenEXR BitmapIO is rather limited. it seems to only support a very limited number of predefined extra-channels. Will it be possible (or is it planned even?) to have a custom OpenEXR BitmapIO that supports all Vray RenderElements ? We are using nuke more and more and OpenEXR is amazing. The features, the compression the extendability is just perfect. But the integration somewhat lacks.

Regards,
Thorste

[panthon]

Is Nuke able to use the extrachannels like zbuffer, id selections and such? And do you know if nuke is actually faster than other apps like fusion, AE or combustion?
What about diffuse, reflection, refraction, etc channels integrated in one single (monster size?) exr file?
I dont know if vray is able to connect rpf-like channels to real passes, eg selecting one object using objectID inside a refraction pass...but it would be cool.
Some other things to consider arise when working in LWF. Using gamma correction as color mapping simply dont work when trying to composite these channels...even when using EXR...

[instinct]

well nuke is pretty damn fast. i havent used fusion yet, but from my testings it eats AE, combustion and shake for breakfast.

It's targeted specifically at using OpenEXR, so yes it can read every extra channel you add to a file (OpenEXR supports complete custom channels with custom names, and different datatypes (like full float, or half float signed etc) in one File. Connecting channels with the newerbuilds shouldnt be a problem (and having one big OpenEXR would help a LOT there, especially since OpenEXR compresses incredibly good!) The newer builds sport renderElements integration and filtering of G-buffer channels (so you get channels that match exactly without AA artefacts/overlaps). There are some channels like RenderID etc that are not filtered due to beeing integer channels basically. But you get Reflection and Reflection filter passes. Combine that with WireColor channel and you could do what you mentioned.

Thorsten

[vlado]

Re: OpenEXR Integration with Renderelements in newer builds

Will it be possible (or is it planned even?) to have a custom OpenEXR BitmapIO that supports all Vray RenderElements?

For reading or writing? I suppose an importer where you can choose which channel to be loaded can be created, but it would be best if this was done by the standard 3dsmax openEXR importer.

Best regards,
Vlado

[instinct]

i meant for writing. Right now if i want to output all channels to exr i have to write them to seperate passes and run the thru a nukescript to embedd them in one EXR. As the EXR saver only supports a subset of channels...some are even incorrectly saved it seems

Thorsten

[vlado]

You can write a .vrimg file and then convert it. vrimg2exr puts all the channels from the .vrimg file into one .exr file by default.

Best regards,
Vlado

[instinct]

yeah, but that's pretty similar to running it thru a shake script. The problem is that this needs a lot of short term space on hd, and it's also a factor in rendertime considering long sequences (we're doing mostly animation). So i was hoping for a way to write a custom EXR writer that supports all vray channels. Are all the channels easily exposed to the maxsdk ?

Thorsten

[studioDIM]

eheh.
try an ntfs folder compression on rpfs :P
half size, no fuss.

Joking, but only half

Btw, the channels are open also to maxscript, for that matter.
With scripting alone (bitmap constructor) it's a BREEZE to extract channels off openable images in max, and save out, or ccompound render channels and save them out.
I wouldn't know, though, about how the exrs are written out (extra channels written correctly or not).
One thing it's for sure, though: exr is stuck on top of max, and by blur, not by autodesk itself. Prolly not the best choice around within this environment.

Lele

[instinct]

wasnt it splutterfish that did the base EXR plug ? at least the claim tho. Anyways, their implementation doesnt allow saving customchannels, not via maxscript either. It is exposed to maxscript, but only to the extend of allowing to call it, set the options that are also in the UI and save/load pics with those options/channels.

What bugs me is the extra step for every frame rendered. If i save out to multiple passes that means like 30 or 40 file-sequences per shot! And then all those passes have to be encoded into one exr sequence. That´s pretty timeconsuming. Besides every additional step is an additional problem/error possibility (and if it can go wrong it will :P).

The vrimg way on the other had would work but vrimg files are HUGE (if you render let´s say 5k frames at HD or 2k or even 4k res). And converting HUGE files also takes longer. But i guess a custom OpenEXR plugin should be possible, as openEXR itself is opensource, and the gbuffer is exposed to max sdk.

Thorsten

[studioDIM]

wasnt it splutterfish that did the base EXR plug ? at least the claim tho. Anyways, their implementation doesnt allow saving customchannels, not via maxscript either. It is exposed to maxscript, but only to the extend of allowing to call it, set the options that are also in the UI and save/load pics with those options/channels.

Did i say blur?
I meant the makers of Brazil. Hence splutterfish, lol.

I mentioned the bitmap constructor as it's the way to override the UIs in general.
I also, though, spoke on a hint, and yes, you're right: not only the chans are limited in the saver, but the scripting access is BAD at best (no mention whatsoever of extra channels bur RGBA).

On the other hand, i tried converting from within max one RPF with a few channells into EXR, and compared sizes.
With a Scanline Block compression (ZIP) i achieve, for the same amount of infos, half the size of an uncompressed RPF (~10 megs against 19).
With a simple NTFS folder compression, that RPF on disk is around 12 megs.

The vrimg way on the other had would work but vrimg files are HUGE (if you render let´s say 5k frames at HD or 2k or even 4k res). And converting HUGE files also takes longer. But i guess a custom OpenEXR plugin should be possible, as openEXR itself is opensource, and the gbuffer is exposed to max sdk.

Expandability aside (i keep saying that one needs to write a writer and a reader for exrs to fully take advantage of their flexibility, so it's out of the reach of most. And so is Nuke, but nevermind, you have it ) i wouldn't see it so straight a preference for EXR.
With what costs today storage (even big,expensive one), a 25% size difference on disk between exr and rpf isn't that big a deal.
300 frames of NTSC animation with 5 channels saved at 32bpc each were 2.5 GB on disk.
They'd be 2 GB at best with exr.
With a lot more hassle.

This said, if the plan is to output something like ALL the passes Vray's capable of into one exr, you are right: cpp and running like mad.
Also, i think the only exposed channels in the MAX sdk are the ones saveable into an rpf (Z-, coverage, IDs, and so on), but not the ones peculiar to vray (diffuse, GI and so on), at least directly.
Anything displayed in the VFB, though, however it's ended up in it, is definitely saveable to a file, both in the script and in the sdk.

Lele

[instinct]

Well out of reach is not really what it is, given that we got Dieter (dimo, aka Mr.Implicit :P ) and (well way below, but still ) me. So writing a custom BitmapIO is actually in reach...just wondered if it was worth the hassle researching (mind you paramblock2 is confusing at last :P ).

And considering compression i seriously doubt NTFS compression gives the same performance as EXR reading...and given 2k planes as input read performance is a BIG issue in compositing. Besides Fileservers are linux, so ntfs compression is not really an option (tho there will be an internal raid in the nuke machine, but not yet).

So i think i´ll look into it.

@vlado :

any pointers on accessing vray´s gbuffer chans ? can i access them like standard max gbuffer chans ? or do i need to go via vray sdk ? (wich i dont know at all yet)

Thorsten

[studioDIM]

Well out of reach is not really what it is, given that we got Dieter (dimo, aka Mr.Implicit :P ) and (well way below, but still ) me. So writing a custom BitmapIO is actually in reach...just wondered if it was worth the hassle researching (mind you paramblock2 is confusing at last :P ).
And considering compression i seriously doubt NTFS compression gives the same performance as EXR reading...and given 2k planes as input read performance is a BIG issue in compositing. Besides Fileservers are linux, so ntfs compression is not really an option (tho there will be an internal raid in the nuke machine, but not yet).
So i think i´ll look into it.

Ah well, i'm plainly and simply envious then

Lele

[vlado]

@vlado :

any pointers on accessing vray´s gbuffer chans ? can i access them like standard max gbuffer chans ? or do i need to go via vray sdk ? (wich i dont know at all yet)

Thorsten

If you render to standard 3dsmax bitmaps (not using the V-Ray VFB) then you can use 3dsmax's own API for this (e.g. get the render element bitmaps and save them out). If you render to the V-Ray VFB, then you'd need to go through the V-Ray SDK. Currently the VFB is not directly accessible, but there is no reason not to make it so - let me know if you decide to do it this way.

On the other hand, i tried converting from within max one RPF with a few channells into EXR, and compared sizes.
With a Scanline Block compression (ZIP) i achieve, for the same amount of infos, half the size of an uncompressed RPF (~10 megs against 19).
With a simple NTFS folder compression, that RPF on disk is around 12 megs.

It is not quite a fair comparizon, since the RPF stores more information than EXR. RPF stores multilayer information where you can have, for example, multiple z-values for a single pixel for the different objects in that pixel whereas EXR is limited in this regard and would store only a single z-value for that pixel.

Best regards,
Vlado

[dimo]

Hi,

I am wondering if we could write to OpenEXR incrementally like to the vrimg so it would allow infinite imagesize, too?

Best Regards,

Dieter

[instinct]

was thinkin about that too dieter...esp when reading the terms "tiled" vs. "scanline" images in the docs of openEXR...but seemingly tiled images are just multi-resolution images. But maybe there is a way.

Thorsten