[Soc-2017-dev] vertex paint project - ply exporter
Howard Trickey
howard.trickey at gmail.com
Wed Jul 26 21:02:59 CEST 2017
Darshan,
Yes, it now appears to work with subdivision surfaces too.
Do you know what to work on next? You have basically finished everything
(and more!) in your GSoC proposal except for the gradient feature and the
part of vertex alpha that would have it affect rendering. So perhaps you
should interact with the user community again to figure out what the most
desired extra features would be, and also to try to encourage more testing
to uncover bugs. Combining known requests with the remainder of your
proposal, we have these ideas so far:
1) gradient as a source of color
2) have vertex alpha affect rendering. I think it might already work by
using nodes, but you (or I) should check to see that the alpha value
properly comes out of the vertex color node and can be an input to other
nodes.
3) soften tool (post #15 in the BA thread
<https://blenderartists.org/forum/showthread.php?427686-GSoC-2017-Vertex-Painting-Improvement>
)
4) random colors (post #15, #25)
5) cleanup tool (post #15)
6) more than 8 layers (post #15, #40)
7) paint multiple layers at the same time
8) take brush strength into account for alpha too (post #68)
An easy one to do next would be more than 8 layers (current suggestion is:
32).
Another fairly easy one would be random colors.
There are also some unaddressed questions / reports in the BA thread that
you might want to answer / address. E.g.,
post #8 re new layer contents
post #14 re numeric entry to change certain vertices
post #23 re occlude mode and symmetry
post #51 re mesh resolution brush
post #52 re polyfill/uvfill brush
post #82 re artifacts with dyntopo
post #86 re importing fbx
On Wed, Jul 26, 2017 at 12:27 PM Darshan kadu <darsh7807 at gmail.com> wrote:
> 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
>>>
>>>
>>
> _______________________________________________
> 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/173ef455/attachment-0001.htm
More information about the Soc-2017-dev
mailing list