Can Vertex paint be drastically redesigned?

Hi guys,
Sorry if my question is noob, or it is the 100th same one in the row, but i have not found answers by googling or browsing the threads here at BA.
So, Blenders vertex paint could be a great tool for painting and texturing eg. sculpts, but it has some serious limtations (eg. speed or symmetry, no support for multires) IMO. BUT these limitations do not show up when using sculpt masking.
What i am curious about is that the possibilites of sculpt masking can be interpretted to vertex paint. I am not a coder, and i dont have any ideas how these two (i assume totally different) methods work in the background, but it seems very logical to me, that some hybrid of them (with the support for symmetry and for multires data) could burst many artists pipeline. So, is it possible that vertex paint could be redesigned in a way, that it would make it a tool like polypaint in zbrush? Or at least, sculpt mask data could be somehow used for more purpouses (like paint mask>>go to vertex paint>>>mask data converted to some colors)?

Thank you for your answers in advance

Well ; there is no problem with the current implementation (aside from masking) the problem is with the OpenGL viewport performance.

Blender uses vertex buffer object in OpenGL to process the high number of vertices , but this is not implemented to every aspect of blender. Every blender mode doesnt seem to use vbo functionality ( this might be partially true , since I do not know the code, its just guessing from user experience).

Even in sculpt mode vbo’s are activated on a conditional cases (without a dynatopo sculpt or multi-res modifier with fast navigate enabled blender still has performance issues in sculpt mode).

So technically if someone would implement the vbo’s to the current vertex paint (or any other mode) blender would speed up. However blender OpenGL is using v2.0 (I think can’t remember the exact version 2.1 maybe) . So any implementation of vbo’s would not be a good investment. Viewport drawing is essential part of the program so switching to OpenGL 4.5 (or the latest version) is not that easy and quick to do; it must be done nonetheless but its a long hard road.

From my understanding (after the fail of Gooseberry) we wont be seeing an upgrade to OpenGL at least for another 2 years.
( Thank the skeptical critiques and trolls here for their outstanding performance in crippling progress and also thank the BA management for letting them , ),

Wow, thanks for the answer. I didn’t know these but i see now that it is not as easy as replacing an old lightbulb with a new one. Of course i’m sorry for that. Maybe some day…

This never was a target for Gooseberry IIRC the targets and plans are still up so feel free to prove me wrong. I also think you give the trolls and critiques far too much credit. The Gooseberry movie failed because it was trying to raise a huge amount of money, I don’t think the Blender community has ever raised that amount of money before and perhaps (and this part is just my opinion), the size of this community especially the part that tends to open their wallets was greatly overestimated.

The Gooseberry pilot is still on and has started but the community(here at least) doesn’t seem to be paying attention, I haven’t seen a Gooseberry thread like we had for Orange, Peach or Durian or maybe I am just not looking hard enough.

Its not about proving anything. I thought it was pretty clear, but maybe I need to explain what I meant. The current number of developers are far less than the anticipated number of the full campaign. Therefore the features take more time to complete if they are started at all. When Gooseberry has less developers the pace of R & D is also toned down.Potential features which might have been researched or developed inside(GB targets) or outside(Extra Targets/Features) of the scope of Gooseberry targets most likely will be postponed to another time. So things which come after GB are postponed more (like OpenGL refactoring).

This is what I meant.

But not only that, I also have conformation from Ton that some OpenGL problems will be addressed in “soonish” time :). But I would like to point out how “soonish” means >> “when we have a free dev who is not working on a GB target/bug report and has the knowledge base to tackle the OpenGL problems”.

I hope this was explanatory.

You also made a good point and answered the troll problem yourself with this comment . :slight_smile:

“the size of this community especially the part that tends to open their wallets”

So already skeptical users who is afraid of donating 5 euros even to blenderfund are more thrown off to donate 175 euros (by the skeptics and trolls) …

Isn’t the Viewport FX GSoC supposed to update OpenGL? Maybe Blender Development Fund/Steam Workshop could be allocated to speed it up.

The original poster was actually on a right track. The difference in speed between sculpt masking and weight/vertex color painting doesn’t have to do with OpenGL. Or viewportFX, or VBOs. Well it has, but not for main performance difference. I think someone, recently (maybe Anthony) on the paint soc mentioned that he may look into weight/vertex color painting and use BVH same as for sculpting. It essentially speeds up updates/lookups.

It essentialy all stopped with Nicolas Bishop departure from Blender. Maybe Anthony will carry on the torch .

EDIT: I found where I read it may be implemented (but scratch that for now):

EDIT2: IMHO Vertex Paint/Weight Paint/Sculpt/Texture Paint should be all unified under Paint/Sculpt mode anyways. Now its a nightmare of segmented development with each one supporting different features using different code paths working on the same data.

I guess I thought wrong about the vertex buffer.
I wonder if someone can simply explain why bounding volume hierarchy is related to vertex information (vertex color,vertex normal).

I thought bvh was used for deformations and ray casting.

Not entirely, VBOs bring much performance but with heavy meshes only way to go is to have partial updates and lookups based on a spatial partitioning scheme.

I had some (novel) ideas about bringing even more (basically unlimited) performance to sculpting/painting but who to tell, no one is interested, and I don’t have the time to decipher whole of the source since I’m not a student and have a business to run.

I agree (maybe except for texture paint. its not the same data is it)

Target not, but the operands are the same.

ah I see, so this explains the performance difference between dynatopo and multi-res. Which means dynatopo is not using a partitioning system either. I guess even with VBO support vertex paint and weight paint would choke on a big buffer size (buffer > 500k).

So a fast bvh look up is the only solution it seems… Thnx for the explanation :yes:

Actually, dyntopo uses PBVH, but its slower due to topology updates. Here is where my idea comes in :). Don’t do topology updates. Make them lazy, and use screen space meshes generated on strokes deformed to the current Z-buffer. The resolution of screen space buffer is finite that way.

Lazy updates are on viewport change, same as MARI.

Hmm thats very interesting actually. So you update the mesh if the view angle is changed or the screen space meshes exceed a certain buffer size. Its hard to imagine how screen space stroke blend with the sculpt mesh (at least what the stroke will look like) but interesting idea nonetheless. :smiley:

It wouldn’t work for some types of sculpting where there are global changes, but for small details it would work (its basically what projection master does). You can even build hierarchical meshes with decoupled topology this way.

think i have to do some research in order to understand your ideas, however i like them as far as i got all these. Back to my original question, a bit more radically: Sculpt mask “connects brightness data” (a value between 0-1 i guess) to vertices. It can be drawn free-hand, with box, and lasso. It supports symmetry (which vpaint does not), multires and dyntopo too. Would it be a wrong idea to “paste” an RGB (or whatever) value to the vertices with the mask (or similar) tool in sculpt mode?

I was looking up that area since I use vertex colors all the time for first pass texturing. If I have the time I might make a patch. There is some considerations about interpolation in dyntopo mode and also multires, as it wont apply automatically to all levels, not without a more extensive refactor AFAIK.


I just played around with Projection Master and it seems very doable. However dropping and picking up meshes can use up some time and I am not sure how it can perform if the user (stroke>changes view) constantly.

One other thing to note is the projection screen space resolution differs from the original sculpt density in Zbrush. So it might be a good idea to clamp the screen space mesh resolution to multi-res resolution . (or dynatopo detail size)

Well good luck if your ever try to go on with this project.

Just don’t get your hopes up, even if it works it will most likey be a proof of concept kind of thing since for a real refactor I wouldn’t have the time anyway. Also with so many projects touching the same code from core Blender developers, I always feel I might be stepping on someones toes if I butt in.