[Bf-committers] Unlimited clay patch review

[Hart's Antler]

Hi Raul,
Please don't give up on Unlimited Clay, every blender artist i know is excited about Unlimited Clay.

On a side note: it probably is better to have it as a modifier, at least thats my feeling.
-brett


--- On Mon, 5/23/11, raulf at info.upr.edu.cu <raulf at info.upr.edu.cu> wrote:

> From: raulf at info.upr.edu.cu <raulf at info.upr.edu.cu>
> Subject: Re: [Bf-committers] Unlimited clay patch review
> To: "bf-blender developers" <bf-committers at blender.org>
> Date: Monday, 23 May, 2011, 12:22 PM
> Hi there :)
> 
> Yes, the patch is more like spagetty code and for internal
> development, I
> use all of those hacks in order to get a working system
> first, and only
> then start reworking/redisigning into a readable form.
> UnlimitedClay is
> about mixing two very separated functionality in Blender
> source code:
> sculpting and mesh editing, and as a result I have to move
> around parts of
> the code to make them visible to other parts, that's why I
> have broken the
> encapsulation principle but I always think of that as a
> temporal solution,
> not something worth to be taken into account.
> I know everyone is busy, so do I releasing the first public
> beta or
> LiveClay for 3DCoat, UnlimitedClay now has two betas ...
> well, they're
> more like alphas ;)
>  I don't expect too much aid in porting it to new sources
> rigth now, so I
> think I will have to make the migration from EditMesh to
> BMesh on my own,
> also I don't like the modifier approach but only time will
> tell whether
> is better or not to have it as an integral feature of the
> sculpting
> module or as a modifier.
> 
> due to the low feedback I'm getting from unlimitedClay for
> Blender .. are
> people still interested on it? I'm still here :(
> >   Hi, Blender Community!
> >
> > I've reviewed unlimited clay patch yesterday. I
> haven't been able to
> > apply patch/compile correctly, so i can't give
> feedback about how things
> > are working, but i could give some feedback about
> patch itself.
> >
> > - First of all it's created against a bit outdated
> version of trunk --
> > some files were moved, some functions renamed and so.
> It lead to plenty
> > of rejected hunks in patchs.
> > - Patch contains plenty of non-functional changes:
> whitespace changes,
> > somewhere "styling" changes, somewhere changed "logic"
> -- code in
> > non-unlimitedclay related code was replaced with
> different code whick
> > makes the same things (like normals in
> getEditMeshDerivedMesh). This
> > makes patch much more difficult to be applied against
> newer trunk and
> > readability of this patch also lower -- can't split
> what is actually
> > changes and what's not.
> > - That including of "ED_mesh.h" in DerivedMesh.c and
> pbvh.c. It's not
> > only ugly usage of absolute path. but it's also a
> breaking of
> > archeticure -- blenkernel/ and blenlib/ shouldn't use
> editors/. I
> > suppose editmesh is needed for easier changing mesh
> topology, but i also
> > suppose it could be made without such hacks. For
> example add some
> > utility functions to blenkernel/intern/mesh which
> would provide list of
> > verts/edges/faces (similar lists as in editmesh). I
> think it's the most
> > worth thing for which EditMesh is used atm.
> > - I also not sure why it's needed to move structures
> (like
> > EditMeshDerivedMesh, StrokeCache, PBVH, PBVHNode and
> so) from .c-fiels
> > into headers. This structures aren't supposed to be
> reused outside of
> > their module and they should be a blackbox for other
> modules.
> > - Styling should be checked. I'd prefer to keep only
> one style inside
> > one module. Check comments, brackets, spaces and so.
> > - Also it looks like there's some unused code adding
> by patch but which
> > isn't used.
> > - I'm not fully like all that new fields inside
> EditVert. Maybe they
> > could be moved inside tmp union or EditVert->data
> could be reused? Or as
> > i mentioned, EditMesh could be replaced by something
> more light and
> > common... Or maybe it'll be special structure for
> unlimited clay
> > purposes and functions like {make,load}_clayMesh?
> > - I'm not sure why stuff like BLI_pbvh_iter_end should
> be changed?
> >
> > That's all feedback i could give atm.
> >
> > We discussed a bit ways to split out unneeded changes
> with Tom, but not
> > sure that ways would be useful. I'd prefer if manual
> reading of patch
> > would be done -- in this case all outdated stuff would
> be found.
> >
> > I hope it'll help to make patch better and acceptable
> to be commited.
> >
> > --
> > With best regards, Sergey I. Sharybin
> >
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> 
> 
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> - Participe en Universidad 2012, del 13 al 17 de febrero de
> 2012. Habana. Cuba. http://www.congresouniversidad.cu
> 
> - Consulte la Enciclopedia Colaborativa Cubana. http://www.ecured.cu
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>