[Soc-2017-dev] vertex paint project - ply exporter
Darshan kadu
darsh7807 at gmail.com
Wed Jul 26 18:26:53 CEST 2017
I changed the sub surface modifiers for alpha. you can test now.
I don't think there is any other part which needs to be changed like this.
--Darshan
On Wed, Jul 26, 2017 at 5:23 PM, Darshan kadu <darsh7807 at gmail.com> wrote:
> Yes, I understood the problem I will work on the subdivision modifier for
> the alpha!
>
> --Darshan
>
> On Wed, Jul 26, 2017 at 4:57 PM, Howard Trickey <howard.trickey at gmail.com>
> wrote:
>
>> Hi Darshan,
>>
>> Thanks for the video, that explained it well. And I agree, baking the
>> vertex colors to image is working to save the correct alpha, as desired! So
>> nothing for you to do in terms of baking.
>>
>> What do you want to work on next? One thing that is left over from the
>> work to make alpha visible in the 3d view (besides trying to figure out
>> what is going on with those backfaces), is to also make it work when you
>> add a subdivision surface modifier (which is different than hitting the
>> subdivide function in edit mode). Alpha is not displayed there because a
>> different derived mesh file is used to draw in that case (I told you about
>> this in an earlier message).
>>
>>
>> On Wed, Jul 26, 2017 at 5:49 AM Darshan kadu <darsh7807 at gmail.com> wrote:
>>
>>> 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
>>>>>>
>>>>>>
>>>>>
>>>> _______________________________________________
>>> 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/0d46afa5/attachment-0001.htm
More information about the Soc-2017-dev
mailing list