[Bf-funboard] Fwd: Critical improvements and features

[David Jeske]

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.

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.

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 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.