mathias.poupard Posted April 30, 2013 Posted April 30, 2013 Hello,We currently use Unigine's WidgetSpriteViewport to render small offscreen thumbnails of custom presets of our scene, that we then save on disk and display in a GUI in another thread. We do this on a per-request basis : i.e. we do not use the automatic rendering feature of WidgetSpriteViewport with setIfps() and such, and only trigger the offscreen rendering explicitly.Basically, when we need to render a thumbnail, we perform the following: save the current camera, lighting and HDR settings of the main scene; initialize the Unigine Player with the camera settings and the rendering parameters with the lighting and HDR settings defined for the thumbnail we are going to capture; set the WidgetSpriteViewport "hidden" property to false; render the scene in our WidgetSpriteViewport; save the image on disk; set the WidgetSpriteViewport "hidden" property to true; restore the previously saved settings of the scene; render the scene normally. It works almost fine except that the rendering of the thumbnail somewhat affects the rendering of the scene on the main screen : the frame(s?) rendered just after each render-to-texture operation looks affected by the brightness levels of our thumbnail frame (if the thumbnail frame rendered to a texture is dark, the next frame rendered to the screen will be darker than it should be). When several thumbnails are rendered, several frames in a row (if it matters, we never render more than one thumbnail per actual frame), this is very noticeable and causes a strong flicker artifact of the main viewport, because it seems to switch between frames with normal and erroneous brightness.We came to think that the problem originates from the HDR adaptation effect. Even though the HDR adaptation value is always zero in our application, we still modify and restore a lot of HDR-related parameters before and after the WidgetSpriteViewport render-to-texture operation. If we disable this change (and only modify the camera settings for example), the flickering ceases.We would like to be able to seamlessly render the scene with arbitrary HDR settings to our offscreen texture at any time without affecting the main rendering process or result.Is there a problem with HDR postprocessing when using WidgetSpriteViewport rendering? Did we overlook something in our rendering process? Is it okay to use the same Unigine Player camera to render to the thumbnail texture and to the main buffer?Thanks in advance.
frustum Posted April 30, 2013 Posted April 30, 2013 What about engine.render.renderImage2D() function? You can specify the hdr rendering mode into rgba16f image. In that case engine's HDR adaptation effect will not be affected.
mathias.poupard Posted May 2, 2013 Author Posted May 2, 2013 Thank you frustum. Rendering the texture via renderImage2D() with RENDER_HDR_QUADRATIC to RGBA16F indeed prevents the next frame to be affected. However we still need our destination format to be RGB(A)8 to be used in the GUI or in a third party application. Is there a way to get the texture data in a normalized pixel format using Unigine ? Or should we write a custom converter?
frustum Posted May 2, 2013 Posted May 2, 2013 Hdr parameter of renderImage2D function is boolean. To convert image from rgba16f format to rgba8 you should convert it to rgba32f format via convertToFormat function and process all pixels to rgba8 manually after that.
mathias.poupard Posted May 2, 2013 Author Posted May 2, 2013 Thanks, I get it. So we have to tone map the resulting image manually then. But is there any other way we could bypass this issue? I was thinking about something like maybe saving/restoring the state of the HDR adaptation effect between offscreen render passes.
mathias.poupard Posted May 13, 2013 Author Posted May 13, 2013 Sorry for bringing this issue up again but it is not very convenient for us to have to convert the floating-point buffer manually. We would like to get the exact same result as we would on screen and be able to save it on disk as an LDR image. Isn't there any way to tell Unigine to process the buffer through the tone mapping/conversion shader? Or, as another way, to discard our offscreen rendering from HDR adaptation?
unclebob Posted November 12, 2013 Posted November 12, 2013 Hi Mathias! Sorrry for late reply, it's been a long time ago. :) If you have source license, you can add it by yourself (something like engine.render.pushHdr/popHdr functions). For now we can't promise we'll add this, sorry. So the solution for you remains the same (render to HDR texture and tonemap manually). Hopefuly, we've added 'real threads' to UnigineScript so you can use it and run your processing and there will be no hiccups.
Recommended Posts