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

Sun Jul 23 17:08:15 CEST 2017

Hello, Mr, Howard,

I had a hard time in understanding how does the bake to vertex color works,
but I figured it out.

I did the following steps:
1) I set the texture are the random image.
2)Set the UV map
3)in the physics tab get to dynamic paint tab
4)Add canvas
5)dynamic output: add paintmap later
6)dynamic initial color:
   initial color: UV texture
 and then set the texture
7) go to object modifier tab
   click apply.

If we subdivide sufficiently we can see the image in vertex paint.
Here alpha is by default 1.
I followed these instructions:
https://blender.stackexchange.com/questions/26503/how-to-bake-uv-map-texture-to-vertex-color-selected-to-active/41677

I just want to know whether is this the correct way to bake or any other
method is there to bake?
This was only for texture to vertex color baking.

Well, I enabled the backface culling in the shading panel on the right-hand
side, the alpha for subdivide was showing properly. But it doesn't consider
the back faces and for things like a plane, it's not good(as the one side
in invisible).
We can set it as default by GL functions, but it won't be correct, right?

Thank you.

On Sat, Jul 22, 2017 at 5:36 PM, Howard Trickey <howard.trickey at gmail.com>
wrote:

> Hi Darshan,
>
> The channel locks seem to work. Thanks.
>
> I think bake color is a great next step.
>
> On Sat, Jul 22, 2017 at 7:03 AM Darshan kadu <darsh7807 at gmail.com> wrote:
>
>> Hello, Mr. Howard,
>>
>> I have implemented the color lock and the alpha blend, have a look at it
>> I have pushed the code.
>>
>> I am now planning to work on bake color. What do you think?
>>
>> Thank you.
>>
>> On Thu, Jul 20, 2017 at 6:15 PM, Howard Trickey <howard.trickey at gmail.com
>> > wrote:
>>
>>> Hi Darshan,
>>>
>>> Your plan to next work blending alpha according to mode, and locking
>>> color, seems good to me.
>>>
>>> Somehow I don't think depth ordering is the issue with the transparent
>>> display.  We'll have to leave this as a background task to fix while moving
>>> on to other things now.  This is only meant at the moment as a kind of
>>> quick hack so the user can see some effect of changing alpha in Vertex
>>> Paint mode, and that much is accomplished.
>>>
>>> The concept of padding is that each C data type takes a certain number
>>> of bytes and is (by default, and by most compilers) aligned on certain
>>> "address boundaries" because machines access them better that way. On
>>> typical machines today:
>>> char, bool - take 1 byte, can go at any address
>>> short - takes 2 bytes, goes on even addresses
>>> int, long, float, pointer - take 4 bytes, go on multiple-of-4 addresses
>>> double - takes 8 bytes, goes on multiple-of-8 addresses
>>>
>>> So when you declare a struct, it puts them in order but if the next
>>> address available would not fit the above rules, internal padding
>>> (basically, unused bytes) is inserted in order to make the required
>>> alignment. For more information, read, say https://en.wikipedia.org/
>>> wiki/Data_structure_alignment
>>>
>>> With some structs in Blender that are to be persisted to disk, we want
>>> the total length of the struct to have size that is a multiple of 8. If by
>>> following the above rules, you end up with a struct that is not a multiple
>>> of 8, you may have to add declaration of some chars and possibly an int in
>>> order to end up with a multiple of 8. Also, it seems that we explicitly put
>>> in pad declarations rather than relying on the compiler to do it for
>>> 'jumps' caused by alignment concerns. I guess this is to make it easy for a
>>> program to do size calculations when looking at the struct defs in the
>>> makesdna directory.  E.g., see the ID and PreviewImage struct defs in
>>> makesdna/DNA_ID.h for both types of pads.
>>>
>>> On Thu, Jul 20, 2017 at 6:07 AM Darshan kadu <darsh7807 at gmail.com>
>>> wrote:
>>>
>>>> Hello, Mr. Howard,
>>>>
>>>> Yes, I also think that the alpha should be blend similar to rgb. It
>>>> will be simple to implement.
>>>>
>>>> About the channel lock, the artists want it, so having it would be good
>>>> think, I can do it with r,g,b bool in the brush struct and changing them
>>>> from  UI,  Can you tell me the concept of padding you mention before for
>>>> adding element in the structure.
>>>>
>>>> For visualization section, Can cull face be useful? but for the cases
>>>> like plane the back view will not be displayed.
>>>>
>>>> Another thing that can be done is drawing according the depth the most
>>>> depth faces first, I haven't done it before). This blog explains this very
>>>> well https://learnopengl.com/#!Advanced-OpenGL/Blending.
>>>>
>>>> But again why only some faces are behaving like that, why not all? This
>>>> is something interesting!
>>>>
>>>> Now, I will be adding the alpha blending similar to rgb, and locking
>>>> color.
>>>>
>>>> Thank you.
>>>>
>>>> On Wed, Jul 19, 2017 at 7:39 PM, Darshan kadu <darsh7807 at gmail.com>
>>>> wrote:
>>>>
>>>>> Hello, Mr. Howard,
>>>>> Sorry, I was ill from yesterday afternoon. I should haven't told you
>>>>> before but internet wasn't very good its monsoon season(heàvy rain) in
>>>>> India.
>>>>>
>>>>> Meanwhile, yesterday I changed the ply importer to take alpha into
>>>>> account. I have pushed the code. I thing the same problem comes with the
>>>>> fbx importer. I will check it. I will give reply to your mail as soon as
>>>>> possible.
>>>>>
>>>>> Sorry, I should have told you yesterday itself.
>>>>>
>>>>> Thank you.
>>>>>
>>>>> On 19-Jul-2017 6:40 PM, "Howard Trickey" <howard.trickey at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Darshan,
>>>>>>
>>>>>> What are you working on now?
>>>>>>
>>>>>> I looked a little more at the issue of alpha display after
>>>>>> subdividing. I am pretty sure now that the alphas are set properly -- if
>>>>>> you remove all but, say, the front (subdivided) face, the display looks OK.
>>>>>> I tried changing the glBlendfunc call to:
>>>>>> glBlendFuncSeparate(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA, GL_ONE,
>>>>>> GL_ONE_MINUS_SRC_ALPHA);
>>>>>> which seems more correct, but it didn't make any difference.
>>>>>>
>>>>>> Maybe someone reading this with more experience with OpenGL and
>>>>>> alpha-blending has an idea?  I wonder if somehow we have to turn on drawing
>>>>>> the elements in proper z-sorted order?
>>>>>>
>>>>>>
>>>>>> On Tue, Jul 18, 2017 at 9:48 AM Howard Trickey <
>>>>>> howard.trickey at gmail.com> wrote:
>>>>>>
>>>>>>> Darshan,
>>>>>>>
>>>>>>> I made a little python function to dump the vertex (loop) colors on
>>>>>>> the console.  You may find this useful.  If you put this in, say, the
>>>>>>> release/scripts/startup folder then you can use the <Space>-menu to search
>>>>>>> for 'Dump Vertex Colors'.  To see which faces and vertices correspond to
>>>>>>> which dumped colors, you can start blender with --debug and then enable the
>>>>>>> 'indices' visualization box in the right-hand panel of view3d (when in Edit
>>>>>>> mode) to see the indices of the currently selected elements.
>>>>>>>
>>>>>>> I think there may be a problem with the ply exporter, discovered by
>>>>>>> using this. I made a simple plane quad and put different colors and alphas
>>>>>>> on each, and then the ply exporter seemed to have an off-by-one error in
>>>>>>> lining up colors with vertices. But I looked briefly at the code and didn't
>>>>>>> see what was wrong.
>>>>>>>
>>>>>>> I also checked the interpolation of alpha's when subdividing and
>>>>>>> agree with you that it seems to be doing approximately the right thing, so
>>>>>>> the problem is somehow in the visualization code.
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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/20170723/0e41a635/attachment.htm 