[Bf-viewport] Viewport

[Mike Erwin]

Hey guys,

No mention of the GPUx library? I designed it to be a faster, safer,
easier-to-use replacement for blender's GPUBuffer. It can be found in the
GPU_data_request branch.

I'd actually like to pull this out and treat it like a 3rd-party library
that blender can (and in my opinion *should*) use. It's pretty generic so
will be useful in other projects too. I've got plans to extend it to other
languages: C++11 and JavaScript. And other targets: WebGL and Vulkan (once
the spec is released).

(GPUx is a temporary name, need to come up with a more descriptive name for
it.)

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Fri, Aug 21, 2015 at 4:43 PM, Rojuinex <rojuinex at gmail.com> wrote:

> 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
> _______________________________________________
> Bf-viewport mailing list
> Bf-viewport at blender.org
> http://lists.blender.org/mailman/listinfo/bf-viewport
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-viewport/attachments/20150821/530e4fae/attachment.htm