Title: OpenEXR output in Fragmentarium 1.0.10 Post by: 3dickulus on August 01, 2015, 11:10:22 PM OpenEXR RGBA16F output is now available in Fragmentarium v1.0.10 enabled by using ".exr" filename extension in the output dialog
Source code. (http://www.digilanti.org/fragmentarium/) Requirements The (E)xtra (C)Make (M)odules package contains FindOpenEXR.cmake Home page (https://projects.kde.org/projects/kdesupport/extra-cmake-modules) Git repository (https://projects.kde.org/projects/kdesupport/extra-cmake-modules/repository) OpenEXR 2.1 libraries and SDK (http://www.openexr.com/downloads.html) Not tested for Win or OSX, compiles using Cmake or QtCreator on linux. For linux install/use the packages provided by your dist, search for "ECM" or "Extra CMake Modules" and "OpenEXR" + "OpenEXR-dev" in the package repositories. Now reports like this... Code: Created front and back buffers as RGBA16F EXR output is also available when fragments request RGBA32F buffers but the file format is still RGBA16F. Title: Re: OpenEXR output in Fragmentarium 1.0.10 Post by: Patryk Kizny on August 02, 2015, 12:36:21 AM (http://www.hd-wallpapers9.com/gallery/Hd/Beer%20Desktop%20Wallpapers/Beer%20Desktop%20Wallpapers-017.jpg)
So cool! I'll wait for the build. Title: Re: OpenEXR output in Fragmentarium 1.0.10 Post by: 3dickulus on August 09, 2015, 08:26:52 PM just a heads up for anyone compiling from source...
the ECM package is only needed if you use cmake if you use QtCreator... Code: LIBS += IlmImf Imath Half Iex IexMath IlmThread EDIT: you may have to add the OpenEXR includes folder to INCLUDEPATH in the .pro file but works on my box without it ;) edit2: loads EXR images as Sampler2D textures too :D Title: Re: OpenEXR output in Fragmentarium 1.0.10 Post by: Patryk Kizny on August 10, 2015, 09:57:55 AM Any ideas when this will be avail in the build?
Title: Re: OpenEXR output in Fragmentarium 1.0.10 Post by: 3dickulus on August 10, 2015, 03:18:17 PM no idea, I haven't got OpenEXR installed on my win box and don't have a mac :sad1: the source is available :) that's the best I can do right now.
Title: Re: OpenEXR output in Fragmentarium 1.0.10 Post by: 3dickulus on August 28, 2015, 07:47:43 AM YAY! halfway there, I have compiled IlmBase as a static .lib on windows7 and will try to get OpenEXR compiled as a static .lib too, hopefully, if I've done it right I will be able to link with Fragmentarium and the Win version will have EXR file I/O for images and textures :D
once that is done it might be possible to save RGBZ files, I found this link https://www.opengl.org/wiki/Common_Mistakes#Depth_Testing_Doesn.27t_Work Quote When you select a pixelformat for your window, and you ask for a Depth Buffer, the depth buffer is typically stored as a Normalized Integer with a bitdepth of 16, 24, or 32 bits. Note: You can create images with true floating-point depth formats. But these can only be used with Framebuffer Objects, not the Default Framebuffer. In OpenGL, all depth values lie in the range [0, 1]. The integer normalization process simply converts this floating-point range into integer values of the appropriate precision. It is the integer value that is stored in the depth buffer. Typically, 24-bit depth buffers will pad each depth value out to 32-bits, so 8-bits per pixel will go unused. However, if you ask for an 8-bit Stencil Buffer along with the depth buffer, the two separate images will generally be combined into a single depth/stencil image. 24-bits will be used for depth, and the remaining 8-bits for stencil. if I am going through the trouble to make Fragmentarium save a depth layer I might as well consider saving other layers too, this should also open up the possibility for environment luminance layer, equirectangular IBL maps? I think the only problem will be the accumulation phase, note that the spline path occlusion works on a single pass but I am not sure if the depth buffer is valid after n frames of progressive rendering, it may only contain the values of the last subframe... Title: Re: OpenEXR output in Fragmentarium 1.0.10 Post by: 3dickulus on September 02, 2015, 03:16:50 AM EXR works perfectly on linux and I have almost got it to compile on windows except for 4 thread functions that exist in the library but don't compile, so so close.
it would be nice if a Windows brainiac could help out... anyone? Title: Re: OpenEXR output in Fragmentarium 1.0.10 Post by: 3dickulus on September 05, 2015, 07:32:53 AM For anyone that wants to try compiling the v1.0.10 source on windows with OpenEXR, this is where I'm at...
IT'S DONE :canadian: :horsie: :banana: :worm: :chilli: now all it needs is a few rofl2 tests... and maybe some docs. Replace your current Fragmentarium exe with OpenEXR win exe + zlib1.dll (http://www.digilanti.org/fragmentarium/) this uses the same Qt-5.3.2 DLLs as before, no need to DL the big zip file. Title: Re: OpenEXR output in Fragmentarium 1.0.10 Post by: Patryk Kizny on September 07, 2015, 05:12:05 PM Dick,
- I downloaded the files /win exe + libs/ and added to the program folder - Frag shows me on startup that it does support EXR "Available output formats: bmp, jp2, jpeg, jpg, pbm, pgm, png, ppm, tif, tiff, wbmp, xbm, xpm, exr" - while trying to do a hires render, in the file dialog there's no .exr extension on the lit. When I type it it does not recognize it and adds .bmp so I get myfile.exr.bmp - if I delete .bmp in the hires anim window it accepts it, but upon render start (I guess right after rendering the first time) the program crashes with an unknown exception - saving via 'save screenshot' option does not show .exr option there and also defaults to .bmp So wasn't able to run it. Title: Re: OpenEXR output in Fragmentarium 1.0.10 Post by: 3dickulus on September 07, 2015, 08:38:54 PM ouch :hurt:
I ran and tested on Win7... works I ran and tested on Wine... works (looking at exr image from win ver as I type) "Save screen shot:" works with QImage/QWidget so no EXR there :sad1: do you have zlib1.dll in the same folder as the Fragmentarium executable? EXR format requires zlib, the dll is bundled in the exe-only file (http://www.digilanti.org/fragmentarium/), perhaps I should rename this file to "update" or something. I'll try to reproduce the error you get when I go over it later today but on initial tests it works fine here :hmh: edit: no longer requires zlib1.dll, compiled with static libz.a with MinGW Title: Re: OpenEXR output in Fragmentarium 1.0.10 Post by: Patryk Kizny on September 07, 2015, 10:17:03 PM Yes, I do have it.
Can I gather some info usable for you for debugging? How? Title: Re: OpenEXR output in Fragmentarium 1.0.10 Post by: 3dickulus on September 07, 2015, 10:44:42 PM ok, I just re'n're'd and uploaded the sources and exe pkgs
I have tested EXR on both Win7 and Wine, it does work as expected :hmh: before and after this latest tweek :hmh: I did not find anything wrong... the only difference is the tweek for EXR image size vs ram consumption, the largest exr image I have rendered is 64000x36000 and ram usage stays flat! grab the exe-only file (http://www.digilanti.org/fragmentarium/) and test like... 1. first test preview, this should always work as not saving file 2. simple scenario, just render a test.exr, with no boxes checked in the hires output dialog and no path just filename only 3. then step it up, check Autosave, render, check unique name, render if these work then animation should be fine but a quick test would be good, when doing this just use the default mandelbulb.frag Title: Re: OpenEXR output in Fragmentarium 1.0.10 Post by: Patryk Kizny on September 08, 2015, 03:58:12 PM Now .exr shows up in the dialog and I can start a render.
Preview window works fine. When I do the actual render (even all checkboxes off) it fails at the first save attempt at the end of tile1. Title: Re: OpenEXR output in Fragmentarium 1.0.10 Post by: Patryk Kizny on September 08, 2015, 04:48:24 PM Sometimes it seems to work. I need to do more testing to confirm why and when it fails.
Title: Re: OpenEXR output in Fragmentarium 1.0.10 Post by: 3dickulus on September 13, 2015, 08:34:27 PM v1.0.11 (http://www.digilanti.org/fragmentarium) is up and EXR i/o has been tested on linux, wine and windows 7/8, seems to work as intended. Moving on to special layers, Z, A, H (depth, alpha, histogram) |