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

[Jason Wilkins]

The design of the derived mesh, edit mesh, and subdivision mesh drawing
code is most like the result of slow accretion of features over time
(unfortunately, until I address it, I've added another layer to it).  It
should at least be separated into legacy and vbo versions (making 3
branches into 6 branches), and the legacy code eventually turned off.  I
wasn't aiming to fix that this summer.

I see fixing the situation as taking one step at a time while making sure
things don't get terribly broken in the meantime.

I don't remember what I said about legacy code providing a low memory
fallback.  My primary argument has always been that a lot of smaller
drawing code in Blender can be replaced systematically (almost
automatically) instead of completely rewritten.  However, I've never argued
that cdm, editmesh, and ccg shouldn't be completely overhauled.

I also wasn't arguing that doing wireframes in one pass shouldn't be done,
just that it would require a more detailed rewrite than I was prepare to do.

My goal was to create a middleware library that can be used to replace
deprecated functionality in such a way that the rest of Blender does not
have to be completely rewritten *all at once*

As a result, Blender can now even be run on top of Direct3D, so I think I
have succeeded for the most part.






On Sat, Sep 21, 2013 at 2:50 AM, David Jeske <davidj at gmail.com> wrote:

> 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.
>
>
>
> _______________________________________________
> Soc-2013-dev mailing list
> Soc-2013-dev at blender.org
> http://lists.blender.org/mailman/listinfo/soc-2013-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/soc-2013-dev/attachments/20130921/b884e295/attachment.htm