Patryk Kizny
|
|
« Reply #30 on: July 15, 2015, 10:55:00 PM » |
|
And frags - apologies for multiple posts, but there's a 256KB limit on the attachments. At least for newbies
|
|
|
Logged
|
Visual Artist, Director & Cinematographer specialized in emerging imaging techniques.
|
|
|
3dickulus
|
|
« Reply #31 on: July 16, 2015, 02:50:44 AM » |
|
32bpp buffer is scaled down do 24bit and split into 3 8b channels. can you encode to RGBA for 32 bit data so... z32 = r*256*256*256 + g*256*256 + b*256 + a; The internal depth buffer use in GL is an odd creature, if you google "working with GL depth buffers", or the like, you will find the same infos I did when hacking up spline path occlusion, I don't know the details of why it works the way it does, I just know that it works, and had no thought of saving the depth buffer to a file while I developed the spline path occlusion, those numbers are the ones that seemed to get the desired results. nice to see you are making some progress
|
|
|
Logged
|
|
|
|
Patryk Kizny
|
|
« Reply #32 on: July 17, 2015, 01:20:50 PM » |
|
can you encode to RGBA for 32 bit data so... Cool, but what would I do with it if I cant export it thanks to QT limitations?
|
|
|
Logged
|
Visual Artist, Director & Cinematographer specialized in emerging imaging techniques.
|
|
|
3dickulus
|
|
« Reply #33 on: July 17, 2015, 03:30:56 PM » |
|
encoded as RGBA? = standard qt image, which could be exported?
|
|
|
Logged
|
|
|
|
3dickulus
|
|
« Reply #34 on: July 18, 2015, 03:09:08 AM » |
|
you can find all Qt image formats here http://doc.qt.io/qt-5/qimage.html#Format-enumthe data structure is directly accessible on a per byte or per scanline.byte basis so if you create an image of the desired size and format you can read/write directly to the storage buffers whatever values you want
|
|
|
Logged
|
|
|
|
Syntopia
|
|
« Reply #35 on: July 18, 2015, 07:37:33 PM » |
|
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?
I'm not sure what you are asking here. But you can control the bit depth of the buffer Fragmentarium is rendering to using the '#buffer RGBA32F' directive (see e.g. 3D.frag). Notice that this is not related at all to the OpenGL depth buffer resolution (which I never used in the original Fragmentarium). By far the best solution to all this would be to integrate a library capable of exporting HDR data, such as the OpenEXR library you suggested yourself. Dick, what is the reason for calculating it that way? i.e what's the reasoning behind "1000.0 - 0.00001" part?
I have written a bit on how to calculate gl_FragDepth here: http://blog.hvidtfeldts.net/index.php/2014/01/combining-ray-tracing-and-polygons/ - notice, that this is ONLY needed if you want to integrate standard OpenGL vector graphics with GLSL pixel graphics (which I don't think you want)
|
|
|
Logged
|
|
|
|
Patryk Kizny
|
|
« Reply #36 on: July 19, 2015, 11:00:23 AM » |
|
Many thanks Mikael.
The QT 32bit is 32bit total, so it is still 8bits per channel. I was thinking about 32bit per channel. Or at least 16. So yes, OpenEXR in the future.
|
|
|
Logged
|
Visual Artist, Director & Cinematographer specialized in emerging imaging techniques.
|
|
|
3dickulus
|
|
« Reply #37 on: July 28, 2015, 07:46:14 AM » |
|
But you can control the bit depth of the buffer Fragmentarium is rendering to using the '#buffer RGBA32F' directive (see e.g. 3D.frag).
I added RGBA16F too, it renders clean pictures so I'm assuming it works, still saves QImage RGB8 edit: ( in latest source code only) By far the best solution to all this would be to integrate a library capable of exporting HDR data, such as the OpenEXR library you suggested yourself.
I have been studying the EXR code and I might be able to manage it, seems relatively simple , the plan: save 16/32 float rgbz directly from the GL buffers when using filename extension ".exr" for output images. It will require a lot of ram me thinks... edit: (not quite there yet )
|
|
|
Logged
|
|
|
|
3dickulus
|
|
« Reply #38 on: July 29, 2015, 06:43:55 AM » |
|
here is the first (ever?) OpenEXR image from Fragmentarium exrstats $> exrstats tile_0.exr
tile_0.exr [512x288]:
exrstats: Scanning 287 exrstats: Done.
Alpha min is 1.000, max 1.000
Luminance min is 0.105, avg 0.666, max 0.964 Red min is 0.106, avg 0.681, max 0.965 Green min is 0.106, avg 0.713, max 0.965 Blue min is 0.094, avg 0.666, max 0.961
Luminance log min is -2.253, avg log -0.364, log max -0.036 Red log min is -2.245, avg log -0.395, log max -0.036 Green log min is -2.245, avg log -0.350, log max -0.036 Blue log min is -2.363, avg log -0.420, log max -0.040
|
|
|
Logged
|
|
|
|
Syntopia
|
|
« Reply #39 on: July 29, 2015, 07:01:21 PM » |
|
Very nice! The image opens nicely in EasyHDR
|
|
|
Logged
|
|
|
|
Patryk Kizny
|
|
« Reply #40 on: July 29, 2015, 08:08:13 PM » |
|
Yeah! The dream came true! Made my day and you rock!
On my end I've implemented simple version of materials with slightly improved and optimized blinn-phong based shading and I'm updating the renderer to deal with transparency and matte objects through the pipeline. It's gonna take a bit more time, but we already see the light!
@Dick - are you able to think about capturing or intercepting multiple layers from fragmentarium to write multiple layers into EXR? I guess there's only one buffer (hopefully i'm wrong), but perhaps we could make use of 2Dsampler/texture objects to funnel data to EXR?
|
|
|
Logged
|
Visual Artist, Director & Cinematographer specialized in emerging imaging techniques.
|
|
|
3dickulus
|
|
« Reply #41 on: July 30, 2015, 03:11:27 AM » |
|
@Syntopia ty on my system it doesn't look quite right, could be the display/conversion prog but it looks a bit too bright when converted to png and too dark, low contrast, in the desktop display app. (OpenEXR is included as part of the SuSE linux dist). It should look exactly like the default bulb image at startup. @PK it is only at a very rudimentary stage, saving one tile, they will still need to be stitched together for larger tiled images, I am looking at layers but again only in the simplest of forms. The image I attached previously should be RGBAF so 4 float layers. I have had no luck with depth buffer, I think it's because rendering is done with 2 accumulation buffers then to a screen buffer, the depth buffer stuff that I did for spline path occlusion is only active when in Non-Tiled + Non-Accumulation mode, however the fragment code should still be populating the depth buffer (maybe that needs to accumulate too), but I think it gets destroyed when we render our texture to a quad for display. Perhaps Syntopia can weigh in with some of the finer points of Fragmentarium's internal rendering flow can we use GL_Accum and Qts default double buffers (created for QGLWidgets) instead of the current setup? My plan is for better colour resolution for printing fractals so I may not take it any farther than that but the end result will be the ability to save EXR images for processing in other software. EDIT: exr image from GL float buffers, first pic shows Fragmentarium render in background, Okular viewer and png converted from exr EDIT: second pic is displayed with the OpenEXR viewer
|
|
« Last Edit: July 31, 2015, 02:20:12 AM by 3dickulus, Reason: i just realized that everything to do this is built into SuSE linux :\\ »
|
Logged
|
|
|
|
3dickulus
|
|
« Reply #42 on: July 31, 2015, 03:38:19 PM » |
|
Again, easier than anticipated I have set it up so that all the user has to do is to make the output base filename end with .exr and you get RGBA16F images, but they are upside down and don't seem to work with odd tile size, must be even so a little tinkering over this weekend and hopefully a fresh release.
|
|
|
Logged
|
|
|
|
Patryk Kizny
|
|
« Reply #43 on: August 01, 2015, 12:10:16 AM » |
|
Yeah! That's great! Is there a build for that already? That puts some pressure on me to add alpha channel to the raytracer and I'm almost there.
|
|
|
Logged
|
Visual Artist, Director & Cinematographer specialized in emerging imaging techniques.
|
|
|
|
|