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

Darshan kadu darsh7807 at gmail.com
Mon Jul 17 19:26:52 CEST 2017 

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

More information about the Soc-2017-dev mailing list