[Soc-2017-dev] vertex paint project - ply exporter

Howard Trickey howard.trickey at gmail.com
Tue Jul 18 12:44:50 CEST 2017 

Hi Darshan,

Glad you seem to have found the slowdown. I will try myself soon.

Did you see the note from Ton about how to set up Buildbot to build your
branch automatically for artists to test? He said:

- Reminder: if you need test builds, any committer use buildbot to make a
build with a patch:
https://wiki.blender.org/index.php/Dev:Doc/Process/Buildbot_Experimental

Why don't you try to do that for your branch?  Let me know if you need help
understanding the instructions.

Also, as you saw in the BlenderArtist thread, there was some pushback on
the idea that your first implemented (based on Fabio's patch) that the
alpha wouldn't be affected by blending mode in the same way as the other
channels.  What do you think? What do other mentors on this list think?  I
think you may want to try changing the functions to have alpha affected the
same was as the other channels, to see what artists think.  There was also
the intriguing idea of "channel lock" that was brought up: you could put up
buttons for r,g,b,a such that when you depress any of those buttons, the
corresponding channel is unaffected by the brush.  That also might be
something to look into.

On Tue, Jul 18, 2017 at 5:50 AM Darshan kadu <darsh7807 at gmail.com> wrote:

> Hello, Mr. Howard,
>
> I think I was right, that lag was due to the print statement.  After I
> removed it the speed is increased, though at the higher no of vertices like
> 4,00,000 it was bit slow as compared to the 2016 branch.
>
> I tried to disable the blend mode but speed was more or less same(why
> speed will decrease with more blend option may be cause of additional
> camparasions?) the non-occulded testing function also not affecting the
> speed much.
>
> I tested it, it seems to be the fine speed to me. What do you think of it?
>
> Thank you.
>
> On Mon, Jul 17, 2017 at 11:06 PM, Howard Trickey <howard.trickey at gmail.com
> > wrote:
>
>> Good that you have isolated the problem to a display issue. I will see if
>> I can figure out later what is going on.  I still suspect it might be
>> backfaces.  Meanwhile, you should move onto other things, like the speed
>> issue investigation.
>>
>> The things you see printed on the console are from a stray debugging
>> printf that you left in do_vpaint_brush_draw_task_cb_ex (which you should
>> remove and commit).
>>
>> On Mon, Jul 17, 2017 at 1:26 PM Darshan kadu <darsh7807 at gmail.com> wrote:
>>
>>> Hello, Mr. Howard,
>>>
>>> Today as you said before I tried to print the values of colors at
>>> various location, but again no result.
>>>
>>> Well, during the whole process it was always found that the color was
>>> getting assigned to the vertices correctly.
>>>
>>> What I think is there might be the problem in the 3d window as you
>>> mention in #case 2, almost at all the places alpha was being considered
>>> whenever col was used.
>>>
>>> If the subdivider would have used some different interpolation method
>>> then the final color would also have been different, but after printing it
>>> is same as other if we give all of them the same color. So what exactly
>>> happening is the final vertices have the same color along with alpha but
>>> the 3d display is different.
>>>
>>>  Also, if we subdivide the darker face which forms after the subdividing
>>> it gets the same color(confused).
>>>
>>> I don't know why this happens (this may be the reason), that when we run
>>> the blender as " blender.exe --debug", while vertex painting we see the ",
>>> ," and occasionally 1 getting printed on the command prompt., (may be this
>>> might be the reason for the slowness?) I will look into more detail of it.
>>>
>>> Thank you.
>>>
>>> On Mon, Jul 17, 2017 at 10:30 PM, Howard Trickey <
>>> howard.trickey at gmail.com> wrote:
>>>
>>>> Hi Darshan,
>>>>
>>>> Did you make any progress on discovering the problem with the values
>>>> after subdividing?  I haven't had time to look myself.  Though I did have
>>>> several thoughts:
>>>> 1) maybe the subdivide code uses some special purpose code in some
>>>> cases in order to do the interpolation?
>>>> 2) maybe the final values after subdivide are actually right but the
>>>> display in the 3d window is somehow wrong?
>>>> To see if it is (2), I'd been tinkering with the idea of having a
>>>> debug-mode way of seeing the loop colors as (r,g,b,a) displayed on the
>>>> screen, to help easily diagnose problems like these. I might send you a
>>>> patch for this tonight. One way in which the 3d window display might be
>>>> wrong: what if we are somehow seeing backfaces rendered differently through
>>>> the partially-transparent faces?
>>>>
>>>> If you are truly blocked without any ideas, you should probably move on
>>>> to something else while so that you are at least accomplishing something.
>>>> One suggestion would be to look at the complaint of someone in BA that said
>>>> that this branch seems much slower than when before you started your work.
>>>> A possible reason for this is that the BLEND mode you just added makes
>>>> things a lot slower, so you could try with and without that enabled, on a
>>>> model with a very large number of vertices, and see if it makes a
>>>> noticeable speed difference.
>>>>
>>>> On Sun, Jul 16, 2017 at 9:28 PM Howard Trickey <
>>>> howard.trickey at gmail.com> wrote:
>>>>
>>>>> Darshan,
>>>>>
>>>>> I too am puzzled because, as you say, the alpha channel does seem to
>>>>> be interpolated properly.
>>>>>
>>>>> One way to debug things like this is to keep printing out the vertex
>>>>> color layer at various points in execution and see where it seems to go
>>>>> wrong.  I think you should try for a bit to debug this yourself rather than
>>>>> have me do it.  If you can't solve it in a day or two, I will try to help.
>>>>>
>>>>> On Sun, Jul 16, 2017 at 2:26 PM Darshan kadu <darsh7807 at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> So, I found the function layerInterp_mloopcol in the file
>>>>>> source\blender\blenkernel\intern\customdata.c which is getting called if
>>>>>> you do subdivide. The interesting thing is it is using the alpha channel,
>>>>>> also as I said in previous mail, after printing the values of all the
>>>>>> vertices with the same color and alpha the values printed of RGBA were
>>>>>> same, this means that values of color to the vertices are getting assigned
>>>>>> properly along with alpha. So, this creates more confusion.
>>>>>> What do you think?
>>>>>>
>>>>>> On Sun, Jul 16, 2017 at 6:18 PM, Howard Trickey <
>>>>>> howard.trickey at gmail.com> wrote:
>>>>>>
>>>>>>> Ah, now I understand, I think. So what seems to be happening is that
>>>>>>> the part of Blender that gets attributes for new vertices created by
>>>>>>> geometry operations - which typically interpolate values between the values
>>>>>>> of old vertices, is probably only interpolating 3 channels of color and not
>>>>>>> 4. See if you can find the part of the code that interpolates values in
>>>>>>> custom layers. If you can't, I'll give you a hint after I get back to my
>>>>>>> computer later.
>>>>>>>
>>>>>>> On Sun, Jul 16, 2017 at 8:34 AM Darshan kadu <darsh7807 at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I divided the mesh by subdivide option in the toolshelf on the left
>>>>>>>> side in the edit mode.
>>>>>>>>
>>>>>>>> On 16-Jul-2017 5:42 PM, "Howard Trickey" <howard.trickey at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Darshan,
>>>>>>>>>
>>>>>>>>> I'm away from computer until later today, so can't check this
>>>>>>>>> right now. But I thought when I tried a few days ago that when I added a
>>>>>>>>> subdivision modifier, I saw drawing done by some function in subsurf_ccg.c.
>>>>>>>>> Did you subdivide some other way?
>>>>>>>>>
>>>>>>>>> One way you can discover for yourself which function is drawing
>>>>>>>>> the faces is to start single stepping in a debugger after hitting a
>>>>>>>>> breakpoint in draw_mesh_paint.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sun, Jul 16, 2017 at 7:37 AM Darshan kadu <darsh7807 at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hello, Mr. Howard,
>>>>>>>>>>
>>>>>>>>>> I am still not able to figure out why some faces have different
>>>>>>>>>> color.
>>>>>>>>>> As, you said that it is an only one case, but other cases
>>>>>>>>>> like emDM_drawMappedFaces this is used in edit mode and I didn't see
>>>>>>>>>> control getting in it while in vertex mode, same goes with
>>>>>>>>>> the ccgDM_drawMappedFaces.  So, this two may not be the reason for this
>>>>>>>>>> behavior.
>>>>>>>>>>
>>>>>>>>>> I printed out the colors of the vertices, here also all the
>>>>>>>>>> vertices had the same color if i assign them the same color along with the
>>>>>>>>>> alpha.
>>>>>>>>>>
>>>>>>>>>> I tried glEnable to blend for both the conditions i.e.
>>>>>>>>>> setDrawOptions NULL and non-NULL . Still no output.
>>>>>>>>>>
>>>>>>>>>> If we look at the Fabio's patch, he added glEnable to
>>>>>>>>>> the cdDM_drawFacesTex_common but control don't go in that function if  we
>>>>>>>>>> are in solid mode. How Fabio would have handled this problem?
>>>>>>>>>> It works properly for alpha 0 and 255 but not for intermediate
>>>>>>>>>> values.
>>>>>>>>>>
>>>>>>>>>> Can the way in which mesh gets divided be the reason for it?
>>>>>>>>>> Thank you ,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, Jul 14, 2017 at 4:24 PM, Howard Trickey <
>>>>>>>>>> howard.trickey at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Darshan,
>>>>>>>>>>> The changes I suggested were just a start to get it working in
>>>>>>>>>>> the most basic case. Good that you got the basic alpha display working!
>>>>>>>>>>>
>>>>>>>>>>> So far, you changed cdDM_drawMappedFaces, which is used to draw
>>>>>>>>>>> the faces for a basic type of derived mesh. But there are other kinds of
>>>>>>>>>>> derived meshes too, and you should try to figure out how to change those
>>>>>>>>>>> too, if you can.  Search for drawMappedFaces in the blenkernel/intern
>>>>>>>>>>> directory and you will see the other versions of the drawing function. When
>>>>>>>>>>> you add a Subdivision Surface modifier, the drawing function will
>>>>>>>>>>> be ccgDM_drawMappedFaces in subsurf_ccg.c .  See if you can figure out
>>>>>>>>>>> yourself how to change the function. See if you can figure out in what
>>>>>>>>>>> circumstances other versions of the drawMappedFaces function are called,
>>>>>>>>>>> and whether or not you think those are important cases to fix.
>>>>>>>>>>>
>>>>>>>>>>> Another case where the current code doesn't work for displaying
>>>>>>>>>>> alpha is when you have pushed the 'Face selection used for masking' or
>>>>>>>>>>> 'Vertex selection used for masking' buttons in vertex paint.  You may want
>>>>>>>>>>> to see if you can figure out how to fix those cases too.
>>>>>>>>>>>
>>>>>>>>>>> I put some hints on how the drawing code works in the basic case
>>>>>>>>>>> in our shared notes, doc,
>>>>>>>>>>> https://docs.google.com/document/d/1SX6ASWpYPoJ3EYJri8bX3BfXC5e-mOmraZkKMH8z4_U
>>>>>>>>>>>
>>>>>>>>>>> You can generally figure out stuff like this yourself by putting
>>>>>>>>>>> breakpoints at interesting places in the code and step through from the
>>>>>>>>>>> breakpoints, to see what code is called, what direction tests go, etc.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Jul 14, 2017, 5:00 AM Darshan kadu <darsh7807 at gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hello, Mr. Howard,
>>>>>>>>>>>>
>>>>>>>>>>>> I have pushed the suggested changes. It is working properly for
>>>>>>>>>>>> the meshes without subdividing.
>>>>>>>>>>>> But after the subdivide it is giving the rectangularly shaped
>>>>>>>>>>>> spots. I tried, but I am not getting any hints. What can be happening?
>>>>>>>>>>>>
>>>>>>>>>>>> Thank you,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Soc-2017-dev mailing list
>>>>>>>>>>> Soc-2017-dev at blender.org
>>>>>>>>>>> https://lists.blender.org/mailman/listinfo/soc-2017-dev
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>> Soc-2017-dev mailing list
>>>>>>>>>> Soc-2017-dev at blender.org
>>>>>>>>>> https://lists.blender.org/mailman/listinfo/soc-2017-dev
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Soc-2017-dev mailing list
>>>>>>>>> Soc-2017-dev at blender.org
>>>>>>>>> https://lists.blender.org/mailman/listinfo/soc-2017-dev
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>> Soc-2017-dev mailing list
>>>>>>>> Soc-2017-dev at blender.org
>>>>>>>> https://lists.blender.org/mailman/listinfo/soc-2017-dev
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Soc-2017-dev mailing list
>>>>>>> Soc-2017-dev at blender.org
>>>>>>> https://lists.blender.org/mailman/listinfo/soc-2017-dev
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Soc-2017-dev mailing list
>>>>>> Soc-2017-dev at blender.org
>>>>>> https://lists.blender.org/mailman/listinfo/soc-2017-dev
>>>>>>
>>>>>
>>>> _______________________________________________
>>>> Soc-2017-dev mailing list
>>>> Soc-2017-dev at blender.org
>>>> https://lists.blender.org/mailman/listinfo/soc-2017-dev
>>>>
>>>>
>>> _______________________________________________
>>> Soc-2017-dev mailing list
>>> Soc-2017-dev at blender.org
>>> https://lists.blender.org/mailman/listinfo/soc-2017-dev
>>>
>>
>> _______________________________________________
>> Soc-2017-dev mailing list
>> Soc-2017-dev at blender.org
>> https://lists.blender.org/mailman/listinfo/soc-2017-dev
>>
>>
> _______________________________________________
> 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/20170718/befa9351/attachment-0001.htm

More information about the Soc-2017-dev mailing list