[Bf-committers] Compositing View Port Proposal

Jason Wilkins jason.a.wilkins at gmail.com
Wed Mar 28 14:19:46 CEST 2012


So, you are saying that if you had more control over what Blender
draws when it draws the view port then you would actually use that
output over Blender's internal renderer?

To be up front about it, that is not what I am setting out to support,
but I do see it as a possible "hack" that would be possible if
somebody took advantage of the new features and ran with them.

Your idea also makes me think that I should look at the Blender game
engine.  There may be some overlap.

On Wed, Mar 28, 2012 at 3:54 AM, Tobias Oelgarte
<tobias.oelgarte at googlemail.com> wrote:
> I would really like to see such features. In my recent times with
> blender there where so many scenarios when just using GLSL would have
> been good enough if it weren't for the lack of:
>
> * soft shadows
> * worldspace normals for materials
> * compositing
> * motion blur trough oversampling (render 16 sub frames, combine them to
> one)
>
> If some of these things where present i would switch gladly from BI to
> GLSL instead. Fast rendering is always a good thing. If it also looks
> good enough, then it is perfect. At least in my opinion.
>
> Am 27.03.2012 22:58, schrieb Jason Wilkins:
>> This year I am considering proposing a new viewport for Blender as a
>> Summer of Code project.
>>
>> Name is subject to change.  I've already had one person think that I
>> want to preview compositing nodes in the view port.  That is not my
>> proposal.
>>
>> This email is to solicit some feedback so that I can write a good
>> proposal or change my focus and propose something else.
>>
>> The problems as I currently see them:
>>
>> * The current view port rendering code in Blender is a mess.
>>
>> * Extending the view port has to be done ad hoc and is even
>> recommended against due to its complexity
>>
>> * Taking advantage of modern opengl features might be especially
>> difficult.  These include:
>> - pixel buffers
>> - floating point or HDR formats
>> - depth textures
>>
>> Parts of a possible proposal:
>>
>> * re-factor all view port drawing operations into a set of composable commands
>> * enable rendering to pixel buffers
>> * compose pixel buffers using GLSL and/or blending operations
>> * new view port modes can be written as scripts, like Render Monkey or
>> DirectX Effect format (or even Quake 3 if you wanna go back that far)
>> * re-enable all current view port modes as just simple scripts in the new system
>> * create new view port modes (like Material Capture or SSAO)
>> * let expert users create their own custom viewports
>> * the ability to control view port script parameters using RNA, i.e.,
>> automatically add controls to the UI
>>
>> I am not proposing doing anything with the GLSL code generator that is
>> used for materials.
>>
>> I have not looked into how this integrates with the different view
>> port drawing modes (triple, etc.)
>>
>> I am concerned that PBVH drawing in 'partial redraw' mode may be more
>> difficult to integrate, or not.
>>
>> Cursor rendering probably is not affected.
>>
>> I discussed this briefly with Ton, he had some ideas about glowing
>> outlines around objects.  That kind of feature would be possible.
>> Part of my proposal could include a set of example view ports scripts
>> like that to get the expert users started.
>>
>> I'd like to really focus this year on a single goal with an easily
>> defined deliverable.
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers


More information about the Bf-committers mailing list