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

[Howard Trickey]

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