Exporting Z-buffer and transparency

[3dickulus]

so from that I gather the 2 minute 1080p render @ 3000 frames that took over night will take over a few months @ film quality resolutions

OpenEXR might be handy for when you find that insanely awesome location and want to get really high quality output for reproductions

aside: I thought delphi-shader might be helpful for MB3D

[laser blaster]

Just tried the delphi-shader - which is nice, but also very slow.

I tried changed a Fragmentarium shader to use doubles (just insert #version400 at the top, and change vec3 -> dvec3, float -> double), which made it run 36.6x slower. (Rather close to the expected theoretical factor 32x for the Nvidia Maxwell GPU I use). Still it was faster than the Delphi-shader (based on the roughly similar Mandelbulb example)! And Maxwell is really bad at double precision: in particular some AMD GPU's are running 1/4th in DP: http://www.geeks3d.com/20140305/amd-radeon-and-nvidia-geforce-fp32-fp64-gflops-table-computing/ (The pro cards, FirePro and Tesla, run double precision at half speed).

So the question is whether running on the CPU is worth it.

Emulated double precision is a lot faster- I get about double the speed on my GTX 880M. Unfortunately, the double precision functions included in Fragmentarium haven't worked for me since I upgraded my GPU- it seems that Nvidia's compilers no longer recognize the fastprecision and fastmath pragmas. It can be fixed by using "precise" qualifiers for all variables, but that either requires OpenGL 4.0 or the extension ARB_gpu_shader5, which is only supported from GL 3.2 and later.

By the way, I made an optimized set of double precision functions that run somewhat faster than the old ones (they require ARB_gpu_shader5, though, because they rely on the single-precision fma operation). I also added fairly fast sin, cos, and exp functions. I didn't make a division one yet- once I add that one, I'll post the whole set.

[Syntopia]

so from that I gather the 2 minute 1080p render @ 3000 frames that took over night will take over a few months @ film quality resolutions

OpenEXR might be handy for when you find that insanely awesome location and want to get really high quality output for reproductions

aside: I thought delphi-shader might be helpful for MB3D

I only think the OP asked for 32-bit output export (which will not lower rendering speed). I don't think internal calculation 64-bit resolution was needed?

Emulated double precision is a lot faster- I get about double the speed on my GTX 880M. Unfortunately, the double precision functions included in Fragmentarium haven't worked for me since I upgraded my GPU- it seems that Nvidia's compilers no longer recognize the fastprecision and fastmath pragmas. It can be fixed by using "precise" qualifiers for all variables, but that either requires OpenGL 4.0 or the extension ARB_gpu_shader5, which is only supported from GL 3.2 and later.

By the way, I made an optimized set of double precision functions that run somewhat faster than the old ones (they require ARB_gpu_shader5, though, because they rely on the single-precision fma operation). I also added fairly fast sin, cos, and exp functions. I didn't make a division one yet- once I add that one, I'll post the whole set.

You are quite right. The EmulatedDouble.frag does not work on my machine either. It has been reported here, but no answer:
https://devtalk.nvidia.com/default/topic/820790/opengl/bug-compiler-no-longer-respects-pragma-optionnv-fastmath-off-is-there-an-alternative-/

Having a set of trigonometric 64-bit functions would be cool. Actually, there are not 64-bit trigonometric functions in GLSL either, so these would be useful.

[Patryk Kizny]

Hi there! Looks like I opened a pandora box

I think there's some confusion coming from visual.bermarte post.
Calculation precision on GPU is what it is and I did not have in mind messing with that part.
What I meant is only being able to export images in either 16bpp int (which is good) or 32fp (which is fantastic, but in most cases 16bpp will do).
Since the internal buffer can already handle 8/16/32 accumulation that looks doable.

And again to explaining why it is important - yes you can tweak exposure and everything in Frag.
But even with a lot of additional frags bells and whistles Frag falls short in terms of image postproduction workflow.
To put that straight, If I want to use fractals in a shortfilm and in a regular VFX workflow that assumes several steps:
- rendering good looking images in fractal software
- exporting that + ZD + Transparency
- compositing in postproduction by adding the layers and stuff I want
- finally color grading the final piece

You can check films by Julius Hortshuis which follow the same workflow.
Conclusion is that the image coming from frag is not a final, it's just an input for further artistic interpretation.
And yes, screens are all 8 bit at the end of the pipe. That's exactly why rendering 8bpp from fract sw is not sufficient - you need headroom for all image manipulation. If you input 8bit, manipulate it slightly you start seeing banding, posterization on gradients etc… All bad things affecting negatively the quality of the image we strive for.

Exporting multiple subexposures from Frag does not make any sense. If the buffer is 16 or 32bpp we only need a way to grab it and save to any usable format.
Now the final word on EXR - I suggested it for 16/32bpp precision, yes, byt also because it handles multiple image layers so you could save normal image RGB on one layer, transparency on the other, Z-depth on the other. I saw some people including multiple independent fractal objects within same space. So the next step could be color-tagging these and adding this render element to the stack for future separation in post.

[3dickulus]

I understand the reasons that make EXR desirable, I did commercial, in-house graphics, animating and video production in the late 80s and early 90s, lots of story boarding and preproduction stuff, so I really do get it. I watched some of your vids on your site, very nice work btw.
I do think HDR/EXR is worth looking at but it's no small task to implement it in a prog like Fragmentarium and we here are mostly pursuing our interests for fun not profit. To that extent, I have downloaded the source code, because I am interested, but it won't compile and they (Ilm) don't provide binaries. If anyone else has compiled it on linux please let me know the trick and I will take a serious look at it.

[visual.bermarte]

I think there's some confusion coming from visual.bermarte post.

Thanks for clearing that up   my main point was to help you suggesting a different sw. Sorry but if you can't get what you want (for free), then you should do your homework with what you have. Still I wish you good luck with your job, i had the chance to see your productions and I find them well done too.  

[Patryk Kizny]

I do think HDR/EXR is worth looking at but it's no small task to implement it in a prog like Fragmentarium and we here are mostly pursuing our interests for fun not profit. To that extent, I have downloaded the source code, because I am interested, but it won't compile and they (Ilm) don't provide binaries. If anyone else has compiled it on linux please let me know the trick and I will take a serious look at it.

Check this plugin:
http://freeimage.sourceforge.net/

Looks like it is avail for Linux and supports many formats including OpenEXR.

[3dickulus]

very cool, source code is available

[Patryk Kizny]

Ok, I got a few more ideas overnight.
So QT gives us 2 bottlenecks:
- 8 bits limit
- no transparency.

I think it could be pretty easy and feasible to introduce on a shader level an 'extra pass' that would render the same scene, but introducing color-tagging of various layers.
So lets say we can encode alpha channel on one channel, fractal body on the other and floor on another one. We could also add another pass rendering just AO, shadows or whatever you like.
This gives a huge amount of flexibility for further postproduction.

Now the easiest case is that we render an extra pass of the animation.
But I am thinking along the lines:
- can we extend fragmentarium on a CPP side that way, that in GLSL we could define few tags and outputs (buffers) render them in the same batch and save to separate files?
Not sure how easy it is, but looks doable and making sense.

So we would have a raytracer with predefined set of elements, checkbox enabled in settings - like: fractal body, floor, alpha, etc…
The we would have some flags in the GLSL that would tell Frag to output these, probably defining also filename suffix.
During animation or still rendering, for each of frames Frag would render a few buffers and save to a few files.

Does that make sense?

[Patryk Kizny]

I have successfully updated the ray tracer to allow for color tagging various layers. So the only remaining question is how tough would it be to add multiple files per frame support on the cpp side.

I think this approach could be used to work around the 8bpp limit. We could tweak the shader to do 2 passes and combine results outside of frag. Time consuming but unless export via 3rd party lines is added this could be a way to go.

[Patryk Kizny]

Small update on the depth.
Even if we're limited by 8bpp, I think there's a simple way of overcoming this limitation for Z depth.
Clip Depth to 24bits size, then split into 3 channels and write to 8bpp RGB. It's easy to recombine it in post (since there's no better option).

Same trick could be used for having better output for color - if we had multiple files per frame output in Frag, we could easily clip the color from the buffer to 16bits, then split into 2 8bpp images (simple per-channel division should work). Then just multiply 8bpp subframe pairs in post.

While Z-Depth can be added as a separate pass, exporting color passes would already require multiple exports per buffer implemented on a Frag side.

[Patryk Kizny]

I am using this bit to populate the depth buffer, as the last line in trace() before returning hitColor, for the spline path occlusion, this does make it available on the C++ side, look in Examples/Include/DE-Raytracer.frag

Code:

gl_FragDepth = ((1000.0 / (1000.0 - 0.00001)) +
(1000.0 * 0.00001 / (0.00001 - 1000.0)) /
clamp(totalDist/length(dir), 0.00001, 1000.0));

Dick, what is the reason for calculating it that way? i.e what's the reasoning behind "1000.0 - 0.00001" part?

I think the depth buffer can be set at 24 or 32 bits depending on your hardware too.

How can this be done? Is that avail on the GLSL side?

[Patryk Kizny]

Internally, the accumulation buffer in Fragmentarium can be 8, 16, or 32 bit (only 32 bit is float - and it is also the default. 8 and 16 is integer). But these cannot be exported: in Qt the QImage image class only supports 8bpp, which means we can only save PNG in 8-bit (at least using Qt). Also some of the code, like putting the tiles together when doing tiled rendering uses the QImage class and is thus 8bpp only. QGLFramebufferObject.toImage() is 8bpp too. There are workarounds for all this, and I guess OpenEXR could be supported but it is quite some work.

Mikael, can you let me know where and how it is decided how Frag buffer is handled?
Do I have control over it on the GLSL side?

[Patryk Kizny]

Here we go. Looks like we're somewhere. Sharing frags.
I have successfully implemented Z-Depth pass and color-tagging of layers.
In addition, I have implemented experimental 24bit Z-Depth buffer, which would require a bit of processing to decode.
32bpp buffer is scaled down do 24bit and split into 3 8b channels.

To recombine use:

Code:

z24 = r*256*256 + g*256 + b;

where r,g,b are pixel values decoded from

[Patryk Kizny]

Trippy 24bpp Depth