<br><br>On Saturday, May 31, 2014, Sergey Sharybin <<a href="mailto:sergey.vfx@gmail.com">sergey.vfx@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">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.</div></blockquote><div><br></div>
I wouldn't suggest that anything be postponed. I could put off merging, but I'm not convinced it would save work later. Seeing as how this year was significantly less work than last year supports that idea (even though it is anecdotal). The difference is merging after 2 months versus 6. It has to be done eventually.<div>
<br></div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div><br></div><div>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?</div>
</div></blockquote><div><br></div><div>Calling it a compatibility layer is probably somewhat of a misnomer. I did designed it to allow legacy OpenGL drivers to work, but it's more like a custom shader support library written on top of OpenGL 3 core that can fall back to older gl.</div>
<div><br></div><div>I actually feel that no gl calls should be made outside of the gpu source directory. I'll continue this thought below...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div><br></div><div>Would really suggest making smaller steps in order to make stuff mergeable to master:</div><div><br></div><div>- 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.</div>
</div></blockquote><div><br></div><div>Right.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">
<div>- 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.</div>
</div></blockquote><div><br></div><div>I would say that over 3/4 of the functions used in Blender drawing code do not exist in core GL. If there were no legacy code at all in Blender we would still want something like the misnamed compatibility layer to make drawing code readable.</div>
<div><br></div><div>Still, the idea of bringing up one module at a time is best, but I do not see the benefit of writing the drawing code, say, in an editor, directly on top of OpenGL. </div><div><br></div><div>OpenGL was low level to begin with. OpenGL 3 is even lower level. Putting code to manage shaders, buffers, and uniforms in higher level code like an editor seems wrong. </div>
<div><br></div>That is why I've taken to calling the compatibility layer a "replacement". It is not compatible with legacy OpenGL, but tries to capture how blender actually uses legacy OpenGL and only implements that functionality which needs to be replaced since it was removed from core. It has a similar interface to make porting easier.</div>
<div><br></div><div>I admit that bringing everything up and live at once might not be the best, but, I also couldn't be sure I had captured everything without actually doing that.</div><div><br></div><div>But now it is clear that I don't have to maintain it anymore since all of the functionality has been proofed. I can now bring up one module at a time without fearing that something in the next module is going to force me to go back and redesign everything.</div>
<div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">
<div>- Then port all the rest areas to new GL. Something like: port them, test them, merge them.</div></div></blockquote><div><br></div><div>The porting has already been done. I don't think you really want me to inline the OpenGL 3.2 code out of the replacement code. My replacement might not have the best design, but I believe it's existence is the correct decision and can be improved as time goes on.</div>
<div><br></div><div>A side note, I wouldn't use the word "fail" to describe my work. I'm guessing you mean I've failed to contribute anything to master. I'll agree with that, and I'm focused on rectifying that.<span></span></div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, May 31, 2014 at 4:12 PM, Campbell Barton <span dir="ltr"><<a href="javascript:_e(%7B%7D,'cvml','ideasman42@gmail.com');" target="_blank">ideasman42@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Recommend meld:<br>
<a href="http://meldmerge.org" target="_blank">http://meldmerge.org</a><br>
<br>
It can be set as git's mergetool and handles 3way merges pretty nice.<br>
<br>
Although I never tried other tools (probably vimdiff is good too if you use vim)<br>
<div><div><br>
On Sat, May 31, 2014 at 3:28 PM, Jason Wilkins<br>
<<a href="javascript:_e(%7B%7D,'cvml','jason.a.wilkins@gmail.com');" target="_blank">jason.a.wilkins@gmail.com</a>> wrote:<br>
> Last year took a few weeks to gain momentum due to fixing up the code after<br>
> merging, so I should have realized I might be in the same boat this year.<br>
><br>
> Luckily, I seem to have learned a thing or two about how to manage this so I<br>
> should have things working again by the end of the weekend. It helps that I<br>
> merged things back in March, but some recent changes to the rendering code<br>
> (loop normals?) caused a lot of pain.<br>
><br>
> The switch to git also helps a lot.<br>
><br>
> This week I've started to contact users about helping me develop and run a<br>
> set of regression and performance tests. There is a thread on Blender<br>
> Artists here:<br>
><br>
> <a href="http://blenderartists.org/forum/showthread.php?338377-Viewport-FX-III" target="_blank">http://blenderartists.org/forum/showthread.php?338377-Viewport-FX-III</a><br>
><br>
> Next week I'll be putting up for review the changes to GHOST that separates<br>
> the window system from the opengl context. I had hoped to have this ready<br>
> to go before gsoc started, but I ended up having to meet some other<br>
> deadlines :(<br>
><br>
> I'm also going to pull some other things out like additional math functions<br>
> and the replacement for the OpenGL matrix stack. While I want to mainly<br>
> focus on getting things that could/can cause lots of conflicts reviewed<br>
> first, I think some modules like a CPU based matrix stack might be useful<br>
> libraries for others to be able to use.<br>
><br>
> Although my branch currently compiles on Windows, it is broken, and does not<br>
> draw properly due to the merge. As I review the diff in order to find<br>
> patches to submit I'm also going to be trying to fix that. grr..<br>
><br>
> No major questions right now.<br>
><br>
> I might venture to ask for people's opinion. I currently use kdiff3 as my<br>
> merge tool. I've found it really helps compared to the tool that comes with<br>
> Tortoise, but really those are the only two tools I've ever used. So, my<br>
> question would be, does anybody have a tool that runs on Windows or MacOS<br>
> that they think is better than kdiff3? I would be open to learning a new<br>
> tool if it would speed merging further, since I have gotten a lot of<br>
> practice at that lately...<br>
><br>
</div></div>> _______________________________________________<br>
> Soc-2014-dev mailing list<br>
> <a href="javascript:_e(%7B%7D,'cvml','Soc-2014-dev@blender.org');" target="_blank">Soc-2014-dev@blender.org</a><br>
> <a href="http://lists.blender.org/mailman/listinfo/soc-2014-dev" target="_blank">http://lists.blender.org/mailman/listinfo/soc-2014-dev</a><br>
><br>
<span><font color="#888888"><br>
<br>
<br>
--<br>
- Campbell<br>
_______________________________________________<br>
Soc-2014-dev mailing list<br>
<a href="javascript:_e(%7B%7D,'cvml','Soc-2014-dev@blender.org');" target="_blank">Soc-2014-dev@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/soc-2014-dev" target="_blank">http://lists.blender.org/mailman/listinfo/soc-2014-dev</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><span style="color:rgb(102,102,102)">With best regards, Sergey Sharybin</span></div>
</div>
</blockquote></div>