[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