Is it just me or does…
This non scaling of the profile is particular to Blender. in other apps, the resultant mesh tries to follow the flow of the base shape (in this case, the arch) and to do so, scales the profile in the corners. Blender pops the same bevel profile in at every vert regardless of the resulting shape. This makes things like windows (above) difficult to bang out quickly.
Does anyone else feel this way?
~Glenn
I feel that some of Blender’s basic tools are in need of improvement. Sometimes it seems that the basics are just left as is while bells and whistles are pursued. So we end up with a lot of half-developed things. Maybe half is too harsh. How about 80% complete.
sometimes I prefer to use beveled curves…especially for complex profiles…model as 3d curve(the outline…easier to see) change to 2d …convert to mesh…and delete the sections that fill the opening…pretty quick and comes out true…
I just played around with this. It does work the way you would expect it to when the base object is a 2D-curve instead of 3D. I wonder if there’s a reason for the behaviour in 3D-mode or if it’s an oversight… I agree that it should in all cases look like you showed in your first post.
Definitely agree with that.
Yuck, I see what you mean.
Could this actually be considered a bug? As experienced as you are Glenn it may be better to contact the devs more directly, ie bugtracker. Posting here is a bit like gambling that someone in the know (or care) will see such things.
Now that I’m trying to actually make something in 2.5 rather than just play around, I’m finding all sorts of interesting oddities and shortcomings that are blocking progress. I’m not sure what’s a bug or what’s just the UI or part of the “Blender culture” so I’m just collating a huge list and will probably create one, large doccument outlining my thoughts.
That said, I wonder why we still have no shape primitives (rectangle/square/straight line) the same way we have simple mesh primitives? I’d love to not have to build a rectangle out of a curve every time I need one (or for that matter, build a cube and delete everything except for the rectangle of edges I need.) 
~Glenn
Best to post a big exhaustive list of these oddities to the developer mailing list and see if any developers will pick it up.
I believe there is a developer right now who has been focusing on Blender’s curve system.
Where’s he developer’s maiuling list anyway?
~Glenn
Done. Ta.
2d does work as expected.
here is what I’d like to see…
~Glenn
That’s a neat bug, Glenn, although I’d like to hear from a dev on whether it’s a bug or a “feature”. There are a lot of things about Blender that I consider bugs, but which aren’t considered bugs by the devs. For example, the falloff on paint strokes is a big one for me. The further away from the viewing normal your face is angled, the less easy it is to paint on objects because of some code introduced in the late 2.4x series. Before, you could paint across everything and it worked fine, but since the addition it’s even hard to paint on a simple cube without constantly rotating the object so that the faces you want to effect are towards the camera.
If you do write this list I’d love it to be public, so that people at other studios could add to it. Paint aside (and there may well be an option now to turn that blending off; I haven’t checked), the fact that all the exporters spit out unwelded vertices is a big one for pipelines that screwed things up for me last year. (Reported as a bug; was told by devs that since Blender doesn’t treat verts as welded it’s an issue for the external program and not something Blender should handle, which I disagree with.) There’s also the issue of objects replacing bones scaling to match the length of the bone, instead of scaling by a length that considers the rested pose bone a “normalized” length. (If it worked in this way, you could more easily use the same object for multiple bones instead of having to duplicate shape objects and scale them on a per-bone basis.)
Who knows-- maybe if enough people say some of these features are bugs, they’ll listen.
yeah, that sounds like this question I posted to a deafening roar of silence…
http://blenderartists.org/forum/showthread.php?t=177273
~Glenn
That’s because the vertex paint tool obeys backface culling, so backfaces aren’t affected. You may call it a bug, but it’s actually a useful thing if you only want to paint the front side of a large object with a large brush or something.
The solution here would be an option for backface culling to be ignored so backfaces get color as well, or another option to spill color onto the backfaces neighboring the visible ones.
qualifier: i’m not a developer 
there is an option for this… (as always the manual is your friend!)
in teh toolbar in paint mode look at the “project paint” subpanel: “normal” checkbox enables/disables taking the normal into account, which is fabulous for preventing streaking and candystriping when painting, so it’s a very useful feature!
the ‘80’ necxt to it is an angle for the falloff from the normal above which strokes get modulated…
(Reported as a bug; was told by devs that since Blender doesn’t treat verts as welded it’s an issue for the external program and not something Blender should handle, which I disagree with.)
there really isn’t a good way to deal with this as blender is primarily “per face” smoothing… edge split gives per edge… but because it’s a modifier needs to be applied on export…
I export to maya a lot and find that it’s the most robust solution for maintaining WYSISYG…9and tghe only way to get per edge smoothing… and in maya I can select the open edges, mark them as hard and merge so no biggie… a two line mel script macro sorts it!
Who knows-- maybe if enough people say some of these features are bugs, they’ll listen.
well, not if they’re not bugs! 
Hmmm… :eyebrowlift2:
Michael, my point is in relation specifically to vertex painting. Which raises another question about consistency in Blender, doesn’t it.
In much the same manner as this thread…
http://blenderartists.org/forum/showthread.php?t=184303
~Glenn
grsaaynoel, yes, you’re right…I was more addressing katkieru…
vertex paint is actually per polygon per vertex (which is desirable for many situations, video games especially) rather than say weight paint which is per vertex for good reason!
in your example the cube is about as extreme a case as you can get… in your case the the occluded polygons are not painted… the only solution is to make surethat all faces on the vertex are in view…
I’m not sure that turning off backface culling would be a desirable fix in this case: you’d be painting stuff you cannot actually see which sounds dangerous…
…but having the option to paint per vertex or per vertexface would solve this issue…(I’ve looked and don’t think we have that ability)…(internally I’m sure it’d still be stored as pervertexface, though!
so again, not strictly a bug, but possibly a feature request…
EDIT: so to clarify, this isn’t the “normal fade” causing this, its backface culling, which is consistent with other paint modes (weight paint excepted!)
Thanks Michael! I’ll have to check it out when I get a spare minute. It’ll be nice to stop round-tripping images into other packages to do minor touchups to baked textures.
(Although I’m not so sure on the usefulness-- I prefer the streaking. That’s how bodypaint works, and I find it less annoying to paint out streaks than to have to constantly rotate the model into position. But that’s not what this thread’s about. ^_^)
there really isn’t a good way to deal with this as blender is primarily “per face” smoothing… edge split gives per edge… but because it’s a modifier needs to be applied on export…
I export to maya a lot and find that it’s the most robust solution for maintaining WYSISYG…9and tghe only way to get per edge smoothing… and in maya I can select the open edges, mark them as hard and merge so no biggie… a two line mel script macro sorts it!
Smoothing isn’t the issue. I can resmooth in Maya no problem, and honestly I find that’s the best way to go. My issue is with how Blender UVs that occupy the same UV space aren’t actually the same UV at export.
Do this: UV a box in Blender, then in Maya click on one UV and try moving it. You’ll find out that if three faces logically share that UV, there are three UVs sitting on top of each other. It’s an easy fix (Select all UV’s and hit Weld with a low tolerance in Maya), but as the external formats like OBJ and FBX exist specifically to facilitate pipeline workflows with other packages, it doesn’t make sense to me that the default settings for UV export, settings that AFAI can tell only apply to Blender, aren’t more pipeline friendly. Especially since Blender can read OBJ files from other packages where faces actually do share UVs just fine.
The logic behind that and the weight painting issue grsaaynoel noted is similar-- Blender deals with certain things at a per-face level, and the user should adapt. But I think that in many circumstances, Blender could be a bit more like other packages on the market and could gain mindshare by doing so, which is why I’m interested in where grsaaynoel goes with his list.
(I suppose the next argument is: if it’s so important, why not submit a patch? Answer: 60±hour work weeks don’t leave a lot of time for coding. ^_^; )
And as far as that list goes, I’ve found the devs are much more keen to listen to people who show images and diagrams of how things could work better, so you know. The current competitive analysis page reads more like a wishlist or someone’s bookmarks of whitepapers than a set of well-thought-out suggestions. Images like the one you posted above showing the difference between 2D and 3D lofting are the kinds of things reports that get issues fixed.
how maya imports data and how you have to condition it after import is really a maya issue…besides, there are many issues created by the importers of external apps rather than by blender’s export too…
maya completely ignores the “obj” tag in obj for example ironic considering it’s originators…
that said, fbx support could be much wider in its compatability if autodesk documented it, but they won’t do that as they want to get 3rd parties to sign up to their sdk and agree with their terms and conditions sadly in-compatible with GPL products( but I digress)
as for the candy striping vs paint thru: I’ve shown you how to disable it if you don’t like it, but also feel compelled to point out that the “normal falloff” feature comes from z-brush and was much requested by users as a good thing… it’s not really “blender being unique and random”, it’s blender adopting features from other software by user request which is what you’re advocating isn’t it? arguing what bodypaint does or doesn’t do is a bit pointless isn’t it? blender isn’t bodypaint…
The logic behind that and the weight painting issue grsaaynoel noted is similar-- Blender deals with certain things at a per-face level, and the user should adapt. But I think that in many circumstances, Blender could be a bit more like other packages on the market and could gain mindshare by doing so, which is why I’m interested in where grsaaynoel goes with his list.
it’s not about blender dealing with things one way and the user must adapt, (though historically the inability to customise keymaps has led to much of this feeling)
it’s that any package offering vertex painting will be considered deficient if it doesn’t use per vertexface… it’s not about blender “being different” for the sake of it.
The “issue” is the omission of a “per vertex” paint mode (regardless of how the data is stored internally) but it would be far far worse for blender to have per vertex and not allow per vertex face… it’d be laughed out of town for missing out what is fundamental to vertexpaint being useful for video games… or capturing lighting in vertex colour for example…
these are the same design constraints that other software face and blender has similar solutions when you look at it…
I’ve been in video games for a long time and over the years have used many programs, as far as I can see blender has an awful lot of max, maya, lightwave etc in its design choices, but they’ve not been “straight copied”, rather made to work coherently for blender (at least that’s the idea!)… (there are some nooks and crannies and some old cruft for sure! and lots of places where blender needs improvement and tidying up,
I just needed to refute your assertion that blender development “ignores” the needs of users and willfully makes things obscure and “non-industry standard”… the truth is the industry standard is about capabilities and certain workflows because when you look at it all the implementations are pretty differnt really, only what they are trying to achieve remains constant…