[Bf-committers] Re: Displaying render result in Image Editor

Ton Roosendaal ton at blender.org
Tue Jun 13 13:44:18 CEST 2006


Hi,

In my commit I've already indicated the problems you noticed... these  
have to be solved yes. Mostly the problem is with the overly packed  
amount of functionality of the Image Window...

Anyhoo, usually feedback works better when people can first toy with it  
around a little bit.

First of all; I've done this to solve complaints from people who miss  
the old "dispview" feature. That one was coded pretty lousy, hardly  
useful, but in use by people with gfx cards that crash when using a 2nd  
window with OpenGL.
The 'render to image window' currently is a better functional  
replacement for that already.

Now how to improve the current situation best... still unsure about  
that. I still like it that the Image Window is being re-used, that  
keeps all image viewing/manipulation unified. There's also benefits of  
rendering to an Image block. These are the main reasons for not  
choosing to add another "Area Space type" for render output.

However, then the current display rules wil conflict with texture map  
usage yes...

> A situation that I would like would be that I have a Screen setup that  
> contains an image window showing Render Result. When I press F12, the  
> active screen automatically changes to that separate screen, then when  
> the render is finished, I can press ESC to return to my previous  
> Screen layout.

I can add an extra rule for the "Full Screen" option yes, it can search  
first for an available configured existing Screen to switch to. This  
cannot be based on "A screen showing a render result image" I think,  
that would give unwanted issues when you are already using an image  
window somewhere in your screens showing the render output.
The more stupid (but workable) rule could be just choose the screen  
called "Render Result", if that exists. Then you're 100% sure it will  
always pop up the right one.

> * If you're not in UV face select mode at the time, but still have an  
> image editor open, as you're working on a texture, just doing a test  
> render will take over the texture that you're looking at (and possibly  
> compare with the render).
> * If you're using the compositor and have a 'Compositor' open in the  
> Image Editor to view the output of your viewer nodes, doing a  
> re-render (for example to update the layers after a change in the 3D  
> geometry or lighting) will over-write your compositor viewer with the  
> raw render result, which is most likely something that you don't care  
> about looking at, at that stage.

I can also adapt the rule to *not* re-use an Image Window when in use  
for textures or composite. The code could search for another available  
large area instead.
Same rule can be for the full-screen. That way I can ensure a more  
unique render-view exists, not used for texturing. Will experiment with  
that.

> Some other issues with this feature:
>
> * The status line containing render statistics should not be drawn in  
> the same colour as the Image Editor's background. It can be very  
> misleading and can make the image shown look smaller than it actually  
> is. See here:
> http://mke3.net/blender/etc/render_stats_bg_prob.png

Problem is that while rendering, no information exists about the entire  
image (the tile render system only knows about its own tile). The  
status line drawing is done separate from the image... so, drawing it  
transparent isn't easy to solve. I thought of drawing it in the window  
header, but a) that one can be hidden and b) after rendering you want  
to see the buttons again and the stutus info anyway.

Simplest solution for now is using another background color for status.  
:)
Once the whole render-to-imagewindow is stabilized I might check on  
nifty opengl tricks to blend the statusline in.

> Rendering to the image editor could be a great improvement on this, if  
> only there was a way to save the currently displayed render result to  
> a Blender image block in memory for future reference, which there  
> unfortunately isn't :(
> It would be great if there was something like a [ 0 ] users button  
> next to the Render Result name, that functioned like a normal  
> std_libbuttons 'make a single user copy'. Then it would be great, you  
> could keep two image editors open simultaneously to compare two  
> different versions.

Right, i can do that for both Composite and Render images. Not too  
hard. :)

> cheers

And thanks!

-Ton-

>
> Matt
>
>
> On 13/06/2006, at 00:39 AM, Ton Roosendaal wrote:
>
>>  The flow, when invoking a Render, goes as follows:
>>   - first it checks if there's an Image Editor visible displaying the  
>> "Render
>>     Result", if so then it uses that area-window.
>>      (Use this option for dual-monitor setups for example, a render  
>> will always
>>      go to the same location then)
>>   - else it checks if there's an Image Editor open in general, it then
>>     assigns that window the "Render Result" Image.
>>   - else: it searches for the largest Area in the screen, and turns  
>> that into
>>     a temporal Image Editor showing render output.
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers
>
>
>
------------------------------------------------------------------------ 
--
Ton Roosendaal  Blender Foundation ton at blender.org  
http://www.blender.org



More information about the Bf-committers mailing list