[Bf-committers] Compositing View Port Proposal

Jason Wilkins jason.a.wilkins at gmail.com
Wed Mar 28 18:47:01 CEST 2012


So far I have several suggestions that I'd put in the "don't do
anything that would make this difficult in the future" column.

They would be:
integration with compositor
integration with game engine
integration with OpenGL renderer

I'm hoping this can be managed just by employing good software engineering :-)

I can't promise anything though.


On Wed, Mar 28, 2012 at 10:09 AM, Tobias Oelgarte
<tobias.oelgarte at googlemail.com> wrote:
> Yes i would do that. In many cases I don't really need reflections,
> glass with IOR or even ambient occlusion. If both would work nearly
> pixel exact AO could still be added by rendering with BI as a second
> pass for compositing.
>
> Currently we have a OpenGL Render capability (the two buttons on the
> right side of the 3D-View menu bar) which is quite useful sometimes, but
> it lacks the mentioned features which are such heavy drawbacks, that it
> isn't a real option to replace rendering. Soft shadows would be my
> personal main priority and the Game Engine would definitely profiting
> from it.
>
> Am 28.03.2012 14:19, schrieb Jason Wilkins:
>> 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
>> _______________________________________________
>> 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