I'd be very willing to put time and effort (moreso than I already have with said document) into the tools and interaction, but I'd need to know it's not in vain. I live in Amsterdam and would love to go to the institute and talk to them, but from what I've seen of Ton (as well as my own limited interactions), he seems deeply stubborn, and against change.
'Blender is for Blender users', as he says.
Even when a patch is submitted there's a very real change it will never be implemented. Not because it doesn't work or doesn't fit with Blender's coding style or because Ton's against it, but just because nobody bothers to commit it. There's the case of the 'reset value' patch by Harley, where he even changed it at the request of an official dev, only to have it ignored (despite posts on the mailing list, forum, irc...).
Without an official way of acknowledging feedback and support, as well as a clear way of influencing development that's shown to be effective, my point stands.
I want a foundation-run uservoice (or other voting system), and a way to pledge money to specific projects, also run by the foundation (otherwise you run the risk of it not getting implemented).
edit: I should add that I'm not trying to be negative, there's a lot to like in Blender, and I regularly defend it to its (many, many) detractors.
We've got some guys over here that use Blender and at first I was a bit skeptical but man they produce some good stuff.. Even more impressive is that they switched from Max to Blender, not for the cost savings(although who's complaining about that?), but because of how much more efficient they find the workflow.
One of the things I've always admired about Blender is that it broke away from the shackles of traditional UI layouts and design, often at the expense of new users of course. Blender always felt like someone took the traditional layout, threw it out(to a degree) and remade it with efficiency in mind, whereas I feel that Max/Maya stick to what users are familiar with, making smaller changes to UI layout, even if larger changes could result in more efficient workflows.
makes sense why they do it, but I give big ups to blender for making those big changes even if it meant increasing the learning curve and loosing potential new users who are too afraid of something that deviates from what they are used to as much as blender does
We've got some guys over here that use Blender and at first I was a bit skeptical but man they produce some good stuff.. Even more impressive is that they switched from Max to Blender, not for the cost savings(although who's complaining about that?), but because of how much more efficient they find the workflow.
One of the big perks to using blender as well is that you dont have to jump through all the hoops associated with licenses and their activations.
You basically have a powerful 3d application which takes up anywhere from 40-100mb give or take, in a folder which doesnt need to be installed but can run straight from a USB stick or drag and dropped on any desktop..and you are ready to go.
Not in this one unfortunately. There is a GSoC project going on that aims to improve the viewport though, so hopefully somewhere down the road it gets a performance boost.
Beautifully put, Dataday. Licensing can be a real headache. And the fact that you can scale the quantity of devices using (it on every conceivable platform) for free, well.. it really doesn't get much better than that. If vertex normal importation can ever be properly sorted out (still get unpredictable results with MoI imports), then I'll have everything I need wrapped up with a nice little ribbon.
Love that I don't have to spend serious money to have a killer 3D application. Words are inadequate to describe the joy of getting constant quality updates without being chained to a draconian license or coercive subscription plan.
There's a bug worth fixing! I knew hanging around to other forums would be bound to be fruitful!
Glad to hear you think so . The undo bug is the most obvious when using QuickEdit to project paint using an external app like Photoshop. Apply, undo, BOOM artifacts everywhere. There's also artifacts created when painting in the 3D view on overlapping UVs.
I'd be very willing to put time and effort (moreso than I already have with said document) into the tools and interaction, but I'd need to know it's not in vain. I live in Amsterdam and would love to go to the institute and talk to them, but from what I've seen of Ton (as well as my own limited interactions), he seems deeply stubborn, and against change.
'Blender is for Blender users', as he says...
He is. I just lost BFCT status over something they were unwilling to even entertain as an idea, and this was something pretty simple to implement (the infrastructure is already in place) that would improve the level of participation from businesses on the Network site. It's a historical problem though, whilst it helped get Blender to where it is, it needs to change, there are a number of communities that have dropped under the radar because they don't push what the Foundation wants to push, which more and more these days is moving towards VFX and movies.
Glad to hear you think so . The undo bug is the most obvious when using QuickEdit to project paint using an external app like Photoshop. Apply, undo, BOOM artifacts everywhere. There's also artifacts created when painting in the 3D view on overlapping UVs.
They are two different bugs. I'm thinking of ways to kill them without hurting performance too much.
I find some of that odd. When you listen to his blender conference speeches (example 2012) he seems open to new ideas and making those ideas more easy to get to the development side of things. Additionally his 2.7-2.8 road map post was more or less about game engine integration, and given his responses he seems more open to that side of the industry.
I also met him at Siggraph and he didnt seem stubborn at all, though from experience its always possible for people to act in a hypocritical way sometimes. To say and promote one thing to a group while via actions doing the opposite.
The good news is though that all the source code is there. Anyone or any group can jump right in and make changes as they see fit for their own branch/fork. I really look forward to that happening actually.
I don't want to turn this into a rant-fest as this isn't an appropriate venue, but many people have tried to do branches over the years and not a single one has succeeded, and that's not through lack of support from branch participants. I'll not say more as it'll just derail the topic.
The two paint bugs are fixed in the GSOC 2013 paint branch. The bug where painting on the same region creates artifacts is fixed for cases where the colour painted on the faces sharing the uv space is the same. Of course it is impossible to solve completely due to the multi-threaded nature of the system (i.e. you can't know which colour will be painted first). generally I would recommend not painting on meshes where two faces share the same uv space, or use face masking to isolate the conflicting faces (Maybe a selection tool can be added for such cases)
Psy-Fi: Just checked out the latest built, great work fixing the artifacts issues
However, there are seams when painting on overlapping UVs (tried changing the Bleed amount but didn't solve it), and some sort of stroke occlusion issue when using quickedit. Here's an example file (purple=3D paint, red=quickedit): http://www.pasteall.org/blend/22564
I'd be very willing to put time and effort (moreso than I already have with said document) into the tools and interaction, but I'd need to know it's not in vain. I live in Amsterdam and would love to go to the institute and talk to them, but from what I've seen of Ton (as well as my own limited interactions), he seems deeply stubborn, and against change.
'Blender is for Blender users', as he says.
Even when a patch is submitted there's a very real change it will never be implemented. Not because it doesn't work or doesn't fit with Blender's coding style or because Ton's against it, but just because nobody bothers to commit it. There's the case of the 'reset value' patch by Harley, where he even changed it at the request of an official dev, only to have it ignored (despite posts on the mailing list, forum, irc...).
Without an official way of acknowledging feedback and support, as well as a clear way of influencing development that's shown to be effective, my point stands.
I want a foundation-run uservoice (or other voting system), and a way to pledge money to specific projects, also run by the foundation (otherwise you run the risk of it not getting implemented).
edit: I should add that I'm not trying to be negative, there's a lot to like in Blender, and I regularly defend it to its (many, many) detractors.
Ton often comes off as stubborn, and sometimes he is, but he's actually quite open to change so long as there is significant weight and reason behind it. You just have to prove that it's a significant, positive change with good reason, and that there's enough people supporting it.
Many of the things you touch on, such as ignored patches, are not necessarily ignored out of any malintent or disagreement. But rather due to a lack of developer time. Blender has a great dev team that is very active but it's a small team and they don't have a hope of keeping up with the userbase's wants for new development.
With so many user requests (and quite a lot of patches) it's important to keep the attention on it. There's hundreds of requests and lots of patches that get submitted all the time that're then just ignored by the submitter. If you have a patch or serious proposal for change then the best thing to do is keep being a squeaky wheel on IRC and/or the mailing list
@PolyHertz, thanks, that was squashed as well. Happy painting! Don't expect however that using quick edit on overlapping UVs is solvable. There's no way the system can determine which colour to use for the same uv space. When painting, the time the stroke itself occurs gives a preference of certain colours over others, but for the quick edit case, where all colours must be applied at once this is simply impossible. Moral of the story: Don't use quick edit on mirrored meshes (Or quick edit only part of the mesh)
Wouldnt it be possible to determine which mirrored side is set to receive the most colour and just use that for the QuickEdit application (voiding/overwriting the smaller amount used on the other mirrored surface(s) )?
Someone stepped up and wrote a custom .obj importer for Blender that brings in vertex normals. Great news for anyone using MoI or other NURBS-based modelers.
Someone stepped up and wrote a custom .obj importer for Blender that brings in vertex normals. Great news for anyone using MoI or other NURBS-based modelers.
Someone stepped up and wrote a custom .obj importer for Blender that brings in vertex normals. Great news for anyone using MoI or other NURBS-based modelers.
The first time I tried importing, the model didn't look so hot, but it was because I didn't un-check the 'weld vertices' option when using MoI's mesh exporter. Un-checking that option is critical for success, as Zalamander explicitly notes (he wrote the importer). I didn't read his instructions the first time I tried it so that was why my mesh didn't look so hot.
The Blender importer works pretty well once you're squared away. Renders (both regular Blender Render and Cycles) look very accurate. Realtime viewport display of imported models is very good, but I will give Modo a nod for slightly better visual accuracy in OpenGL display. Even better in Modo is exporting models using .lwo (generally flawless importation into Modo from my experience).
Edit: You know, the more I look at the models, I don't really see any striking difference. Pretty much one-to-one in quality.
I can't seem to find much info on this: is it possible to remove vertices in Blender like in 3dsmax? For example, I have two quads [|], I want to select the center two vertices and in 3dsmax I hit CTRL+BACKSPACE and it removes the verts and gives me a single quad. Same with edges, etc. If it's not supported, has anyone seen plans to make that a feature?
I can't seem to find much info on this: is it possible to remove vertices in Blender like in 3dsmax? For example, I have two quads [|], I want to select the center two vertices and in 3dsmax I hit CTRL+BACKSPACE and it removes the verts and gives me a single quad. Same with edges, etc. If it's not supported, has anyone seen plans to make that a feature?
Sounds like you're looking for Dissolve, which you can find from the Delete menu (X).
Just wondering but does anyone actually like the default setup for navigation/selection? Tried going back to the default because the newest builds don't work with my 2.66 key setup anymore and it's a pain to remake, but the default for selection at least just seems like there was no thought put into it at all.
User interaction just needs to be rethought from the ground up. There's no consistency at all, with keys sometimes doing one thing, sometimes another (box select's a great example: suddenly, shift no longer ads to the selection, it's mmb). Cessen (Nathan Vegdahl) has made a really nice start on an experimental keymap that adresses a lot of my concerns, going beyond what's possible with just a keymap and actually doing a bit of coding to make it work. Highly recommended, although it's a work in progress.
I just ate it and learned the Blender defaults - which now seem second-nature to me. Which is probably why I think the UI is actually pretty intuitive. I know this is a personal preference, but I think Blender's layout and key mappings are really kind of awesome. With every application I've learned, it has always been better for me, in the long term, to just embrace the pain and learn the program's native way of doing things, even if a semi-decent interaction model of existing tools I already know is an option. I totally get not wanting to retrain the muscles and nerves, though. It's time you could spend making stuff, not awkwardly retraining your mind and digits to do the basics. And I also get how customizing things can make life a lot easier, especially if you are focusing most of your energy to very specific tasks and workflows. Best of luck to those frustrated by it - I know it can be a drag.
surly: there's an objective and a subjective side to it. Inconsistency is absolutely irrefutably not a good thing.
I've bitten the bullet and learned the Blender defaults, and I know my way around it fairly well, but certain things just aren't well thought out at all, which is understandable when you know they were added on later. Hell, undo and edge/face selection were added on fairly late!
Which is why Cessen's keymap rethink is a very, very good thing.
I see what you're saying about consistency, Mighty Pea. Glad Cessen's keymap is a step in the right direction for you. Might take a look at it just to see what it can do.
The defaults are fine IMHO. Some stuff is a little odd, sure, but I'm cool with what we have right now (stuff like U for unwrap in the 3d preview and E for the same thing in the UV window is just stupid though). :P
Of course I'm happy for the new key maps to be added as an option but I wouldn't want them to be the default key set simply because most people are used to the defaults, it would cause massive inconsistency in all the available learning material and documentation that has been made since 2.5 was released and huge headaches for 98% of users who would have to relearn everything from scratch while they try to reset their muscle memory. Most of the keys are also pretty well optimised and intuitive once you learn them well.
I think it'd be better to have Cessan's default since it's way more sane, and would make it easier for people to use Blender. The old default can be moved to the optional keymap since old school users will know how to select it.
I think it is one of those things that if it is just changed, even those that resist would probably move over to it. The default in there now is amazingly inefficient for selections which is mostly what Cessan's keymap improves. The controls in his keymap are listed in this commit.
I don't believe in an ideal keymap; it's always going to reflect the workflow of the designer. For example, I switch between layers all the time, whereas Cessen's keymap moves vertex/edge/face modes to the number keys and apparently forces you to click to switch layers. Furthermore, as soon as remappable keys came out, I mapped the merge menu to Q because I use it so often, whereas his keymap still has it at Alt+M, surely a position you'd only put it in if you'd rarely use it. I also fail to see why you'd move selection to LMB, I think it's kind of clever to have RMB as a dedicated selection button while LMB handles interactions.
metalliandy:
Not for people new to the software. You may have gotten used to it, but that does not make it good, or even 'fine'. Certainly not for something so easy to fix.
It's extremely counterintuitive, and part of what makes Blender so hard to get into (although it's much, much less so than older versions).
The Circle and Box Select work differently from regular select. lmb selects instead of rmb, and instead of shift-click deselecting, mmb does, without clicking.
Select linked also works differently: You just hold your cursor over the mesh part you want and press L, Blender will pick whatever’s closest. Existing selections make no difference. In addition to this, it always adds to the selection, whereas other ‘regular’ selection in Blender will override the previous selection, needing the Shift key to be held to add/toggle - which, in this case only deselects. Furthermore, in the uv/image editor L does override the previous selection! In addition to that, with ‘Sync selection’ turned on it fails to work entirely.
ctrl-n in editmode triggers ‘make normals consistent’ rather than reloading the startup file, as it does in object mode. Keys don't need to be 100% consistent, but ctrl-n, really?
In the uv editor, the N and T hotkeys toggle side-bars in reversed order.
The uv/image editors snap settings are linked to the 3d viewport and can only be viewed/changed there, even when it's hidden. Not all snap settings work in the uv editor. Same thing goes for soft selection (proportional editing).
Select Shortest Path was only recently fixed for vertices, so things are being looked at and fixed, just in a piecemeal way.
As for other stuff, Cessen's keymap finally adds keys to add and subtract from a selection rather than just one that toggles.
The current default keymap is the primary reason for Blender's absurdly steep learning curve and it harms Blender's adoption rate. Experienced 3D Artists try Blender all the time, but most can't figure out how to do anything except move the 3D cursor without looking at documentation/tutorials. The time investment to learn a completely unique interactivity paradigm is too big for a lot of people.
Cessan's keymap eliminates this because it has more conventional methods for selecting and deselecting things. If you can select units in Warcraft III, you can select things in Blender with Cessan's keymap.
Experienced users are always welcome to tweak the keymap to make their personal workflow more efficient, but the default mapping should strive for familiarity as much as it can.
metalliandy:
Not for people new to the software. You may have gotten used to it, but that does not make it good, or even 'fine'. Certainly not for something so easy to fix.
It's extremely counterintuitive, and part of what makes Blender so hard to get into (although it's much, much less so than older versions).
The Circle and Box Select work differently from regular select. lmb selects instead of rmb, and instead of shift-click deselecting, mmb does, without clicking.
Select linked also works differently: You just hold your cursor over the mesh part you want and press L, Blender will pick whatevers closest. Existing selections make no difference. In addition to this, it always adds to the selection, whereas other regular selection in Blender will override the previous selection, needing the Shift key to be held to add/toggle - which, in this case only deselects. Furthermore, in the uv/image editor L does override the previous selection! In addition to that, with Sync selection turned on it fails to work entirely.
ctrl-n in editmode triggers make normals consistent rather than reloading the startup file, as it does in object mode. Keys don't need to be 100% consistent, but ctrl-n, really?
In the uv editor, the N and T hotkeys toggle side-bars in reversed order.
The uv/image editors snap settings are linked to the 3d viewport and can only be viewed/changed there, even when it's hidden. Not all snap settings work in the uv editor. Same thing goes for soft selection (proportional editing).
Select Shortest Path was only recently fixed for vertices, so things are being looked at and fixed, just in a piecemeal way.
As for other stuff, Cessen's keymap finally adds keys to add and subtract from a selection rather than just one that toggles.
Like I said, there are some crappy things, but what about all the great hotkeys? There are plenty of things that work really well.You really can't get more intuitive than R for rotate, E for extrude, S for Scale, G for grab, CTRL+E/F/V for Edge/Face/Vert menus etc.
I'm not saying that Blender couldn't clean up some stuff regarding inconsistencies but changing the hotkeys for the entire program seems a little OTT when many of them are perfectly fine.
Maybe I'm just used to the hotkeys as they are, but in most cases I don't understand what all the fuss is about.
The current default keymap is the primary reason for Blender's absurdly steep learning curve and it harms Blender's adoption rate. Experienced 3D Artists try Blender all the time, but most can't figure out how to do anything except move the 3D cursor without looking at documentation/tutorials. The time investment to learn a completely unique interactivity paradigm is too big for a lot of people.
Cessan's keymap eliminates this because it has more conventional methods for selecting and deselecting things. If you can select units in Warcraft III, you can select things in Blender with Cessan's keymap.
Experienced users are always welcome to tweak the keymap to make their personal workflow more efficient, but the default mapping should strive for familiarity as much as it can.
Blender doesnt have a absurdly steep learning curve any more (IMO) and people can learn it in a few days if they want to (it's much easier with the new interface). If someone moved from ZBrush to Mudbox or Photoshop to Illustrator they would have exactly the same problem with not being able to make something for a little while. It's all part and parcel of learning new software.
Also who says that another software is correct? What is familiar to one isn't to another...It's all down to perspective really.
The BF should just get on with making a set of complete hotkeys for Max/Maya/ and XSI users and have done with it, without the needless rehashing of the hotkeys that 98% of people are used to and happy with (inconsistencies notwithstanding).
Also who says that another software is correct? What is familiar to one isn't to another...It's all down to perspective really.
It's not about being 'correct' ; it's about being logical, consistent, efficient, and easy to learn/use. The argument "Everyone should learn it because that's the way it is" is a great way to stall progress. 2.5 (new UI) and 2.63 (B-Mesh integrated) were both releases that needed to happen for Blender to become more widely adopted, but there were a lot of of people that were opposed to such changes simply because they didn't want to learn something new, the Keymap is no different.
It's not about being 'correct' ; it's about being logical, consistent, efficient, and easy to learn/use. The argument "Everyone should learn it because that's the way it is" is a great way to stall progress. 2.5 (new UI) and 2.63 (B-Mesh integrated) were both releases that needed to happen for Blender to become more widely adopted, but there were a lot of of people that were opposed to such changes simply because they didn't want to learn something new, the Keymap is no different.
Come on, man. I'm the last person who would say "Everyone should learn it because that's the way it is". I probably push more than almost anyone on Polycount regarding improving Blender for game artists and am one of its harshest critics in regards to stuff that needs improving...just read my previous posts.
BMesh was needed because the mesh tools couldn't move forward without it, The UI needed to be changed because it was getting cluttered and devs were running out of space. Blender doesn't 'need' a new key map, it's just that some people would like one, which is fine, I just don't think it should be default.
Most software follows similar conventions, not even specific to 3D. Inkscape, MSPaint, LibreOffice Draw, QBitTorrent, the video game Lemmings; they all use the same selection methodology people are used to. It is the same that you use to manage icons on your desktop, or files in your filemanager.
- LMB selects
- LMB-Drag does a box select.
- Shift+LMB adds to selection.
- Ctrl+LMB removes from a selection.
- Clicking outside deselects all.
This means on first launch of most applications you do not need to learn these basic input mechanisms. In Blender's case it would even free up the A and B keys for something better.
Cessan's keymap is typically superior on the other hotkeys too. Rather than the hilariously bad Ctrl+Tab+1,2,3 for vertex,edge,face select, it's just 1,2,3. Modes are changed with the spacebar key rather than tab. Letters or numbers can be used to quickly pick the actual mode. Spacebar+E (or 2) goes to edit mode, Spacebar + S (or 3) goes to sculpt mode. Etc. There isn't that confusion of where does tab go if I'm in pose mode?
I think what xrg is saying is correct though. If you're going to build a keymap then OS standards should be considered first and foremost as everyone, despite what apps they've used, will be acquainted with them.
...It's extremely counterintuitive, and part of what makes Blender so hard to get into (although it's much, much less so than older versions)...
When users hit Blender as their first 3D app they have little trouble beyond the typical "newb" learning curve.. I've watched this happen quite extensively educating users new to Blender and 3D, and this is especially true of people coming at content production never having done *any* art before. So the problem isn't Blender per say, it's actually the baggage users bring with them after having tried/used other applications. Note that vice versa also holds true.
That's not to say that what's being said here about maps is without merit, but it needs to be contextualised.. it's bad relative to what? Is the comparison being made with respect to it being 'bad' the way a particular function works in Blender, or is it bad relative to the way other applications work?
Blender is the only 3D package I've ever used, and it took me about 2 weeks to just figure out navigation and controls. Blender should try to cater to any 3D artists, not just 3D noobs.
However, from observation and feedback from professors and non-acclimated-students alike, they said the learning curve was extremely steep.
Anyway, I hope Blender drags ya'll Luddites along kicking and screaming and puts Cessan's keymap as default, like they did with the UI and Bmesh. :poly124: I really think there would be less "I tried Blender a few times, but it is just too alien to learn" posts and it would wind up being more common in Studio settings and the like.
The answer to that quote is "teach it differently then", as someone who has provided education materials for a good few years I don't say that lightly.
Is the comparison being made with respect to it being 'bad' the way a particular function works in Blender, or is it bad relative to the way other applications work?
bad relative to other applications - most software I can pick up and start making stuff in a few hours like picking up Mudbox for the first time after using Zbrush for a while.
I really wanted to like Blender when I was shopping around for a 3D Painting app but holy hell, it had me almost punching my screen in frustration.
Anyway, I hope Blender drags ya'll Luddites along kicking and screaming and puts Cessan's keymap as default, like they did with the UI and Bmesh. :poly124: I really think there would be less "I tried Blender a few times, but it is just too alien to learn" posts and it would wind up being more common in Studio settings and the like.
They changed the UI and added BMesh because the software couldn't progress without the changes. The UI was cramped and the old mesh code was 15 years old.
Replies
There's a bug worth fixing! I knew hanging around to other forums would be bound to be fruitful!
I'd be very willing to put time and effort (moreso than I already have with said document) into the tools and interaction, but I'd need to know it's not in vain. I live in Amsterdam and would love to go to the institute and talk to them, but from what I've seen of Ton (as well as my own limited interactions), he seems deeply stubborn, and against change.
'Blender is for Blender users', as he says.
Even when a patch is submitted there's a very real change it will never be implemented. Not because it doesn't work or doesn't fit with Blender's coding style or because Ton's against it, but just because nobody bothers to commit it. There's the case of the 'reset value' patch by Harley, where he even changed it at the request of an official dev, only to have it ignored (despite posts on the mailing list, forum, irc...).
Without an official way of acknowledging feedback and support, as well as a clear way of influencing development that's shown to be effective, my point stands.
I want a foundation-run uservoice (or other voting system), and a way to pledge money to specific projects, also run by the foundation (otherwise you run the risk of it not getting implemented).
edit: I should add that I'm not trying to be negative, there's a lot to like in Blender, and I regularly defend it to its (many, many) detractors.
One of the things I've always admired about Blender is that it broke away from the shackles of traditional UI layouts and design, often at the expense of new users of course. Blender always felt like someone took the traditional layout, threw it out(to a degree) and remade it with efficiency in mind, whereas I feel that Max/Maya stick to what users are familiar with, making smaller changes to UI layout, even if larger changes could result in more efficient workflows.
makes sense why they do it, but I give big ups to blender for making those big changes even if it meant increasing the learning curve and loosing potential new users who are too afraid of something that deviates from what they are used to as much as blender does
One of the big perks to using blender as well is that you dont have to jump through all the hoops associated with licenses and their activations.
You basically have a powerful 3d application which takes up anywhere from 40-100mb give or take, in a folder which doesnt need to be installed but can run straight from a USB stick or drag and dropped on any desktop..and you are ready to go.
It is such a nice feeling.
Not in this one unfortunately. There is a GSoC project going on that aims to improve the viewport though, so hopefully somewhere down the road it gets a performance boost.
Love that I don't have to spend serious money to have a killer 3D application. Words are inadequate to describe the joy of getting constant quality updates without being chained to a draconian license or coercive subscription plan.
Glad to hear you think so
They are two different bugs. I'm thinking of ways to kill them without hurting performance too much.
I also met him at Siggraph and he didnt seem stubborn at all, though from experience its always possible for people to act in a hypocritical way sometimes. To say and promote one thing to a group while via actions doing the opposite.
The good news is though that all the source code is there. Anyone or any group can jump right in and make changes as they see fit for their own branch/fork. I really look forward to that happening actually.
However, there are seams when painting on overlapping UVs (tried changing the Bleed amount but didn't solve it), and some sort of stroke occlusion issue when using quickedit. Here's an example file (purple=3D paint, red=quickedit): http://www.pasteall.org/blend/22564
Ton often comes off as stubborn, and sometimes he is, but he's actually quite open to change so long as there is significant weight and reason behind it. You just have to prove that it's a significant, positive change with good reason, and that there's enough people supporting it.
Many of the things you touch on, such as ignored patches, are not necessarily ignored out of any malintent or disagreement. But rather due to a lack of developer time. Blender has a great dev team that is very active but it's a small team and they don't have a hope of keeping up with the userbase's wants for new development.
With so many user requests (and quite a lot of patches) it's important to keep the attention on it. There's hundreds of requests and lots of patches that get submitted all the time that're then just ignored by the submitter. If you have a patch or serious proposal for change then the best thing to do is keep being a squeaky wheel on IRC and/or the mailing list
Links:
http://moi3d.com/forum/messages.php?webtag=MOI&msg=6003.1
http://www.blenderartists.org/forum/showthread.php?299193-Modified-OBJ-Importer-for-Custom-Vertex-Normals
That is fantastic!
Nice! I will try this out
The Blender importer works pretty well once you're squared away. Renders (both regular Blender Render and Cycles) look very accurate. Realtime viewport display of imported models is very good, but I will give Modo a nod for slightly better visual accuracy in OpenGL display. Even better in Modo is exporting models using .lwo (generally flawless importation into Modo from my experience).
Edit: You know, the more I look at the models, I don't really see any striking difference. Pretty much one-to-one in quality.
Blender and this importer rock!
Sounds like you're looking for Dissolve, which you can find from the Delete menu (X).
I've bitten the bullet and learned the Blender defaults, and I know my way around it fairly well, but certain things just aren't well thought out at all, which is understandable when you know they were added on later. Hell, undo and edge/face selection were added on fairly late!
Which is why Cessen's keymap rethink is a very, very good thing.
I'd like to see him finish it by the 2.7 release, and see if it can't be made default.
Of course I'm happy for the new key maps to be added as an option but I wouldn't want them to be the default key set simply because most people are used to the defaults, it would cause massive inconsistency in all the available learning material and documentation that has been made since 2.5 was released and huge headaches for 98% of users who would have to relearn everything from scratch while they try to reset their muscle memory. Most of the keys are also pretty well optimised and intuitive once you learn them well.
I think it is one of those things that if it is just changed, even those that resist would probably move over to it. The default in there now is amazingly inefficient for selections which is mostly what Cessan's keymap improves. The controls in his keymap are listed in this commit.
Not for people new to the software. You may have gotten used to it, but that does not make it good, or even 'fine'. Certainly not for something so easy to fix.
It's extremely counterintuitive, and part of what makes Blender so hard to get into (although it's much, much less so than older versions).
The Circle and Box Select work differently from regular select. lmb selects instead of rmb, and instead of shift-click deselecting, mmb does, without clicking.
Select linked also works differently: You just hold your cursor over the mesh part you want and press L, Blender will pick whatever’s closest. Existing selections make no difference. In addition to this, it always adds to the selection, whereas other ‘regular’ selection in Blender will override the previous selection, needing the Shift key to be held to add/toggle - which, in this case only deselects. Furthermore, in the uv/image editor L does override the previous selection! In addition to that, with ‘Sync selection’ turned on it fails to work entirely.
ctrl-n in editmode triggers ‘make normals consistent’ rather than reloading the startup file, as it does in object mode. Keys don't need to be 100% consistent, but ctrl-n, really?
In the uv editor, the N and T hotkeys toggle side-bars in reversed order.
The uv/image editors snap settings are linked to the 3d viewport and can only be viewed/changed there, even when it's hidden. Not all snap settings work in the uv editor. Same thing goes for soft selection (proportional editing).
Select Shortest Path was only recently fixed for vertices, so things are being looked at and fixed, just in a piecemeal way.
As for other stuff, Cessen's keymap finally adds keys to add and subtract from a selection rather than just one that toggles.
Cessan's keymap eliminates this because it has more conventional methods for selecting and deselecting things. If you can select units in Warcraft III, you can select things in Blender with Cessan's keymap.
Experienced users are always welcome to tweak the keymap to make their personal workflow more efficient, but the default mapping should strive for familiarity as much as it can.
Like I said, there are some crappy things, but what about all the great hotkeys? There are plenty of things that work really well.You really can't get more intuitive than R for rotate, E for extrude, S for Scale, G for grab, CTRL+E/F/V for Edge/Face/Vert menus etc.
I'm not saying that Blender couldn't clean up some stuff regarding inconsistencies but changing the hotkeys for the entire program seems a little OTT when many of them are perfectly fine.
Maybe I'm just used to the hotkeys as they are, but in most cases I don't understand what all the fuss is about.
Also who says that another software is correct? What is familiar to one isn't to another...It's all down to perspective really.
The BF should just get on with making a set of complete hotkeys for Max/Maya/ and XSI users and have done with it, without the needless rehashing of the hotkeys that 98% of people are used to and happy with (inconsistencies notwithstanding).
It's not about being 'correct' ; it's about being logical, consistent, efficient, and easy to learn/use. The argument "Everyone should learn it because that's the way it is" is a great way to stall progress. 2.5 (new UI) and 2.63 (B-Mesh integrated) were both releases that needed to happen for Blender to become more widely adopted, but there were a lot of of people that were opposed to such changes simply because they didn't want to learn something new, the Keymap is no different.
Come on, man. I'm the last person who would say "Everyone should learn it because that's the way it is". I probably push more than almost anyone on Polycount regarding improving Blender for game artists and am one of its harshest critics in regards to stuff that needs improving...just read my previous posts.
BMesh was needed because the mesh tools couldn't move forward without it, The UI needed to be changed because it was getting cluttered and devs were running out of space. Blender doesn't 'need' a new key map, it's just that some people would like one, which is fine, I just don't think it should be default.
- LMB selects
- LMB-Drag does a box select.
- Shift+LMB adds to selection.
- Ctrl+LMB removes from a selection.
- Clicking outside deselects all.
This means on first launch of most applications you do not need to learn these basic input mechanisms. In Blender's case it would even free up the A and B keys for something better.
Cessan's keymap is typically superior on the other hotkeys too. Rather than the hilariously bad Ctrl+Tab+1,2,3 for vertex,edge,face select, it's just 1,2,3. Modes are changed with the spacebar key rather than tab. Letters or numbers can be used to quickly pick the actual mode. Spacebar+E (or 2) goes to edit mode, Spacebar + S (or 3) goes to sculpt mode. Etc. There isn't that confusion of where does tab go if I'm in pose mode?
Ya'll should at least try it out.
I think what xrg is saying is correct though. If you're going to build a keymap then OS standards should be considered first and foremost as everyone, despite what apps they've used, will be acquainted with them.
That's not to say that what's being said here about maps is without merit, but it needs to be contextualised.. it's bad relative to what? Is the comparison being made with respect to it being 'bad' the way a particular function works in Blender, or is it bad relative to the way other applications work?
Here is an educator Anyway, I hope Blender drags ya'll Luddites along kicking and screaming and puts Cessan's keymap as default, like they did with the UI and Bmesh. :poly124: I really think there would be less "I tried Blender a few times, but it is just too alien to learn" posts and it would wind up being more common in Studio settings and the like.
bad relative to other applications - most software I can pick up and start making stuff in a few hours like picking up Mudbox for the first time after using Zbrush for a while.
I really wanted to like Blender when I was shopping around for a 3D Painting app but holy hell, it had me almost punching my screen in frustration.
They changed the UI and added BMesh because the software couldn't progress without the changes. The UI was cramped and the old mesh code was 15 years old.