[Soc-2017-dev] Weekly Report #02 - Silhouette Operator

Sergey Sharybin sergey.vfx at gmail.com
Mon Jun 12 12:17:24 CEST 2017


Hi,

Was having a look into the branch this morning.

Here is feedback so far:

- Please follow our code style [1]. Otherwise it's a bit tricky to read the
code of mixed style.
- What's your compiler? There are some picky compiler errors, and some of
them are real bugs: for example, passing array as a pointer to array,
especially around BKE_pbvh_node_get_BB(). Those are reported immediately
 by GCC.
- Those two points iv'e addressed in the patch [2]. Please doublecheck it
and apply parts which are relevant (mainly check that i didn't break any
math).

There's some issue i've encountered: at the moment of alt-LMB (which is
supposed to start silhouette stroke) i've got full screen covered with some
sort of face.Rotating the view gets rid of it. Is it something you're
having as well? Additionally, i didn't have any geometry created, is that
something being commented out or so?

Now, answering your question from IRC (doing it here, so more developers
can have a look as well and comment):

- Overall design around sculpt_silhouette_stroke*() seems fine to me, this
is exactly something i was keeping in mind.
- Generating new geometry should indeed happen
in sculpt_silhouette_stroke_done(). But there's something weird with number
of polys you generate (currently it's stroke->totvert-1) Guess that's some
place-holder before doing some more sophisticated generation code?

Now, let's cover PBVH updates.

The idea you're implementing might work, but some things needs
clarification:

- Did you make sure the bounding box of leaf gets propagated up in the tree
hierarchy?
- Did you make sure that prim_indices, vert_indices, face_vert_indices
stored in PBVHNode are all correct after attaching the mesh?
- BKE_pbvh_attach_mesh seems to be attaching the whole mesh as a leaf,
while in theory it should only attach the new geometry.

Now, while it will be nice to be able to partially rebuild BVH, there are
some corner cases to be tackled here. Additionally, it is always a
trade-off between speed of BVH update and quality of BVH. This could
quickly make BVH non-optimal enough after few strokes, so you'll need to
rebuild it anyway.

For now i think it makes more sense to simply request full PBVH rebuild
after new geometry was created and focus on geometry generation itself.
PBVH update we can optimize later.

[1] https://wiki.blender.org/index.php/Dev:Doc/Code_Style
[2] https://hastebin.com/fugahojubi.diff

On Fri, Jun 9, 2017 at 6:44 PM, Sebastian Witt <W.Basti at gmx.de> wrote:

> *Week two is over, time for a small summary on the Silhouette Operator:*
>
>
>
> *   I designated this week to get the base done. A rough operator skeleton
> is now in place, custom draw-calls for the UI and first bare minimum
> geometry generation takes place. Here a short rundown of the different
> parts: Silhouette Operator Skeleton After abandoning the Idea of the
> silhouette brush the silhouette operator is now starting to take shape. In
> this week I implemented a simple standard modal operator. It has currently
> three stages. 1. Invoke, data for the silhouette gets allocated triggered
> by an alt-leftclick within sculpt-mode. 2. Modal, the drawn shape while
> holding the keys is saved and a visual UI representation is updated. 3.
> Exec, from the drawn shape 3D geometry gets generated and attached to the
> current PBVH. Afterwards data is cleaned up (more or less). This is just a
> basis for the operator it will most likely get extended by several stages
> to be able to make changes after sketching a new shape. Similar to other
> operators you should be able to change the input values afterwards and may
> be able to reshape the drawn silhouette. Custom Draw-Calls To get a visual
> feedback the operator needs a fitting UI. In this week I set the foundation
> for it by registering a custom draw call. Currently only a red contour is
> drawn but with the draw call in place this can easily be extended! One
> thing to note: The UI code uses OpenGL immediate draw calls which will get
> removed in 2.8 and will need to be ported later. -Shouldn’t be much of a
> problem though. Geometry Generation The biggest challenge I faced this week
> was definitely the geometry generation. The existing sculpting system does
> not support topology changes with the exception of dyntopo. My current
> approach aims to make it possible to insert a mesh into the PBVH mesh tree
> system without rebuilding the whole tree. I am currently at the point where
> i can insert a mesh into a one-node-tree with it not crashing instantly. I
> have now got a rough idea of the PBVH structure and i think i will soon be
> able to insert into more complex topology. It is a lot of pointer
> reshuffling, buffer updating and indices magic which took longer than
> expected and I am just at the start. I may need to reevaluate my approach
> even though i am confident it will work.   The foundation for the
> Silhouette Operator slowly takes shape. With this I will soon be able to
> get into a more explorative workflow!   Best Regards, Sebastian Witt
> Current Branch status:
> https://developer.blender.org/rBce2671b0e29ba91e38d88858d5f5aba387d4e0c2
> <https://developer.blender.org/rBce2671b0e29ba91e38d88858d5f5aba387d4e0c2>
> To try the Silhouette Operator press alt-leftclick in sculptmode and draw a
> shape. When drawn without overlap of a simple object a shape gets
> generated. (crashes most likely) *
>
>
> _______________________________________________
> Soc-2017-dev mailing list
> Soc-2017-dev at blender.org
> https://lists.blender.org/mailman/listinfo/soc-2017-dev
>
>


-- 
With best regards, Sergey Sharybin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/soc-2017-dev/attachments/20170612/9aadfd7f/attachment.htm 


More information about the Soc-2017-dev mailing list