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

Tue Jul 18 11:50:01 CEST 2017

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/soc-2017-dev/attachments/20170718/4e0cc8bd/attachment-0001.htm 