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

[Darshan kadu]

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