[Soc-2014-dev] Weekly Report #02 - Viewport FX III

Sat May 31 23:54:28 CEST 2014

On Saturday, May 31, 2014, Martijn Berger <martijn.berger at gmail.com> wrote:

> Hi Jason, Sergey, Campbell,
>
> I think I agree with Sergey that the scope of what you are trying to
> achieve is really huge. It is a cool project though and in my opinion very
> very needed as many cool future things depend on it and getting to the
> latest features on all platforms (especially Apple) is being made harder
> when needing legacy GL.
>

More input is welcome.  I feel like I've probably gone out on a limb and
people might proceed to cut that limb off.

> One thing that is not really super clear to me is what subset of OpenGL
> features we are targeting for this. I would guess that the intersection of
> OpenGL ES 2.0 / OpenGL 3.2 core context is the feature level would make a
> good lowest common denominator to have blender's GL work.
>

This would only be true for certain things like the interface and the most
basic drawing.

Advanced features can be detected optionally.  My work has largely been let
blender draw almost anything at all when the deprecated features are
removed without making the code significantly worse.

IMO, I think low level OpenGL 3+ drawing code in the places in using my
replacement API would be horrible.

> I have no experience with porting large scale projects like blender form
> using legacy OpenGL to something slightly more modern but generally
> speaking I would say that trying to do a compatibility layer just sort of
> moves the problem around.
>

Imagine if I rewrote blender to use OpenGL 3.2 core in a straightforward
way and then factored out the common patterns of use so I didn't violate
DRY (don't repeat yourself).

I think it would look a lot like what I've done so far.

Yes, some things might be better if they were completely rewritten in the
new style.  I've made a bet that my approach is less work since porting is
mostly search/replace.  Performance critical areas can be rewritten as they
are discovered.

> And I would think the newer way of handling GL calls is here to stay so we
> might just bite the bullet and move over to it. It will not be easy and
> most likely some people will cry about it but I really think it is
> unavoidable in the long run.
>

I think the crying and gnashing of teeth is inevitable. The "compatibility"
is not there solely to appease programmers.  I think the alternative of
using OpenGL 3 directly is worse.  It is better if programmers don't have
to write the same boilerplate every time they want to draw something simple.

The library can also be improved as time passes.  I'm sure patterns will
emerge that can be exploited and the API can be made friendlier and faster
than what it replaced.

>
>
>
> And if that makes your project easier and therefore more likely to succeed
> that is a good thing.
>

I'm not sure what bullet I'm supposed to be biting.  If I started out
rewriting things directly in OpenGL 3 I'd probably be in a similar place
that I am now.

The mistake I've made seems to be to continually underestimate how much
work the next merge is going to be.  I need to start slicing vertically
instead of horizontally.

I do think the horizontal step was needed, but that's just not the way
forward now.  I get that now.  I feel a little silly for having to have it
pointed out :-)

>
>
>
> --
> With best regards, Martijn Berger
>

>
>
> On Sat, May 31, 2014 at 12:27 PM, Sergey Sharybin <sergey.vfx at gmail.com>
> wrote:
>
> I'm not sure why to blame merges. We couldn't postpone everything
> actually. Not even sure why it might be an issue for the project. You might
> easily ignore them for now.
>
> Looks like you're trying to put all the legacy code onto the compatibility
> layer and bring it to live all together, which is rather a huge project and
> which didn't work two times already. What is the point of compatibility
> layer anyway?
>
> Would really suggest making smaller steps in order to make stuff mergeable
> to master:
>
> - Put all the stuff needed from GHOST side and all the mathutils stuff and
> other utility functions to master. This should work just fine with the
> legacy OpenGL we're using.
> - In the branch start porting areas one-by-one into new GL. Starting with
> window draw and interface elements. And by porting i mean port to new GL
> calls, not some compatibility layer. It should even be possible to have
> interface using newer GL and viewport using legacy code.
> - Then port all the rest areas to new GL. Something like: port them, test
> them, merge them.
>
>
> On Sat, May 31, 2014 at 4:12 PM, Campbell Barton <ideasman42 at gmail.com>
> wrote:
>
> Recommend meld:
> http://meldmerge.org
>
> It can be set as git's mergetool and handles 3way merges pretty nice.
>
> Although I never tried other tools (probably vimdiff is good too if you
> use vim)
>
> On Sat, May 31, 2014 at 3:28 PM, Jason Wilkins
> <jason.a.wilkins at gmail.com> wrote:
> > Last year took a few weeks to gain momentum due to fixing up the code
> after
> > merging, so I should have realized I might be in the same boat this year.
> >
> > Luckily, I seem to have learned a thing or two about how to manage this
> so I
> > should have things working again by the end of the weekend.  It helps
> that I
> > merged things back in March, but some recent changes to the rendering
> code
> > (loop normals?) caused a lot of pain.
> >
> > The switch to git also helps a lot.
> >
> > This week I've started to contact users about helping me develop and run
> a
> > set of regression and performance tests.  There is a thread on Blender
> > Artists here:
> >
> > http://blenderartists.org/forum/showthread.php?338377-Viewport-FX-III
> >
> > Next week I'll be putting up for review the changes to GHOST that
> separates
> > the window system from the opengl context.  I had hoped to have this
> ready
> > to go before gsoc started, but I ended up having to meet some other
> > deadlines :(
> >
> > I'm also going to pull some other things out like additional math
> functions
> > and the replacement for the OpenGL matrix stack.  While I want to mainly
> > focus on getting things that could/can cause lots of conflicts reviewed
> > first, I think some modules like a CPU based matrix stack might be useful
> > libraries for others to be able to use.
> >
> > Although my branch currently compiles on Windows, it is broken, and does
> not
> > draw properly due to the merge.  As I review the diff in order to find
> > patches to submit I'm also going to be trying to fix that. grr..
> >
> > No major questions right now.
> >
> > I might venture to ask for people's opinion.  I currently use kdiff3 as
> my
> > merge tool.  I've found it really helps compared to the tool that comes
> with
> > Tortoise, but really those are the only two tools I've ever used.  So, my
> > question would be, does anybody have a tool that runs on Windows or MacOS
> > that they think is better than kdiff3?  I would be open to learning a new
> > tool if it would speed merging further, since I have gotten a lot of
> > practice at that lately...
> >
> > _______________________________________________
> > Soc-2014-dev mailing list
> > Soc-2014-dev at blender.or
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/soc-2014-dev/attachments/20140531/4a3c560c/attachment-0001.htm 