[Bf-funboard] Fwd: Critical improvements and features

[Campbell Barton]

On Fri, Sep 20, 2013 at 8:57 AM, David Jeske <davidj at gmail.com> wrote:
> On Thu, Sep 19, 2013 at 1:38 PM, Gatis Kurzemnieks <
> gatis.kurzemnieks at gmail.com> wrote:
>
>> Thanks for your answers and ideas! I agree that some of them can be done by
>> workarounds, but It would be nice for new users to have familiar
>> behaviours.
>>
>
> With respect, it's important that we be clear where there is missing
> functionality, and where there are ideas for easier workflows for things
> which *are* possible, but might be cumbersome. Figuring out how to make
> those cumbersome elements easier often requires tradeoffs with other UI
> choices which are quite nice, so it seldom ends up as clear as it seems at
> first.
>
> In other words, I've learned that generally when blender is doing something
> wonky there *is* a reason for it, even if it's not obvious at first. Let's
> dig a little deeper before we jump off the cliff of thinking every one of
> these things should be changed. Then at least if we jump, we'll be informed.
>
>
>> > 1. Viewport performance is very poor - especially when entering edit
>> mode.
>> > Performance drops dramatically when entering edit mode for models with
>> > high polygon counts (500k+). Performance is quite bad even outside edit
>> > mode (for models with 1-2 million polygons), but when entering edit mode
>> -
>> > blender almost freezes and is not usable.
>> > In comparison in Softimage or Maya Viewport 2.0, everything is silky
>> > smooth for the same polygon counts, so this could be improved
>> dramatically
>> > and is very important.
>> >
>>
>> - no comments here. Someone with core understanding about blender viewport
>> openGL implementation should approach this.
>>
>
> It would be nice to hear comments from someone in-the-know on this.
>
> Is this strictly a GL drawing performance issue? For example, I know
> drawing many independent sets of gl-lines from a derived mesh which is
> merely triangulated is pretty slow. Likewise, using old-school immediate
> glVertex3f style calls is pretty darn slow, and I think blender does both.
> (though I could be wrong?)
>
> Even if Blender is going to support really old GL for compatibility
> reasons, it might be time to start using GLSL to render the viewport
> whenever it is available. Then we could write much faster GLSL shader code
> to handle all viewport drawing modes (solid, textured, wire, xray, etc)...
> using techniques like single-pass wireframes.
>
> This might be some of the thinking behind Ton's plan to incorporate the
> Blender-game-engine as an interactive viewport. However, it might be a
> smaller change to make a fully capable GLSL-120 rendering mode for the
> standard viewport features.
>
>
>> > Good outliner is one of the core features used in managing complex scenes
>> > and hierarchies and reason for most complaints.
>>
>> I don't see any need for the 'blender-ism' style pre selection - it's just
>> confusing. Behaviour should be identical as in any other 3d program:
>>
>
> So far I agree with you on this one. Though I'd love to hear an explanation
> of the blender-ism split-selection benefits from someone in-the-know.
>
> Some reasons I can imagine for the split-selection are:
> - ? the outliner displays items which are not in the 3d-viewport, so they
> can't be "3d selected"
> - ? the outliner can be used for non-3d-viewport tasks, such as in the VSE
>
> Am I getting warmer? I'm just guessing, as split-selection merely confuses
> me in both outliner and dopesheet.
>
>
>> - Multi object mesh editing:  all "illegal" operations when editing
>> multiple selected meshes should just fail gracefully - with proper error
>> message to user. it is just logical that some operations are not
>> reasonable. This is the behaviour in other 3d apps as well. I think illegal
>> would be all operations which connect geometry between selected object. All
>> other operations should be no problem - cutting, extruding, unwrapping UVs
>> (this is actually very very important and frequently used feature - to make
>> single UV layout for multiple selected objects but keep them separated).
>> Now it would require joining them and separating after.
>>
>
> Some more detail would be helpful. Do you expect to be able to freely
> select vertices across objects? Simultaneously extrude pieces of different
> objects?? Are the objects visually distinguished in any way? (btw, I think
> UV unwrapping several objects into a single UV unwrap might be simpler and
> not require going into edit-mode on multiple objects simultaneously)
>
> It might be helpful to see a really simple video of what you expect it to
> do, recorded in your favorite 3d program. For example, I have Maya, but I
> don't do these things, and I think many blender devs don't have access to
> Maya to know exactly what you expect it to do.
>
>
>> - Property panel UI should have ability to handle multiple selected
>> objects. In some tabs it does not make sense to support multiple selections
>> and therefore these tabs can be hidden/inactive when multiple objects are
>> selected (modifiers tab, mesh data, simulation etc.). Object tab should
>> definately support multiple selections and all parameters should have
>> special state to show value if the value differs for selected objects.
>
>
> I'm with you.
>
> - about materials - simplest solution would be for materials to have some
>> dedicated materials palette/window where all scene materials are displayed
>>
>
> Since materials are assigned in edit-mode, if edit-mode is extended to
> support multiple object editing this would already be "fixed", since you
> would just select multiple objects, toggle into edit-mode, select surfaces
> across objects (or select all), and then "assign" the material.
>
>
>> (multiple view modes - list, icons, thumbnails + search options). Then
>> there can be simple button/menu item - "Apply to selected", to apply
>> selected material to selected scene objects.
>
>
> ...here you are asking to assign materials to whole objects from
> object-mode. Seems like this could be done pretty easily. Anyone know any
> reasons this isn't possible today?
>
> (extrude connected behavior)
>
>> Simple example with sphere from Cinema4D extrude:
>> http://postimg.org/image/kj9ncu3yv/  <http://postimg.org/image/kj9ncu3yv/>
>>
>
> I 100% agree with you the above result should be easy to get in Blender.

You can do this: E, Esc, Alt+S

> The results you show are what I expect to get from "individual origins"
> extrude, but I see now that blender does weird things with verticies shared
> by faces.

Fixed in trunk.

> Curiously, it has the same problem if you extrude the region without moving
> it, and then try to use the "normal" transform orientation. Even if you
> smooth the shape (presumably making the point normals the average of
> surrounding faces), blender is arbitrarily picking the normal of one of the
> connected faces for the transform.
>
> Here is a picture to illustrate Blender's behavior, which seems really
> weird to me. You can see the way the two central verticies each picked a
> different neighboring face normal, so they moved away from eachother.
>
> http://www.pasteall.org/pic/show.php?id=59584
>
> Yuck. Seems like maybe a bug to me? Probably easy to fix if someone can
> confirm this is not the intended behavior for some reason.

I *think* this is the same fix referred to above.

>>  - I am talking about object origins (pivots). Now you can set origin to 3D
>>  cursor, but this is 2 steps - and moving 3d cursor is also not easy. It
>> would be nice to be able to do this with standard transformation tools.
>
>
> It is easy enough to do this with standard transformation tools, but it's
> four steps. Add an empty (axis for example). Move it where you want the
> origin. Snap the 3d-cursor to it. set origin to 3d cursor. Delete empty.
>
> If there was "set origin to active", it could be three steps (and it could
> include local rotation).
>
> It could be one step with a feature "select object origin", which would
> turn the origin into an actual 3d object, letting you move it until it
> deselected. I personally don't see any downsides of this feature, other
> than making sure it's clean and stays bug free.
> _______________________________________________
> Bf-funboard mailing list
> Bf-funboard at blender.org
> http://lists.blender.org/mailman/listinfo/bf-funboard



-- 
- Campbell