User Suggestions for 2.8x

[Razorblade]

UNDO…
Just thinking, maybe blender could just try to sty X steps behind and save it as actions.
And keep an object/mesh track save option.
Or some kind of snapshot auto backup, based upon time or amount of edit actions.
But then there is a difference in say, change a single vertex, or apply a smooth over all vertexes.

• not all functions might be undo-able… so this might not be do-able given the current dev path.

And since it seams blender never was made in such a way from scratch, i got an idea

how about :

Each time when one switches between “object edit” and “mesh edit”
(as i think here the most problems occurs).
Such a switch triggers a file backup action of the object : (like projectX-Cube1-ver032.Blend)
And the whole scene “projectX.blend” file would be a file that has no mesh content only links to other files. We allready can link other blend files so that wouldnt be a problem.

But when one does do a full save of the “projectX.blend” one could optionally destroy the small backup object-based blend files, who are not from the latest version.
However if one works on a mesh, (projectX-someMesh-ver1005.blend) then have an option on it to override automatic deletion. (so for example to keep a human mesh in a state before mirror was aplied)

Such a workflow would allow for new ways of working with Blender
ea suppose you are making a street scene in blender.
Then without loading the main blender file, you could instead open just a streatlight, and work on just that. Then when launching the master blend file again, it might prompt you that some meshes have been updated and ask you to use latest or a specific version.

— this looks a lot like how sintel and other movies where made from what i understand.
with the difference of keeping version numbering on mesh/object edits and save them
add automatic linking for masterproject blend file (might be much inline with current development).
versioning control (some addon) to deal with updating links.

benefit
one could easily add options to have low poly animation master blend files
and full movie finished master blend files (the difference just what object version they use).

Pottentially this would cause a lot of small object files (to be all linked in the master). instead of a single use blend file.
But if the masterBlend file where a bit smarter (ea braking standards with .blend save files), it couls as well be a link list that knows that some blendobject version file contains more then on streetlight, but in fact contains also trees, garbage cans, and cars. And that it knows that people are in another blend file.

Pro

• it wouldnt require huge changes for the Blender program
• would be more close to how blender movies are allready made.
• maybe not that much c++ coding required (adding save action to obje/edit mode switch)
• no changes required in all object edit methods, can keep curent
• a way of dealing with master link file would need to be made (could be all python i think).

neg

• projects wont consist of a single file anymore, a minium of 1 master.blend, and 1 objectversion.blend
  (but could be zipped). (but have option to open such zips in blender would be nice).
• rethink of storage of textures etc, preferably always relative path link.
  • it could allow for a master file to change in between lowress vs highres textures.
• it might require that each project would always start as a file system folder with its master en object.
  and a link to textures etc. (personally i wouldnt mind some organizing here)

• or that we change to zip save by default (a zip of files in the folder).

[motorsep]

Here is food for thought.

Initial scene is ~20 objects, instanced over a plane. After I make duplicates real, Blender takes about 40 min to turn instances into real objects.

After than my scene has 172 objects, total tris count 83M. 3D view is obviously unmanageable for me as-is, so all I really want it to set the objects to be shown in the 3D view as bounds. Blender uses 4-something Gb of RAM out of 8Gb RAM I have. Windows 7 64-bit.

All I am trying to do is select a few (20+) objects at a time in the Outliner, then set them to be displayed as bounds. Blender takes ages to select objects, then ages to turn set them to be displayed as bounds and when I am almost done, it crashes video drives for whatever reason o.O

I tried this in 2.76b official and a build of 2.77 from Jan 23 2016 downloaded from Blender.org

It’s annoying that things like that bring my work to a halt. Dear devs, before anything, please fix existing parts of Blender.

[Piotr_Adamowicz]

@m9105826

Undo definitely needs an overhaul. Everything should be an action that gets added to the undo stack, with separate stacks per area type, controlled by mouse hover i.e. an undo stack for the 3D view, and undo stack for the properties panel, an undo stack for the NLA editor, etc. each with smart undo depending on where user focus is.

I think you haven’t sufficiently thought this through. If you’re going to separate stacks per area, that means that when you undo things, they might be undone in a different order than they were first performed, one that might make no sense or lead to unwanted results that will be particularly hard for new users to understand since in most software you don’t have to pay attention to where your mouse is when you undo. For example:

1. Add a cube
2. In the properties panel, add a UV layer
3. Unwrap your cube in the UV editor
4. Press Ctrl-Z while hovering over the properties panel (without paying attention to where the mouse is hovering)
5. Oops! Your work just got obliterated since you’ve undone adding the UV layer.
6. You press Redo and Blender dutifully adds back the UV layer… empty, since the unwrapping actions were not part of the Properties undo stack.
7. (bonus question: what’s the state of the UV editor undo stack now?)

This is further exacerbated by the fact that you can perform certain actions from multiple contexts.

This is a horrible idea and a learner’s nightmare. Blender already separates undo stacks for Object, Sculpt and Edit mode, and it sometimes leads a few moments of lost work even for me, and I’d say I’m plenty experienced. (perhaps it’s fixed now? I know it used to be this way at least)

I’d say Blender needs to do the opposite - have a single, predictable, global stack without separating into modes or areas, and register into it everything that changes anything - data edits being the obvious thing, but also things like mode switching, editor switching, window resizing, setting changes on sculpt brushes, etc. (Note, I make no claims as to the feasibility of any of this.)

[Ace_Dragon]

Razorblade; your solution gives the impression of being more in the way of an over-complicated workaround as opposed to something that would finally give Blender a proper global undo system.

In my opinion, the main issues are memory use (due to the utter lack of the ability to store just the minimal data needed for that step to be undone), speed (which ties in strongly to the memory issue), and the rather dumb way that the presence of multiple stacks are handled (undoing an editmode or sculpt session should not delete the respective stack with no way to recover it). The devs. need to get to the root of the problem and fix them on the core level without adding any new layers of complexity (it’s the only way to ensure a future-proof design that won’t bite you in the butt later).

Sure, it might take a while to get such a system overhaul in full working order, but working around it would also take a while.

[sourvinos]

@Piotr Adamowicz

I think you haven’t sufficiently thought this through. If you’re going to separate stacks per area, that means that when you undo things, they might be undone in a different order than they were first performed, one that might make no sense or lead to unwanted results that will be particularly hard for new users to understand since in most software you don’t have to pay attention to where your mouse is when you undo. For example:

1. Add a cube
2. In the properties panel, add a UV layer
3. Unwrap your cube in the UV editor
4. Press Ctrl-Z while hovering over the properties panel (without paying attention to where the mouse is hovering)
5. Oops! Your work just got obliterated since you’ve undone adding the UV layer.
6. You press Redo and Blender dutifully adds back the UV layer… empty, since the unwrapping actions were not part of the Properties undo stack.
7. (bonus question: what’s the state of the UV editor undo stack now?)

This is further exacerbated by the fact that you can perform certain actions from multiple contexts.

This is a horrible idea and a learner’s nightmare. Blender already separates undo stacks for Object, Sculpt and Edit mode, and it sometimes leads a few moments of lost work even for me, and I’d say I’m plenty experienced. (perhaps it’s fixed now? I know it used to be this way at least)

I’d say Blender needs to do the opposite - have a single, predictable, global stack without separating into modes or areas, and register into it everything that changes anything - data edits being the obvious thing, but also things like mode switching, editor switching, window resizing, setting changes on sculpt brushes, etc. (Note, I make no claims as to the feasibility of any of this.)

Holy words!

pity that no one seems to care minimally, at least so far (too much work, they told).

paolo

[m9105826]

@Piotr Adamowicz

I think you haven’t sufficiently thought this through. If you’re going to separate stacks per area, that means that when you undo things, they might be undone in a different order than they were first performed, one that might make no sense or lead to unwanted results that will be particularly hard for new users to understand since in most software you don’t have to pay attention to where your mouse is when you undo. For example:

1. Add a cube
2. In the properties panel, add a UV layer
3. Unwrap your cube in the UV editor
4. Press Ctrl-Z while hovering over the properties panel (without paying attention to where the mouse is hovering)
5. Oops! Your work just got obliterated since you’ve undone adding the UV layer.
6. You press Redo and Blender dutifully adds back the UV layer… empty, since the unwrapping actions were not part of the Properties undo stack.
7. (bonus question: what’s the state of the UV editor undo stack now?)

This is further exacerbated by the fact that you can perform certain actions from multiple contexts.

This is a horrible idea and a learner’s nightmare. Blender already separates undo stacks for Object, Sculpt and Edit mode, and it sometimes leads a few moments of lost work even for me, and I’d say I’m plenty experienced. (perhaps it’s fixed now? I know it used to be this way at least)

I’d say Blender needs to do the opposite - have a single, predictable, global stack without separating into modes or areas, and register into it everything that changes anything - data edits being the obvious thing, but also things like mode switching, editor switching, window resizing, setting changes on sculpt brushes, etc. (Note, I make no claims as to the feasibility of any of this.)

I think it could be made to work woth a proper dependency tree, but indeed it would be a coding nightmare. Your proposed solution (giant global undo pool for every action) would certainly be a better option than what we have now.

[pitiwazou]

How the other softwares works on the Undo ?

[Razorblade]

@Ace Dragon
I Know it is quite a bit different, but at the same time, its also how big movies are made these days with blender.
They do it more manual currently, but the complexity in my ideas could be automated by scripting making the usage simple again.
The idea came to me, as i was thinking in terms of file systems that are file versioning aware (i’m investigating them for something else).

The file complexity could be reduced in a few ways

• allowing for a folder zipped structure (blender allready has internal zip support), a starting user wouldnt need to know whats inside
• it could be made that only the most recent, and those with special exception are kept during a master blend file save
  (all older versions get deleted).

And well basically with only one exception i can think of this could all be made in a python plugin in todays Blender.
The only exception is to add some c++ code, as required of saving object.version.blend files between meshedit/object edit switching.
In other words it wouldnt require huge code changes for every kind of function that edits on mesh/object.
It would also be backwards compatible

And especially with the lookout on improvements that are worked on by dev currently
As I remind to have seen recently in Blender’s object outliner (to support file links to other files).
This kind of undo would use that a lot, i mean the master file would only consists of such links then.

Also this solution wont require a lot of memory, rather it would use more disk space (which is pretty cheap).
Wich later could even be reduced by performing differential saves (a technique used in file versioning systems).

For the rest no big coding changes required.
While at the same time have a production workflow, that could be used by teams (where people work on their object-version.blend).

Multiple master files could exist, with different preferences as to file version, or textures etc.
A 3 minute movie scene could simply be a master file, based upon the same assets.

[Ace_Dragon]

@Razorblade

@Ace Dragon
I Know it is quite a bit different, but at the same time, its also how big movies are made these days with blender.
They do it more manual currently, but the complexity in my ideas could be automated by scripting making the usage simple again.
The idea came to me, as i was thinking in terms of file systems that are file versioning aware (i’m investigating them for something else).

The file complexity could be reduced in a few ways

• allowing for a folder zipped structure (blender allready has internal zip support), a starting user wouldnt need to know whats inside
• it could be made that only the most recent, and those with special exception are kept during a master blend file save
  (all older versions get deleted).

And well basically with only one exception i can think of this could all be made in a python plugin in todays Blender.
The only exception is to add some c++ code, as required of saving object.version.blend files between meshedit/object edit switching.
In other words it wouldnt require huge code changes for every kind of function that edits on mesh/object.
It would also be backwards compatible

And especially with the lookout on improvements that are worked on by dev currently
As I remind to have seen recently in Blender’s object outliner (to support file links to other files).
This kind of undo would use that a lot, i mean the master file would only consists of such links then.

Also this solution wont require a lot of memory, rather it would use more disk space (which is pretty cheap).
Wich later could even be reduced by performing differential saves (a technique used in file versioning systems).

For the rest no big coding changes required.
While at the same time have a production workflow, that could be used by teams (where people work on their object-version.blend).

Multiple master files could exist, with different preferences as to file version, or textures etc.
A 3 minute movie scene could simply be a master file, based upon the same assets.

Can you imagine though, every little scene you want to make needing multiple files rather than having everything neatly packed together?

It might be useful for movie makers, but that’s where it stops (some people here have perfected the art of banging out a still image almost every day, can you imagine the mountains of files they would need to deal with)?

[Razorblade]

thats why, i opted to also have an option save as zips, and be able to work with such zips.
That would make it easier for those who start with blender.
Also when working with the masterproject.blend (consisting only of links to other object.blend files), it should behave just as a normal current blend file.

in fact if i scrap the whole “versioning undo” part of it, this could allready be done today as we can link to other blend files already.
The versioning however would make it also intresting for those who work on still images / modelling.
As one could go back in time with no limits. It would be an ulitmate endless undo option.
Unlike other progs who work with a stack of memory based undo, who only can do like x undo’s (like photoshop etc).

[KWD (Kévin Dietrich)]

@pitiwazou

How the other softwares works on the Undo ?

Apparently Photoshop makes a copy of the entire document (psd file), but shares between the documents whatever hasn’t changed. (

)

I believe, Blender does something somewhat similar.

[Ace_Dragon]

@Razorblade

thats why, i opted to also have an option save as zips, and be able to work with such zips.
That would make it easier for those who start with blender.
Also when working with the masterproject.blend (consisting only of links to other object.blend files), it should behave just as a normal current blend file.

in fact if i scrap the whole “versioning undo” part of it, this could allready be done today as we can link to other blend files already.
The versioning however would make it also intresting for those who work on still images / modelling.
As one could go back in time with no limits. It would be an ulitmate endless undo option.
Unlike other progs who work with a stack of memory based undo, who only can do like x undo’s (like photoshop etc).

This may or may not require a major overhaul with how the .blend file format works (which might be a bit of a bigger task than simply redoing the undo code). I think with my method of how undo could work, it could even be done incrementally so it doesn’t cause much user disruption and users can benefit from the new system much sooner.

Like the different data types to be stored depending on the action, the first step wouldn’t even include functional changes since you would just be defining what the types are and what Blender should do with them. That would be followed by possibly having a new Undo step type enum for RNA and then replacing the plugs for the current global undo with plugs for the new system. Ideally, the undo system would have a bit of resemblance to how .diff files work in version control.

[Love_3D]

Does it make sense to have the ability to rotate (translate) the world background within the preview window ?

[Regnas (• I don't speak English "by default", so...)]

@Love 3D

Does it make sense to have the ability to rotate (translate) the world background within the preview window ?

Why not?

            .

[jpb06]

Presets and asset browsers (already under development), for ideas on the user interaction see how Poser or DAZ Studio or Vue handle the thing (select object, double click or drag upon to apply preset).

A non-binary format for files (in addition to .blends not in substitution), for reference see Svechock JSON files. Reason: to allow completely different programs to read/write meshes, materials etc. etc. etc.

[zeauro]

It is already there. You just have to give texture coordinates to world background.

[Love_3D]

Hahaha thats funny.

Too much work.something like cryengine 2.8

[cekuhnen]

Not a bad idea actually to do this visually but I am also ok with the mapping node tool to rotate it.

[kolux2016]

Hi can someone please help me out i use blender for a while now and am trying to uv unwrap my model i did in mud-box too it into blender for re-topology. when i try UV unwrap the object it come out well but when i apply a texture to it. it doesn’t come out right as one side is darker than other side and it has a separate in the texture is there anything i can do to make then blend as it look quite not normal thank you.
[ATTACH=CONFIG]420807[/ATTACH][ATTACH=CONFIG]420806[/ATTACH][ATTACH=CONFIG]420808[/ATTACH]

[Love_3D]

or somthing like this, icons 4 viewer and mute.awesome

Oh m and ctrl+shift+click still work.