Re: [Bf-committers] Quit and unsaved changes ...

[CoDEmanX]

Hey Gaia,

thank you for your improvement work, the quit prompt really deserves 
some lovin' :)

I propose the following prompt:

-
Unsaved changes:

C:\the\path\to\file.blend

[Overwrite] [Save as...] [Discard & Quit] [Abort]
-

Overwrite should be the default button. It saves to the .blend as shown 
in the msgbox (thus overwriting what is currently on your persistent 
storage).

Save as... would be a handy addition to allow for quick save to new 
.blend (dunno how to integrate this well, I worry it would need to open 
the OS save-as modal dialog).

Discard & Quit looks verbose but it makes clear, that you will lose 
unsaved changes and Blender quit immediately after a click.

Abort simply cancels the dialog and no action is taken.


I believe it's possible to create msgboxes with arbitrary buttons with 
Windows API, it's more complicated than the msgboxes with a default set 
of buttons. Not sure about other OS?

Greetings,
Cody


Am 17.01.2014 15:06, schrieb Gaia:
> Hi;
>
> Yesterday i was asking in irc about the Quit confirm box.
> After talking with jensverwiebe i was able to make a small
> change that now only shows a quit confirm popup if:
>
> 1.) The current session has unsaved changes.
> 2.) The "use quit prompt" user preference is enabled
>
> This works like a charm (imo). But now the text in the confirm
> box could be changed from
>
> "Quit Blender"
>
> to (for example):
>
> "Unsaved Changes. Quit anyways ?"
>
> What do you think ?
>
> cheers,
> Gaia
> ___
> 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] E key eyedropper tool... add icon?

[CoDEmanX]

The E shortcut works also for objects,
an icon to make it more discoverable and clickable is planned:

https://developer.blender.org/T37521


Am 09.02.2014 06:49, schrieb Garrett Williams:
> With the new ability to press the E key over an object picker(parenting,
> for example), it seems an eyedropper icon would be useful so the feature is
> discoverable. We already have one for the color picker when you click it,
> so I propose the eyedropper icon be added to the drop-down menu that lists
> objects for the object picker, possibly at the bottom-right(separates it
> from the actual list), to associate it with picking an object and to show
> it only when somebody intends to choose an object.
> In addition, a tooltip with the keyboard shortcut for both eyedropper
> icons(color picker, object picker) would add discoverability for the
> shortcut.
>
> I'm new to coding, so I certainly don't know what to change and am hoping
> this is the right list for the suggestion. I do know that Campbell Barton
> added the e-key shortcut in revision 60610, though I don't know if that
> involved the object pickers.
>
> ~Garrett Williams
> ___
> 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] Saving and retreiving custom object properties

[CoDEmanX]

Hey Patrick,

there are different kinds of properties, see:

http://wiki.blender.org/index.php/Doc:2.6/Manual/Extensions/Python/Properties#Summary

There are only ID-Properties internally, but ID-Props and static props 
are separated from python perspective.

What you seem to use are ID-Properties, which are a set per datablock.
Get and set them like:

someObject['prop']
someObject['prop'] = 123

In contrast, static properties (bpy.types.*.prop = bpy.props.*) are 
accessed like:

someObject.prop
someObject.prop = 123

Don't mix it up, like:

someObject['prop'] = "foobar"
print(someObject.prop)

or you will get errors like:

# ['prop']
KeyError: 'bpy_struct[key]: key "prop" not found'

# .prop
AttributeError: 'Object' object has no attribute 'prop'

Due to how properties are handled internally, both "prop" properties 
will conflict. You should avoid name duplicates. You can easily run into 
funny behavior it seems - edit a static prop in Custom Properties panel 
via Edit popup, and set value to a number or list - static prop will be 
cleared and no ID property exists either!.

Submitted a bug report:
https://developer.blender.org/T38778


Am 23.02.2014 04:58, schrieb patrick boelens:
> Hi everyone,
>
> I've been asked to revisit an old addon I did and make it up-to-date, and in 
> doing so I noticed something. While object properties are saved with the 
> .blend, they are only accessable through a key, and no longer as a property 
> of that object. Is this intended behaviour? If so, is there a reason for 
> this? It seems a bit counter-intuitive imho. Here's an example of what I mean:
>
> - Open Blender
> - Enable addon
> - Perform an addon function and set "someObject.prop = 5"
> - Request "someObject.prop"
> - Returns 5
> - Save .blend and close Blender
> - Reopen, re-enable addon and request "someObject.prop"
> - Returns property not found error
> - Request "someObject['prop']"
> - Returns 5
>
> Cheers,
> Patrick
>   
> ___
> 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] numpy for 2.70

[CoDEmanX]

They charge for MKL, so the free version should definately not use / 
require it.

Direct download links for Anaconda Windows builds:

http://repo.continuum.io/archive/.winzip/

I checked the content in 7zip and it seems to contain py2.7 builds only?
Or is it compatible with py3.3?



Am 24.02.2014 18:43, schrieb dba...@citytech.cuny.edu:
> could we use one of the builds of numpy from anaconda
> https://store.continuum.io/cshop/anaconda/ I believe their free version (
> the one you get by default if you install it using conda)  isn't built
> against MKL.
>
>
> On Mon, Feb 24, 2014 at 9:48 AM, Martijn Berger 
> wrote:
>
>> I have tried compiling numpy but it seems you need either gcc/gfortran when
>> building for mingw or intel's compiler when building for msvc build python.
>> There is a version available online that works at:
>> http://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy.
>> But there is also a problem. This version is build against the Intel's MKL
>> (http://software.intel.com/en-us/intel-mkl) a non free but very high
>> performance math library.
>> For me the easiest solution would by bundling this version but we it seems
>> we can not as that would constitute a GPL violation.
>>
>> It seems we have 3 options.
>>- we don't bundle numpy on windows
>>- we bundle this numpy and we might violate the GPL
>>- we get a copy of Intel's Fortran compiler so we can build and maintain
>> a version of numpy for use with blender that does not violate the GPL.
>>
>> I am not a layer and not a numpy specialist, any conclusions drawn above
>> are the result of my best understanding of our situation
>>
>>
>> On Mon, Feb 24, 2014 at 1:16 AM, Campbell Barton >> wrote:
>>
>>> A while ago it was agreed that blender would bundle numpy, with very
>>> positive response from some script authors and general agreement,
>>>
>>> See meeting minutes:
>>> http://lists.blender.org/pipermail/bf-committers/2013-April/039809.html
>>>
>>> Previous discussions on the topic:
>>>
>> http://lists.blender.org/pipermail/bf-committers/2012-November/038215.html
>>> http://lists.blender.org/pipermail/bf-committers/2012-April/036428.html
>>>
>>>
>>> We setup scons and cmake to bundle numpy with Python, and now the 2.70
>>> Linux build bundles numpy 1.80, but (unless I'm mistaken). OSX and
>>> ms-windows still don't include numpy.
>>>
>>> If there are no blocking issues - (we can't get numpy to compile for
>> eg...)
>>> I think its a reasonable target to have numpy bundled on all platforms
>>> for 2.70, not just for Linux.
>>>
>>> Added tracker tickets for this so this isn't overlooked.
>>> https://developer.blender.org/T38791
>>> https://developer.blender.org/T38792
>>>
>>> Maintaining platform deps is often done by volunteers, so if you don't
>>> have time for it, say so and someone else can try to fill in the gaps.
>>>
>>> --
>>> - 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
>>
> ___
> 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] File Upload on GraphicAll failed!

[CoDEmanX]

It often fails to complete the upload, it may depend on the browser you 
use (it used to work for IE, and fail a lot with Chrome/Firefox).

It should work with Firefox, as long as it's a new build, or if you 
update an existing one, either change the info OR the build. When I 
changed the info and uploaded a new build in one step, it failed. But it 
worked doing it in two steps, not sure if it reported an error, but it 
definately worked.


Am 03.03.2014 20:02, schrieb Fabio Russo:
> Hello everybody,
>
> I can't upload the file on GraphicAll, because it appears the following
> message: Build update failed due to a server error!
> How could I solve this problem?
>
> Thank you in advance for your kind help.
> Fabio (ruesp83)
> ___
> 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] Download stats for blender.org

[CoDEmanX]

And still 9,200/day if we dropped linux and osx support :P


Am 27.08.2014 19:19, schrieb Ton Roosendaal:
> Hi,
>
> Analytics was hooked up with the downloader on blender.org, there are over 
> 10k downloads per day via our site!
> Full month of july stat:
>
> http://download.blender.org/institute/2014-july-downloads.pdf
>
> Logging started in May only. More stats later in the year.
>
> -Ton-
>
> 
> Ton Roosendaal  -  t...@blender.org   -   www.blender.org
> Chairman Blender Foundation - Producer Blender Institute
> Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands
>
>
>
> ___
> 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 developer meeting notes - 31 August, 2014

[CoDEmanX]

There should really be a pre-flight check, to prompt the user what to do 
BEFORE even preparing rendering. It would catch unavailable drivers, 
missing textures, non-writable target devices etc.


Am 31.08.2014 19:29, schrieb Daniel Salazar - patazstudio.com:
> About the Reload Trusted issue, don't forget background mode too which is
> even more "invisible". You launch render and never notice anything wrong
> until you see the frames
>
> Daniel Salazar
> patazstudio.com
>
>
> On Sun, Aug 31, 2014 at 9:32 AM, Ton Roosendaal  wrote:
>
>> Hi all,
>>
>> Here are today's minutes from the weekly meeting in irc.freenode.net
>> #blendercoders.
>>
>> 1) Upcoming 2.72 release
>>
>> - The wiki page with our planning: (no changes, in 2 weeks a first release
>> build should be there)
>>http://wiki.blender.org/index.php/Dev:Doc/Projects
>>
>> - Meeting discussed the too many open issues in tracker.
>>
>> - Joshua Leung has quite some animation issues (NLA, constraints) on his
>> desk. Most fixes require big changes, and should not be done now - but more
>> early in a release cycle. He can start work on it late October earliest due
>> to other obligations.
>>
>> - Martijn Berger: for 2.72 there are a bunch of windows platform bugs that
>> need to be resolved. Andrea Weikert offers assistance.
>>
>> - Jonathan Williamnson points at this UI issue that should be revised -
>> for append/linking of data.
>> https://developer.blender.org/T41593
>> A quick fix would be to bring the "Link" checkbox back again, a more
>> proper fix involves a bit of UI thinking. It was already discussed with
>> Campbell, but preferably should be tackled for the release.
>>
>> 2) Other projects
>>
>> - Blender Institute (as part of Gooseberry project) agreed on assigning
>> Antonis Ryakiotaks to (nearly) half time on helping Jason Wilkins with the
>> Viewport branch. First goal should be clearly mapping out where we are,
>> what deliverables and benefits are, and then agree on a planning for it.
>>
>> - Lukas Toenne still works on hairsim, first results are on Gooseberry
>> blog:
>>   http://gooseberry.blender.org/weekly-august-29-2014/ <- check video for
>> hairsim
>>
>> - Bastien Montagne has "Custom Split Normals" branch ready for review,
>> Campbell will check.
>>
>> - New Blender development fund grant: for Nicholas Bishop - to work 6
>> weeks on sculpt related features.
>>The Mesh modeling / sculpting module team will check with him on the
>> work target(s).
>>
>> - Lukas Treyer has a new DXF importer ready, is in master now.
>>
>> http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.72/Addons#DXF_Import_Addon
>>
>> - Thomas Dinges likes to get feedback on splitting the caustics option:
>>https://developer.blender.org/D766
>>
>> 3) UI stuff
>>
>> - Jopnathan made a proposal for a planning and roadmap:
>> http://wiki.blender.org/index.php/Dev:Doc/Projects/UI#Projects
>>
>> - Pablo Vazquez: We need to redesign the whole "Reload Trusted" workflow,
>> at the moment it goes unnoticed even for power users (and devs!). Proposal
>> is to make it more prominent (animation, colors?) and add an option to
>> remember this setting (AKA turn on "Auto Run Python Scripts" and save user
>> preferences).
>>
>>
>> -Ton-
>>
>> 
>> Ton Roosendaal  -  t...@blender.org   -   www.blender.org
>> Chairman Blender Foundation - Producer Blender Institute
>> Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands
>>
>>
>>
>> ___
>> 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
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Temporary "global" storage

[CoDEmanX]

How about using RNA with SKIP_SAVE flag?

bpy.types.World.temp_var = StringProperty(description="Label of the 
control", options={'SKIP_SAVE'})

Or in C:

prop = RNA_def_int(ot->srna, "prop_name", 1, 1, INT_MAX, "Prop Name", 
"", 1, 10);

RNA_def_property_flag(prop, PROP_SKIP_SAVE);


Am 21.06.2012 09:52, schrieb Jorge Rodriguez:
> I need a place where I can put a UI-related temporary variable for storing
> things such as what was the last button pressed and when did the last
> tooltip close. It must be in some scope that's visible to and accessible by
> all controls. I can't put it in RNA because those things are stored to the
> hard drive, and these things are runtime-related and shouldn't be stored. I
> don't want to make a global variable because that's obviously sloppy. There
> doesn't seem to be any UI-related area to place stuff that should be
> visible to all controls but not stored on the hard drive. If I can solve
> this problem then I should be able to immediately remove two things from my
> list.
>

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

Re: [Bf-committers] Color to greyscale conversion - confusion

[CoDEmanX]

I use a rgb to luminance conversion in my Blender-CoD like:

c_lum = c[0] * 0.3 + c[1] * 0.59 + c[2] * 0.11

but correct seems to be:

Y = 0.2126 R + 0.7152 G + 0.0722 B

http://en.wikipedia.org/wiki/Luminance_(relative)

Am 22.06.2012 20:19, schrieb Dalai Felinto:
>> The second looks like an sRGB luminance model transformation.
> while the first one is a linear space transformation? wondering.
>
> But yeah even gimp you tell you that you can go from RGB to BW in different
> ways.
>
> --
> Dalai
> ___
> 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] The Future of Blender Projects WAS meeting notes

[CoDEmanX]

1.) I'd like to see some improvements for 2.5D creation. Ideally, 
Blender would work similar to Adobe AfterEffects.

Composing movie clips and FX should become very intuitive, especially by 
a new properties editor, which would support group manipulation (values 
adjustable simultaneously).

It should support easy Fade in / out for clips etc., to be the better 
alternative to Windows Movie Maker Live (it would be portable!!!)


2.) There could be some sort of class, which IO addons would derive to 
store per-addon settings permanently. In User prefs > Addons, each addon 
would get its own "Settings" button to open a preferences dialog. Users 
would set default paths and stuff here.


3.) IO addons should be able to register their supported import file 
extensions. Dragging & dropping and OBJ onto Blender for instance, would 
import the dropped OBJ (either directly or showing a popup with import 
settings first).


4.) TODOS, like image file drag'n'drop to material image and multiple 
objects (un)parenting in outliner :)


5.) Image editor with repeat setting on should not cap the maximum tiles 
drawn, but rather fill the entire screen (either faster code, or 
progressive drawing...)

6.) +1 for investigations on a merged view of all 2D screens (uv, image, 
movie, mask...)
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Syntax error in export_3ds.py

[CoDEmanX]

Commited fix:

http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-extensions&revision=3595

Should now work as expected.

Thanks for reporting!


Am 08.07.2012 06:08, schrieb IRIE Shinsuke:
> Hi,
>
> When I was byte-compiling release/scripts/addons/ (r3577), I got a
> syntax error in io_scene_3ds/export_3ds.py as follows:
>
>File "/usr/share/blender/2.63/scripts/addons/io_scene_3ds/export_3ds.py", 
> line 227
>  """
> class _3ds_point_4d(object):
>  """Class representing a four-dimensional point for a 3ds file, for 
> instance a quaternion."""
>
>
>  ^
> SyntaxError: invalid syntax
>
>
> The triple-quotes """...""" are enclosed by the same style of
> triple-quotes:
>
> """
> class _3ds_point_4d(object):
>  """Class representing a four-dimensional point for a 3ds file, for 
> instance a quaternion."""
>  __slots__ = ...
>
> """
>
> so the inside of the inner ones is not a string literal.
> Please use the different style of triple-quotes like below:
>
> '''
> class _3ds_point_4d(object):
>  """Class representing a four-dimensional point for a 3ds file, for 
> instance a quaternion."""
>  __slots__ = ...
>
> '''
>
> Anyway, I think triple-quotes shouldn't be used to comment out
> multiple lines.
>

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

Re: [Bf-committers] *** GMX Spamverdacht *** Re: Syntax error in export_3ds.py

[CoDEmanX]

My bad! Turned it back into utf8, hope it's ok now.

http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-extensions&revision=3602


Am 08.07.2012 15:55, schrieb IRIE Shinsuke:
> Hi CoDEmanX,
>
> r3595 causes another error:
>
> Traceback (most recent call last):
> File "/usr/lib/python3.2/runpy.py", line 160, in _run_module_as_main
>   "__main__", fname, loader, pkg_name)
> File "/usr/lib/python3.2/runpy.py", line 73, in _run_code
>   exec(code, run_globals)
> File "/usr/lib/python3.2/py_compile.py", line 187, in 
>   sys.exit(main())
> File "/usr/lib/python3.2/py_compile.py", line 169, in main
>   compile(filename, doraise=True)
> File "/usr/lib/python3.2/py_compile.py", line 116, in compile
>   codestring = f.read()
> File "/usr/lib/python3.2/codecs.py", line 300, in decode
>   (result, consumed) = self._buffer_decode(data, self.errors, final)
> UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe4 in position 905: 
> invalid continuation byte
>
>
> export_3ds.py was accidentally saved with non UTF-8 character encoding.
>
> 12/07/08, CoDEmanX wrote:
>> Commited fix:
>>
>> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-extensions&revision=3595
>>
>> Should now work as expected.
>>
>> Thanks for reporting!
>>
>>
>> Am 08.07.2012 06:08, schrieb IRIE Shinsuke:
>>> Hi,
>>>
>>> When I was byte-compiling release/scripts/addons/ (r3577), I got a
>>> syntax error in io_scene_3ds/export_3ds.py as follows:
>>>
>>> File 
>>> "/usr/share/blender/2.63/scripts/addons/io_scene_3ds/export_3ds.py", line 
>>> 227
>>>   """
>>> class _3ds_point_4d(object):
>>>   """Class representing a four-dimensional point for a 3ds file, for 
>>> instance a quaternion."""
>>>
>>>
>>>   ^
>>> SyntaxError: invalid syntax
>>>
>>>
>>> The triple-quotes """...""" are enclosed by the same style of
>>> triple-quotes:
>>>
>>> """
>>> class _3ds_point_4d(object):
>>>   """Class representing a four-dimensional point for a 3ds file, for 
>>> instance a quaternion."""
>>>   __slots__ = ...
>>>
>>> """
>>>
>>> so the inside of the inner ones is not a string literal.
>>> Please use the different style of triple-quotes like below:
>>>
>>> '''
>>> class _3ds_point_4d(object):
>>>   """Class representing a four-dimensional point for a 3ds file, for 
>>> instance a quaternion."""
>>>   __slots__ = ...
>>>
>>> '''
>>>
>>> Anyway, I think triple-quotes shouldn't be used to comment out
>>> multiple lines.
>>>
>>
>
>

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

Re: [Bf-committers] Why is use fake user not default for actions?

[CoDEmanX]

I agree.

However, this can be fixed with a simple addon, core code:


from bpy.app.handlers import persistent

# Auto-enable fake user to rescue unused actions
@persistent
def fakeuser_for_actions(scene):
 for action in bpy.data.actions:
 action.use_fake_user = True


This addon needs to be enabled by default to ensure it always sets the 
fake user!

Am 09.09.2012 02:41, schrieb Alberto Torres:
> The idea of users make sense with datablocks that are *used*. Most of
> them are always used. Actions aren't (unless you *always* use the
> NLA). It is usual that you just have a library of animation cycles
> ready to use or for a game. IMHO that's the reason actions should go
> back to fakeuser-by-default.
>
> DiThi
>
>
> 2012/9/8 patrick boelens :
>>
>> I think this was initially done so as to stay consistent in handling fake 
>> users; it now acts the same as for materials, textures, etc. However, I've 
>> also seen this being discussed before, and I think the consensus then was to 
>> roll-back to the old "fake-by-default", though I could be wrong here. Either 
>> way, I agree the old system might be best for this. User experience/ 
>> frustration > consistency imo. =
>>
>> -Patrick
>>
>>> Date: Sat, 8 Sep 2012 12:50:29 -0700
>>> From: dfeli...@gmail.com
>>> To: bf-committers@blender.org
>>> Subject: Re: [Bf-committers] Why is use fake user not default for actions?
>>>
>>> I know blender tries to stay popup-free, but a warning when
>>> selecting/creating actions may solve that
>>>
>>> ("No datablock linked to action 'Run'. if you don't set FakeUser the action
>>> will be deleted")
>>>
>>> We got more than one "bug" report for that as well, so it may be fair to
>>> consider the current design not clear for (new) users.
>>>
>>> Dalai
>>> On Sep 8, 2012 12:41 AM, "Mitchell Stokes"  wrote:
>>>
 Hello devs,

 It used to be that use_fake_user was default for action datablocks.
 Sometime in the last version or two, this stopped being the case. Now
 we get forums posts on people losing their animations[0][1]. Lost data
 is never a good thing, so what was the reason for it being off by
 default?

 Cheers,
 Mitchell Stokes

 [0] http://blenderartists.org/forum/showthread.php?265132-Lost-Animations
 [1]
 http://blenderartists.org/forum/showthread.php?258161-Problems-with-actions
 ___
 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
>>
>> ___
>> 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
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Gesture Recognition

[CoDEmanX]

just in case you guys don't know it already:

A basic gesture recognition for translate/scale/rotate has been done for 
Blender 2.5x as py addon:

http://blog.inhumanvision.com/2011/09/26/enabling-mouse-gestures-in-blender-2-5/


Am 16.10.2012 22:37, schrieb Carsten Wartmann:
>
>
>
>
> Jason Wilkins  schrieb:
>
>> My Google Fu has failed me though and there does not seem to have been
>> much work on this yet.  Am I missing something?
>
> Only that we had already gestures in blender since like ever until 2.5x ;-)
>
> There were only three for GSR so a more generic approach would be needed.  I 
> did used at least 2 of the three gestures regularly.
>
> Carsten
>
>> ___
>> 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] Unregistering UI panel

[CoDEmanX]

It shouldn't add the same panel multiple times, unless you change 
bl_idname or the unregister_class call is bad. Any errors in console?

For manual removal, you can do in pyconsole:
bpy.utils.unregister_class(bpy.types.SCENE_PT_layers) # replace 
SCENE_PT_layers with bl_idname!

Am 25.10.2012 21:48, schrieb Tobias Oelgarte:
> Hello,
>
> i started to write an addon and it needs a lot of testing. But every
> time I'm running my script it adds an additional panel to the UI.
> Unregistering the panel seams only to work if i let my script to be
> loaded as an addon. But how can i remove my added panel(s) if I'm
> running this script for the second time or from another script? Using
> bpy.utils.unregister_class(ClassName) seams not to work in this case,
> because it is treaded as something different.
>
> Greetings from
> Tobias Oelgarte
> ___
> 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] Triangulate modifier

[CoDEmanX]

We already have tesselation (tris+quad), and you can turn the quads into 
triangles by taking vert 0,1,2 and 2,3,0. That will give you a 
triangulation like seen in Blender viewport. So why not use tessfaces? 
I'd like to have a viewport option to show triangulation edges, but I 
can't see the reason for triangulation modifier.

btw. I wrote a little script to make tessellation visible why creating a 
new mesh from tessfaces:
http://blenderartists.org/forum/showthread.php?255806-Release-Tessfaces-to-new-mesh-(makes-tessellation-visible)

Am 10.11.2012 15:10, schrieb Morten Mikkelsen:
>>
>>> When baking with an all quad mesh, the triangulation that is done
>>> internally in Morten's TS might not match the manual triangulation that
>>> the user applies on export, which potentially could cause issues because
>>
>
> This is not exactly the issue. Let me clarify.
> The mikktspace part is done at quad level if there are quads and will
> always give the same
> tangent spaces at vertex level no matter what the order of vertices or
> faces is.
> This is its very strong advantage which other tangent space calculators
> can't do.
>
> After mikktspace has already run the problem occurs at a later stage
> because before rendering/baking triangulation has to have been performed.
> So the issue is eventhough the tangent spaces at the vertices aren't
> impacted by how quads are triangulated (since triangulation happens later)
> the interpolated tangent space is heavily impacted by which diagonal is
> picked. Similar to how Gouraud shading is heavily impacted by which
> diagonal is picked. So eventhough tangent space is consistent at the
> vertices you get problems if baker and render don't pick the same
> triangulation
> due to differences in the interpolated tangent space.
>
> I should mention I am using "render triangulation" loosely here since it
> can happen in a lot of places though for a game it would typically happen
> somewhere in the engine's tools pipeline. Anyway the advantage to this
> modifier is it enforces a consistent triangulation which will be received
> by both baker and renderer (incl. Blender's renderer). Further, this is
> achieved without causing permanent triangulation.
> It's a sensible practice which is already used by artists in other modeling
> products.
>
> Morten M.
> ___
> 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] Triangulate modifier

[CoDEmanX]

Sounds to me like there is an inconsistency somewhere in Blender, which 
causes the difference in mesh geometry between what baker uses and the 
stored/exported data... Shouldn't everything in Blender use tessfaces, 
if triangles are required?

"When baking with an all quad mesh, the triangulation that is done
internally in Morten's TS might not match the manual triangulation that
the user applies on export [...]" - Morten Mikkelsen

There shouldn't be "manual triangulation", as export scripts can use 
tessfaces to get triangulated geometry. Maybe here's the inconsistency? 
The "Triangulate Faces" operator (former Quads to Tris) might create 
triangles different from the tessfaces. I wonder how Morten's TS does 
triangulation, hm, maybe I missed your point! (sorry if so)


Am 10.11.2012 19:32, schrieb Antony Riakiotakis:
> Exactly, the point is not display, but data availability for baking. A
> {0,1,2} {2,1,3} scheme is also being considered for the modifier.
> ___
> 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] Triangulate modifier

[CoDEmanX]

Alright, maybe what i had on mind isn't possible in your case.

As Blender has a tessface cache, I thought it should be used throughout 
the application for everything that requires tessellated mesh geometry. 
Polygon and tessface data can be accessed at the same time, so this is 
basically non-destructive as well. What is missing IMO is a checkbox to 
toggle display of tessfaces (we already see tesselated faces, but they 
aren't outlined etc.)

A modifier might offer an extra ability of editing the triangulated mesh 
non-destructively, not sure if possible, but if so, it would be great to 
be able to adjust triangulation in certain spaces (tessfaces don't make 
up "nice" triangles)


Am 14.11.2012 00:25, schrieb metalliandy:
> The point of the modifier is not how it is triangulated, it is that the
> triangulation is non destructive and can be visibly toggled on and off
> by the user at will and without the need for undo steps :)
>
> Also that quote you was from me, not Morten and I was 100% accurate.
>
> Morten replied and said in his reply to me
>
>> This is not exactly the issue. Let me clarify.
>> The mikktspace part is done at quad level if there are quads and will
>> always give the same
>> tangent spaces at vertex level no matter what the order of vertices or
>> faces is.
>> This is its very strong advantage which other tangent space calculators
>> can't do.
>>
>> After mikktspace has already run the problem occurs at a later stage
>> because before rendering/baking triangulation has to have been performed.
>> So the issue is eventhough the tangent spaces at the vertices aren't
>> impacted by how quads are triangulated (since triangulation happens later)
>> the interpolated tangent space is heavily impacted by which diagonal is
>> picked. Similar to how Gouraud shading is heavily impacted by which
>> diagonal is picked. So eventhough tangent space is consistent at the
>> vertices you get problems if baker and render don't pick the same
>> triangulation
>> due to differences in the interpolated tangent space.
>>
>> I should mention I am using "render triangulation" loosely here since it
>> can happen in a lot of places though for a game it would typically happen
>> somewhere in the engine's tools pipeline. Anyway the advantage to this
>> modifier is it enforces a consistent triangulation which will be received
>> by both baker and renderer (incl. Blender's renderer). Further, this is
>> achieved without causing permanent triangulation.
>> It's a sensible practice which is already used by artists in other modeling
>> products.
>>
>> Morten M.
>
> I hope that clears everything up :)
>
> -Andy
>
> On 13/11/2012 23:12, CoDEmanX wrote:
>> Sounds to me like there is an inconsistency somewhere in Blender, which
>> causes the difference in mesh geometry between what baker uses and the
>> stored/exported data... Shouldn't everything in Blender use tessfaces,
>> if triangles are required?
>>
>> "When baking with an all quad mesh, the triangulation that is done
>> internally in Morten's TS might not match the manual triangulation that
>> the user applies on export [...]" - Morten Mikkelsen
>>
>> There shouldn't be "manual triangulation", as export scripts can use
>> tessfaces to get triangulated geometry. Maybe here's the inconsistency?
>> The "Triangulate Faces" operator (former Quads to Tris) might create
>> triangles different from the tessfaces. I wonder how Morten's TS does
>> triangulation, hm, maybe I missed your point! (sorry if so)
>>
>>
>> Am 10.11.2012 19:32, schrieb Antony Riakiotakis:
>>> Exactly, the point is not display, but data availability for baking. A
>>> {0,1,2} {2,1,3} scheme is also being considered for the modifier.
>>> ___
>>> 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
>>
>
> ___
> 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] Triangulate modifier

[CoDEmanX]

OBJ exporter offers a "Triangulate Faces" option. If enabled, it won't 
export quads, but take the tessfaces and turn quads into tris by using 
vert 0,1,2 for one tris, and 2,3,0 for another. This way, you get what 
you see in viewport, non-destructive and without extra calculations.

Search for "f_v_iter":
https://svn.blender.org/svnroot/bf-extensions/trunk/py/scripts/addons/io_scene_obj/export_obj.py

Am 14.11.2012 21:31, schrieb Morten Mikkelsen:
> The important thing is that any proposed solution will work with export too.
> If the obj exporter is still exporting quads and beyond then this is not a
> solution.
> The modifier solution will make sure the exporter when exporting the dm
> exports the same
> triangulation. If what you are proposing does that then it's probably fine.
>
>
>
>
> On Tue, Nov 13, 2012 at 4:07 PM, Brecht Van Lommel <
> brechtvanlom...@pandora.be> wrote:
>
>> Tessfaces contain both quads and triangles. The render engine can
>> store quads natively (uses less memory) and has its own splitting
>> algorithm which is different than what OpenGL does. Perhaps it would
>> not be a bad thing to add an option to Mesh datablocks to disable that
>> smart render engine splitting and have it the same as the viewport,
>> and enable it by default even.
>>
>> I don't know how important the smarter splitting it is in practice, in
>> Cycles I intentionally did not add it because it can pop in animation
>> and be inconsistent with the viewport, did not see complaints about it
>> so far.
>>
>> Brecht.
>>
>> On Wed, Nov 14, 2012 at 1:00 AM, CoDEmanX  wrote:
>>> Alright, maybe what i had on mind isn't possible in your case.
>>>
>>> As Blender has a tessface cache, I thought it should be used throughout
>>> the application for everything that requires tessellated mesh geometry.
>>> Polygon and tessface data can be accessed at the same time, so this is
>>> basically non-destructive as well. What is missing IMO is a checkbox to
>>> toggle display of tessfaces (we already see tesselated faces, but they
>>> aren't outlined etc.)
>>>
>>> A modifier might offer an extra ability of editing the triangulated mesh
>>> non-destructively, not sure if possible, but if so, it would be great to
>>> be able to adjust triangulation in certain spaces (tessfaces don't make
>>> up "nice" triangles)
>>>
>>>
>>> Am 14.11.2012 00:25, schrieb metalliandy:
>>>> The point of the modifier is not how it is triangulated, it is that the
>>>> triangulation is non destructive and can be visibly toggled on and off
>>>> by the user at will and without the need for undo steps :)
>>>>
>>>> Also that quote you was from me, not Morten and I was 100% accurate.
>>>>
>>>> Morten replied and said in his reply to me
>>>>
>>>>> This is not exactly the issue. Let me clarify.
>>>>> The mikktspace part is done at quad level if there are quads and will
>>>>> always give the same
>>>>> tangent spaces at vertex level no matter what the order of vertices or
>>>>> faces is.
>>>>> This is its very strong advantage which other tangent space calculators
>>>>> can't do.
>>>>>
>>>>> After mikktspace has already run the problem occurs at a later stage
>>>>> because before rendering/baking triangulation has to have been
>> performed.
>>>>> So the issue is eventhough the tangent spaces at the vertices aren't
>>>>> impacted by how quads are triangulated (since triangulation happens
>> later)
>>>>> the interpolated tangent space is heavily impacted by which diagonal is
>>>>> picked. Similar to how Gouraud shading is heavily impacted by which
>>>>> diagonal is picked. So eventhough tangent space is consistent at the
>>>>> vertices you get problems if baker and render don't pick the same
>>>>> triangulation
>>>>> due to differences in the interpolated tangent space.
>>>>>
>>>>> I should mention I am using "render triangulation" loosely here since
>> it
>>>>> can happen in a lot of places though for a game it would typically
>> happen
>>>>> somewhere in the engine's tools pipeline. Anyway the advantage to this
>>>>> modifier is it enforces a consistent triangulation which will be
>> received
>>>>> by both baker and render

Re: [Bf-committers] ascii art

[CoDEmanX]

Forget cycles, render ascii! xD

http://nopaste.php-quake.net/406431
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] ascii art

[CoDEmanX]

I did that by hand ;)
Also tried image to text converters, but with awful results. The major 
problem is, that a converter can't find the important contours. At least 
me doesn't know how to get an outline from 3d render like on right-hand 
side:
http://www.pasteall.org/pic/40459


Am 15.11.2012 13:55, schrieb Abhinav Yadav:
> thats cool , is it a script or a complete add-on.
>
>
> On Thu, Nov 15, 2012 at 4:57 PM, CoDEmanX  wrote:
>
>> Forget cycles, render ascii! xD
>>
>> http://nopaste.php-quake.net/406431
>> ___
>> 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
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Cursor to center of mass

[CoDEmanX]

It's pretty easy to handle:

http://www.pasteall.org/37405/python


Am 21.11.2012 04:55, schrieb Brecht Van Lommel:
> Tessfaces includes both triangles and quads, it doesn't triangulate
> entirely, so you'd need to handle the quads still.
>
> Brecht.
>
> On Wed, Nov 21, 2012 at 4:30 AM, Ummi Nom  wrote:
>> Hi!
>>
>> I've written some center of mass calculations in python for closed meshes,
>> but there is an issue with using tessfaces in my code; I run mesh.update
>> with tessfaces=True but when I loop over mesh.tessfaces there are only 6
>> faces in default scene cube so the center of mass is offset.
>>
>> It seems to work when the mesh is triangulated
>> http://www.pasteall.org/37396/python
>>
>> # Code
>> import mathutils
>> from mathutils import *
>> import bpy
>>
>> tess_count = 0
>>
>> # Handle tri as a tetrahedron with fourth point at origo
>> def handleTri(v1, v2, v3):
>>  global tess_count
>>  tess_count = tess_count + 1
>>
>>  temp = (v3-v1).cross(v2-v1)
>>  nor = temp.normalized()
>>  area = 0.5*temp.dot(nor)
>>  vol = area*nor.dot(v1)/3.0
>>  centroid = (v1+v2+v3)/4.0
>>
>>  return (centroid, vol)
>>
>>
>> for me in bpy.data.meshes:
>>  me.update(calc_tessface=True)
>>
>>  sumc= Vector()
>>  summ = 0
>>
>>
>>  for f in me.tessfaces:
>>  v1 = Vector(me.vertices[f.vertices[0]].co)
>>  v2 = Vector(me.vertices[f.vertices[1]].co)
>>  v3 = Vector(me.vertices[f.vertices[2]].co)
>>
>>  centroid, mass = handleTri(v1, v2, v3)
>>  sumc += centroid * mass
>>  summ += mass
>>
>>  print(tess_count)
>>
>>  print(sumc/summ)
>> ___
>> 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
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Search Field for browsing Shapekeys

[CoDEmanX]

The popup closes too easily indeed (if you click on search list entry 
outside of the popup's rectangle), but one can add an empty column, 
scale it's height and add a separator to match the search list size to 
workaround this problem:

http://i.imagebanana.com/img/nexx4hvt/prop_search_shapekeys.png

I know this is against Blender's design concept, but what about adding 
another popup type, which requires to click either on Abort or OK, and 
doesn't close on other user input? For certain situations this would be 
quite useful.


Am 24.11.2012 06:43, schrieb Juan Pablo Bouza:
>
> Thanks Campbell!! :D
>
> I'll check it out later today!
>
>
>> Date: Sat, 24 Nov 2012 16:40:24 +1100
>> From: ideasma...@gmail.com
>> To: bf-committers@blender.org
>> Subject: Re: [Bf-committers] Search Field for browsing Shapekeys
>>
>> committed r52529. though there was a conflict with having this
>> popup-within-a-popup, so I had to stop using the redo popup for this
>> operator.
>>
>> On Sat, Nov 24, 2012 at 4:46 AM, Bassam Kurdali  wrote:
>>> +1 yeah, that's a great idea for any list type menu that can grow to
>>> large numbers.
>>> On Fri, 2012-11-23 at 13:28 -0300, Juan Pablo Bouza wrote:

 A year ago or so I asked Campbell to add a search field for adding scene 
 clips in the VSE, cause I was working with lots of scenes in the same 
 blend file, and the rectangle list that appeared when I wanted to browse a 
 scene exceeded the dimensions of my screen.

 Well, now I'm having the same problem with shapekeys... I'm currently 
 using a workflow for facial rigging where I need 50 or more shapekeys. 
 When I need to call the "blend from shape" operator, a huge rectangle 
 appears listing all of the shapes. These is really not practical, and it 
 is a huge problem if you don't have the necessary screen resolution.

 So, It would be great if a search field could be added for browsing the 
 shapekeys in the "blend from shape" menu, just like there is now for clip 
 browsing in the VSE.

 See you!

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

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

Re: [Bf-committers] Blender 2.65 RC2 AHOY

[CoDEmanX]

Could anyone (=ZanQdo?) write some lines about the film response addon? 
It's new and official, already mentioned in the release notes for 2.65 
but wiki has just a single sentence:

http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Render/Film_Response


Am 06.12.2012 17:52, schrieb Sergey Sharybin:
> Thomas just told me in IRC: OSL should be updated once again.
>
>
> On Thu, Dec 6, 2012 at 10:44 PM, Sergey Sharybin wrote:
>
>> Hello everyone,
>>
>> It's the high time for second release candidate, which i  hope is the last
>> for 2.65 series.
>>
>> Build still happens from trunk svn using this revisions:
>>
>> - Main tree revision: 52796
>> - Addons: 4029
>> - Contrib addons: leave as-is, they wouldn't be included to final release
>> anyway
>> - Translations: 1262
>>
>> Usual naming is blender-2.65-RC2-
>>
>> Place builds to usual place and let me know when they're ready.
>>
>> That's it for now, thanks all!
>>
>> --
>> With best regards, Sergey Sharybin
>>
>>
>
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] handling large lists in Blender (vertex groups, shape keys, materials)

[CoDEmanX]

3 variations of possible filter integration:

http://www.pasteall.org/pic/show.php?id=41437



Am 06.12.2012 18:44, schrieb Gaia:
> I played with my 2d image editor and created this mockup:
>
>   http://www.pasteall.org/pic/show.php?id=41429
>
> I added a drag handle to the lower right corner of the list.
> What do you think? Would that be convenient, acceptable
> and easy to implement ?
>
> cheers,
> Gaia
>
>
> On 06.12.2012 17:43, Bassam Kurdali wrote:
>>
>> I was myself wishing for filtering in vertex groups recently. +1 from
>> this user. Also agree the resize is a bit hidden.
>> On Thu Dec  6 2012 11:01:59 AM EST, Gaia > > wrote:
>>
>>> On 06.12.2012 16:52, Tobias Oelgarte wrote:
 We have resizeable list areas. Hold Shift and and use the
>> mousewheel to
 resize them. It's not always as responsible as it should be. I often
 need to move the mouse around a bit while rolling the mousewheel, so
 that it will continue to grow or shrink.
>>>
>>> Heh, that is cool :) Very good to know that!
>>> However wouldn't it be more intuitive to add a drag handle
>>> to the lower left corner of the list ?
>>> That might also solve the responsiveness issue in an elegant way.
>>> ___
>>> 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
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] handling large lists in Blender (vertex groups, shape keys, materials)

[CoDEmanX]

I really like them!
But dunno if it's a good idea to put the stuff inside of the list 
(visually yes, but how to implement this properly?)

Here are two variants which could be done with little change to UI code:

http://www.pasteall.org/pic/show.php?id=41471
http://www.pasteall.org/pic/show.php?id=41472

Basically, all what's needed is C code for list filtering. In python, 
there should eventually be an extra parameter for lists to specify a 
StringProp, which would be the prop of the search field.

bpy.types.Scene.search_shapekeys = bpy.props.StringProperty()
...
row.template_list(key, "key_blocks", ob, "active_shape_key_index", 
rows=rows, filter_data=scene, filter_prop="search_shapekeys")


Am 07.12.2012 01:39, schrieb Gaia:
> Having the filter in a popup box might have the advantage
> of saving some space on the screen. But on the other side
> your top variant shows the filter settings together with the
> resulting list. So i like the top variant most.
>
> Here is another comparison based on your top variant
> which saves one line of space:
>
> http://www.pasteall.org/pic/show.php?id=41449
>
> It would be awesome if someone from the blender
> development team could comment on this and allow
> to get something done here. Maybe the layout is wrong
> but at least it would be just cool if we could get the
> functionality.
>
> Gaia
>
>
>
> On 06.12.2012 22:25, CoDEmanX wrote:
>> 3 variations of possible filter integration:
>>
>> http://www.pasteall.org/pic/show.php?id=41437
>>
>>
>>
>> Am 06.12.2012 18:44, schrieb Gaia:
>>> I played with my 2d image editor and created this mockup:
>>>
>>> http://www.pasteall.org/pic/show.php?id=41429
>>>
>>> I added a drag handle to the lower right corner of the list.
>>> What do you think? Would that be convenient, acceptable
>>> and easy to implement ?
>>>
>>> cheers,
>>> Gaia
>>>
>>>
>>> On 06.12.2012 17:43, Bassam Kurdali wrote:
>>>> I was myself wishing for filtering in vertex groups recently. +1 from
>>>> this user. Also agree the resize is a bit hidden.
>>>> On Thu Dec  6 2012 11:01:59 AM EST, Gaia >>> <mailto:gaia.cl...@machinimatrix.org>> wrote:
>>>>
>>>>> On 06.12.2012 16:52, Tobias Oelgarte wrote:
>>>>>> We have resizeable list areas. Hold Shift and and use the
>>>> mousewheel to
>>>>>> resize them. It's not always as responsible as it should be. I often
>>>>>> need to move the mouse around a bit while rolling the mousewheel, so
>>>>>> that it will continue to grow or shrink.
>>>>> Heh, that is cool :) Very good to know that!
>>>>> However wouldn't it be more intuitive to add a drag handle
>>>>> to the lower left corner of the list ?
>>>>> That might also solve the responsiveness issue in an elegant way.
>>>>> ___
>>>>> Bf-committers mailing list
>>>>> Bf-committers@blender.org <mailto: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
>>>
>> ___
>> 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
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Bachelor-thesis

[CoDEmanX]

Hi Paal,

have a look at the projects of this year's Google Summer of Code, 
(external) programmers contributed great stuff to Blender:

http://wiki.blender.org/index.php/Dev:Ref/GoogleSummerOfCode/2012/Overview

You could do something similar, but a lot of other things need to be 
done as well, here's the official TODO-list:

http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo

Personally, I'd like to get a new navigation operator, similar to the 
Fly mode. But it should allow navigation similar to a firstperson 
shooter: WASD to move (forward, backwards, strafe left/right), mouse to 
look around. Q and E to move up and down on Z axis. Ideally, user would 
be able to set up their custom key configs, as everyone has a different 
taste when it comes to key maps ;)

But that's just me, we can discuss this further however if you are 
interested.

Greetings,
Cody

Am 18.12.2012 18:32, schrieb Pål Mathias Ellefsen:
> Hi blender developers
>
> My name is Paal and I am currently looking for a bachelor-thesis for my
> Computer Engineering degree. I thought I could use this opportunity to use
> my thesis to contribute to the blender development community.But this
> is my first time with open source development and I do not know how I can
> contribute to this community. I have about 300 work hours to contribute to
> the project and I would very like to receive any suggestions on which field
> I can contribute into:
>
> Languages I have worked with :
>   Visual Basic .NET, C++, C#, Java, HTML, JavaScript, CSS, XML,HLSL, GLSL,
> Oracle SQL, PostgreSQL, MS SQL, Windows Batch, PHP, Objective-C
>
> Frameworks, SDKs and etc.: .
> NET, .NET Compact, XNA, Android SDK, OpenGL, ASP.NET, WiX, Jquery, Windows
> Mobile SDK, Google Web Toolkit, Java RMI, .NETInstaller, 3DS Max, Java
> Server Pages, Razor,DirectX, Smarty, Ajax, Linux Shell (Bash), Windows
> Batch, Windows OS, Linux Ubuntu OS, XCode, Git,SVN
>
> Looking forward for your replies.
>
> Regards Paal
> ___
> 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] Simplified Header Stats (with icons)

[CoDEmanX]

Am 23.12.2012 19:30, schrieb Tobias Oelgarte:

> I see this number every time in the
> splash screen, but more importantly i usually need to know the revision
> number instead of the version number.

I bet most people don't care at all, some do care the version number as 
they wanna follow a tutorial with the same blender version, but only a 
few need the revision number and you can find it in the splash screen. 
I'd keep it like it is.

> If we want to be consistent, following your guideline, then we should
> remove this icon as well. I know it is the famous blender icon... :P

No, it performs an action -> opens the splash screen. Seems consistent 
to me. And the icon makes the following version number understandable!

> Considering the overall design, i have to say that anything goes, as
> long it does not stand out or conflicts heavily with the rest of an
> interface. I for my part would really like to get rid of this hard to
> read text line and would not consider stats as buttons as long they have
> no button-border or react to the mouse while hovering over them.

I like Gaia's Stats Flyout proposal, as the stats info header becomes 
interactive (action on click). Doesn't have to be a flyout, I think i'd 
rather make it call a yet-to-code stats addon which would show a popup 
with detailed stats incl. icons

The stats header could stay text-only, but with spaces instead of | and 
everybody should be happy ;)

Or make "showText" and "showIcon" user pref options (as proposed by 
Harley), would give full freedom.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] import_obj.py - Reimplementation

[CoDEmanX]

OBJ import can take quite some time and use a lot memory, but only if 
you use splitting ("keep vert order" imports way faster). Is there 
something else causing the bad performance?

Multiprocessing would be great, for splitting it might work. But 
probably not for any code that calls bpy api functions...

C/C++ importer: This year's GSoC project "FBX importer" wasn't actually 
about FBX, but assimp integration (= C/C++ importers for FBX, OBJ etc.). 
There are builds available at graphicall.org. However, I'd keep the 
python addons in trunk.

Python + Lib: Why improve performance of a python script if a C/C++ 
importer is available (assimp) and faster than the script will ever be? 
In addition, I/O scripts should be kept simple IMO, so that scripters 
can learn from them for their own addons.

If there are any simple python hacks to improve performance, they should 
be applied of course.


Am 03.01.2013 03:16, schrieb Isaac Lenton:
> Hi
>
> A few days ago I was using Blender's import_obj.py script to import a few
> rather bulky OBJ files into blender (200MB and above).  On my little system
> it takes about 2 minutes for every file.  I have been looking into improving
> this script with simple optimisation, splitting the work amongst multiple
> workers and changing the amount of memory the script uses.  Some of these
> methods are successful, but the results are only minor.  I did manage to
> reduce the loading time of the 200MB file to 1 minute 40 seconds.
>
> Although a quicker method for importing my data into Blender would be to
> use another format, I quite like the OBJ format and I am "in the mood" for
> optimising.
>
> In order to significantly improve the speed of Blender's OBJ importer I can
> see a couple of options:
>
>  - Implement the importer straight in C/C++ and build into Blender.
>  I think this option is probably undesirable considering it takes
>  away one of the really nice things about Blender's add-ons (the
>  add-on part!).
>
>  - Keep the implementation in pure python.
>  Also, in my opinion, undesirable.  The Python is great, but it can
>  slither only so fast.  (Also, what are your opinions on using 
> Python's
>  multiprocessing module in import scripts?)
>
>  - Keep the python script but implement the most expensive methods in
>  a C dynamic library.  This option will keep the interface to the
>  exporter exactly the same, the module will still be able to be
>  imported using pythons `import` and Blender will not even notice
>  the difference.  The library would be placed in the same directory
>  as the script (scripts/addons/io_scene_obj) and the script would
>  simply add the line `from . import TheNewLibrary` at the start.
>  Downside: using plain C and python can be painful (but fun).
>
>  - Keep the python script but implement the most expensive methods in
>  a boost::python C++ dynamic library.  Same as above.
>  Downside: Boost::Python libraries have a big overhead.
>
> I find for my own code, when size is not important, I prefer the last option.
>
> I am interested to hear any opinions on the above ideas, and any ideas anyone
> may have on generally improving the speed of Blender's importers.  Are any
> of these options Blender compatible (as in, could they be included in the
> official release)?
>
> Thanks,
> Isaac Lenton
> (ilent2)
> ___
> 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] Simplified Header Stats (with icons)

[CoDEmanX]

It shouldn't be a panel that generates stats on every redraw.

Campbell:

"Counting geometry on every redraw (from python), is just too slow and
will interfere with workflow on higher poly models.

Would suggest to have a tool that is more comprehensive and runs from
a menu/button rather then on every redraw.

This tool could show a popup reporting on the current mesh with
surface area, sorted by material - number of ngons, number of concave
ngons... number of manifold edges, free-standing verts, zero area
faces ... whatever.

Alternately - we could add tri/quad/ngons functionality into blender,
though the header is already quite crammed - just saying it could be
done in a way which isnt't performing slow."


Stats should be generated in a "lazy" manner, not sure how though. A 
button for a stats popup seems like a good option. But could also be a 
panel with a "Refresh" button...



Am 04.01.2013 13:36, schrieb Ton Roosendaal:
> Hi,
>
> Thanks, that's looking ok to me :)
>
> To the people who really like to improve our statistics; a very acceptable 
> way for Blender is to make a special statistics panel - either for the 
> Property sidebar in views (so it can do local stats), or for the property 
> editor itself. It can provide far more information than we do now, with 
> collapsable hierarchy even.
>
> Google a bit around to see how other programs do this too.
>
> -Ton-
>
> 
> Ton Roosendaal  Blender Foundation   t...@blender.orgwww.blender.org
> Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands
>
> On 4 Jan, 2013, at 1:37, Harley Acheson wrote:
>
>> Hello,
>>
>> Since the idea of having icons at that location won't fly, I decided to
>> make a new patch that simply modifies the existing statistics string to
>> incorporate the many lessons learned in this exercise, but without using
>> icons.
>>
>> My goal was to make it simpler, more readable, add new features, but still
>> keep the length within what we see now. The vertical bars are removed. I
>> find that those compete with the information there and can quickly look
>> like a number one.  Using whitespace to separate the areas does not have
>> the same effect.  I also added a space after each colon because that helps
>> the readability. It shows memory usage at all times, not just in object
>> mode like now.
>>
>> Currently, while in Object mode the statistics are for the entire scene. So
>> you know how many faces there are in total, but not how many are in each
>> object. You can only get those by entering Edit mode.  With this change you
>> can see how many vertices/faces/tris comprise each object without entering
>> edit mode.
>>
>> If the selected count is zero or equal to the total count then only the
>> total is shown.  So you don't see "0/213456" or "213456/213456".  Face and
>> triangle counts are shown when editing text objects, and you generally see
>> the proper information in each mode. the count of of hidden objects is now
>> shown.
>>
>> In order for this to all fit within the same space I combined the object
>> count into one area with active object name.  It also shows only total
>> memory used (instead of current total minus memory mapped and then memory
>> mapped in brackets). Memory doesn't have a "Mem:" label since it is fairly
>> obvious what it is with "MB" behind the number.
>>
>> The following image compares the current behavior against what you see with
>> the patch. Obviously I am hoping that you find the bottom of each pair more
>> readable than each top one:
>>
>> http://projects.blender.org/tracker/download.php/9/127/33573/23396/StatisticsStringOnly.png
>>
>>
>> The patch is here if you want to try it:
>> http://projects.blender.org/tracker/download.php/9/127/33573/23397/StatisticsString.diff
>>
>>
>> Cheers, Harley
>> ___
>> 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
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Interested in GSoC 2013 for Blender Organisation

[CoDEmanX]

Am 25.01.2013 14:00, schrieb Xavier Thomas:
> -Third, look for small bug or simple feature in the area you are interested
> in.
> http://projects.blender.org/

Especially the Simple Todos on Todo list are a good point to start:

http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo/Simple_Todos

Drag'n'Drop for image textures is probably something many users wait for.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Feature request - "Copy Render Layer"

[CoDEmanX]

maybe it can be implemented as RenderLayer.copy(scene=context.scene), so 
it could be used with python and UI.


Am 01.02.2013 23:31, schrieb Juan Pablo Bouza:
>
> Hi!!
>
> Moreover, I think that there should be an option to copy a render layer from 
> one scene to another one
>
> In many cases you need to do exact copies of render layers throughout many 
> scenes. Currently the only way to do this is to create an empty scene with 
> the render layer settinga, and then you have to start appending the objects 
> from the animation scene.
>
>
>
>> From: bartekskor...@bartekskorupa.com
>> Date: Fri, 1 Feb 2013 23:15:23 +0100
>> To: bf-committers@blender.org
>> Subject: [Bf-committers] Feature request - "Copy Render Layer"
>>
>> I am missing a little feature that shouldn't be very hard to implement, 
>> especially that I was able to create a simple add on that does exactly what 
>> I am looking for.
>> When creating render layers we have the option to add new render layer, 
>> remove render layer, but what is missing is the ability to make the exact 
>> copy of existing render layer.
>> It would help in many cases, like when you want to add new render layer 
>> where you'd like to change just one setting comparing to the render layer 
>> that already exists.
>>
>> As I mentioned at the beginning I created a simple add on that does it. It 
>> adds a button in the render layers panel. The button executes the operator 
>> that creates exact copy of selected render layer.
>> I could simply ask for including this add on to blender, but I think such 
>> feature shouldn't be implemented via add-on, but on a "higher level". What 
>> do you think?
>>
>> Here's the code:
>> http://www.pasteall.org/39349
>>
>>
>> http://cg.bartekskorupa.com/copy-render-layer/
>>
>>
>> Cheers
>>
>> Bartek Skorupa
>>
>> www.bartekskorupa.com
>>
>> ___
>> 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
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Weight paint: display unreferenced verts in black instead of blue ?

[CoDEmanX]

I agree as well, especially when it comes to game engine export, it 
would be great to have that visual feedback. Several engine formats 
don't allow verts without weight / with no vgroup and I've seen exporter 
addons complain about such verts. A visual feedback would help users to 
find these easily.


Am 14.02.2013 10:03, schrieb Damir Prebeg:
> I agree with Gaia, Blender lacks in visual feedback in some areas, this is
> one of them.
>
> On 14 February 2013 09:59, Gaia  wrote:
>
>> Hi, Campbell;
>>
>> So i have to ask back: Where would it be bad to get a visual
>> information about unreferenced vs. referenced verts  using
>> the black/blue color code ?
>>
>> There are situations where knowing if a vertex is referenced
>> (even with zero weight) becomes relevant. It can even be
>> wanted that verts are members of a vertex group but weighted
>> to zero (or almost zero). And in such a case cleaning up low/zero
>> weighted vertices with blender cleanup tool might be not practical.
>> And seeing them all in blue doesn't help either.
>>
>> One case where it is mandatory to have each vertex be placed in
>> at least one vertex group is when it comes to create items for
>> game engines outside of Blender. Yes, we already have added a
>> lot of helper tools to our own addons for finding unreferenced
>> verts, visualising them, forbid to export partially unweighted
>> meshes, etc.
>>
>> However getting this little extra visual control would help as well.
>>
>> cheers,
>> Gaia
>>
>> On 14.02.2013 03:04, Campbell Barton wrote:
>>> On Thu, Feb 14, 2013 at 12:32 PM, Gaia 
>> wrote:
 Hi;

 This is about weight painting in blender compared to
 weight painting in Maya:

 In Maya:

 Maya displays locations in black if the corresponding verts
 are NOT member of the active vertex group. All  other parts
 are displayed as usual (blue to red)

 Maya also supplies a delete from group brush which allows
 to remove verts from the current vertex group.

 Both features are very intuitive and easy to use as far as i
 can tell after playing a bit with it.

 

 In blender:

 Vertices which are not in the active vgroup and zero weighted
 vertices are both displayed in blue. The only method (that i know)
 to find out which verts are members of the current
 vertex group is:

 - go to edit mode
 - unselect all verts
 - select all verts from the current vertex groups.

 If you want to know which verts are weighted to 0:

 - go to weight paint mode
 - enable vertex select mask

 Now you can see all verts in the groups displayed as yellow
 dots. If you want to remove verts from the group:

 - go back to edit mode
 - select the verts you want to remove
 - remove from current group

 

 What do you think about adding such a feature to Blender as well ?

 cheers,
 Gaia
>>> What is the reason you are concerned with which vertex is in a group or
>> not?
>>>
>>> The typical work-flow for blender treats zero weighted verts the same
>>> as verts which aren't in the group.
>>> You can do your weight painting, then run 'Clean' tool to remove zero
>>> weight verts (to be a little more efficient).
>>> ___
>>> 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
>>
> ___
> 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] 'help'

[CoDEmanX]

It's 3 clicks from wiki start page to svn page:

http://wiki.blender.org/index.php/Dev:Doc/Tools/SVN_checkout_and_usage


Am 23.02.2013 20:57, schrieb Erwin:
> At a first glance that wiki page has no information about the subversion 
> repository. It usually takes me a while of searching too.
>
> So what is the svn url?
>
> Sent from my iPhone
>
> On Feb 23, 2013, at 11:28 AM, Tom M  wrote:
>
>> Follow the directions here
>>
>> http://wiki.blender.org/index.php/Dev:Doc/Building_Blender
>>
>> Which will direct you to the method for downloading the source code from SVN.
>>
>> Good luck,
>>
>> LetterRip
>> ___
>> 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
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] proposal for better integration of addon functionality

[CoDEmanX]

1.) you can set the plugin-icon for any custom menu entry, see python 
template "Addon Add Object". This isn't used by most addons though, and 
I actually like it - the plugin icon (as well as the old 2.49 snake 
icon) kind of annoy me in menus - most menus don't have any icons, and 
the ones with plugin-icon would get the most (visual) attention; menus 
like Add > Mesh do have icons, but the plugin-icon doesn't mean anything 
here, the icon should indicate what shape to expect.

2.) I like the idea, but the menu entry should read as "Online Manual 
(addon)" or something like that. There should be an indicator if that 
entry was created by an addon, and it should be possible to jump to the 
addon docs - bl_info['wiki_url'] - but not sure if it's a good idea to 
replace the online manual target, maybe rather add an additional entry 
like "Addon Manual".

3.) Well, how? Using an index number won't work, if another addon 
already added something, maybe even in different (non-subsequent) 
places, your entries will end up somewhere - but not where you wanted 
them. And new built-in menu entries may be added, and they also may 
change. So a "before/after menu entry of name x" wouldn't work either. 
Nonetheless, I'd like to have an operator / low-level API for 
re-ordering panels - currently it's like with menus, either prepend or 
append...


Am 26.02.2013 10:41, schrieb Gaia:
> Hi;
>
> Currently you can not tell if a button or a panel has been added by an
> addon.
> We also can not always add additional functionality to meaningful locations.
>
> A hypothetical example:
> =
>
> Lets say my addon has added a new transform function in Object mode:
>
>  "Transform Origin to Active"
>
> The natural location for that new option would be (marked with "[A]"):
>
> Object -> Transform -> ...
>
>  Origin to Geometry
> Origin to 3D Cursor
>  [A] Origin to Active
>
>  Randomize Transform
>  ...
>
> But an addon can not add new menu entries "inbetween" existing entries.
> We only can add a menu entry to the top or the bottom of a menu.
> And we can not tell if a function has been added by an Addon or if it is
> a Blender default.
>
> A possible solution:
> =
>
> 1.) mark menu buttons as addon using a color code and/or an icon,
> similar to how blender 2.49 marked python scripts.
> 2.) Optional: allow to click on the marker icon and get beamed to the
> online documentation of that function (currently available under RMB ->
> Online manual)
> 3.) Allow to add menu buttons at any functional reasonable location
> within a menu.
>
> ___
> 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] proposal for better integration of addon functionality

[CoDEmanX]

The addon's name could be added to the tooltip, but screencasts wouldn't 
benefit then... for video tutorials it would make sense to indicate 
whether users need an addon or if need just the built-in functions.

append_after(bpy.ops.*) looks ok, but shouldn't it rather be 
append_after("mesh.foobar") ?

And what to call the other function? prepend_before (I dislike)?

One problem is still not covered: what if someone uses an addon with 
older blender, addon works but the given op / op name of a built-in 
function doesn't exist in that version?


Am 26.02.2013 14:04, schrieb Gaia:
> Basically to help users to understand what comes from Blender
> and what has been added from outside. Especially the first part
> of my proposal about getting the ability to add menu entries
> "inbetween" the standard entries might make it convenient to
> know that "this" is from blender, and "that" is from an addon.
>
> Well it may be useful to distinguish between system addons
> which are distributed along with blender (and can be considered
> as part of blender), and the rest of the world.
>
> And ok, so lets make it a system option "mark addon elements" in
> user preferences. then a screencaster can enable that to give visual
> hints to the users. and users can decide to not care and disable the
> visual mark...
>
> On 26.02.2013 13:36, Bart Crouch wrote:
>> On Tue, Feb 26, 2013 at 10:41 AM, Gaia  wrote:
>>
>>> Currently you can not tell if a button or a panel has been added by an
>>> addon.
>>>
>> Could you perhaps explain why it would be desired to make a visual
>> distinction between add-ons and built-in functionality?
>> >From a user-perspective I don't think it is very interesting to know
>> whether a tool was written in Python or in C. And from a
>> developers-perspective, I like the integration I can get when writing an
>> add-on.
>> ___
>> 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
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Suggestion: Drop zip archives (Windows releases)

[CoDEmanX]

+1 for keeping zip AND 7z!

I often need a portable blender and therefore download an archive, not 
exe. 7z is about the size of the exe, while zip is quite larger and 
internet connection isn't always fast...


Am 09.03.2013 21:23, schrieb Bastien Montagne:
> Not a Windows user, but I seriously wonder what people who are not able
> to open a .7z could do with Blender? 3D programs are among the most
> complex pieces of software, so if they can’t even manage to find how to
> extract some .7z...
>
> Bastien
>
> On 09/03/2013 21:05, Harley Acheson wrote:
>> Mikhail,
>>
>>> Anyway pool on blenderartists should show actual users preferences.
>> A pool on BlenderArtists could show that a majority of windows users can
>> open 7z, but it will remain that *ALL* of them can open zip.
>>
>> Harley
>> ___
>> 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
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Node Efficiency Tools - can it go to trunk?

[CoDEmanX]

Proper formatting:

props = layout.operator(NodesLinkActiveToSelected.bl_idname, 
text="Replace Links")

props.prop1 = True
props.prop2 = True
props.prop3 = False

But please don't do this if the amount of props varies (prop1-propN)! 
Use a CollectionProperty instead. I think i did this in the Game 
Property Visulizer addon to replace the evil eval().


Am 25.03.2013 16:08, schrieb Bartek Skorupa (priv):
> Thank you for the explanation.
>> props = layout.operator(NodesLinkActiveToSelected.bl_idname, text="Replace 
>> Links").prop1 = True
>>  props.prop2 = True
>>  props.prop3 = False
> Oops… I didn't know you can do it :-) Really…
>
> Every day I learn something.
> I will change all those properties accordingly.
>
> Thank you once again
>
> Regards
>
> Bartek Skorupa
>
> www.bartekskorupa.com
>
> On 25 mar 2013, at 16:02, Bastien Montagne  wrote:
>
>> Hi,
>>
>> On 25/03/2013 15:51, Bartek Skorupa (priv) wrote:
>>> Thank you for this quick review.
>>> Yes you're right about my understanding of bl_label. I did mismatch this 
>>> and I can change it, np.
>>>
>>> About my 'option' properties:
>>> In many cases I can change it to enums, but sometimes StringProperty is 
>>> used because I need to pass more than one property in one go.
>>> Say I need to set 3 properties:
>>> prop1 = True
>>> prop2 = True
>>> prop3 = False
>>>
>>> I wrap it in one StringProperty that gets the value of 'True True False' 
>>> and then in execute I use string split( ), and eval to get 3 booleans.
>>>
>>> Please take a look at line 1325 for example:
>>> layout.operator(NodesLinkActiveToSelected.bl_idname, text="Replace 
>>> Links").option = 'True True False'
>>>
>>> option then is passed to execute of NodesLinkActiveToSelected and split.
>>> see lines: 795 to 798:
>>>  option_split = self.option.split( )
>>>  replace = eval(option_split[0])
>>>  use_node_name = eval(option_split[1])
>>>  use_outputs_names = eval(option_split[2])
>>>
>>> This way I get 3 variables out of one property 'option'
>>>
>>> Is there a better way of doing it?
>> Yes there is! :)
>>
>> In such case, you should do that:
>>
>>  props = layout.operator(NodesLinkActiveToSelected.bl_idname, 
>> text="Replace Links").prop1 = True
>>  props.prop2 = True
>>  props.prop3 = False
>>
>>> Another question:
>>> Could you please explain me why using StringProperty instead of proper 
>>> EnumProperty is wrong?
>>> Is it a convention, speed issues or anything else?
>> First of all, it is a convention. True/false options should be booleans,
>> options with a well defined set of choices should be enums, etc.
>>
>> This also helps on documentation level (as each enum items has its own
>> label/description, you do not need comments in code, and doc can be
>> retrieved easily by multiple ways).
>>
>> And there is also an UI interest, as using enums you can get a nice
>> drop-down list as a control, or you can even auto-generate a menu where
>> each entry will execute the operator with one of the options of the enum, …
>>
>> By the way, note that if you have a set of related booleans options that
>> are not mutually exclusive, you can use an enum with 'ENUM_FLAG' option
>> (in that case you are just limited to at most 32 different flags - the
>> length of a classical integer ;) ).
>>
>> Kind regards,
>> Bastien
>>
>>> Thank you in advance
>>>
>>> Regards
>>>
>>> Bartek Skorupa
>>>
>>> www.bartekskorupa.com
>>>
>>> On 25 mar 2013, at 15:24, Bastien Montagne  wrote:
>>>
 Hi Bartek,

 Just did a (very quick) skim review of your addon, and I agree that
 there are valuable features in it, worth moving it to trunk. However, I
 noted at least two points that imho should be addressed before the move:

 First, you seems to mismatch labels and tips of operators! E.g. instead
 of this line:

  bl_label = "Copy Settings of Active Node to Selected Nodes"

 I would rather see those:

  bl_label = "Copy Node Settings"
  bl_description = "Copy the settings of the active node to selected
 ones"

 The second point is, I think, more important. You should replace your
 “multipurpose” "option" StringProperty by relevant properties. E.g.

  # option: 'from active', 'from node', 'from socket'
  option = StringProperty()

 Should be replaced by:

  source = EnumProperty(name="Source", description="A relevant
 description…", default='FROM_ACTIVE',
items=(('FROM_ACTIVE', "From Active", "A
 relevant description…", 'ICON_NONE', 1),
   ('FROM_NODE', "From Node", "A relevant
 description…", 'ICON_NONE', 2),
   ('FROM_SOCKET', "From Socket", "A
 relevant description…", 'ICON_NONE', 3),
  )
   )

 (with relevant changes in other parts of the code).

Re: [Bf-committers] Node Efficiency Tools - can it go to trunk?

[CoDEmanX]

if the number of properties you pass to an operator differ, e.g. one 
prop per Custom Property of the active object, then you shouldn't do 
something like

prop1 = ...
prop2 = ...
...
prop20 = ...

to allow for up to 20 properties be passed to the operator. Why? Cause 
you don't need 20 properties if you mostly need to pass just one or two, 
and there may be situations in which you need more than 20. So a fixed 
amount is really bad.

Instead, you can use a CollectionProperty and add an item for every 
element you need to pass.

Here's an example:

http://www.pasteall.org/40829/python


If ideasman is fine with your code, then it's ok to move to trunk!


Am 25.03.2013 17:33, schrieb Bartek Skorupa (priv):
> Hey,
> @CoDEmanX:
> I don't quite get what you mean by:
>> But please don't do this if the amount of props varies (prop1-propN)!
> Could you elaborate, please?
>
>
> Bartek Skorupa
>
> www.bartekskorupa.com
>
> On 25 mar 2013, at 17:19, CoDEmanX  wrote:
>
>> Proper formatting:
>>
>> props = layout.operator(NodesLinkActiveToSelected.bl_idname,
>> text="Replace Links")
>>
>> props.prop1 = True
>> props.prop2 = True
>> props.prop3 = False
>>
>> But please don't do this if the amount of props varies (prop1-propN)!
>> Use a CollectionProperty instead. I think i did this in the Game
>> Property Visulizer addon to replace the evil eval().
>>
>>
>> Am 25.03.2013 16:08, schrieb Bartek Skorupa (priv):
>>> Thank you for the explanation.
>>>> props = layout.operator(NodesLinkActiveToSelected.bl_idname, text="Replace 
>>>> Links").prop1 = True
>>>>  props.prop2 = True
>>>>  props.prop3 = False
>>> Oops… I didn't know you can do it :-) Really…
>>>
>>> Every day I learn something.
>>> I will change all those properties accordingly.
>>>
>>> Thank you once again
>>>
>>> Regards
>>>
>>> Bartek Skorupa
>>>
>>> www.bartekskorupa.com
>>>
>>> On 25 mar 2013, at 16:02, Bastien Montagne  wrote:
>>>
>>>> Hi,
>>>>
>>>> On 25/03/2013 15:51, Bartek Skorupa (priv) wrote:
>>>>> Thank you for this quick review.
>>>>> Yes you're right about my understanding of bl_label. I did mismatch this 
>>>>> and I can change it, np.
>>>>>
>>>>> About my 'option' properties:
>>>>> In many cases I can change it to enums, but sometimes StringProperty is 
>>>>> used because I need to pass more than one property in one go.
>>>>> Say I need to set 3 properties:
>>>>> prop1 = True
>>>>> prop2 = True
>>>>> prop3 = False
>>>>>
>>>>> I wrap it in one StringProperty that gets the value of 'True True False' 
>>>>> and then in execute I use string split( ), and eval to get 3 booleans.
>>>>>
>>>>> Please take a look at line 1325 for example:
>>>>> layout.operator(NodesLinkActiveToSelected.bl_idname, text="Replace 
>>>>> Links").option = 'True True False'
>>>>>
>>>>> option then is passed to execute of NodesLinkActiveToSelected and split.
>>>>> see lines: 795 to 798:
>>>>>  option_split = self.option.split( )
>>>>>  replace = eval(option_split[0])
>>>>>  use_node_name = eval(option_split[1])
>>>>>  use_outputs_names = eval(option_split[2])
>>>>>
>>>>> This way I get 3 variables out of one property 'option'
>>>>>
>>>>> Is there a better way of doing it?
>>>> Yes there is! :)
>>>>
>>>> In such case, you should do that:
>>>>
>>>>  props = layout.operator(NodesLinkActiveToSelected.bl_idname, 
>>>> text="Replace Links").prop1 = True
>>>>  props.prop2 = True
>>>>  props.prop3 = False
>>>>
>>>>> Another question:
>>>>> Could you please explain me why using StringProperty instead of proper 
>>>>> EnumProperty is wrong?
>>>>> Is it a convention, speed issues or anything else?
>>>> First of all, it is a convention. True/false options should be booleans,
>>>> options with a well defined set of choices should be enums, etc.
>>>>
>>>> This also helps on documentation level (as each enum items has its own
&g

Re: [Bf-committers] Using C++11 features in Blender source code?

[CoDEmanX]

I remember a recent discussion about moving from MSVC 2008 to 2010, it 
was rejected / post-poned for a simple reason: the build team members 
don't own 2010 and can't afford the required amount of licenses. And 
community members who want to compile Blender with CUDA support would 
have to upgrade as well if the project moved on to a newer version i guess?


Am 27.03.2013 23:16, schrieb Bastien Montagne:
> iirc, we also need gcc4.2 support (for OSX) ? Guess this one isn’t much
> C++11-aware either… :/
>
> On 27/03/2013 22:16, Manuel Bellersen wrote:
>> Hey Dalai,
>>
>> It's not directly a project list. More a list of things I miss inside the
>> game engine.
>>
>> Downsides of C++11…
>> Probably the worst downside is compiler support for it.
>> With GCC 4.7 / 4.8 and Clang 3.3 you probably won't have a problem. But MS
>> Visual Studio is again far behind :-(.
>> Here is a little comparison:
>> http://cpprocks.com/a-comparison-of-c11-language-support-in-vs2012-g-4-7-and-clang-3-1/
>> http://cpprocks.com/c11-compiler-support-shootout-visual-studio-gcc-clang-intel/
>>
>> C++11 is fully backwards compatible.
>> Just your code might not be as clear as it should be ;-)
>> http://stackoverflow.com/questions/4326045/is-new-c-backward-compatible
>>
>> In my Blender branch I used C++11 features and had no real problems so far.
>> In the beginning I had to fix some lines the compiler otherwise would have
>> seen as string literal operators:
>> http://blenderartists.org/forum/showthread.php?283156-Fix-Compiling-BGE-with-C-11-option-gives-errors
>>
>>
>> You are right. Most C code in the game engine is glue to Blender.
>> But sometimes I find things like assert.h, float.h, math.h, stddef.h,
>> stdlib.h, stdio.h, malloc, free…
>> Trying to figure out where the game engine starts drove me through a lot of
>> C - that scared me - and lead to the impression, that there is more in the
>> GE. But it looks quite clear. (I thought that Blender would be total C++ …).
>>
>>
>> Hi Mitchell,
>>
>> MSVC 2008 sounds really bad.
>> I guess that means no C++11. Too bad.
>> In the code I already modified I used things like: auto,shared_ptr, for,
>> move, array, nullptr, constexpr - just to name some.
>>
>>
>> Thanks for your answers!
>>
>> Cheers!
>> Manuel Bellersen
>>
>>
>> 2013/3/27 Dalai Felinto
>>
>>> Hi Manuel,
>>> I need to re-visit your post to read it more through, but interesting
>>> initiative. For some of your projects you may want to drop on irc
>>> #bgecoders (or even #blendercoders) channel to bounce ideas before getting
>>> down to code. Mainly to smooth out future merges.
>>>
>>> Now to your topic:
>>> Could you elaborate on the downsides of using C++11? (backward
>>> incompatibility? Lack of compilers? )
>>> And the problems of mixing it up with the existent C++ code.
>>>
>>> Also BGE shouldn't have C code. As far as I can think of, the only part in
>>> C are the dependencies coming from Blender or code for the embedded BGE.
>>>
>>> Cheers,
>>> Dalai
>>> On Mar 27, 2013 7:52 AM, "Manuel Bellersen"
>>> wrote:
>>>
 Hey there!

 I just got in contact with coding Blender, especially the internal game
 engine.
 (Here is my personal branch https://bitbucket.org/Urfoex/blender/
 and a little write-up:

>>> http://urfoex.blogspot.com/2013/03/bge-qt5-coding-blender-game-engine.html
>>> )
 I like to code using the new features of C++11.
 But currently Blender isn't using C++11 anywhere.
 (I think it is kind of funny because it uses Python 3.3 that came out
 29.09.2012
 but doesn't use C++11 which showed up already a year earlier on
 12.08.2011.)

 So the question is:
 Can I contribute code written using C++11 features?
 Or am I forced to do the C&  C++ mix I found (and fear)?


 Best regards,
 Manuel Bellersen
 ___
 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
>>>
>> ___
>> 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
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Feature Request: predefined rotation values in spin tool

[CoDEmanX]

Toggling between CW and CCW is basically done by changing the sign of 
the angle value, so a small button could be added to toggle the sign - 
or a checkbox as you suggested, but its state would have to be updated 
if the sign of angle value changed.

Some convenience buttons for common rotations would be useful i guess, 
how about adding a preset list? (45, 90, 180, 270, 360)

Number of turns is 360 * n, two buttons could be added to add/subtract 
360° from the angle property... Not sure though how this worked in 
Blender 2.4x, did it do

number of turns * 360 + given angle ?

or did the number of turns-property overwrite the angle if != 1 ?



Am 27.03.2013 19:17, schrieb Jakub Strykowski:
> This is a feature request of new buttons in spin tool, predefined rotation 
> values of often used angles 45 90 180 360, and clockwise button to quick set 
> direction of spining, without typing minus (-)
> It was in 2.49 and later disappear.
> My suggestion is in the attachment
>
> http://projects.blender.org/tracker/download.php/9/498/34787/24649/spin%20tool.jpg
>
>
>
>
> ___
> 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] Odp: Re: Feature Request: predefined rotation values in spin tool

[CoDEmanX]

That's actually the better idea, limiting it to min=0 + checkbox

Just wondering if positive values = CW, negative = CCW?

Displaying a group as a 2x2 grid is possible, but not using column_flow() :(

Here's a UI demo:
http://www.pasteall.org/40866/python

Note: it's written in python which is really easy, doing the same in C 
will be harder.


Am 28.03.2013 09:17, schrieb Jakub Strykowski:
> Maybe it is possible to make angle value be only positive (skip and delete 
> typed sign before value) , and toggling between cw and ccw only by checkbox?
>
> Preset list with 5 values is fine, i suggested 4 because they can easily be 
> set in a rectangle, and save vertical space.
>
> I dont know it is possible, but now i have idea that selecting one of 
> predefinied values will overwride previous selected angle and typed angle 
> value, And with holded Shift button angles can by added? so to make 270' you 
> click 180'  shift 90 or 180 shift 45 to make 225'. It can be probaly hard to 
> do.
>
> I don't understand why need number of turns greater than 360' ?
>
>
> Dnia Środa, 27 Marca 2013 23:50 CoDEmanX  napisał(a)
>> Toggling between CW and CCW is basically done by changing the sign of
>> the angle value, so a small button could be added to toggle the sign -
>> or a checkbox as you suggested, but its state would have to be updated
>> if the sign of angle value changed.
>>
>> Some convenience buttons for common rotations would be useful i guess,
>> how about adding a preset list? (45, 90, 180, 270, 360)
>>
>> Number of turns is 360 * n, two buttons could be added to add/subtract
>> 360° from the angle property... Not sure though how this worked in
>> Blender 2.4x, did it do
>>
>> number of turns * 360 + given angle ?
>>
>> or did the number of turns-property overwrite the angle if != 1 ?
>>
>>
>>
>> Am 27.03.2013 19:17, schrieb Jakub Strykowski:
>>> This is a feature request of new buttons in spin tool, predefined rotation 
>>> values of often used angles 45 90 180 360, and clockwise button to quick 
>>> set direction of spining, without typing minus (-)
>>> It was in 2.49 and later disappear.
>>> My suggestion is in the attachment
>>>
>>> http://projects.blender.org/tracker/download.php/9/498/34787/24649/spin%20tool.jpg
>>>
>>>
>>>
>>>
>>> ___
>>> 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
>
>
>
>
> ___
> 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] Odp: Re: Feature Request: predefined rotation values in spin tool

[CoDEmanX]

Hm i actually had a custom entry in the enum, didn't think about the 
benefit of a "custom" button to set/add/subtract the set angle - that 
would be handy of course!

BUT: the spin tool isn't a live operator, so you need to set its 
parameters in the redo panel. Redo + operators to change a property 
inside that panel in C = will it work?

Am 28.03.2013 16:18, schrieb Antony Riakiotakis:
> Not really, probably with the addition of "Custom" in the buttons
> where the custom angle is taken into account
> ___
> 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] Odp: Re: Feature Request: predefined rotation values in spin tool

[CoDEmanX]

Why a custom enum? The set/add/subtract thing is operators, not enum.

Am 28.03.2013 16:28, schrieb Antony Riakiotakis:
> That's exactly the reason why you need a "Custom" enum
> ___
> 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] Radial control, pie menus and nice wip feature: Conflict?

[CoDEmanX]

I like the overall idea of such a widget, but i find it rather confusing 
that it's a wheel you have to spin for different actions. It makes 
perfect sense for rotations, but for scew/scale/move? The arrow icons 
rotate with the wheel menu, making it really unpredictable...

Here's my own proposal:

http://www.pasteall.org/pic/show.php?id=48369

I also like the Texture position widgets in Google Sketchup, they are 
easy to use and support snapping.


Am 01.04.2013 01:57, schrieb Antony Riakiotakis:
> Hi, I've been trying to work around some nice way to control the stencil
> mapping of brushes. My first approach was to find a shortcut, and after
> some thinking about what would be lenient, intuitive and hardest of all,
> available to all paint modes I settled on Right-Click.
>
> Now the issues begin: I thought that I would use a similar scheme to our
> brush radial control, namely ctrl-F, F, Shift-F. And I did code a light
> version of that. However, clever coder kgeogeo came up with a nice
> solution, see
>
> http://www.youtube.com/watch?feature=player_embedded&v=kAOoCZfZS9o
> http://www.youtube.com/watch?v=6WaRvMCHgeg
>
> This is very nice IMO. It has a play factor, it allows to select many
> properties and tweak any of them. So my question is: Would such a design
> conflict with the upcoming pie menus? I think they are slightly different
> in that pie menus don't allow tweaking of properties. I would like to tweak
> the existing radial control to allow for such a UI (or write a new one? Not
> 100% certain it could accomodate it without drastical changes).
>
> Thoughts?
> ___
> 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 [55940] trunk/blender/release/scripts/ startup/bl_ui/properties_freestyle.py: Added to the Freestyle panel in the Render buttons a

[CoDEmanX]

Maybe a good time to discuss (again) about the UI organization of the 
Properties editor? There's i.e. a UI proposal for the modifiers since a 
long time. And there is no group editor (like regular editor but not 
limited to context object) - if scripters were able to add tabs, and 
addon would do.

Am 10.04.2013 22:32, schrieb Thomas Dinges:
> Hi Tamito,
> I am not so happy with this solution.
>
> The only place where we use this, is the modifier stack at the moment.
> One could argue, that such a button or notice could be added to a lot
> more places. Imho, we should just document where the settings are, that
> should be fine.
>
> I understand that for long time Freestyle users this might be a bit
> confusing atm, but on the other hand we should really avoid adding such
> special cases in the UI to jump from one place to another, just because
> all settings are not in 1 place.
>
> Best regards,
> Thomas
>
> Am 10.04.2013 22:20, schrieb Tamito Kajiyama:
>> Revision: 55940
>> 
>> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=55940
>> Author:   kjym3
>> Date: 2013-04-10 20:20:20 + (Wed, 10 Apr 2013)
>> Log Message:
>> ---
>> Added to the Freestyle panel in the Render buttons a button to switch to the 
>> Render Layers context.
>>
>> Modified Paths:
>> --
>>   trunk/blender/release/scripts/startup/bl_ui/properties_freestyle.py
>>
>> Modified: trunk/blender/release/scripts/startup/bl_ui/properties_freestyle.py
>> ===
>> --- trunk/blender/release/scripts/startup/bl_ui/properties_freestyle.py  
>> 2013-04-10 20:05:11 UTC (rev 55939)
>> +++ trunk/blender/release/scripts/startup/bl_ui/properties_freestyle.py  
>> 2013-04-10 20:20:20 UTC (rev 55940)
>> @@ -60,7 +60,9 @@
>>row.active = (rd.line_thickness_mode == 'ABSOLUTE')
>>row.prop(rd, "line_thickness")
>>
>> -layout.label(text="Line style settings are found in the Render 
>> Layers context")
>> +row = layout.row()
>> +row.label(text="Line style settings are found in the Render Layers 
>> context")
>> +row.operator("wm.properties_context_change", text="", 
>> icon='BUTS').context = 'RENDER_LAYER'
>>
>>
>># Render layer properties
>>
>> ___
>> Bf-blender-cvs mailing list
>> bf-blender-...@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-blender-cvs
>
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Proportional editing distance calculation ?

[CoDEmanX]

Maybe as simple as:

Connected (Distance)
Connected (Geometry)

?

There should be a more in-depth tooltip text of course.

Am 12.04.2013 21:51, schrieb Jace Priester:
> I can think of a reason. Say you want to use proportional edit along a
> curve, either an actual curve object or mesh representing a curve, and this
> curve is some sort of camera or object path or whatnot. It seems likely
> that in this situation one would be interested in proportional editing
> based on the distance traversed down the path, rather than based on simply
> nearest points in 3d space. This is actually the mode that I use sometimes
> since I frequently deal with curve-based motion paths which occasional loop
> back around on themselves and such. IMO it shouldn't be switched to one or
> the other, but a new option added instead so that both methods can be
> accommodated.
>
> Label suggestions ... ?
> Connected/By 3D Distance
> Connected/By Distance Along Path
>
>
> On Fri, Apr 12, 2013 at 9:17 AM, Bradley Smith  wrote:
>
>> Proportional editing connected mode is using the graph distance (the
>> distance calculated when traversing the mesh to find connected
>> vertices) rather than the Euclidean distance. The behavior seems to
>> have been altered on Feb 1, 2010, with commit 26537 "Proportional Edit
>> Connected: Use connectivity distance for falloff (connectivity
>> distance now also calculated across inner face edges)."
>>
>> Reversing the behavior can be easily accomplished by deleting three
>> lines of code (lines 1724-1726 in transform_generics.c). However, I
>> don't know what effect this would have beyond fixing the behavior of
>> mesh editing with proportional editing connected mode.
>>
>> Does someone know a reason for using the graph distance rather than
>> the Euclidean distance?
>>
>>Bradley
>>
>>
>> On Sat, Apr 6, 2013 at 2:13 PM, Hadrien Brissaud 
>> wrote:
>>> Hello,
>>>
>>> I have come across an annoying behaviour when using proportional editing
>> -
>>> connected mode. This mode is very useful for situations where we don't
>> want
>>> nearby, unconnected areas to be affected by transformations made with
>>> proportional editing enabled.
>>>
>>> This happens with "*proportional edit"* on :
>> http://i.imgur.com/FE6uPh1.png
>>> Now, this happens with "*proportional editing connected"* on :
>>> http://i.imgur.com/U5TZW3i.png
>>>
>>> I understand this is likely due to the way Blender calculates distance to
>>> nearby vertices - for instance, diagonals may be calculated as twice
>>> farther than directly-connected vertices. This is verified by attempting
>>> the same deformation on a radially-subdivided mesh :
>>> http://i.imgur.com/O6PPKVf.png (it works "as expected")
>>>
>>> As reference, Maya handles both situations the same way, and this is the
>>> result : http://imgur.com/B6bQ0sL
>>>
>>> How easily could this be fixed ?
>>>
>>> Thank you,
>>>
>>> Hadrien
>>> ___
>>> 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
>>
>
>
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender online

[CoDEmanX]

Multiple people working on a single image sounds ridiculous indeed, but 
with 3D, it's a different story. Especially if you use Blender to create 
game environments, multiple working working on the map is really a use 
case. Since Blender isn't designed to stream 3d content, a sharing 
feature should be kept simple. So how about a button to update linked 
library objects? That way, one could sort of work on the same scene.

Am 26.04.2013 10:27, schrieb Ton Roosendaal:
> Hi,
>
> Oh - yeah I was interpreting it as similar to how we setup pipelines in a 
> studio. Where you keep the .blends individually owned, and link in data.
>
> Work on the same .blend scene together is a specification that would right go 
> deep into the core of Blender's design. I wouldn't recommend to try this, nor 
> do I think it would become a succesful project with the current state of 
> Blender.
>
> The issue of efficient data sharing for projects is really something you can 
> handle on a meta level, and not try to do it on vertex/objects level or on 
> tools.
>
> Take GIMP for example. It sounds fun to have 2 people do operations on 1 
> image, but if this is useful? In practice, ownership of such data is really 
> not a limitation.
>
> That goes for character rigs, models, environments, props, etc. Easy to 
> design a data structure based on .blends being managed by individuals.
>
> -Ton-
>
> 
> Ton Roosendaal  Blender Foundation   t...@blender.orgwww.blender.org
> Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands
>
> On 26 Apr, 2013, at 1:22, Brecht Van Lommel wrote:
>
>> Hi,
>>
>> On Thu, Apr 25, 2013 at 11:38 PM, Moisés Bonilla  wrote:
>>> First of all, thanks for the quick response.
>>>
>>> Ton Roosendaal: That idea about the "normalized" file IO sounds good. Do
>>> you think that maybe I could start thinking about the case when two people
>>> starts with a empty scene and each one sends to the other simple commands
>>> (Create cube at ..., Rotate object ..., etc)?
>>
>> I think Ton misunderstood what you were proposing? Handling network
>> paths is quite different from realtime sharing.
>>
>>> And no, although summer of code sounds interesting, I would prefer to "take
>>> it easy" for now :). Anyway, I should start by proposing the project in the
>>> wiki, isn't it?
>>
>> Yes, you can add make a wiki page about the project.
>>
>> But note that there's a reason Verse was never finished and
>> integrated. If it's a research project where you create a proof of
>> concept then it can work, but to make this ready for production use is
>> problematic. That's because there are many different data structures
>> and editing operations in Blender, and they weren't designed with this
>> kind of thing in mind. It's quite possible to make it work for a small
>> subset of those, but supporting this across Blender in a way that's
>> reliable and maintainable probably requires a major redesign of
>> Blender internals.
>>
>> Brecht.
>> ___
>> 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
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Some changes in 3D view header (and general RNA-generated UI)

[CoDEmanX]

Hey Mont,

good work on the UI stuff, this is always great for python scripters :)


Two questions about the patch:

> ** enum-operator-generated menus are now PULLDOWN in headers too.

Does that mean the visual order is inversed?

> ** All bit-flag enums expanded in ROW buttons now have a handling
> consistent with e.g. layers, or what we already have for transform
> manipulators, i.e. clicking select only one element, shift-click to
> select multiple ones.

Sounds great, since we can't code such behavior in python as 
window.eventstate isn't exposed. But when does it apply? For all 
BoolVectorPropeperty's? Only if subtype='LAYER'? Maybe there's a need a 
layer bool vec prop (20 elems) which allows just a single bool / layer 
selected, in this case, another subtype with no shift-click would be 
required i guess?

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

Re: [Bf-committers] Edit mode tools.

[CoDEmanX]

GG-slide with clamp turned off can be used to extend like described, but 
snapping isn't supported, so this was either achieved with an addon or 
just snapping without caring about the direction of the connected edge.

Am 12.05.2013 23:08, schrieb Blender Attitude:
> Did you try double typing the G key ?
> Le 12 mai 2013 23:07, "Knapp"  a écrit :
>
>> On Sun, May 12, 2013 at 11:01 PM, Blender Attitude
>>  wrote:
>>> Maybe you simply search the double G key ? Now when you press the G key
>> two
>>> times in edit mode, there is a guide line.
>>> Le 12 mai 2013 22:58, "Knapp"  a écrit :
>>
>> This was something where you could extend a vert and then it would
>> stick to the surface of the next shape. It was a new thing and it had
>> a video showing it off. I think it also worked with extending polygon
>> against other polygons too but it was a long time ago so I am not
>> certain.
>>
>> --
>> Douglas E Knapp
>>
>> Creative Commons Film Group, Helping people make open source movies
>> with open source software!
>> http://douglas.bespin.org/CommonsFilmGroup/phpBB3/index.php
>>
>> Massage in Gelsenkirchen-Buer:
>> http://douglas.bespin.org/tcm/ztab1.htm
>> Please link to me and trade links with me!
>>
>> Open Source Sci-Fi mmoRPG Game project.
>> http://sf-journey-creations.wikispot.org/Front_Page
>> http://code.google.com/p/perspectiveproject/
>> ___
>> 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
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Edit mode tools.

[CoDEmanX]

Well if moving on the face is ok, then standard snapping will do:

http://youtu.be/v-Ly-BeqFpQ


Am 12.05.2013 23:12, schrieb Knapp:
> On Sun, May 12, 2013 at 11:10 PM, CoDEmanX  wrote:
>> GG-slide with clamp turned off can be used to extend like described, but
>> snapping isn't supported, so this was either achieved with an addon or
>> just snapping without caring about the direction of the connected edge.
>
> If my memory is correct, it extended to an intersection with a plane
> and you could move the point around on that plane. It could have been
> an addon.
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] 2.67a proposed fixes

[CoDEmanX]

node.type returns the old enum string, whereas nodes.new(type=...) 
expects one of the new type names:

http://wiki.blender.org/index.php/User:Phonybone/Python_Nodes/API_changes

I don't think this is a good idea to not break old scripts, the required 
effort to update the types seems little and would confuse scripters less 
(it already did [1], and they didn't know about the above wiki page).

So I suggest to either change the strings of node.type to the new ones, 
or print a warning in console if this is accessed to inform scripters 
that it doesn't match the type used in nodes.new()

[1] 
http://blenderartists.org/forum/showthread.php?291921-2-67-won-t-add-node
___
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 [57153] trunk/blender/source/blender/ makesrna/intern/rna_text.c: Made text datablock properties 'is_in_memory' and 'is_dirty' edi

[CoDEmanX]

Vincent Akkermans' GSoC-project is about action replay, it will involve 
changes to the undo system:

http://wiki.blender.org/index.php/User:Ack-err/GSoC_2013/Proposal

That sounds like an occasion to also improve the text editor, since it 
shares the global undo and scripts get easily reverted to old states if 
a user tries to undo changes in the 3d view.

Text editor should
- have its own undo system
- not log every keystroke, but meaningful undo steps
- support undo/redo properly (it gets confused a lot currently and might 
remove or overwrite lines you never touched)
- handle internal / external files differently?

Not sure if Vincent will have a chance / is willing to tackle these, but 
if so, the way to pack/unpack/whatever texts might also need re-thinking.


Am 31.05.2013 20:45, schrieb Sergey Sharybin:
> That'd be really confusing situation when you'll set is-internal to False
> for the textblock which originally was internal. You'll basically loose all
> the data i guess.
>
> Also is_dirty pretty dangerous thing. Setting it to false will also lead to
> nothing else than confuse.
>
> This is probably acceptable for short-term solution, but for longer term
> is't more like a confusing way to reach the goal. And in context of recent
> API breakage discussing think it's better to support nice way of reaching
> the goal from the start, rather than breaking api later.
>
> And for long term, not sure how pack/unpack is different from
> make_internal/make_external. Sounds more like a pseudonyms to the same
> thing, and perhaps we could already call functions this way?
>
>
> On Sat, Jun 1, 2013 at 12:30 AM, Campbell Barton wrote:
>
>> I requested Tamito use flags rather then a function,
>> The reason for this is that making a text internal/external is fairly
>> low-level (not something regular script devs would care about
>> typically).
>> if you add make_internal() then theres the chance you'll want a
>> make_external() function (which could be OK but adds more API calls).
>>
>> Longer term, I think it would be good if we could have text that isn't
>> necessarily stored inside a blend file (like how images aren't stored
>> unless packed),
>> in that case text blocks can have pack(), unpack() functions as mentioned.
>>
>> On Sat, Jun 1, 2013 at 4:08 AM, Tamito KAJIYAMA
>>  wrote:
>>> Hi Sergey,
>>>
>>> Indeed .make_internal() was exactly what I was proposing initially.
>>> http://www.pasteall.org/42705/diff
>>> Then I was suggested to address the issue in the present way.
>>> I tend to agree with your opinion from the scripter perspective.
>>>
>>> --
>>> KAJIYAMA, Tamito 
>>>
>>>
>>> -Original Message-
>>> From: Sergey Sharybin
>>> Sent: Friday, May 31, 2013 10:17 AM
>>> To: Blender Developers
>>> Subject: Re: [Bf-committers] [Bf-blender-cvs] SVN commit:
>> /data/svn/bf-blender [57153] trunk/blender/source/blender/
>>> makesrna/intern/rna_text.c: Made text datablock properties
>> 'is_in_memory' and 'is_dirty' editable in Python.
>>>
>>> Hi,
>>>
>>> Not sure this is the best way to go. IMO this is rather confusing from
>>> scripter POV and confuses system a bit.
>>>
>>> Why not make it a TextBlock.make_internal() method? Name of the method is
>>> discussable -- could be pack/unpack to match other datablocks, but think
>>> callback is the way to go to achieve things you want :)
>>>
>>>
>>> On Fri, May 31, 2013 at 1:40 PM, Tamito Kajiyama
>>> wrote:
>>>
 Revision: 57153


>> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=57153
 Author:   kjym3
 Date: 2013-05-31 07:40:03 + (Fri, 31 May 2013)
 Log Message:
 ---
 Made text datablock properties 'is_in_memory' and 'is_dirty' editable in
 Python.

 The rationale of this revision is to provide an easy way to make text
 datablocks internal
 from within Python (i.e., by setting these properties to True and the
 'filepath' property
 to empty string).

 Modified Paths:
 --
  trunk/blender/source/blender/makesrna/intern/rna_text.c

 Modified: trunk/blender/source/blender/makesrna/intern/rna_text.c
 ===
 --- trunk/blender/source/blender/makesrna/intern/rna_text.c
>> 2013-05-31
 06:28:11 UTC (rev 57152)
 +++ trunk/blender/source/blender/makesrna/intern/rna_text.c
>> 2013-05-31
 07:40:03 UTC (rev 57153)
 @@ -148,7 +148,6 @@

  prop = RNA_def_property(srna, "is_dirty", PROP_BOOLEAN,
>> PROP_NONE);
  RNA_def_property_boolean_sdna(prop, NULL, "flags", TXT_ISDIRTY);
 -   RNA_def_property_clear_flag(prop, PROP_EDITABLE);
  RNA_def_property_ui_text(prop, "Dirty", "Text file has been
>> edited
 since last save");

  prop = RNA_def_property(srna, "is_modified", PROP_BOOLEAN,
 PROP_NONE);
 @@ -158,7 +157,6 @@

  prop = RNA_def_property(srna, "is_in_memor

Re: [Bf-committers] Blender roadmap article on code blog

[CoDEmanX]

Am 29.06.2013 16:41, schrieb Ton Roosendaal:
> - Where Python is too slow (I/O), we can also improve the api a lot still. 
> For our UI now it's more than fast enough.

There are two areas where it's notably slow: user preferences input and 
addon UI - due to the high number of layout elements I guess. However, 
it's acceptable in this area.

Where python performance really bugs me is I/O. Due to GIL, python can't 
make use of multi-core systems (runs with max. 25% of an i5 with two 
real cores / four virtual cores). And multiprocessing isn't really 
applicable, since blender doesn't allow multiple threads accessing the 
RNA system without crashes.

Looking at the OBJ importer, the real bottleneck is the mesh splitting 
code. It takes a serious amount of time for gigabyte-sized OBJs, and a 
huge amount of memory (like 500 MB OBJ, 6 GB mem). Not sure if one could 
optimize the python code, but a C/C++ importer would always be superior 
(see Meshlab speed!). Any plans on merging assimp support from Bratwurst 
into trunk?
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Hive system

[CoDEmanX]

There are two pictures in the ba.org thread, so check it out:

http://www.blenderartists.org/forum/showthread.php?256747-The-Hive-system-version-0-91-released&p=2133217&viewfull=1#post2133217

Looks similar to CryEngine's FlowGraph. Once it will be integrated into 
Blender and use native PyNodes, that would be a huge step forward for 
the engine - but I hope it won't stay an "on top" addition, but rather 
replace the bricks!


Am 17.07.2013 16:38, schrieb Thomas Volkmann:
> Hi,
> you don't have any screenshots or videos anywhere by any chance? I'm too busy
> for installing and testing it myself... :/
>
> cheers,
> Thomas
>
>
>> Sjoerd de Vries  hat am 17. Juli 2013 um 16:14
>> geschrieben:
>>
>>
>> Hi everyone,
>>
>> Just a quick notification that a new (beta) version of the hive system for
>> nodal logic has been released. It now has 100+ pages of documented
>> tutorials and examples.
>> It runs in pure Python on top of the BGE, with Blender 2.65 or later.
>> The GUI is currently external (using Qt), but will be ported to run
>> in-Blender (using PyNodes) this summer.
>>
>> More information can be found on the BA thread:
>> http://www.blenderartists.org/forum/showthread.php?256747
>>
>> Feedback and suggestions on all aspects are most welcome. In particular,
>> the user experience for artists. The hive system has fine-grained control
>> and mechanics, but I have no expertise in developing intuitive interfaces
>> for non-technical users. I hope to learn from the people on this mailing
>> list.
>>
>> cheers
>>
>> Sjoerd
>>
>> PS. For those who remember the last discussion: the license has now been
>> changed from GPL to BSD.
>> ___
>> 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
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] IMAGE_OT_invert missing undo

[CoDEmanX]

Just noticed another issue:

If the image datablock is float (and not int), it doesn't update on 
inversion.

One can call Image.update() and Area.tag_redraw() with python to force 
the update. But should be handled by C op for sure.


Am 30.10.2013 18:15, schrieb Antony Riakiotakis:
> Codemanx brought this into attention on irc. If this was a paint operation
> I would just use the paint undo stack, but I have no idea how something
> like that is to be handled...ideas?
> ___
> 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] Point cache Import

[CoDEmanX]

it exists: Export mesh Pointcache data (.pc2)
in addons\io_export_pc2.py
Version 1.0


Am 07.06.2012 14:23, schrieb Christophe Leyder:
> Hey all, we're trying to import an animated mesh into Blender from
> Softimage for smoke simulation, Collada isnt working at all and FBX isnt
> there. The only thing thats left is a point cache (.pc2), but I cant find
> the importer anywhere, has it been dropped?
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Import CS in Blender ?

[CoDEmanX]

Format specs:
http://www.crystalspace3d.org/docs/online/manual/XML-File-Format.html

you could write an import script, seems to be rather simple XML-based 
format.

Am 13.06.2012 15:23, schrieb John Smith:
> Hi,
>
>
> I know there is a tool to export Blender to Crystal Space (CS,
> http://www.crystalspace3d.org/), but how about in the other direction
> ? Is there a way to import CS in Blender ?
>
> So far I only have been able to find 'Assimp'
> (http://assimp.sourceforge.net/main_features_export.html), and
> although it looks promising, those formats are not available (yet).
>
>
> Regards,
>
>
> John Smith.
> ___
> 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