[Bf-viewport] Viewport

[Rojuinex]

Yes it was my intent to help with replacing the immediate mode code, but wasn't sure how to do it. Now I see what to do. Also is master the branch I should work from or is there another I should work from?

Sent from my iPhone

> On Aug 21, 2015, at 03:47, Antony Riakiotakis <kalast at gmail.com> wrote:
> 
> Hi,
> 
> While the design of the new viewport is not final, I would not invite
> people to start working on that, but the viewport target is full of
> little
> subtargets that can be handled collectively.
> 
> I think the easiest pick for a new developer is to find and eliminate
> immediate mode drawing calls throughout blender's code base.
> Those should be substituted by our GPUBuffer system (Check
> GPU_buffers.h and gpu_buffers.c). This should not be that difficult
> and
> there's actually much drawing code in blender so help there would be
> quite welcome.
> 
> The GPUBuffer system in the file itself is a bit tied to how
> derivedmeshes work, but ultimately, GPUBuffers are just, well, arrays
> of data.
> What is missing from the GPU buffer system, is a -generic- way of
> representing the vertex format, where again the code is too tied to
> the derivedmesh system. However for most drawing code in blender (UI
> for instance) we need a few ready-made vertex formats, such as
> vertex-uv or vertex-color-uv, which don't really require a specialized
> system to deal with.
> 
> So again, if you'd like to help, I'd recommend:
> 
> * Scout the code for glBegin/glEnd/glVertex
> * Create small GPUBuffers to hold the data instead. These could be
> dynamically generated and deleted if the underlying code treats them
> like that or cached somewhere if the size remains the same or if a
> clear owner of the buffer with clear invalidation rules can be
> determined. Keep in mind that there mush be a way to clear those
> GPUBuffer caches centrally (in case of context invalidation, user
> preference changes for type of buffers used, etc). For some reusable
> things like button styles, rectangles etc, we could probably have some
> cached reusable buffers somewhere.
> 
> Another subproject we could use help with is substituting the OpenGL
> matrix stacks with our own. There is already code that does that in
> the temp_viewport_fx_merge branch but the way it does it currently is
> by hooking a matrix flush to OpenGL before every draw call which is
> horribly inefficient and was done only to prove the proof of concept
> works. Ideally flushing should be done before drawing only if the
> matrices haven't changed. The lazy way to do this is to just add
> checks before each draw call, but the proper way to do it is by
> examining the code and only do it when we must (no checks, just
> programmer vigilance). The reason is simple: Not all draw calls use
> matrices. In fact, for some things like UI we could very well use
> entirely 2D pipeline/shaders in the future). Flushing in that case is
> just wasted cycles.
> It's a highly volatile project though and would not recommend it to beginners.
> Probably there will be some code from me there first, then we can
> proceed and do the call for help, just like with the recent
> looptriangle refactor.
> _______________________________________________
> Bf-viewport mailing list
> Bf-viewport at blender.org
> http://lists.blender.org/mailman/listinfo/bf-viewport