[Bf-committers] Compositing View Port Proposal

[Jason Wilkins]

On Tue, Mar 27, 2012 at 11:16 PM, Campbell Barton <ideasman42 at gmail.com> wrote:
> Quick reply on this topic...
>
> * happy view-port is getting some attention, it needs it :)

Great, I hope I can provide a good proposal.

> * Project seems ambitious, suggest to provide minimum targets in your proposal.

I think the minimum target is to divide all the different view point
drawing operations into separate and repeatable commands that can
re-directed into different render targets (including the screen).
There should be some sort of abstract syntax data structure for
representing commands and some new commands for composition.

> * I would feel better about this project if our view-code was in a
> better state, Ideally IMHO this code should be improved before large
> changes like this (draw modes and settings are mixed up and not nice
> from code or user POV)

I'm setting aside time this week to dig further into the code.  I'm
familiar with it enough from what I've done with it to realize it is
full of conditions.

> * One problem with large changes to our OpenGL drawing is our
> selection code which is tricky - mixed bone/object select, vertex
> select, face & vertex select in weight paint mode - supporting all
> configurations is probably not trivial if you plan to refactor this
> code.

It may be, my strategy for this kind of thing right now is to make a
command called "draw bone/object with select" or "draw with weight
paint select" and re-factor those commands later if needed.

There are other problems, like partial-redraw of a PBVH object that I
have not even thought about enough to know if it can work in general,
although I think preserving the contents of some buffers between
frames may be good enough.

> * Rule of thumb - we support 5 year old hardware, can this be done on
> standard/crappy GFX cards from 5 years ago? - if not is there a
> reasonable fallback which wont complicate things too badly?

I have a GeForce 9800 GTX which was released in 2008.  It was a
high-end card at the time and I hate to think about how it would be
considered a poor card now because its wicked fast... for 2008 :-(

At the minimum level the opengl commands issued by a view-draw script
would be the same as those issued now.  The difference is they would
be scriptable.  If the script says to render to off screen buffers,
that capability was available in DirectX 8 which is over 10 years old
I think.  Compositing buffers with blend ops is as old as OpenGL.
Compositing buffers using GLSL then is the only thing you may be
worried about, and it is optional, and I also think it may be well
over 5 years old at this point.

The main point is that basic functionality requires nothing new from a
user's hardware.  Deciding to make a new view-draw capability a
standard part of Blender instead of a user add-on would be the same as
it is now.  However, scripts could support advanced options with some
ability to fallback or at least warn the user if their hardware can't
handle it.

> - Campbell
>
> On Wed, Mar 28, 2012 at 12:43 PM, Mike Erwin <significant.bit at gmail.com> wrote:
>> With all the major stuff you've done for sculpt, what I meant was "if
>> anyone can tackle a tough problem, it's you." Sorry for being unclear!
>>
>> So for instance the 3D view, would you issue one call like "3D view,
>> draw thyself", then composite widgets & overlays on top of that based
>> on a script? Or does it go deeper into how the 3D view is actually
>> drawn? Or am I missing the point entirely?
>>
>> Mike Erwin
>> musician, naturalist, pixel pusher, hacker extraordinaire
>>
>>
>>
>> On Tue, Mar 27, 2012 at 7:06 PM, Jason Wilkins
>> <jason.a.wilkins at gmail.com> wrote:
>>> On Tue, Mar 27, 2012 at 4:50 PM, Michael Fox <mfoxdogg at gmail.com> wrote:
>>>> Oh yes it is more then a mess, its a nightmare, I am trying to add view
>>>> tessellation option to the view port, and im having one hell of a hard
>>>> time. we defiantly need an cleaning out
>>>
>>> I'm curious what you are trying to do.
>>>
>>> To answer Mike's question about if I can handle this, yes, I am rather
>>> confident.  The fancy view port could be written along side the
>>> existing one where it can grow features until it replaces the old one.
>>>  That is also good for A-B switching.
>>>
>>> Although I want to emphasis generality and programmability, which are
>>> sometimes evil tar-pits, I can start with a very domain specific set
>>> of pieces and replace those with more general pieces as time allows.
>>>
>>> In other words, as long as I don't try to jump straight to absolute
>>> best implementation right away I'll be fine.  I think this is
>>> something that can be made to approach "perfection" over multiple
>>> iterations instead of something I get stuck in over my head.
>>> _______________________________________________
>>> 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
>
>
>
> --
> - Campbell
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers