Blender converts floats/ints as needed on file load, see: cast_elem on dna_genfile.c.
All basic functionality related to the datalayer should be ready to be used. The only thing missing now is the viewport and renderers compatibility outside sculpt mode.
After this patch, I think the next step should be renaming the old vertex color data to something like "Face Corners Data" to start the development of Attribute Paint. We can also rename later this datalayer to "Vertex Colors", but I prefer to not do that in this patch to avoid more naming confusion.
Wed, Nov 20
- Finish MVertColor implementation
- Support multiple sculpt vertex color layers
- Sculpt Vertex Colors layers UI
- Reproject all layers when remeshing
Ah yes, @Campbell Barton (campbellbarton) this was just a mindless port. Will add these features and do some clean-up.
@Phil Gosch (saphires) can you implement support for multi edit?
It would be nice to support multi-edit-mode, don't think using ParamHandle is necessary for basic operations like this, otherwise functionality seems useful.
Seems fine to me. The code seems to be very straightforward and easy to understand.
@Konstantin (bokoa) please make a new bug report with details of how to redo.
Tue, Nov 19
Set the viewport shading color to single and 100% white
This has been open for so long T54558: Make Single User on an action or world in Outliner with the view Blender File crash blender, will merge these reports...
Guys, I sculpted today from scratch almost same sized high-poly mesh like a human body in 2.81 and can say for sure that the reason is not just undo operation. When size reaches about 200 verts and 200 faces it starts lagging. My file in which I noticed the lags for first time was about 60 mb made in 2.8, but new file is 60 mb made in 2.81, they are very similar and both lagging in 2.81 but not in 2.8. I think it's important information for you to fix this in future probably. Thanks!
Thanks for the report. Make Single User is from the outliner is not working at the moment. It wasn't in 2.79 either.
@Juan Gea (juang3d), I'd be fine with removing features at first if they're blocking the patch (see e.g. Workbench engine support), but now the remaining issues (Tile UI and Packing) are very basic stuff that I can't remove.
- Rebased to latest master
- Fixed crash in Cycles
- Fixed crash in 3D texture painting (FINALLY, this one has been around for ages)
- Fixed crash in OpenGL texture display
- Minor tweaks
I like the new option quite a lot, but personally I think it would look a lot better if there was a mix between the two methods. What I mean is that it would be a lot easier to see your selected object/objects if they had that effect while the rest of the model looked like the old option. Would be far easier to determine what you're looking at that way, the way I see it.
- Review update
Mon, Nov 18
- Remove debug code
I think X-ray reads better with fresnel added, I'm not sure if it's worth adding another checkbox to activate it, and another one to set the intensity.
What about having the fresnel color as a theme option. The fresnel color is multiplied by this value. This way we can disable it or tweak the intensity .
It looks like something that you want once and for all , rather than a case by case depending on the viewport / scene.
so now it will be fised only in 2.82? this is worst bug i ever had in sculpting and now no one knows how to fix it.
I would like that this option would also work for other shading modes, It is currently too isolated and the implementation is rough on the edges. Doesn't this need an slider for the amount of Fresnel to render.
Perhaps first come up with a design so we can discuss with others what workflows would benefit this so we can find the exact requirements and build a solution on actual requirements.
- Fix Crash
Sun, Nov 17
- Review update, use PROP_SKIP_SAVE
- Update versioning
- Review update
Fri, Nov 15
@Pablo Dobarro (pablodp606) Yes, it's good idea.
Just giving your patch a go for GafferCycles. I might've made a mistake on my end, but I am getting an assert in the ImageManager::remove_image(int flat_slot) function on the EnvironmentTextureNode, when it tries to get the image back from the slot number it returns a null pointer to image. I'll investigate further, but it looks like it is related to removing the destructors and relying on the ImageSlotNode destructor with this patch.
- Review Update
- Add versioning code
Thu, Nov 14
The Grease Pencil Team was also interested in these brushes and the Kelvinlet formulas are the same for mesh sculpting and Grease Pencil.
@Antonio Vazquez (antoniov) Maybe we can take a look at this during 2.82, move the Kelvinlets to a place where can be reused in both sculpting systems and check if everything is correct?
- Review Update
The current way of dealing with the PBVH nodes is not the best, but I will improve it after finishing the patch for the pose brush with inverse kinematics, which needs to store multiple pose factors per vertex at the same time.
- Review update, Add versioning code
The main trimming tools will cut directly through the whole mesh from the view using a box or lasso selection and should be available as a tool directly from the toolbar (like box mask and box hide) using the new boolean code in T67744 and the sculpt mode undo, so hopefully, they will be much faster and precise than this.
This operator is more similar to mask extract, and should only be used when you need to remove a masked selection, so I think it is a good idea to keep them separate.
- Review update
True, input curves should not be hardcoded, but for now, this is better than having them linear. My plan is to add a function datablock to control this from paint_stroke.c directly. That way we can create custom functions to map pen tablet outputs to paint mode brush inputs using any curve or math operation. We can ship Blender with the current mapping functions in the brush defaults as a node function, but users will also be able to tweak them if they want to, like in any other painting software. After that, all these new functions (and the previous ones that are modifying the input values in sculpt.c) can be removed.
- Review Update
Codewise is fine, just a check
Code is fine, would just check with the UI team as this is a UI/UX change.
Do we need to add migration code. Seems like the setting is set to 0.25f I expected some sort of migration code.
Not sure how we should proceed with this patch? So perhaps have more feedback from users.
You mention other slicing tools. Does this still fit into this list of tools?
Note I didn't see any migration code for existing curves. Is this needed?
- Add comments, review update
Wed, Nov 13
The way the Rip works right now is, after splitting the edges, it initiates the TRANSFORM_OT_translate operator, that is, move. Which, of course, respects other settings, like the current pivot point and transform orientation. So, if pivot point is set to Individual Origins, and the orientation is set to Normal, after pressing V you can hit Z, and the ripped off vertices will move along the normal, (each ripped region - along its own normal, thanks to Individual Origins). This is something one wouldn't be able to do with a "simple" (circle) gizmo without resorting to hotkeys, but will be able to do easily with the full manipulator (yes, I also mean the one with planes as well).
My whole last comment was based on taking up your idea of using the move manipulator, so once again I agree on move gizmo being a good choice for an advanced rewrite and also on the z axis as normal movement handle. If that will be decided it's all fine and dandy and I'm with you.
@Debuk (Debuk) ...which is why I am proposing to make it into the move manipulator :) That's already subject to pivot point and transform orientation settings. With current modal rip operator, you always move in view plane, and have to rely on hotkeys for axes. With a manipulator (+individual origins +normal orientation) you would just pull the Z handle.