User Details
- User Since
- Nov 8 2011, 7:42 PM (550 w, 2 d)
Jan 25 2022
Dec 6 2021
Sep 24 2021
Apr 22 2021
Apr 18 2021
Apr 16 2021
Apr 15 2021
Apr 12 2021
Apr 8 2021
Apr 7 2021
Mar 23 2021
Jan 26 2021
See also
Jan 14 2021
Jan 13 2021
Nov 29 2020
Nov 27 2020
Oct 20 2020
Oct 9 2020
Oct 4 2020
Sep 28 2020
Sep 1 2020
Jul 26 2020
Jul 15 2020
- some minor ui fixes and default setting tweaks
Jul 14 2020
So... what was the point of migrating the modifier UI code from python back to C in 2.90 again ?!
Making external devs angry ?
You sacrifice a lot of flexibility having UI code being run in python for some drag and drop eye candy ? seriously ?!
That is a big step backwards imho. Now i would need to backport the UI code to C... yuck... tried that. But what about the template_list() function ?
Its C equivalent needs a Context pointer. Great... one of those you never have handy at your disposal.
Where does it come from in the python function ? USE_FUNC_CONTEXT looks like a big automagically stuff... In that state i am unable to update the UI code and the patch for 2.90.
And the code really should not fail because of some UI stuff.
Some easy to find documentation / migration guide for that imho totally unnecessary UI code policy thing would have also helped.
and better function names, not uiItemR and stuff like that... and really, UI code belongs into the python part.
Jun 20 2020
Jun 19 2020
Jun 16 2020
Jun 10 2020
May 30 2020
May 15 2020
May 14 2020
May 12 2020
May 2 2020
May 1 2020
Apr 23 2020
Apr 21 2020
Apr 18 2020
Apr 9 2020
Apr 6 2020
Apr 2 2020
hrm, i better should NOT have rebased my arcpatch branch to master before... lol... now there are unrelated changes in here as well (weld modifier stuff, curve stuff etc)
but the wiki docs regarding arcanist and arc diff (aka updating your diff) recommended that.
- attempt to perform all review related changes
Apr 1 2020
Mar 31 2020
@Pablo Dobarro (pablodp606) First, thanks for your help :)
So, but the voxelremesh operator lacks CSG functionality, filters, as well as texture / material transfer, and the preserve Hard edges support. And not yet speaking of the ability to mesh particles. Should this be part of the operator then too ? So both the modifier and the operator can share a common codebase ? Either way, I disagree here that is just a little bit of work. I would estimate it is not rocket science, but not too trivial either.
Means I just need a bigger slot of time in order to do the required changes. Not sure whether other devs could do this faster, because they would need to read their way thru the code on their own or ask me for help in order to accelerate this a bit.
Mar 30 2020
Mar 24 2020
Mar 20 2020
Mar 16 2020
Mar 13 2020
Ok, what about:
Mar 6 2020
some more pre-review cleanup, aka removing unintended changes
Mar 5 2020
dead code cleanup and clang formatting of patch
Mar 4 2020
Update of diff for recent 2.83 master, no functional changes.
@Brecht Van Lommel (brecht) I would like a review for this to be included in 2.83
Feb 29 2020
Feb 27 2020
Feb 25 2020
Feb 4 2020
Jan 22 2020
Jan 15 2020
Jan 3 2020
Jan 2 2020
in order for the ModifierList addon to show the CSG UI elements, i think the highlighted python code (from modifiers drawing code) must be added to the addon too.
Or atleast the operator names should be made known to the addon.
And for the skin modifier as CSG operand, seems to work here. If the original CSG object is set to Textured, it will just hide the remeshed part I think, so it should be hidden in viewport or render.
Theoretically "reproject data" should transfer UVs or materials too, from the skin modifier original object to the remeshed part (tho there are seam issues still)
@paul geraskin (mifth) Hmmm, i am not sure yet how to implement this. Vertexcolors or weights would need to manipulate the filtering in openvdb somehow...
Added custom data reprojection for UVs and materials (for some reason, vertex and edge data doesnt work so well with it, using datatransfer code)
Jan 1 2020
Tried to patch this, but the more I dig into it, the more questions arise, lol...
For example what on earth has "Overrides" to do with copying something on RNA level ? Is that the same as Static / Dynamic Override (which never was finished up to now) or something different with the same name ?
Lol... Anyways, I will share here my partially working patch, but it wont copy the Custom Profile, just re-assign it to the other modifier. Probably this is some corner case with Pointer Properties, which are not meant to be copied but to be assigned somewhere else only. But this doesnt work here. In case one of the other bevel modifier objects is deleted, blender will crash.
Probably, in order to make the CurveProfile more re-usable and copy-able (in one go) , it must become some separate ID which can be linked into the bevel modifier, like a cachefile is linked into the Meshcachesequence modifier or Particle Settings are being linked into a Particle System Modifier.
Dec 31 2019
@Hans Goudey (HooglyBoogly)
Thanks, the custom_profile.update() call seems to work. But the target curve's widget looks often a bit weird afterwards, aka weird triangular artifacts.
Hmm, seems this is no simple oneliner in order to fix this issue.
After some search in the code and some debugging, i found out that here
https://developer.blender.org/diffusion/B/browse/master/source/blender/editors/interface/interface_context_menu.c$543
but->rnapoin.data && but->rnaprop seem not to be set (if you rightclick on the curve in the bevel modifier).
The curve is defined here basically
https://developer.blender.org/diffusion/B/browse/master/source/blender/editors/interface/interface_templates.c$4959
but there is no uiBut (no button) inside the curve area itself one could bind the context menu entries to. Its just an uiBlock, which works differently.
The rnapoin and rnaprop data is handled by a callback here, RNAUpdateCb.
Bottom line, it seems (for me atleast, who is unfamiliar to that code area) not so super easy to fix this properly.
Maybe one would need to write a custom (mass) copy operator which iterates over the curve points / handles or so. But i dont think those are exposed via python,
so this needs to be done in C.
Dec 30 2019
Dec 13 2019
Dec 2 2019
Nov 26 2019
Nov 24 2019
Nov 7 2019
Nov 4 2019
Nov 3 2019
@Lukas Stockner (lukasstockner97) Hi, feel free to commit the patch :) I am busy with other work and a bit out of the loop atm.
Oct 16 2019
Sep 29 2019
Sep 17 2019
Hmm, didnt actually check the code, but it possibly draws triangles in sculpt mode due to usage of MLoopTris instead of MFace, aka triangle only mesh representation vs tri and quad like before.
( I doubt sculpting supports ngons and polys directly, but i could be wrong here.) Could also be the drawing code does own triangulation there.
Tried the provided blend with 76650402f300 and a master version from september 13th.
Except maybe the extraneous green dot "far away" from the active vertex I also had no flicker or locking.
Windows 10 Pro 64-bit
Intel UHD 620 (laptop) (Lol, a miracle 2.8 seems to run flawlessly with this hardware :) )