[Soc-2017-dev] Weekly Report #02 - Silhouette Operator
Sebastian Witt
W.Basti at gmx.de
Mon Jun 12 13:30:24 CEST 2017
Hi Sergey,
Thanks for checking the code!
The points you addressed are exactly what i needed! Here are my thoughts
on it:
"Please follow our code style" - Yes i really should and tried to in
earlier patches. It is currently in a very experimental stage so i just
wanted to get a rough setup to see if it works ;). My coding style
suffered from it. A bad habit i will try to get rid of :)
"What's your compiler?" - I am developing with XCode with the standard
LLVM apple 8.0 compiler. I got reports and warnings about passing arrays
as pointers i just didn't fix those errors yet. -Again bad "i can clean
it up later" attitude. I will try to get a cleaner workflow!
"Those two points iv'e addressed in the patch" Thanks a lot for the
cleanup! All my warnings are gone.. i wonder why ;)
"i've got full screen covered with some sort of face" - The UI related
bugs are due to inconsistent draw calls and they way i implemented the
stroke system. For me it rarely happens though. I have created a quick
gif to show how it should look like [1]. I wanted to address the UI
stuff later and thought it is working good enough for now.
"Additionally, i didn't have any geometry created" - Currently geometry
is only created in a very rare corner case. Only when drawing outside of
a one-node-object. It is the simplest case so i started with that. In
the other cases just some debug boxes for the nodes to integrate into
are drawn.
"But there's something weird with number of polys you generate" - Indeed
that is just a placeholder for the generation later. Currently it just
generates an extruded line below the stroke. (stroke->totvert is the
number of verts drawn)
"Did you make sure the bounding box of leaf gets propagated up in the
tree hierarchy" - I just addressed this this morning, but multiple
values need to propagate in the tree
prim_indices, vert_indices, face_vert_indices etc. like you've said
these need to be setup as well. Currently they are partially updated,
thats what i was currently working on.
"BKE_pbvh_attach_mesh seems to be attaching the whole mesh as a leaf" -
Currently it searches for the closest node if not within one and inserts
the new data. When inserting the data into the PBVH multiple cases might
happen. Just to name a few:
* New Mesh is inside a node and node.verts+mesh.verts < node.limit
| update single node
* New Mesh is outside of all nodes and node.verts+mesh.verts <
node.limit | resize node and include new verts
* New Mesh needs to be integrated into multiple nodes
* New Mesh is bigger than node limit | multiple new nodes need to
be generated etc.
There a are a more cornercases so there is a lot to keep in mind.
"This could quickly make BVH non-optimal enough after few strokes" - I
think if those cornercases are addressed and the mesh is well integrated
it is possible to maintain a clean BVH tree.
"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." - I agree! With all those
cornercases and different vert arrays which will need to be reshuffled
it is better to focus on that later! Even though most of the last week
work was about integrating into the PBVH and most of it needs to be
wiped out. I've now got a good idea of the tree structure and i think i
will be able to integrate it properly later. (Dyntopo might need a
completely different logic as well)
Thanks a lot for the feedback and the cleanup!
Sebastian Witt
[1] http://pasteall.org/pic/show.php?id=116328
On 12.06.17 12:17, Sergey Sharybin wrote:
> 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
> <mailto:W.Basti at gmx.de>> wrote:
>
> **
>
> *Week twois 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 <mailto:Soc-2017-dev at blender.org>
> https://lists.blender.org/mailman/listinfo/soc-2017-dev
> <https://lists.blender.org/mailman/listinfo/soc-2017-dev>
>
>
>
>
> --
> With best regards, Sergey Sharybin
>
>
> _______________________________________________
> Soc-2017-dev mailing list
> Soc-2017-dev at blender.org
> https://lists.blender.org/mailman/listinfo/soc-2017-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/soc-2017-dev/attachments/20170612/914560af/attachment-0001.htm
More information about the Soc-2017-dev
mailing list