- User Since
- Feb 15 2017, 4:55 PM (221 w, 2 d)
Mar 29 2021
@YimingWu (NicksBest) Congrats on patch landing ! (pun intended :)
Jan 22 2021
This is a wonderful upgrade. And you guys are beautiful, with your hard work, devotion and patience with each other.
Dec 6 2020
Hi @Germano Cavalcante (mano-wii), upon trying your last linux build, i find this issue still present:
Dec 4 2020
We could actually build a whole ecosystem around such 'priority' switch and keep both sides satisfied :)
How about a main behavior switch?
Something like for the left / right click select in the splash menu in the beginning... If you choose 'Regular' - GRS for regular / Ctrl+GRS for basepoint transform and if you choose 'Precision' - GRS for basepoint / Ctrl+GRS for regular transform?
Nov 28 2020
Nov 24 2020
I'll think about it better after I land the patch, but for now, unless the benefit is evident, I prefer to avoid making too many changes.
Nov 23 2020
I tried to implement this, but is this not how it currently works?
The x is displayed throughout the process of choosing a new base point.
Nov 19 2020
No, please leave it be as is, this is the intended behavior.
We already have plenty of convenient ways to set the rotation pivot prior to rotating, like Median, Individual Origins, Centers, or 3D Cursor, yet we have no way to set the snap target for precise rotation.
If we change this behavior now we go back to the start again with no way to set a specific rotation snap target.
Nov 18 2020
Some things i noticed at first glance is that snap is immediately considered as in permanent mode (not via ctrl). Although it makes sense because of all the 'base snap' topic, perhaps it would help for consistency for ctrl key to work still if the user was in the 'passive' snapping before the action. In short - to respect the snapping mode in this 'base' regime also, the snap wouldn't work if the user doesn't press the ctrl key (if in passive snap mode previously). If in active, it would behave as it does now.
I'm also not sure I understand.
Nov 17 2020
The use case where base point transform would really shine is to be able to choose the 'base point' of the scale. Right now it still uses the origin as the base point which is probably not what most of precise modeling users will try to use it for.
Oh wow, is this finally happening? Great work @Germano Cavalcante (mano-wii) , tried the linux build.
Nov 7 2020
Nov 4 2020
Ah, ok, overlay engine - makes total sense. That's great info!
Good luck with this one too!
Sorry to derail a bit, don't have a twitter, and you're a bit hard to contact...
I see you changed your course towards aligning this patch with grease pencil. In regards to architectural work and all of us craving for a pure-engineering-FreeCAD-like realtime line engine, will this addition still give a possibility to work completely in such an environment?
I was kinda looking forward to finally have a workbench engine to create and edit my objects in pure line fashion, like some of your early presentations.
Aug 6 2020
Jun 23 2020
Jun 18 2020
Jun 15 2020
Jun 12 2020
Jun 3 2020
May 5 2020
May 2 2020
Ah, ok. Sorry for the off-toppic.
Apr 30 2020
Great task! Just throwing couple of ideas in, if i understood the scope of this task correctly...
Apr 27 2020
Apr 22 2020
Apr 4 2020
Mar 13 2020
Feb 9 2020
Nov 8 2019
Oct 25 2019
@Germano Cavalcante (mano-wii) , correct me if i am wrong, but i get the impression their priorities are still really low for these topics.
Sep 17 2019
Sep 6 2019
Aug 26 2019
Aug 22 2019
Aug 5 2019
Jul 31 2019
A third thing that should be considered in the “precision modelling” is the ability to toggle on/off orthogonal only transformations.
Jul 29 2019
Yes, good examples and my exact thoughts. It would be ideal if these suggestions could be tested in 'battle'.
Well, the tool system as it is now could probably work in the future without this feature. In fact i use it on daily basis in 2.79 as such.
Jul 26 2019
Yes, practically a new concept of storing tool / transform settings throughout a certain session. Wouldn't quite call it a 'keystroke storing', but a new scene (blend file) property of some sort that is specific to all tools independently.
Well, i don't know if something like this was mentioned for 2.8 as an idea but what i had in mind is a simple check-mark setting, for example at the end of the top bar where the tool settings are shown. If checked, the user might 'lock' a certain tool setting preset for the next time that tool is activated. And for some tools he might restrict from doing so and let the tool always start with the default settings as they do in 2.79, because that certain tool e.g. is used in various ways in that particular session.
I have some experience with 'repeat last command' operators in CAD apps, they are actually very useful, practically indispensable, boosting the speed of editing perhaps 2x. But - from my experience i myself rarely use the same transform operation more than once in a row, e.g. rotate around z than again rotate around z. It is more like - rectangle / stretch / move / align / extrude /poly / poly / poly / poly (repeat last command), trim / trim / trim / extend / rectangle / move etc. So, while for poly or trim commands 'repeat last command' operator is very useful, other commands usually benefit from remembered settings (rectangle, move, align, rotate...). I kinda feel the 'repeat last command' operator has it's place in the editing pipeline independently from saved operator settings, and should be incorporated eventually, regardless of the former.
Jul 25 2019
Nice concept, Paul.
Jul 20 2019
Jul 19 2019
Mar 1 2019
This is by far the most important criteria i had when i was choosing the NLE editor for linux. I thought this would never get a mention in Blender and i didn't even bother to make a suggestion, you proved me wrong. Tremendous upgrade!
Feb 23 2019
Nov 20 2018
Similar error Brecht, first time i can not run Blender in Linux, it seems you guys started using some fresh-out-the-oven libraries:
Nov 15 2018
Oct 7 2018
Oct 4 2018
Yes, perhaps you're right.
Anyway, big thanks once again, to you and the rest of the crew!
Oct 3 2018
Hi Jacques, hi guys! I just saw Pablo's notification and video and wanted to say big thanks! Been waiting (and probably not alone) for this for so long. Didn't try it yet, but judging from the video, it seems like a nice implementation. Congrats!
Jun 11 2018
@Jean Da Costa (jeacom256) It is sometimes a good practice to read the post before replying to it :)
Jun 10 2018
I agree with @Sterling Roth (sterlingroth) , if it is possible, it would be nice to have the edge calculation method also, it is much cleaner from tech - aesthetics point of view -
Jun 9 2018
Can i dump all of my tokens here?
I just remembered a feature i missed a couple times while making addons, i don't know if it is possible - to be able to call a node editor as a popup.
Jun 8 2018
Jun 6 2018
Great addition @Clément Foucault (fclem)! Thanks for the hard work guys.
Jun 2 2018
On par with @cédric lepiller (pitiwazou) here. Don't underestimate the power of subtle floating widgets in the 3D view. You could port the complete settings to the viewport, much like you already do with custom armature widgets for characters.
@Jeroen Bakker (jbakker) strikes again!
May 31 2018
Guys, you might wanna check this out. This might be the first functional App Template, and with a lot of nice UI concepts for 2.8 to take inspiration from:
May 21 2018
If i can put some of my experience (and long time grief) to use here - LMB (or selection mouse button) to empty space - deselect all.
May 15 2018
Some can already be snapped to vertex, but wider support would be welcome and make them a lot more useful for precision modeling.
As it stands they are not yet very suited for hard surface modeling or situations where geometric precision or alignement is more desirable.
If it somehow integrated with a workflow similar to the outlined at T45734, it would certainly make a lot of people happy.
Great initiative on Widget Info! That's how you do it :)
May 14 2018
May 11 2018
Ok, great. Cheers!
Great addition with the interactive primitive creation! Been whining for that for half a decade now :)
May 8 2018
Yes, i presumed the problem was along those lines, thank you @Zsolt Stefan (zsoltst) . The first problem i saw in my mind when considering this was the clipping distance. There are also light calculations, material parameters and who-knows-what.
Ok Brecht, thanks for the explanation. That puts this issue into a new perspective.
Keep up the good work!
But depending on how you look at it, it does (and should) scale. If you make a 1x1x1 unit cube, and tell Blender that you'd like to work in km, that cube is now 1km x 1km x 1km. If you then change it so you work in cm, that cube is now 1cm x 1cm x 1cm. Essentially, that cube is now way smaller. That's how it's intended to work, and that's how it should work. Otherwise, it'd be impossible to work at very large or very small scales.
May 7 2018
Just to put some more light on the terminology, i have a feeling we are being confused by two different words here:
Cool :) Check the intellectual property though. Some big companies use it, although i think some open source do also. Check LibreCAD, QCAD, i believe it is safe.