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

Antony Riakiotakis kalast at gmail.com
Wed Jul 9 18:52:59 CEST 2014


Great, I will make sure to check it out on my linux box too when ready.


On 9 July 2014 17:12, Jason Wilkins <jason.a.wilkins at gmail.com> wrote:

> It took a bit more time than I expected but I have a GLX implementation
> now.  I actually got it to work on OSX, so no need for me to setup a Linux
> box. (It didn't take much work to use x11 on osx actually)
>
> I'll be committing it later today after cleaning it up.
>
> This is a heads up for Antony since he indicated he wanted to look at the
> GLX context class.  It actually works on OSX but there may be a surprise on
> Linux so that would be a good idea.
>
> On Sunday, July 6, 2014, Jason Wilkins <jason.a.wilkins at gmail.com> wrote:
>
>> Beside GLX support I just need to get feedback.
>>
>> On Sunday, July 6, 2014, Antony Riakiotakis <kalast at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> It's not entirely clear to us what the state of the project is. We had
>>> agreed before GSOC to have GHOST initialization reviewed and merged as soon
>>> as possible, so that we could at least have the basis on which to port the
>>> new vertex streaming code.
>>>
>>> As far as I know this is not achieved yet.
>>>
>>> I would really rather one target is finished, reviewed and merged first,
>>> then move on to other targets.
>>> Not doing concentrated work will surely result again in unfinished work
>>> and the code in an uncertain state.
>>> Let's avoid that this time.
>>>
>>>
>>>
>>> On 5 July 2014 16:36, Jason Wilkins <jason.a.wilkins at gmail.com> wrote:
>>>
>>>> I set a few modest goals last week and I was a little disappointed that
>>>> that is about all I was able to do.  Then I realized I lost a couple of
>>>> days due to having to go home early one day (a pipe burst) and of course,
>>>> the July 4th holiday.
>>>>
>>>> This week:
>>>>
>>>> * Extension Shims - This is just a way of reducing the amount of
>>>> conditional compilation and branches that can happen due to the different
>>>> possible OpenGL APIs that may be available.
>>>>
>>>> * State Policy - Reducing the number of OpenGL API calls by choosing a
>>>> "policy" for each state that results in the fewest calls.  For example I
>>>> eliminated a few dozen calls to glBlendFunc by just assuming that the state
>>>> is GL_ALPHA/GL_ONE_MINUS_SRC_ALPHA.
>>>>
>>>> At this point I regretted that I ignored the Game Engine last year
>>>> because I'm not completely sure that all my state policies can hold across
>>>> all of Blender, BlenderPlayer, and the embedded Game Engine without more
>>>> testing.
>>>>
>>>> Next Week:
>>>>
>>>> One reason I was conservative about goals last week was that I wanted
>>>> to think about my next move, since it wasn't completely clear to be at the
>>>> time, but I think I figured it out.
>>>>
>>>> There is a module called "gpu_immediate" that is meant as a replacement
>>>> for immediate mode.  Not a great name since it is more like a vertex buffer
>>>> builder and is capable of saving vertex buffers for reuse.  My goal for
>>>> this week is to get that module into a reviewable state.
>>>>
>>>> There is some overlap between it and gpu_buffers and some of the cases
>>>> where Blender uses vertex arrays instead of immediate mode that should be
>>>> combined to remove the redundancy.  Also I've been meaning to use vertex
>>>> array objects for over a year now and I want to get to that.
>>>>
>>>>
>>>> _______________________________________________
>>>> Soc-2014-dev mailing list
>>>> Soc-2014-dev at blender.org
>>>> http://lists.blender.org/mailman/listinfo/soc-2014-dev
>>>>
>>>>
>>>
> _______________________________________________
> Soc-2014-dev mailing list
> Soc-2014-dev at blender.org
> http://lists.blender.org/mailman/listinfo/soc-2014-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/soc-2014-dev/attachments/20140709/f974ae38/attachment.htm 


More information about the Soc-2014-dev mailing list