[Soc-2013-dev] Weekly Report 13-14 Viewport FX

[David Jeske]

On Fri, Sep 20, 2013 at 11:58 PM, Jason Wilkins
<jason.a.wilkins at gmail.com>wrote:

> It is getting to a point where I can start experimenting with new
> techniques, such as drawing wires and lighting in a single pass.  It is
> quite a bit just to refactor things so that everything can be drawn using
> GLSL, so that was my focus this summer.
>

I have only just begun to look at what you've done, so I'm sure to
mis-understand something...

It feels a bit odd to have this draw-array/GLSL code if-conditioned into
the existing functions (ccdm_draw*), rather than providing an alternate
version of those functions. Though I also find it odd that each DerivedMesh
has it's own function pointers, rather than having a single shared
DerivedMeshHandler struct of function pointers (kind of like a class
vtable).

I noticed a comment on your BA thread about how the legacy code provides a
good low-memory fallback... Why is this necessary? Do you buffer lots of
draw-arrays? I don't see any reason a fallback like this should be needed.
"modern" GLES/GL doesn't even have the old legacy immediate calls.


> Also, the wireframe isn't exactly one-to-one with the primitives used to
> draw the solid, so it would actually be rather complicated to pass which
> edges to draw into the shader (at least, it would require a lot of work to
> rewrite it work right).
>

While this is a good point, all those extra loops over the data surely
can't help performance. I think BMesh has enough information to spit out
the right data into the face-render, and the loose-edges can probably be
rendered as quads right into the same array-list.

I'll have to dig through that code and see if I can make sense of it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/soc-2013-dev/attachments/20130921/f6773e98/attachment.htm