Yup, that's been a problem since 2.80 and I also think Blaizer's complaint is justified. It definitely gets worse the more dense the mesh is and the more modifiers are stacked such as mirror and array. It should be a lot more responsive in 2.79. I've gotten used to modeling with the subsurf modifier disabled though and intermittently check the result. This is probably cuz I model the high and low poly at the same time for hard surface models. It might be a bad habit though (inaccurate initial placement of support loops) and I'm curious whether you guys prefer modeling with the subdivided result visible?
@pior When I said I was confused I wasn't being sarcastic or anything—I am genuinely confused whether the performance I showed was what he considered unacceptable. That's why went ahead and I recorded it. Because if it's not then there's something else contributing to the performance issues he described, making it solvable (or at least less noticeable!) without depending on BF.
Usually I just avoid engaging in this kind of discussion, but his computer spec is relatively similar to mine and the test case was simple to reproduce. It wouldn't hurt to test it and potentially help someone. Excluding install issues modifiers stack also impact performance, including disabled modifiers, and that's another thing you can change to minimize the performance drop. But to change it you need to be aware of it in first place.
And personally I agree about documenting the issue and contrasting with other examples. BF is an open-source project. Their growing userbase and limited resources make them very picky about what they'll prioritize, and I'd say they can be frustratingly prone to closing down even well documented issue reports. So if you want results your best bet is to be kind to the devs by being super through to minimize their workload. Like... don't even show videos of someone modelling something random on whatever software you're comparing to Blender and tell them to watch the X minutes of it, create a simple test case and record exactly what you're describing. Create a test file for blender with the test case, record a comparison and share the file. Be as objective as possible, this type of thing.
@birb , my thoughts exactly ! Here's good old Silo that I reinstalled just for that. Note that the recording is capped at 60fps but the in app performance is probably higher.
(how the hell to you embed youtube videos here ??)
Of course "workable" vs "unworkable" is subjective. But personally I wouldn't wish this kind of editing performance on anyone ... Personally that doesn't affect me much as I barely model these days, and if I do I'd be mostly relying on marked hard edges / marked creases / marked bevels. But TBH the poor Blender performance with subd is probably what pushed me towards these techniques in the first place.
@f1r3w4rr10r@birb i have installed both versions, 2.83, and 2.90. I downloaded the 2.90 alpha version to check out the new modifiers because i was said to do it. I complained about the poor performance of 2.83, and like i said, 2.90 has a similar performance as Blender 2.78 (opensubdiv was used in that version).
Just subdivide the box one more time, and you'll see how terrible is all. All the responsiveness is lost. In the other example, Blender is at the "limit".
If with a simple box we have issues, imagine a character model of 200k+ polygons and 2 iterations. I've loaded several models, and i simply can't work with them. It's like playing a game with 2-3 fps and micro freezings, when modo is having more than 200 fps.
Working with "raw polygons" is a not an option for me. I've been using subdivsision modelling with Silo, Modo, Hexagon and other apps since year 2004 without these problems (with a shitty PC of that year), and i'm not going to change the way i work because a software is not well coded, nor optimized for a simple and very old task. We are in year 2020, not 2001.
Just re-watch the video Pior linked, and imagine a full body. If Silo is a very good app, imagine Modo. In Gacha terms, Modo would be like class SSR, Silo A, and Blender F. I was expecting to have a Silo Performance in Blender, but it's still a dream with version 2.90.
This issue was already described, documented, re-described, reported, and re-reported, and .blend files were attached to reproduce the problem in several ways. And not 1 time, but a hundred. I'm bored of it already, and i'm fed up of this. All case supports were mergued into one, and filed as "problem solved" because they are like sceptical with all, they think performance is more than enough (like you, birb). They don't want to see the problem because it's very complex, and at the end, the most important issues are not adressed.
I can't do much more, except making noise about an issue, here, and there. Don't expect me to act as a Blender fanboy, i'm pretty old for that .
I'm with you on that Blaizer, but please keep in mind : to a software developer who is not a direct user of the tool being worked on, "poor performance" and "good performance" are absolutely meaningless terms since they are relative, and even if you tell a dev "well, it has to hit 60fps" then you'll get an answer along the lines of "sure, but for how many polygons ?", and so on. It never comes from a bad place but it is still extremely frustrating for sure.
So providing a .blend file supposedly demonstrating poor performance will not do anything to raise the issue (well, unless the issue is being picked up by someone who cares about the topic and is an actual user of the workflow, but again that's obviously not been the case here). That's why Id' highly encourage you to record comparisons with other apps. And then posting that in all the possible places, every other months or so if needed - Twitter, BlenderArtists, RightclickSelect, and so on. As long as it is worded nicely then I personally think that's fine. As a a matter of fact since such videos speak for themselves there's basically no need for verbose explanations anyways.
Speaking of which, anyone is free to use the video from my earlier post to do just that if needed.
I am with you on that, that it can be improved. I guess I am just more tolerant to performance issues. To me those are just a few frame drops with the example I reproduced, but still workable.
@Blaizer You said the tickets/defects were close and marked solved. Where is that? Because from what @Nominous linked, they are still
The last one I linked shows you just how much stuff there is to do and also in the first line basically asks for someone as a commissioner to push the issue and test fixes.
I am posting this here because by now I have seen multiple people say that either the developers don't care about them or that problems are being ignored. Just when I look in the tracker, it's all there. This is a trend in open source I really don't like seeing. I am a programmer myself (not in 3D), who contributes to open source projects. I have seen numerous developers and maintainers getting burned out and turned away from essentially offering their work and time for free, because they are getting yelled at and sometimes even insulted by the users of the software they write. I feel like this has increased recently all over open source. I would really hate for this to happen to Blender. So support where you can instead of becoming hostile.
Edit: I realize that my situation makes this a somewhat biased opinion and more sided with the developers, but I just wanted to get this off my chest.
@f1r3w4rr10r : unfortunately these 3 trackers confirm the issue (of course) ... but also that fact that it is still not fully grasped.
For instance in the third one the stated goal is "Big picture: 2.7x level of performance for mesh editing.". This is obviously a good thing but there's a catch : when it comes to subdivision modeling in particular, even 2.7 performance was near unworkable to begin with (in the context that Blaizer and I describe, i.e. being able to freely and smoothly edit a subdivided mesh on the fly with about two levels of subdivision). I just tested it with the same mesh yet again in 2.78 and indeed it is not fluid. About 2 times faster than 2.8x which is of course a significant difference, but still nowhere near as fluid as it should be, at all.
Of course no one should be aggressive towards the devs. My point is the opposite really : given the situation, it is obvious that they are not quite aware of the issue and that it likely wont change anytime soon. Since it is *not* a commercial program, there's no other choice for the users than to live with it, report the issue with practical examples as often as possible ... while at the same time not putting too much hope in seeing the issue fixed anytime soon. Basically being okay with reporting the problem ... while having no guarantee of it being fixed in return. Personally I am fine with that, as this is embedded in the nature of non-commercial projects.
Observing that whoever is/was currently in charge of overseeing modeling performance for 2.8 was probably not aware of the issue because they are likely not hardcore users is not meant to be condescending, it's just the way these things go really. If anything it's a pretty good justification for the situation : it's open source, and they can't have an expert on every topic on board. So, it is what it is.
I understand some devs might be bored of so many complaints, but they are just ignoring the issue. Let's be realistic. This is a very complex issue, and not all Blender devs have the technical knowledge or time. This is what happens with free software and open projects.
Don't get me wrong, but what i'm seeing in all these years, is that Blender devs put effort in what they really want to improve. Nevertheless, is an open project software, so logically, all is a little mess. There's no good direction for me. But this is just my opinion and you can disagree with me, we can have different points of views and that's the problem. Too many people involved with different points of views.
Creating a thread there is like shouting to the void.
Is there any way to set up hotkeys to add modifiers in edit mode? (not applying). When i set up hotkey for the mirror modifier for instance, it only works on object mode.
@Udjani Setting up this shortcut through the context menu will add it to the Object Mode section of the keymap. To make it work in the 3D view independently of mode you need to add it to the 3D View (Global) section.
Go to the Keymap tab in Preferences. Since you already created a shortcut it's quicker to search for it to copy the operator and confirm the other settings. Blender lets you search for either a term in the name or keybing.
In this case the operator is object.modifier_add, type Mirror.
Erase whatever is in the search bar to display the full list and navigate to 3D View > 3D View (Global). Scroll to the bottom of the section to find the "Add New" button. Setup everything like the other shortcut. Don't forget to delete the original shortcut now it became redundant.
@Blaizer I just looked into the first ten in that list you linked. They are not simply closed without reason. One was closed because it did not have enough info and the one who filed it did not answer questions from the devs. 2 were closed because they were implemented/fixed. The rest was closed as duplicates. So saying issues are closed just because is not true. That is not an opinion, that is a fact.
I am getting the feeling that this is so important to people, that a lot of duplicates are filed for the devs to take a look at. Yes that is one way to express interest in it, but each one takes time away from someone developing and instead having to evaluate the new filed issue, only to realize it's the same thing ten other guys already filed. This is not unique to open source. This is a normal process in software development. Big companies will do just the same thing, only that their tracker might not be public.
@Amiminoru That even gives me more reason to think that the problem might be with OpenSubDiv and not necessarily Blender itself. It could either be it is not integrated well into Blender or OSD has some performance issue on its own. I also found this post by Brecht while searching for the problem and he also said that the Blender subdivision code is faster to update on changes in edit mode than OSD.
Edit: Looking a bit further, I found this video explaining OpenSubDiv a bit. And even back then it was clear that there is no performance benefit when editing a mesh using it. It was mainly used for animation and sculpting.
This makes me wonder why it is the only option now, when the Blender internal subdiv was much better at editing.
Blender has gotten a lot of new features the past year. It is only natural that it would suffer some performance decreases no? I'm no dev but content implements usually come with more overhead so slower performance in some area's where it hasn't integrated as nicely with the existing code base. Some legacy code will probably need to be reworked but since this code is integrated with a lot of other systems that takes time.
Bad performance is a problem to be sure, but let's have some faith in the developers. They haven't done us dirty yet. Blender is growing and getting more developmental resources. It's only a matter of time before this gets fixed be patient.
You can always head over to blender today and chat with pablo to get a lifeline to the studio, they get performance questions a lot but asking politely again will only show that the community requires performance improvements.
"Blender has gotten a lot of new features the past year. It is only natural that it would suffer some performance decreases no?"
Not at all - a new feature doesn't have to retroactively affect any other aspect of the program, you can have tons of new modeling tools or other new features without affecting performance. The issue here is that they rewrote the whole viewport , moving it to a more modern rendering style (which of course is a great thing), but while doing so overlooked some fundamental aspects which imho should have much higher priority. To me the really saddening part is that it shows a big paradigm shift, as 2.7x was amazingly elegant in many aspects. Yet 2.8 is more of a "checkbox" release imho : fantastic and impressive new features, but a lot of not-so-minor aspects being negatively affected. It's not immediately apparent (and obviously impossible to notice for anyone stating out with 2.8x without prior experience of older versions) but it affects many things : not just performance, but also UX (collections being more "standard" now but way less efficient, GreasePencil getting a lot of new features but also becoming oddly convoluted to use, and so on).
Now my comments are not just "bashing" - they come from experience actually making character game assets with Blender. And while 2.8 does add some great things, it just cannot recommend it for anyone needing to work fast with, say, lots of skeletal meshes to edit and export. Even though 2.7x doesn't have a PBR viewport it is still my main hub for asset creation simply because it makes the job so much faster.
@f1r3w4rr10r Mostly all closed threads are filed as a "duplicate" issue (and points out to another "duplicate" and closed issue, example: https://developer.blender.org/T58503). I did not say they close the issues because yes, and i'm not going to enter a stupid debate about the reasons of why they close them, because too many threads are closed and they may have less, zero, or more reason. In my previous reply i just said, and i repeat literally: "they are just ignoring the issue. Let's be realistic". Please, don't distort what i clearly said.
If you read me well, my opinion is about: the development of Blender, that is a mess and a disaster for me. And that, it's just a personal appreciation or opinion, and of course, it might be a real fact. And like i said, you can agree or disagree with me, and that's all. A similar thing happens with Modo development. 4K native support is being asked for more than 6 years, and they just ignored all petitions or suggestions in their UI/UX department. It seems they have other priorities, much important than 4k support.
So, giving feedback on the matter, sometimes, it's just pointless. They just have other priorities. So threads are closed in a polite/robotic way.
The efforts put on Blender are not going in the good direction.
There is no way to access individual polygons from procedurally generated geometry without applying the modifiers first, right? Lets say I have a polygon plane, assign a Solidify modifier to it, and then want to put another modifier that e.g. exclusively influences the sides (rim) of the solidify? There is e.g. no 'delete' modifier that can delete procedurally generated faces?
@wilson66 None that I know of. For all intents and purposes modifier-generated geometry is seen as real geometry by the following modifiers in the stack, except without granular control like vertex groups because, well, this vertex data doesn't exist in the mesh data until you make it real. If it doesn't exist—no indices, anything—it can't be referenced either. But take this with a grain of salt, I could be wrong.
You'll have to vary your approach according to the used modifier and what you want to do. In your example to isolate the rim I'd duplicate / linked duplicate the mesh and use a solidify with Complex mode and Only Rim, using a solidify modifier without the rim in the first mesh to generate the other faces.
Hi friends, I Created an operator in a panel that basically creates modifiers to the selected object. However, it doesn't open the modifier properties panel on the right when I click the operator. Is there any way to access this via script? Thanks
I know people probably want to move on from discussing the terrible editing performance of high-poly counts in blender but I was bored so ran some testing on my own. I compiled blender in debug mode and attached WinDBG for testing. Within the sub-surface generation of blender it creates and populated a struct called SubdivStats. This contain some time values for different parts of the process. I found that the "subdiv_to_mesh_geometry_time" took the most time by far and this the process of generating a blender mesh from an openSubd representation.
Milestone 3 - opensubdiv Fast mesh OpenSubdiv viewport implementation. Time estimate: ?
Would help speed up the process as you would not convert it back to a blender mesh object, instead rendering the OpenSubD representation. Though this means that no modifier could affect the mesh once the modifier is added. This is similar to the implementation of "GPU Display" in the 3ds max open subdiv modifier.
Does anybody know how useful that option is inside of 3ds max and if people use it often in their workflows?
@Surfa That's some good research! If you have a look at the vid I linked earlier (https://www.youtube.com/watch?v=dzIl_S-qHIQ), Sergei mentioned that you will only get a speed up, if the Subdiv modifier is the last in the stack. So the logic could have already been in there at some point. The video is a few years old by now after all.
@Surfa That's some good research! If you have a look at the vid I linked earlier (https://www.youtube.com/watch?v=dzIl_S-qHIQ), Sergei mentioned that you will only get a speed up, if the Subdiv modifier is the last in the stack. So the logic could have already been in there at some point. The video is a few years old by now after all.
I have seen that video but the comparisons there only highlight the negative aspect of version 2.8x. All OpenSubD code is using the CPU backend for the evaluation. Although again the video highlights the benefit of OpenSubD for mesh deformation with the same topology and not for making changes to the topology like you would within Edit Mode.
The work in improving the performance of higher polycount modelling is nice but for most case having the SubSurf modifier's performance be good would be more beneficial.
@ikruz98 Yes, through bpy.context.workspace.screens. Don't quote me on that but I think the index of the active workspace is always 0, making it screens[0].
With the correct workspace in hand you need to find the target area. The simplest way is perform a loop checking its type. You'll be looking for the panel with the "PROPERTIES" type (unexpected ikr! ).
In this case it also had index 0, resulting in the following line of code:
Does anyone know any tricks to changing the focal length while keeping a specific object in focus? Usually I would change the FL through the View tab, but doing this zooms in/out the entire scene. Ideally I'd love it if I could auto-zoom as I change the FL, so that whatever is framed remains framed, like so:
Makes prototyping shots so much faster and natural.
The Dolly Zoom technique, I was missing that name in my vocabulary Thanks @RN ! That script of yours is great. Before I buy this, I assume it is working in the 2.83 LTS release?
Hmm if you don't mind me asking @Justo, why the need to jump on the latest version anyways ? 2.83 LTS has been announced/released merely 10 days ago. This has always puzzled me - if anything by doing so you are basically setting yourself up for annoyances since that means that any add-on could very well break. Why not stick to, say, 2.81, or some other version that works well for your needs ?
To each their own of course but I'd be curious to understand the motivation since I can only see downsides to it and not a single benefit.
(this addon looks great btw @RN , getting it asap !)
@Justo It's been tested with 2.82, and from the list of 2.83 API changes (in here) I can tell that there are no breaking changes -- and you can always reach me with a PM or email in case you want something changed or fixed of course, my email is on that gumroad page.
@pior I use it with camera background images, it helps a lot. Good luck!
@pior What you say is completely true. For my needs though, it's not a big problem. I'm not using Blender a lot at work, and if I do so it's for very small things, so I don't rely on too much if I update. It just so happens that I was previously using a custom build of 2.82, in which the creator had modified it so as to turn off limit-selection-to-visible without the need of using XRay (which brings its own annoying problems such as switching from area-based selection in edit mode to center-based selection). To me, this feature is too valuable not to have . I loved it, but a few addons started malfunctioning, namely Boxcutter.
Now another user made an addon to do the same thing for newer versions, so I decided to try it out with 2.83 and get up to date with my favorite addons. AFAIK Blender ppl want to make these LTS versions last for a while, and since I'm not too used to updating Blender, I'm okay with trying to update it now and see if it's worth the effort.
Still haven't deleted it from my PC - it's just so goddamn gud. If you'd like I can upload in a rar the whole thing. I've never done this with Blender, so honestly I don't know if it's doable though I don't see why not. Certainly a lot easier than having to merge and compile patches with builds and repositories, imo.
@melviso that pixelation in the bump map comes from the low bit-depth of the generated image. Turn on Float Buffer in the settings of the image object ***. This will make the image go from 32-bits-per-pixel to 128-bits-per-pixel (or 8 bit color channels to 32 bit color channels, with each pixel having R,G,B,A channels), so it'll have way more nuance.
You can then pack your painted image into your blend file, or save it to a file by using the OpenEXR format with "Float (Full)" depth. The TIFF or PNG formats only let you use 16bit color channels at most so you might lose detail coming in from the 32bit Float Buffer if you use these formats.
*** If you turn on Float Buffer, the image will be cleared to its background color. If you want to preserve your painting you might want to save it as OpenEXR + Float(Full) first and then reopen it.
Sorry if this is a dumb question but I am super confused about how to set up my grid in blender 2.83 to work with unreal and do some trim sheets/modular stuff.
Here is what I do currectly:
I set the units to centimeters under scene>units. I then change the unit scale to 0.01 there as well otherwise the unreal third person character model comes in wrong size and 0.01 is the only one that gave me the correct result in dimensions.
Now in the viewport options there is floor and there is grid. Grid doesn't seem to do a thing. Grid subdivisions setting is greyed out even though I can change it and while I can change the scale there to 0.1, 0.25, 0.5, 1 to evely divide the grid in ortho viewports this doesn't work and I do not get matching grids visually even though I have the same settings on both.
I have meters as scene units and my exports to unreal always come in at correct scale. The blender grid will default to 1 unit per square I believe which is fine for the modular stuff I have been doing.
You say you've set up you're metrics in CM and you import the unreal dude and it comes in 100x too small so If you set your scene to meters it will come in correct.
The grid settings are tied to the unit settings in the world settings. So if you set metric to none the grid subdivisions will become available.
@pior I've uploaded the custom Blender here To anyone interested in it, keep in mind this was done with an early beta version of 2.82, so some scripts or addons that work in the official 2.82 release may not work here. Enjoyyy
@Justo - well, what can I say ! This is excellent and so immediately natural. This is fascinating really, as "not selecting what one doesn't see" does sound like a reasonable thing - but in practice it truly is the opposite. Even though I did get used to switching to wire mode over the last few yeas of getting into Blender, this habit is incredibly fast to unlearn once given the proper option. Truly a great example of how whoever is in charge of that aspect of development should indeed listen much more to industry veterans coming from other backgrounds.
I have meters as scene units and my exports to unreal always come in at correct scale. The blender grid will default to 1 unit per square I believe which is fine for the modular stuff I have been doing.
You say you've set up you're metrics in CM and you import the unreal dude and it comes in 100x too small so If you set your scene to meters it will come in correct.
The grid settings are tied to the unit settings in the world settings. So if you set metric to none the grid subdivisions will become available.
@pior@Justo I find this utterly fascinating. Because in essence the option to switch between two select modes is already there in vanilla Blender. Yet this custom way seems to be the more accepted one for some people. Is the X-Ray (which would give you even more visual control over what you are selecting, one would think) that much of a difference? Or do you think it just adds visual noise and that's why you don't like it?
I am really intrigued, because UI/UX is a bit of a side hobby of mine and how perception psychology plays into it.
Replies
Usually I just avoid engaging in this kind of discussion, but his computer spec is relatively similar to mine and the test case was simple to reproduce. It wouldn't hurt to test it and potentially help someone. Excluding install issues modifiers stack also impact performance, including disabled modifiers, and that's another thing you can change to minimize the performance drop. But to change it you need to be aware of it in first place.
And personally I agree about documenting the issue and contrasting with other examples. BF is an open-source project. Their growing userbase and limited resources make them very picky about what they'll prioritize, and I'd say they can be frustratingly prone to closing down even well documented issue reports. So if you want results your best bet is to be kind to the devs by being super through to minimize their workload. Like... don't even show videos of someone modelling something random on whatever software you're comparing to Blender and tell them to watch the X minutes of it, create a simple test case and record exactly what you're describing. Create a test file for blender with the test case, record a comparison and share the file. Be as objective as possible, this type of thing.
Here's good old Silo that I reinstalled just for that. Note that the recording is capped at 60fps but the in app performance is probably higher.
https://www.youtube.com/watch?v=vBAq7UYmWdY
(how the hell to you embed youtube videos here ??)
Of course "workable" vs "unworkable" is subjective. But personally I wouldn't wish this kind of editing performance on anyone ...
Personally that doesn't affect me much as I barely model these days, and if I do I'd be mostly relying on marked hard edges / marked creases / marked bevels. But TBH the poor Blender performance with subd is probably what pushed me towards these techniques in the first place.
Just subdivide the box one more time, and you'll see how terrible is all. All the responsiveness is lost. In the other example, Blender is at the "limit".
If with a simple box we have issues, imagine a character model of 200k+ polygons and 2 iterations. I've loaded several models, and i simply can't work with them. It's like playing a game with 2-3 fps and micro freezings, when modo is having more than 200 fps.
Working with "raw polygons" is a not an option for me. I've been using subdivsision modelling with Silo, Modo, Hexagon and other apps since year 2004 without these problems (with a shitty PC of that year), and i'm not going to change the way i work because a software is not well coded, nor optimized for a simple and very old task. We are in year 2020, not 2001.
Just re-watch the video Pior linked, and imagine a full body. If Silo is a very good app, imagine Modo. In Gacha terms, Modo would be like class SSR, Silo A, and Blender F. I was expecting to have a Silo Performance in Blender, but it's still a dream with version 2.90.
This issue was already described, documented, re-described, reported, and re-reported, and .blend files were attached to reproduce the problem in several ways. And not 1 time, but a hundred. I'm bored of it already, and i'm fed up of this. All case supports were mergued into one, and filed as "problem solved" because they are like sceptical with all, they think performance is more than enough (like you, birb). They don't want to see the problem because it's very complex, and at the end, the most important issues are not adressed.
I can't do much more, except making noise about an issue, here, and there. Don't expect me to act as a Blender fanboy, i'm pretty old for that
So providing a .blend file supposedly demonstrating poor performance will not do anything to raise the issue (well, unless the issue is being picked up by someone who cares about the topic and is an actual user of the workflow, but again that's obviously not been the case here). That's why Id' highly encourage you to record comparisons with other apps. And then posting that in all the possible places, every other months or so if needed - Twitter, BlenderArtists, RightclickSelect, and so on. As long as it is worded nicely then I personally think that's fine. As a a matter of fact since such videos speak for themselves there's basically no need for verbose explanations anyways.
Speaking of which, anyone is free to use the video from my earlier post to do just that if needed.
For instance in the third one the stated goal is "Big picture: 2.7x level of performance for mesh editing.". This is obviously a good thing but there's a catch : when it comes to subdivision modeling in particular, even 2.7 performance was near unworkable to begin with (in the context that Blaizer and I describe, i.e. being able to freely and smoothly edit a subdivided mesh on the fly with about two levels of subdivision). I just tested it with the same mesh yet again in 2.78 and indeed it is not fluid. About 2 times faster than 2.8x which is of course a significant difference, but still nowhere near as fluid as it should be, at all.
Of course no one should be aggressive towards the devs. My point is the opposite really : given the situation, it is obvious that they are not quite aware of the issue and that it likely wont change anytime soon. Since it is *not* a commercial program, there's no other choice for the users than to live with it, report the issue with practical examples as often as possible ... while at the same time not putting too much hope in seeing the issue fixed anytime soon. Basically being okay with reporting the problem ... while having no guarantee of it being fixed in return. Personally I am fine with that, as this is embedded in the nature of non-commercial projects.
Observing that whoever is/was currently in charge of overseeing modeling performance for 2.8 was probably not aware of the issue because they are likely not hardcore users is not meant to be condescending, it's just the way these things go really. If anything it's a pretty good justification for the situation : it's open source, and they can't have an expert on every topic on board. So, it is what it is.
This is still open, and dates from 2018: https://developer.blender.org/T58191
I understand some devs might be bored of so many complaints, but they are just ignoring the issue. Let's be realistic. This is a very complex issue, and not all Blender devs have the technical knowledge or time. This is what happens with free software and open projects.
Don't get me wrong, but what i'm seeing in all these years, is that Blender devs put effort in what they really want to improve. Nevertheless, is an open project software, so logically, all is a little mess. There's no good direction for me. But this is just my opinion and you can disagree with me, we can have different points of views and that's the problem. Too many people involved with different points of views.
Creating a thread there is like shouting to the void.
Go to the Keymap tab in Preferences. Since you already created a shortcut it's quicker to search for it to copy the operator and confirm the other settings. Blender lets you search for either a term in the name or keybing.
In this case the operator is object.modifier_add, type Mirror.
Erase whatever is in the search bar to display the full list and navigate to 3D View > 3D View (Global). Scroll to the bottom of the section to find the "Add New" button. Setup everything like the other shortcut. Don't forget to delete the original shortcut now it became redundant.
Bad performance is a problem to be sure, but let's have some faith in the developers. They haven't done us dirty yet. Blender is growing and getting more developmental resources. It's only a matter of time before this gets fixed be patient.
You can always head over to blender today and chat with pablo to get a lifeline to the studio, they get performance questions a lot but asking politely again will only show that the community requires performance improvements.
Not at all - a new feature doesn't have to retroactively affect any other aspect of the program, you can have tons of new modeling tools or other new features without affecting performance. The issue here is that they rewrote the whole viewport , moving it to a more modern rendering style (which of course is a great thing), but while doing so overlooked some fundamental aspects which imho should have much higher priority. To me the really saddening part is that it shows a big paradigm shift, as 2.7x was amazingly elegant in many aspects. Yet 2.8 is more of a "checkbox" release imho : fantastic and impressive new features, but a lot of not-so-minor aspects being negatively affected. It's not immediately apparent (and obviously impossible to notice for anyone stating out with 2.8x without prior experience of older versions) but it affects many things : not just performance, but also UX (collections being more "standard" now but way less efficient, GreasePencil getting a lot of new features but also becoming oddly convoluted to use, and so on).
Now my comments are not just "bashing" - they come from experience actually making character game assets with Blender. And while 2.8 does add some great things, it just cannot recommend it for anyone needing to work fast with, say, lots of skeletal meshes to edit and export. Even though 2.7x doesn't have a PBR viewport it is still my main hub for asset creation simply because it makes the job so much faster.
If you read me well, my opinion is about: the development of Blender, that is a mess and a disaster for me. And that, it's just a personal appreciation or opinion, and of course, it might be a real fact. And like i said, you can agree or disagree with me, and that's all.
A similar thing happens with Modo development. 4K native support is being asked for more than 6 years, and they just ignored all petitions or suggestions in their UI/UX department. It seems they have other priorities, much important than 4k support.
So, giving feedback on the matter, sometimes, it's just pointless. They just have other priorities. So threads are closed in a polite/robotic way.
The efforts put on Blender are not going in the good direction.
You'll have to vary your approach according to the used modifier and what you want to do. In your example to isolate the rim I'd duplicate / linked duplicate the mesh and use a solidify with Complex mode and Only Rim, using a solidify modifier without the rim in the first mesh to generate the other faces.
Just keep in mind, that those are just meeting minutes and not an official roadmap yet.
If we go back to our favourite ticket on the blender dev site:
https://developer.blender.org/T73360
Fast mesh OpenSubdiv viewport implementation.
Time estimate: ?
Would help speed up the process as you would not convert it back to a blender mesh object, instead rendering the OpenSubD representation. Though this means that no modifier could affect the mesh once the modifier is added. This is similar to the implementation of "GPU Display" in the 3ds max open subdiv modifier.
Does anybody know how useful that option is inside of 3ds max and if people use it often in their workflows?
I have seen that video but the comparisons there only highlight the negative aspect of version 2.8x. All OpenSubD code is using the CPU backend for the evaluation. Although again the video highlights the benefit of OpenSubD for mesh deformation with the same topology and not for making changes to the topology like you would within Edit Mode.
Again the best comparison would be for someone with 3ds MAX to look at the editing performance of the OpenSubD modifier and commenting on that:
https://knowledge.autodesk.com/support/3ds-max/learn-explore/caas/CloudHelp/cloudhelp/2018/ENU/3DSMax-Modeling/files/GUID-AC9DDAB2-52E4-482A-B245-F5C30CC45544-htm.html
The work in improving the performance of higher polycount modelling is nice but for most case having the SubSurf modifier's performance be good would be more beneficial.
With the correct workspace in hand you need to find the target area. The simplest way is perform a loop checking its type. You'll be looking for the panel with the "PROPERTIES" type (unexpected ikr!
In this case it also had index 0, resulting in the following line of code:
Here are the full lists of Properties ids and area types in the API docs.
Makes prototyping shots so much faster and natural.
Hmm if you don't mind me asking @Justo, why the need to jump on the latest version anyways ? 2.83 LTS has been announced/released merely 10 days ago. This has always puzzled me - if anything by doing so you are basically setting yourself up for annoyances since that means that any add-on could very well break. Why not stick to, say, 2.81, or some other version that works well for your needs ?
To each their own of course but I'd be curious to understand the motivation since I can only see downsides to it and not a single benefit.
(this addon looks great btw @RN , getting it asap !)
Now another user made an addon to do the same thing for newer versions, so I decided to try it out with 2.83 and get up to date with my favorite addons. AFAIK Blender ppl want to make these LTS versions last for a while, and since I'm not too used to updating Blender, I'm okay with trying to update it now and see if it's worth the effort.
https://cgcookie.com/questions/10569-texture-paint-bump-map-in-blender-2-8
Still haven't deleted it from my PC - it's just so goddamn gud. If you'd like I can upload in a rar the whole thing. I've never done this with Blender, so honestly I don't know if it's doable though I don't see why not. Certainly a lot easier than having to merge and compile patches with builds and repositories, imo.
Sorry if this is a dumb question but I am super confused about how to set up my grid in blender 2.83 to work with unreal and do some trim sheets/modular stuff.
Here is what I do currectly:
I set the units to centimeters under scene>units. I then change the unit scale to 0.01 there as well otherwise the unreal third person character model comes in wrong size and 0.01 is the only one that gave me the correct result in dimensions.
Now in the viewport options there is floor and there is grid. Grid doesn't seem to do a thing. Grid subdivisions setting is greyed out even though I can change it and while I can change the scale there to 0.1, 0.25, 0.5, 1 to evely divide the grid in ortho viewports this doesn't work and I do not get matching grids visually even though I have the same settings on both.
How do you guys go about setting up your grid?
https://tzosf.blogspot.com/2020/06/donkey-to-mule-making-blender-like.html
I have meters as scene units and my exports to unreal always come in at correct scale. The blender grid will default to 1 unit per square I believe which is fine for the modular stuff I have been doing.
You say you've set up you're metrics in CM and you import the unreal dude and it comes in 100x too small so If you set your scene to meters it will come in correct.
The grid settings are tied to the unit settings in the world settings. So if you set metric to none the grid subdivisions will become available.
I've uploaded the custom Blender here
More info on what this build changes: https://developer.blender.org/D6322
Talk of faster edit mesh roadmap in blender today (timestamp 12:00) :