[Bf-committers] Render Panel Proprosal (Variable OSA, Render Sizes)

[Roel Spruit]

Before anyone thinks of coding custom presets, I already coded it in Tuhopuu
1.
The only reason I didn't port it is because I cannot find a good solution to
the
drop down vs. buttons problem:

If you have a drop down menu, and you choose a setting, you would expect it
to
change to "custom" if you changed a setting. Because I wasn't very well
versed in
the event stuff of the menu's I couldn't code a satisfying solution.

Roel

-----Oorspronkelijk bericht-----
Van: bf-committers-admin@blender.org
[mailto:bf-committers-admin@blender.org]Namens Robert Tiess
Verzonden: zondag 22 februari 2004 4:45
Aan: bf-committers@blender.org
Onderwerp: Re: [Bf-committers] Render Panel Proprosal (Variable OSA,
Render Sizes)


Thank you very much, Ton, for replying to my ideas.
It's an honor to hear from you.  I fully agree with the deeper
issues you raise concerning th jitter, 16 samples limit (which
I painfully learned cannot be easily undone by my source
experiments), better motion blur control, and better AA.
Adaptive AA would be amazing.

One of my tests for the variable OSA included my complex
"Jewels" scene, which was last week's Elysiun weekend
challenge winner.  With the official 2.32 binary it took about
7 hours to render with all its raytracing as OSA 11.  Using
the experimental OSA 2 with a slighly expanded Gauss (2.0)
it rendered in about 17 minutes on my 2.4ghz system with
suprisingly little image degradation concerning the disparity
in OSA levels -- so much that a simple "render large then
resize down" act in an extimage editor could have ridded
many if not of the remaining jaggies.

The less memory and faster rendering, especially where ray
tracing and high sample area lamps are concerned, seemed
to make the lower OSA value particularly valuable.  For my
motion blur animation test the image quality difference
between 640x480xOSA16+mblur+Gauss 2.0 was just as
surprising to me, because of the vast speed gain versus the
less than expected drop in image quality.

The variable render size is also very helpful I find, because
it quickly lets you dial in a render size without forcing the
user to edit the SizeX and SizeY settings, which can get
tricky to edit once one has perfectly framed a scene in the
render camera view.  The ability to go up to 200% is very
handy too, especially when people request larger renders.

Regarding presets:  your idea sounds great!  Do you think
a drop down menu for render sizes on the right side of that
pane might be the next step in terms of possibly revising that
area?  Such a menu could be made to read in values from
the ASCII file you propose.

User feedback is important too.  I'm a frequent poster
at Elysiun (I'm "RobertT") so most of these proposed
enhancements come from sustained intense Blender use
as well as consideration of posts I read daily here at
blender.org and over at Elysiun.  The overwhelming realization
I have though is that the software is extremely robust and
well thought out internally while intuitive, rapid, flexible
and pro-artist on external levels that other "high end" 3D
software do not even begin to approach, so touching the
source seems almost at times like tampering with perfection.

I've halted my furious blending pace to devote most of my
free time to studying the source.  The more I stare at those
lines the more I understand and appreciate just how much
thought went into things. I hope in some small way I can
help bring more functionality to Blender and my fellow
blenderheads out there, mostly out of my deep gratitude for
what the coders have created, yet also out of my interest
in seeing Blender fulfilling its potential as the undisputed
3D cg tool of choice for all graphics users.

Thank you very much for your time and efforts, Ton.

Robert
rjtiess@warwick.net
(RobertT on Elysiun.com)



_______________________________________________
Bf-committers mailing list
Bf-committers@blender.org
http://www.blender.org/mailman/listinfo/bf-committers