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

Sat Jul 22 14:06:25 CEST 2017

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