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

Darshan kadu darsh7807 at gmail.com
Wed Jul 26 11:49:37 CEST 2017 

I attached the video in the previous mail so its under moderation, but here
is the link of gdrie.
https://drive.google.com/file/d/0B3ZxL0OKDmc7R3Z6NUZBSlo0QnM/view?usp=sharing


On Wed, Jul 26, 2017 at 2:56 PM, Darshan kadu <darsh7807 at gmail.com> wrote:

> Hello, Mr. Howard,
>
> I have attached the video for the previous instruction.
>
> Thank you.
>
>
> On Tue, Jul 25, 2017 at 11:11 PM, Darshan kadu <darsh7807 at gmail.com>
> wrote:
>
>> Hello, Mr. Howard,
>>
>> I can't create video now(the internet is too slow to download software
>> for that and upload video),
>> I did this to bake vertex color to PNG.
>> -->set  mode as UV editing
>> --> select the mesh in edit mode, press<space> select mark seam.
>> -->press<U> select unwrap
>> -->in render tab go to bake select bake mode to vertex color
>> -->bake color
>> -->come back to UV you will get color on uv.
>> -->save it as png file
>>
>> One thing I Notice if I use this png file then to bake vertex colors then
>> the alpha was properly assigned,
>> but if I use the other png file which I took from the internet alpha was
>> not getting properly assigned.
>>
>>
>> On Tue, Jul 25, 2017 at 5:24 PM, Howard Trickey <howard.trickey at gmail.com
>> > wrote:
>>
>>> Darshan,
>>>
>>> I'm sorry, I'm not figuring out how you did that (baking vertex color to
>>> a PNG file).  Could you explain the steps your followed in detail or maybe
>>> make a video showing how you did it?
>>>
>>> On Tue, Jul 25, 2017 at 6:35 AM Darshan kadu <darsh7807 at gmail.com>
>>> wrote:
>>>
>>>> Hello, Mr. Howard,
>>>>
>>>> I tried bake to vertex color,  I applied color to vertex color from
>>>> transparent PNG file, it took alpha properly and was showing it in 3d view.
>>>>
>>>> I then bake vertex color to PNG file, i got the transparent image.
>>>>
>>>> I think this shows that the bake color is working properly with the
>>>> alpha also, and don't need any modification what do you think?
>>>>
>>>> Thank you.
>>>>
>>>> On Mon, Jul 24, 2017 at 7:00 PM, Howard Trickey <
>>>> howard.trickey at gmail.com> wrote:
>>>>
>>>>> Hi Darshan,
>>>>>
>>>>> I will have to look more about baking to see if there is another way,
>>>>> but glad you found one way.
>>>>>
>>>>> Interesting about the backface culling. I was suspecting that the
>>>>> artifacts we were seeing were due to backfaces. But as you say, culling
>>>>> them is not really the best fix here. Still, a good clue.
>>>>>
>>>>> As discussed in IRC, I did the steps to the Builder to build your
>>>>> branch. It seemed to work.  Some builds are building now. For the record,
>>>>> here's what I did
>>>>> git checkout experimental-build
>>>>> git merge master
>>>>> git merge --squash soc-2017-vertex_paint
>>>>> git commit -a
>>>>> git revert HEAD
>>>>>
>>>>> noted that commit for the place where your code is merged in is:
>>>>> de3ee9f7bb
>>>>>
>>>>>
>>>>>
>>>>> On Sun, Jul 23, 2017 at 11:08 AM Darshan kadu <darsh7807 at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> 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/20170726/d16100b4/attachment-0001.htm

More information about the Soc-2017-dev mailing list