Re: [Bf-committers] bpy.context.scene.frame_set(i) issue

[Bartek Skorupa]

1. Take any scene that plays back 1 frame per second or so. (I can't  
upload any example now, but I'm sure everybody has such scene  
somewhere). Many objects (2000?, 3000?), constraints, shapekeys,  
armatures, curves etc.
2. No matter if the layers are active or not, no matter what the draw  
mode is etc - it is slow. I can place all of my obs in layer 2,  
activate only empty layer 1, and it doesn't influence the speed.
3. Even if frame_set() is as fast as playback - I'm not happy. 250  
frames - 1 frame per second = 250sec. = 4 minutes. Who wants to wait 4  
minutes?

Bartek Skorupa

www.bartekskorupa.com


On 2012-01-21, at 00:58, Campbell Barton wrote:

> Hi Bartek,
>
> Would you be able to upload a test scene which is unusably slow?
> can't see why this would be any slower then playing back the animation
> (if anything should be faster since it doesn't have to draw).
>
> On Sat, Jan 21, 2012 at 9:58 AM, Bartek Skorupa
>  wrote:
>> Hi,
>>
>> I'd like to draw your attention to frame_set(i) method.
>> In many scripts we have to refresh the scene several times, sometimes
>> we need to collect some data for every frame in the whole animation.
>> In such cases the only way I know in blender's python is to set the
>> frame using bpy.context.scene.frame_set(frame)
>> Almost every exporter that base on baking the data and exporting them
>> as "keyframe for every frame" use this kind of loop:
>>
>> start = bpy.context.scene.frame_start
>> end = bpy.context.scene.frame_end
>> for frame in range (start, end + 1):
>> bpy.context.scene.frame_set(frame)
>> '''
>>  all the magic that needs data for each frame 
>> '''
>>
>> My exporter to Adobe After Effects (io_export_after_effects.py) does
>> exactly the same.
>>
>> The issue here is that setting the frame sometimes takes ages.
>> I was once advised to use bpy.context.frame_current = frame
>> Well... It's very fast, but doesn't do the trick. It sets the frame,
>> but doesn't update the scene and in most cases - this is what we want
>> - We want to have our scene refreshed for every frame.
>>
>> bpy.context.scene.frame_set(frame) method is so slow, that many
>> exporters become almost useless or if not useless - very badly
>> perceived because of their performance.
>> The process of simple export to After Effects can sometimes take
>> several minutes and this is definitely not the performance we are
>> looking for.
>> I looked through many existing exporters and they all use this  
>> method,
>> so I suppose I'm not the only one facing "frame_set" speed issue.
>> Does anyone know other method to achieve refreshing the scene for
>> every frame, but not that slow?
>>
>> Isn't this performance a bug of some kind?
>>
>> I'd appreciate any help.
>>
>> Cheers,
>> Bartek Skorupa
>>
>> www.bartekskorupa.com
>>
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>
>
>
> -- 
> - Campbell
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] bpy.context.scene.frame_set(i) issue

[Campbell Barton]

frame_set() updates all layers of the scene which I expect is the problem here,

there could be an optional argument to pass a layer list to
frame_set()  but this doesn't necessarily help if the current scene
layers are not setup efficiently.

looking into this you could update only the objects you want like this...

# objects to update
objects = bpy.context.selected_objects
scene = bpy.context.scene
start = scene.frame_start
end = scene.frame_end
for frame in range (start, end + 1):
scene.frame_current = frame
for obj in objects:
obj.update_tag(refresh={'OBJECT'})  # 'DATA' too if you care
about geometry
scene.update()
'''
 all the magic that needs data for each frame 
'''


On Sat, Jan 21, 2012 at 7:56 PM, Bartek Skorupa
 wrote:
> 1. Take any scene that plays back 1 frame per second or so. (I can't
> upload any example now, but I'm sure everybody has such scene
> somewhere). Many objects (2000?, 3000?), constraints, shapekeys,
> armatures, curves etc.
> 2. No matter if the layers are active or not, no matter what the draw
> mode is etc - it is slow. I can place all of my obs in layer 2,
> activate only empty layer 1, and it doesn't influence the speed.
> 3. Even if frame_set() is as fast as playback - I'm not happy. 250
> frames - 1 frame per second = 250sec. = 4 minutes. Who wants to wait 4
> minutes?
>
> Bartek Skorupa
>
> www.bartekskorupa.com
>
>
> On 2012-01-21, at 00:58, Campbell Barton wrote:
>
>> Hi Bartek,
>>
>> Would you be able to upload a test scene which is unusably slow?
>> can't see why this would be any slower then playing back the animation
>> (if anything should be faster since it doesn't have to draw).
>>
>> On Sat, Jan 21, 2012 at 9:58 AM, Bartek Skorupa
>>  wrote:
>>> Hi,
>>>
>>> I'd like to draw your attention to frame_set(i) method.
>>> In many scripts we have to refresh the scene several times, sometimes
>>> we need to collect some data for every frame in the whole animation.
>>> In such cases the only way I know in blender's python is to set the
>>> frame using bpy.context.scene.frame_set(frame)
>>> Almost every exporter that base on baking the data and exporting them
>>> as "keyframe for every frame" use this kind of loop:
>>>
>>> start = bpy.context.scene.frame_start
>>> end = bpy.context.scene.frame_end
>>> for frame in range (start, end + 1):
>>>     bpy.context.scene.frame_set(frame)
>>>     '''
>>>      all the magic that needs data for each frame 
>>>     '''
>>>
>>> My exporter to Adobe After Effects (io_export_after_effects.py) does
>>> exactly the same.
>>>
>>> The issue here is that setting the frame sometimes takes ages.
>>> I was once advised to use bpy.context.frame_current = frame
>>> Well... It's very fast, but doesn't do the trick. It sets the frame,
>>> but doesn't update the scene and in most cases - this is what we want
>>> - We want to have our scene refreshed for every frame.
>>>
>>> bpy.context.scene.frame_set(frame) method is so slow, that many
>>> exporters become almost useless or if not useless - very badly
>>> perceived because of their performance.
>>> The process of simple export to After Effects can sometimes take
>>> several minutes and this is definitely not the performance we are
>>> looking for.
>>> I looked through many existing exporters and they all use this
>>> method,
>>> so I suppose I'm not the only one facing "frame_set" speed issue.
>>> Does anyone know other method to achieve refreshing the scene for
>>> every frame, but not that slow?
>>>
>>> Isn't this performance a bug of some kind?
>>>
>>> I'd appreciate any help.
>>>
>>> Cheers,
>>> Bartek Skorupa
>>>
>>> www.bartekskorupa.com
>>>
>>> ___
>>> Bf-committers mailing list
>>> Bf-committers@blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>>
>>
>> --
>> - Campbell
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers



-- 
- Campbell
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] bpy.context.scene.frame_set(i) issue

[Bartek Skorupa]

Thank you very much for that.
I will try it and maybe it will do the trick.
I wonder however if it updates objects when their matrices depend on  
other objects not included in selection (parenting, constraints, etc).

Anyway, thank you very much, I'll see if it improves anything.


Bartek Skorupa

www.bartekskorupa.com




On 2012-01-21, at 11:54, Campbell Barton wrote:

frame_set() updates all layers of the scene which I expect is the  
problem here,


there could be an optional argument to pass a layer list to
frame_set()  but this doesn't necessarily help if the current scene
layers are not setup efficiently.

looking into this you could update only the objects you want like  
this...


# objects to update
objects = bpy.context.selected_objects
scene = bpy.context.scene
start = scene.frame_start
end = scene.frame_end
for frame in range (start, end + 1):
   scene.frame_current = frame
   for obj in objects:
   obj.update_tag(refresh={'OBJECT'})  # 'DATA' too if you care
about geometry
   scene.update()
   '''
    all the magic that needs data for each frame 
   '''


On Sat, Jan 21, 2012 at 7:56 PM, Bartek Skorupa
 wrote:

1. Take any scene that plays back 1 frame per second or so. (I can't
upload any example now, but I'm sure everybody has such scene
somewhere). Many objects (2000?, 3000?), constraints, shapekeys,
armatures, curves etc.
2. No matter if the layers are active or not, no matter what the draw
mode is etc - it is slow. I can place all of my obs in layer 2,
activate only empty layer 1, and it doesn't influence the speed.
3. Even if frame_set() is as fast as playback - I'm not happy. 250
frames - 1 frame per second = 250sec. = 4 minutes. Who wants to  
wait 4

minutes?

Bartek Skorupa

www.bartekskorupa.com


On 2012-01-21, at 00:58, Campbell Barton wrote:


Hi Bartek,

Would you be able to upload a test scene which is unusably slow?
can't see why this would be any slower then playing back the  
animation

(if anything should be faster since it doesn't have to draw).

On Sat, Jan 21, 2012 at 9:58 AM, Bartek Skorupa
 wrote:

Hi,

I'd like to draw your attention to frame_set(i) method.
In many scripts we have to refresh the scene several times,  
sometimes
we need to collect some data for every frame in the whole  
animation.

In such cases the only way I know in blender's python is to set the
frame using bpy.context.scene.frame_set(frame)
Almost every exporter that base on baking the data and exporting  
them

as "keyframe for every frame" use this kind of loop:

start = bpy.context.scene.frame_start
end = bpy.context.scene.frame_end
for frame in range (start, end + 1):
bpy.context.scene.frame_set(frame)
'''
 all the magic that needs data for each frame 
'''

My exporter to Adobe After Effects (io_export_after_effects.py)  
does

exactly the same.

The issue here is that setting the frame sometimes takes ages.
I was once advised to use bpy.context.frame_current = frame
Well... It's very fast, but doesn't do the trick. It sets the  
frame,
but doesn't update the scene and in most cases - this is what we  
want

- We want to have our scene refreshed for every frame.

bpy.context.scene.frame_set(frame) method is so slow, that many
exporters become almost useless or if not useless - very badly
perceived because of their performance.
The process of simple export to After Effects can sometimes take
several minutes and this is definitely not the performance we are
looking for.
I looked through many existing exporters and they all use this
method,
so I suppose I'm not the only one facing "frame_set" speed issue.
Does anyone know other method to achieve refreshing the scene for
every frame, but not that slow?

Isn't this performance a bug of some kind?

I'd appreciate any help.

Cheers,
Bartek Skorupa

www.bartekskorupa.com

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers




--
- Campbell
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers


___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers




--
- Campbell
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers


___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] bpy.context.scene.frame_set(i) issue

[Bartek Skorupa]

Tried it and it doesn't work unfortunately.
It simply doesn't update :-(
Tried with a default scene where I added keyframes for cube's location  
and printed locations for every frame. It showed exactly the same  
values throughout the animation.


Bartek Skorupa

www.bartekskorupa.com




On 2012-01-21, at 11:54, Campbell Barton wrote:

frame_set() updates all layers of the scene which I expect is the  
problem here,


there could be an optional argument to pass a layer list to
frame_set()  but this doesn't necessarily help if the current scene
layers are not setup efficiently.

looking into this you could update only the objects you want like  
this...


# objects to update
objects = bpy.context.selected_objects
scene = bpy.context.scene
start = scene.frame_start
end = scene.frame_end
for frame in range (start, end + 1):
   scene.frame_current = frame
   for obj in objects:
   obj.update_tag(refresh={'OBJECT'})  # 'DATA' too if you care
about geometry
   scene.update()
   '''
    all the magic that needs data for each frame 
   '''


On Sat, Jan 21, 2012 at 7:56 PM, Bartek Skorupa
 wrote:

1. Take any scene that plays back 1 frame per second or so. (I can't
upload any example now, but I'm sure everybody has such scene
somewhere). Many objects (2000?, 3000?), constraints, shapekeys,
armatures, curves etc.
2. No matter if the layers are active or not, no matter what the draw
mode is etc - it is slow. I can place all of my obs in layer 2,
activate only empty layer 1, and it doesn't influence the speed.
3. Even if frame_set() is as fast as playback - I'm not happy. 250
frames - 1 frame per second = 250sec. = 4 minutes. Who wants to  
wait 4

minutes?

Bartek Skorupa

www.bartekskorupa.com


On 2012-01-21, at 00:58, Campbell Barton wrote:


Hi Bartek,

Would you be able to upload a test scene which is unusably slow?
can't see why this would be any slower then playing back the  
animation

(if anything should be faster since it doesn't have to draw).

On Sat, Jan 21, 2012 at 9:58 AM, Bartek Skorupa
 wrote:

Hi,

I'd like to draw your attention to frame_set(i) method.
In many scripts we have to refresh the scene several times,  
sometimes
we need to collect some data for every frame in the whole  
animation.

In such cases the only way I know in blender's python is to set the
frame using bpy.context.scene.frame_set(frame)
Almost every exporter that base on baking the data and exporting  
them

as "keyframe for every frame" use this kind of loop:

start = bpy.context.scene.frame_start
end = bpy.context.scene.frame_end
for frame in range (start, end + 1):
bpy.context.scene.frame_set(frame)
'''
 all the magic that needs data for each frame 
'''

My exporter to Adobe After Effects (io_export_after_effects.py)  
does

exactly the same.

The issue here is that setting the frame sometimes takes ages.
I was once advised to use bpy.context.frame_current = frame
Well... It's very fast, but doesn't do the trick. It sets the  
frame,
but doesn't update the scene and in most cases - this is what we  
want

- We want to have our scene refreshed for every frame.

bpy.context.scene.frame_set(frame) method is so slow, that many
exporters become almost useless or if not useless - very badly
perceived because of their performance.
The process of simple export to After Effects can sometimes take
several minutes and this is definitely not the performance we are
looking for.
I looked through many existing exporters and they all use this
method,
so I suppose I'm not the only one facing "frame_set" speed issue.
Does anyone know other method to achieve refreshing the scene for
every frame, but not that slow?

Isn't this performance a bug of some kind?

I'd appreciate any help.

Cheers,
Bartek Skorupa

www.bartekskorupa.com

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers




--
- Campbell
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers


___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers




--
- Campbell
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers


___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Transform tool tweaks

[Yousef Hurfoush]

it wasn't me who wrote this it was (Jorge Rodriguez), please read well before 
mailing!

Regards
Yousef Harfoush


ba...@msn.com



> Date: Fri, 20 Jan 2012 22:48:12 +0100
> From: raho...@googlemail.com
> To: bf-committers@blender.org
> Subject: Re: [Bf-committers] Transform tool tweaks
> 
> 2012/1/20 Jorge Rodriguez 
> 
> > On Thu, Jan 19, 2012 at 11:33 AM, Yousef Hurfoush  wrote:
> >
> > I will be doing this. I do not wish to irritate existing users.
> >
> 
> That's good news, thank you very much !
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
  
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Transform tool tweaks

[Yousef Hurfoush]

> 
> I'm sorry. Can you explain this better? Break it down into steps for me to
> reproduce it and I'll see if I can fix it.
> 

the optimal case for it to work is:
-freeze the mouse movement
-press g (now it will lock to mouse)
-move your mouse as desired
-press g to confirm

the error can happen if do the above steps, but:
-instead of the 1st step, you'll be moving your mouse.

it will lock and confirm directly!
i think it's easy to fix, but as i said before :
the whole patch doesn't add any simplicity to using blender.

Regards
Yousef Harfoush


ba...@msn.com



  
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Transform tool tweaks

[Jorge Rodriguez]

Unless I'm misunderstanding, that behavior is intentional. The patch adds
two features, one being tap to confirm, the other being drag and drop.

Now that I think about it, I should make drag and drop an option also.

On Sat, Jan 21, 2012 at 8:29 AM, Yousef Hurfoush  wrote:

>
> >
> > I'm sorry. Can you explain this better? Break it down into steps for me
> to
> > reproduce it and I'll see if I can fix it.
> >
>
> the optimal case for it to work is:
> -freeze the mouse movement
> -press g (now it will lock to mouse)
> -move your mouse as desired
> -press g to confirm
>
> the error can happen if do the above steps, but:
> -instead of the 1st step, you'll be moving your mouse.
>
> it will lock and confirm directly!
> i think it's easy to fix, but as i said before :
> the whole patch doesn't add any simplicity to using blender.
>
> Regards
> Yousef Harfoush
>
>
> ba...@msn.com
>
>
>
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
Jorge "Vino" Rodriguez
jo...@lunarworkshop.com
twitter: VinoBS
919.757.3066
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Transform tool tweaks

[Rainer Hohne]

2012/1/21 Yousef Hurfoush 

>
> it wasn't me who wrote this it was (Jorge Rodriguez), please read well
> before mailing!
>

I am sorry Yousef, I missed deleting the header of the quote.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Transform tool tweaks - Patch available

[Jorge Rodriguez]

Martin,

The new patch is in.

http://projects.blender.org/tracker/index.php?func=detail&aid=29945&group_id=9&atid=127

I had problems updating the old so I created a new one. Sorry if that
causes any problems.

Both the tap to confirm and the drag and drop functionality are now
optional. They default to off. To turn them on you can go into the user
preferences, 3D view, and expand the Grab command, and they should be there.

Let me know if you have any trouble or feedback. I love feedback.

On Tue, Jan 17, 2012 at 7:43 PM, Jorge Rodriguez wrote:

> Thanks Martin I'd appreciate that a lot. I see you're the Transform module
> owner so it's good to know it's being looked at :)
>
> I tried to keep the workflow compatible with the current workflow. It
> should be entirely compatible with the exception of RR. If you have ideas
> of how to support both at once I would love to hear.
>
>
> On Tue, Jan 17, 2012 at 7:37 PM, Martin Poirier  wrote:
>
>> Hi Jorge,
>>
>> I'll be looking at this as soon as I have time (probably on Thursday).
>>
>> Some of the changes (confirming with release among others) are stuff that
>> I tried early on while porting transform to the 2.5 operator system and
>> should be doable with the current keymap setup. If you want a workflow that
>> isn't currently possible with the customization that exists, I generally
>> think it's better to make the system flexible enough to support both (which
>> might be what you did, haven't looked at the patch yet) and then discuss
>> what the default keymaps/options should be.
>>
>>
>> I'll get back to you once I've had a good look at your patch.
>>
>> Thanks,
>>
>>
>> Martin
>>
>>
>> >
>> > From: Jorge Rodriguez 
>> >To: bf-blender developers 
>> >Sent: Tuesday, January 17, 2012 9:25:07 PM
>> >Subject: Re: [Bf-committers] Transform tool tweaks - Patch available
>> >
>> >The patch is now available here:
>> >
>> >
>> http://projects.blender.org/tracker/index.php?func=detail&aid=29919&group_id=9&atid=127
>> >
>> >I would love it if people could try it out and inform me of any problems
>> or
>> >suggestions. I would be happy to update the patch given feedback.
>> >
>> >Following is a reprint of the patch description:
>> >
>> >This patch is against svn r43478
>> >
>> >Changes:
>> >
>> >* Pressing the grab/rotate/resize button while the tool is already active
>> >will cause the tool to confirm the current transformation. In the case of
>> >switching rotation modes, this functionality has been moved to Shift-R
>> >instead.
>> >* When using a transform tool bound to right click, right clicking will
>> >confirm instead of cancel; otherwise it will cancel like before.
>> >* Holding a transform button/key will drag the object. If the user holds
>> >for longer than 250ms or farther than 10 pixels then the action is
>> treated
>> >like a drag and when the key is released the transformation is
>> >automatically confirmed.
>> >
>> >Notes:
>> >
>> >* This patch removes some duplicate code in the modal handler for
>> transform
>> >events.
>> >* In order to support this patch some slight changes have been made in
>> the
>> >way handler operators are called. Duplicate button/key presses are now
>> >filtered by the handler and not sent to the operator, and information
>> about
>> >the handler/keymapitem which invoked the operator (if any) have been
>> added
>> >to the wmOperator structure.
>> >* The previous event state also now includes the "prevkeytime" - the time
>> >that the previous keyboard key was pressed.
>> >
>> >Justification:
>> >
>> >This patch attempts to improve the usability of the transformation tools
>> by
>> >implementing behavior which most users will expect. If a button is
>> pressed
>> >once to activate a tool, than users can expect to be able to press that
>> >same button again to deactivate the tool. If the user presses and holds
>> the
>> >button then the functionality should remain active for as long an the
>> >button is held down and then deactivate when it is released.
>> >
>> >In order to implement this behavior, the behavior when pressing the
>> >rotation button twice had to be changed. Before, the second press toggled
>> >the rotation type. This functionality has been moved to Shift-R. I
>> >recommend that the default bindings also be changed so that Shift-R
>> >activates rotation directly in trackball mode, to reduce the number of
>> key
>> >presses required to access that mode. I feel that while the different
>> >behavior may cause some friction for some current Blender users, the new
>> >features should help users, new users especially, feel more comfortable
>> >with Blender.
>> >
>> >--
>> >Jorge "Vino" Rodriguez
>> >jo...@lunarworkshop.com
>> >twitter: VinoBS
>> >919.757.3066
>> >___
>> >Bf-committers mailing list
>> >Bf-committers@blender.org
>> >http://lists.blender.org/mailman/listinfo/bf-committers
>> >
>> >
>> >
>> 

Re: [Bf-committers] blender UI state

[mindrones]

Here we go:
http://wiki.blender.org/index.php/Dev:Ref/Proposals/Usability_Project

This is the result of formalizing contents of my own mail
http://lists.blender.org/pipermail/bf-committers/2012-January/035215.html
(still have to add most of my screenshots, will do next week)

Try to do the same with your ideas instead of putting them here.
Upload images on the wiki as I did and link them in the usability page.

Please keep stuff short, to the point and schematic:
* rants are for personal pages
* long discussions are for the talk page
I'll edit discussions to shorten them, and to summarize stuff, so
don't waste time on long threads there anyway :)

After some time we can judge if problems and solutions listed there
make sense in a more general sense than just fixing an icon here and
there, and it will be a document to discuss here and in some future
sunday meeting.

Let's see what happens :)

Regards,
Luca
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] blender UI state

[Wolter van der Velde]

I think this wiki page is a great idea. But I looked trough the wiki 
today and found numerous UI proposals already there. Maybe it's a good 
idea to collect them in a single place, maybe this new wikipage.

Here are the pages i found, there may be more:
http://wiki.blender.org/index.php/Dev:Ref/Proposals/UI
http://wiki.blender.org/index.php/Dev:Ref/Requests (This page contains 
all kinds of requests not only UI. But If you look in the sidebar you 
can see a bunch of relevant subpages.)
http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo/UserInterface 
(this page has some really nice mockups.)
http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo/Simple_Todos
http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Proposals/UI (This 
page contains a broken link to a UI design document (this link 
), 
which is unfortunate because if I remember correctly it was quite an 
interesting document.)
http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Proposals/2.50_and_beyond_goals
 
(Under the "Interface" heading are a few goals regarding this topic.)
http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Proposals/RemoveFeatures
 
(This page doesn't really have new ideas but removing annoyances can 
also have a great influence on the workflow and the UI)

Cheers, Wolter

On 21-1-2012 19:47, mindrones wrote:
> Here we go:
> http://wiki.blender.org/index.php/Dev:Ref/Proposals/Usability_Project
>
> This is the result of formalizing contents of my own mail
> http://lists.blender.org/pipermail/bf-committers/2012-January/035215.html
> (still have to add most of my screenshots, will do next week)
>
> Try to do the same with your ideas instead of putting them here.
> Upload images on the wiki as I did and link them in the usability page.
>
> Please keep stuff short, to the point and schematic:
> * rants are for personal pages
> * long discussions are for the talk page
> I'll edit discussions to shorten them, and to summarize stuff, so
> don't waste time on long threads there anyway :)
>
> After some time we can judge if problems and solutions listed there
> make sense in a more general sense than just fixing an icon here and
> there, and it will be a document to discuss here and in some future
> sunday meeting.
>
> Let's see what happens :)
>
> Regards,
> Luca
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] blender UI state

[Troy Sobotka]

While it is great to be discussing Blender's UI, I would hope that it
may be acceptable to put Mr. Roosendaal's recent comment on a request
at the top of the page:

"Instead of explaining why you need it, or calling it "better" or
"more useful", just write down a neutral and very precise
specification of how it looks."

As we can see from this brief thread, words like "obvious", "good",
"better", etc. are without context and of relatively worthless value
with regards to Blender's UI discussion.

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Blender Compile Broken

[Kel M]

Hi, the blender compile has stopped working with Cmake. It starts with
r43588, I think.

[  0%] Building C object
source/blender/editors/curve/CMakeFiles/bf_editor_curve.dir/curve_ops.c.o
[  0%] Building C object
source/blender/editors/gpencil/CMakeFiles/bf_editor_gpencil.dir/drawgpencil.c.o
[  0%] Building C object
source/blender/editors/metaball/CMakeFiles/bf_editor_metaball.dir/mball_edit.c.o
[  0%] Building C object
source/blender/editors/armature/CMakeFiles/bf_editor_armature.dir/armature_ops.c.o
[  0%] [  0%] Building C object
source/blender/editors/interface/CMakeFiles/bf_editor_interface.dir/interface.c.o
[  0%] Building C object
source/blender/editors/animation/CMakeFiles/bf_editor_animation.dir/anim_channels_defines.c.o
Building C object
source/blender/editors/mesh/CMakeFiles/bf_editor_mesh.dir/editface.c.o
[  0%] Building C object
source/blender/editors/object/CMakeFiles/bf_editor_object.dir/object_add.c.o
[  0%] Building C object
source/blender/editors/curve/CMakeFiles/bf_editor_curve.dir/editcurve.c.o
/home/b99/blender-vol/blender/source/blender/editors/object/object_add.c:
In function ‘object_add_duplicate_internal’:
/home/b99/blender-vol/blender/source/blender/editors/object/object_add.c:1799:5:
error: ISO C90 forbids mixed declarations and code
[-Werror=declaration-after-statement]
cc1: some warnings being treated as errors

make[2]: ***
[source/blender/editors/object/CMakeFiles/bf_editor_object.dir/object_add.c.o]
Error 1
make[1]: ***
[source/blender/editors/object/CMakeFiles/bf_editor_object.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs
[  0%] [  0%] Building C object
source/blender/editors/armature/CMakeFiles/bf_editor_armature.dir/editarmature.c.o
Building C object
source/blender/editors/curve/CMakeFiles/bf_editor_curve.dir/editfont.c.o
[  0%] Building C object
source/blender/editors/metaball/CMakeFiles/bf_editor_metaball.dir/mball_ops.c.o
Linking C static library ../../../../lib/libbf_editor_metaball.a
[  0%] Building C object
source/blender/editors/gpencil/CMakeFiles/bf_editor_gpencil.dir/editaction_gpencil.c.o
[  0%] Built target bf_editor_metaball
[  0%] Building C object
source/blender/editors/gpencil/CMakeFiles/bf_editor_gpencil.dir/gpencil_buttons.c.o
[  0%] Building C object
source/blender/editors/mesh/CMakeFiles/bf_editor_mesh.dir/editmesh.c.o
[  0%] Building C object
source/blender/editors/gpencil/CMakeFiles/bf_editor_gpencil.dir/gpencil_edit.c.o
[  0%] Building C object
source/blender/editors/gpencil/CMakeFiles/bf_editor_gpencil.dir/gpencil_ops.c.o
[  0%] Building C object
source/blender/editors/mesh/CMakeFiles/bf_editor_mesh.dir/editmesh_add.c.o
[  0%] Building C object
source/blender/editors/animation/CMakeFiles/bf_editor_animation.dir/anim_channels_edit.c.o
[  0%] Building C object
source/blender/editors/gpencil/CMakeFiles/bf_editor_gpencil.dir/gpencil_paint.c.o
[  0%] Building C object
source/blender/editors/animation/CMakeFiles/bf_editor_animation.dir/anim_deps.c.o
[  0%] Building C object
source/blender/editors/interface/CMakeFiles/bf_editor_interface.dir/interface_anim.c.o
[  0%] Building C object
source/blender/editors/gpencil/CMakeFiles/bf_editor_gpencil.dir/gpencil_undo.c.o
[  0%] Building C object
source/blender/editors/armature/CMakeFiles/bf_editor_armature.dir/editarmature_generate.c.o
[  0%] Building C object
source/blender/editors/animation/CMakeFiles/bf_editor_animation.dir/anim_draw.c.o
[  0%] Building C object
source/blender/editors/armature/CMakeFiles/bf_editor_armature.dir/editarmature_retarget.c.o
[  0%] Building C object
source/blender/editors/mesh/CMakeFiles/bf_editor_mesh.dir/editmesh_lib.c.o
Linking C static library ../../../../lib/libbf_editor_gpencil.a
[  0%] Building C object
source/blender/editors/interface/CMakeFiles/bf_editor_interface.dir/interface_draw.c.o
[  0%] Built target bf_editor_gpencil
[  0%] Building C object
source/blender/editors/interface/CMakeFiles/bf_editor_interface.dir/interface_handlers.c.o
[  0%] Building C object
source/blender/editors/armature/CMakeFiles/bf_editor_armature.dir/editarmature_sketch.c.o
[  0%] Building C object
source/blender/editors/animation/CMakeFiles/bf_editor_animation.dir/anim_filter.c.o
[  0%] Building C object
source/blender/editors/armature/CMakeFiles/bf_editor_armature.dir/meshlaplacian.c.o
[  0%] Building C object
source/blender/editors/animation/CMakeFiles/bf_editor_animation.dir/anim_ipo_utils.c.o
[  0%] [  0%] Building C object
source/blender/editors/interface/CMakeFiles/bf_editor_interface.dir/interface_icons.c.o
Building C object
source/blender/editors/armature/CMakeFiles/bf_editor_armature.dir/poseSlide.c.o
[  0%] Building C object
source/blender/editors/animation/CMakeFiles/bf_editor_animation.dir/anim_markers.c.o
[  0%] Building C object
source/blender/editors/armature/CMakeFiles/bf_editor_armature.dir/poseUtils.c.o
[  0%] Building C object
source/blender/editors/armature/CMakeFiles/bf_editor_armature.dir/poselib.c.o
[  0%] Building C object
source/blender/editors/armature/CM

Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [43589] trunk/blender/source/blender/ editors/object/object_add.c: fix for last commit - declarations must be in the begin of the

[Campbell Barton]

We should have MSVC compiler warnings set up to disallow this as with GCC.

On Sun, Jan 22, 2012 at 11:49 AM, Dalai Felinto  wrote:
> Revision: 43589
>          
> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=43589
> Author:   dfelinto
> Date:     2012-01-22 00:49:12 + (Sun, 22 Jan 2012)
> Log Message:
> ---
> fix for last commit - declarations must be in the begin of the block (C, tsc 
> tsc)
>
> Modified Paths:
> --
>    trunk/blender/source/blender/editors/object/object_add.c
>
> Modified: trunk/blender/source/blender/editors/object/object_add.c
> ===
> --- trunk/blender/source/blender/editors/object/object_add.c    2012-01-21 
> 23:57:28 UTC (rev 43588)
> +++ trunk/blender/source/blender/editors/object/object_add.c    2012-01-22 
> 00:49:12 UTC (rev 43589)
> @@ -1790,13 +1790,13 @@
>                /* check if obdata is copied */
>                if(didit) {
>                        Key *key = ob_get_key(obn);
> +                       bActuator *act;
>
>                        if(dupflag & USER_DUP_ACT) {
>                                BKE_copy_animdata_id_action((ID *)obn->data);
>                                if(key) BKE_copy_animdata_id_action((ID*)key);
>
>                                /* Update the duplicated action in the action 
> actuators */
> -                               bActuator *act;
>                                for (act= obn->actuators.first; act; act= 
> act->next) {
>                                        if(act->type == ACT_ACTION) {
>                                                bActionActuator* actact = 
> (bActionActuator*) act->data;
>
> ___
> Bf-blender-cvs mailing list
> bf-blender-...@blender.org
> http://lists.blender.org/mailman/listinfo/bf-blender-cvs



-- 
- Campbell
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [43589] trunk/blender/source/blender/ editors/object/object_add.c: fix for last commit - declarations must be in the begin of the

[Dalai Felinto]

I actually built on OSX with cmake+make (using framework gcc I think).
So we need to expand the disallowance to osx as well I guess.

2012/1/21 Campbell Barton 

> We should have MSVC compiler warnings set up to disallow this as with GCC.
>
> On Sun, Jan 22, 2012 at 11:49 AM, Dalai Felinto 
> wrote:
> > Revision: 43589
> >
> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=43589
> > Author:   dfelinto
> > Date: 2012-01-22 00:49:12 + (Sun, 22 Jan 2012)
> > Log Message:
> > ---
> > fix for last commit - declarations must be in the begin of the block (C,
> tsc tsc)
> >
> > Modified Paths:
> > --
> >trunk/blender/source/blender/editors/object/object_add.c
> >
> > Modified: trunk/blender/source/blender/editors/object/object_add.c
> > ===
> > --- trunk/blender/source/blender/editors/object/object_add.c2012-01-21
> 23:57:28 UTC (rev 43588)
> > +++ trunk/blender/source/blender/editors/object/object_add.c2012-01-22
> 00:49:12 UTC (rev 43589)
> > @@ -1790,13 +1790,13 @@
> >/* check if obdata is copied */
> >if(didit) {
> >Key *key = ob_get_key(obn);
> > +   bActuator *act;
> >
> >if(dupflag & USER_DUP_ACT) {
> >BKE_copy_animdata_id_action((ID
> *)obn->data);
> >if(key)
> BKE_copy_animdata_id_action((ID*)key);
> >
> >/* Update the duplicated action in the
> action actuators */
> > -   bActuator *act;
> >for (act= obn->actuators.first; act; act=
> act->next) {
> >if(act->type == ACT_ACTION) {
> >bActionActuator* actact =
> (bActionActuator*) act->data;
> >
> > ___
> > Bf-blender-cvs mailing list
> > bf-blender-...@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-blender-cvs
>
>
>
> --
> - Campbell
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [43589] trunk/blender/source/blender/ editors/object/object_add.c: fix for last commit - declarations must be in the begin of the

[Jorge Rodriguez]

I'm using MSVC, CMake, VS10 generator, and I'm pretty sure I've seen errors
related to this. It may not be all versions or configurations of MSVC.

On Sat, Jan 21, 2012 at 5:29 PM, Dalai Felinto  wrote:

> I actually built on OSX with cmake+make (using framework gcc I think).
> So we need to expand the disallowance to osx as well I guess.
>
> 2012/1/21 Campbell Barton 
>
> > We should have MSVC compiler warnings set up to disallow this as with
> GCC.
> >
> > On Sun, Jan 22, 2012 at 11:49 AM, Dalai Felinto 
> > wrote:
> > > Revision: 43589
> > >
> >
> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=43589
> > > Author:   dfelinto
> > > Date: 2012-01-22 00:49:12 + (Sun, 22 Jan 2012)
> > > Log Message:
> > > ---
> > > fix for last commit - declarations must be in the begin of the block
> (C,
> > tsc tsc)
> > >
> > > Modified Paths:
> > > --
> > >trunk/blender/source/blender/editors/object/object_add.c
> > >
> > > Modified: trunk/blender/source/blender/editors/object/object_add.c
> > > ===
> > > --- trunk/blender/source/blender/editors/object/object_add.c
>  2012-01-21
> > 23:57:28 UTC (rev 43588)
> > > +++ trunk/blender/source/blender/editors/object/object_add.c
>  2012-01-22
> > 00:49:12 UTC (rev 43589)
> > > @@ -1790,13 +1790,13 @@
> > >/* check if obdata is copied */
> > >if(didit) {
> > >Key *key = ob_get_key(obn);
> > > +   bActuator *act;
> > >
> > >if(dupflag & USER_DUP_ACT) {
> > >BKE_copy_animdata_id_action((ID
> > *)obn->data);
> > >if(key)
> > BKE_copy_animdata_id_action((ID*)key);
> > >
> > >/* Update the duplicated action in the
> > action actuators */
> > > -   bActuator *act;
> > >for (act= obn->actuators.first; act;
> act=
> > act->next) {
> > >if(act->type == ACT_ACTION) {
> > >bActionActuator* actact
> =
> > (bActionActuator*) act->data;
> > >
> > > ___
> > > Bf-blender-cvs mailing list
> > > bf-blender-...@blender.org
> > > http://lists.blender.org/mailman/listinfo/bf-blender-cvs
> >
> >
> >
> > --
> > - Campbell
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
Jorge "Vino" Rodriguez
jo...@lunarworkshop.com
twitter: VinoBS
919.757.3066
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [43589] trunk/blender/source/blender/ editors/object/object_add.c: fix for last commit - declarations must be in the begin of the

[Campbell Barton]

odd, this shouldn't be allowed, see CMakeLists.txt:1424

if(CMAKE_COMPILER_IS_GNUCC)
# --- snip
ADD_CHECK_C_COMPILER_FLAG(C_WARNINGS
C_WARN_ERROR_DECLARATION_AFTER_STATEMENT
-Werror=declaration-after-statement)

Unless the gcc version doesn't support this argument.

On Sun, Jan 22, 2012 at 12:29 PM, Dalai Felinto  wrote:
> I actually built on OSX with cmake+make (using framework gcc I think).
> So we need to expand the disallowance to osx as well I guess.
>
> 2012/1/21 Campbell Barton 
>
>> We should have MSVC compiler warnings set up to disallow this as with GCC.
>>
>> On Sun, Jan 22, 2012 at 11:49 AM, Dalai Felinto 
>> wrote:
>> > Revision: 43589
>> >
>> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=43589
>> > Author:   dfelinto
>> > Date:     2012-01-22 00:49:12 + (Sun, 22 Jan 2012)
>> > Log Message:
>> > ---
>> > fix for last commit - declarations must be in the begin of the block (C,
>> tsc tsc)
>> >
>> > Modified Paths:
>> > --
>> >    trunk/blender/source/blender/editors/object/object_add.c
>> >
>> > Modified: trunk/blender/source/blender/editors/object/object_add.c
>> > ===
>> > --- trunk/blender/source/blender/editors/object/object_add.c    2012-01-21
>> 23:57:28 UTC (rev 43588)
>> > +++ trunk/blender/source/blender/editors/object/object_add.c    2012-01-22
>> 00:49:12 UTC (rev 43589)
>> > @@ -1790,13 +1790,13 @@
>> >                /* check if obdata is copied */
>> >                if(didit) {
>> >                        Key *key = ob_get_key(obn);
>> > +                       bActuator *act;
>> >
>> >                        if(dupflag & USER_DUP_ACT) {
>> >                                BKE_copy_animdata_id_action((ID
>> *)obn->data);
>> >                                if(key)
>> BKE_copy_animdata_id_action((ID*)key);
>> >
>> >                                /* Update the duplicated action in the
>> action actuators */
>> > -                               bActuator *act;
>> >                                for (act= obn->actuators.first; act; act=
>> act->next) {
>> >                                        if(act->type == ACT_ACTION) {
>> >                                                bActionActuator* actact =
>> (bActionActuator*) act->data;
>> >
>> > ___
>> > Bf-blender-cvs mailing list
>> > bf-blender-...@blender.org
>> > http://lists.blender.org/mailman/listinfo/bf-blender-cvs
>>
>>
>>
>> --
>> - Campbell
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers



-- 
- Campbell
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers