Re: [Bf-committers] Camera tracking UI
Hi again, Commited some interface changes to tomato branch, Please check commit message for details: http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=41744 -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Camera tracking UI
I'm not sure if having "Solve" button in reconstruciton mode is good idea. Ofcourse you can re-adjust tracks position and resolve. But most probably it'll lead to movement of some bundles which you used to use as reference points. And it was feedback from actual users of motion tracking in blender how to organize panels in clip editor ;) François T. wrote: >> I also would expect "Solve Camera" in the >> > Reconstruction mode, instead of in Tracking mode. > I understand why, but for a workflow matter I disagree. > When you are going to fine tune your solve to low down the error, you'll > tweak your trackers a lot and hit solve very often. If you have to change > mode each time its going to be a huge pain. That why we decide with Seb to > keep it the tracking mode. > Becareful that the logic don't get in the way of confortable workflow. -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Camera tracking UI
t;>> terms you got to know as well. Reconstruction is a common one for >> instance. >> The difficulty is that if everything is made automatic with no choices, >> then the tool is less useful since in many situations the difference in >> whether you can track a shot or not depends on which algorithm you pick. >> >> Welcome to computer vision, where the pixels don't care what you want :) >> > Dont give me wrong, I have been working on both side R&D and Artist. I know > the need of all the details stuff on the dev side. But front-end doesn't > need all that. And by no mean I meant everything should be hidden or > automatic. I also know that FAST or SAD WON'T mean a thing to most peoples. > And even if they look into matchmoving books or tutorial from other > software (since our workflow is similar to other any technics could be > applied)... they won't find the anwser. They'll have to get into computer > vision (the dark side for the artist) to understand the difference. > It's like go ask a modeler what a matrix is :) ... he won't even know it > does exist, and still he is using it each time he moves something around > > > > >> So yeah on the overall, lots of cleaning stuff to do, and lets drop the >>> geeky dev side. This is a tool for artist and not for devs as far as I'm >>> concern >>> >> Do you have concrete proposals to do so? >> > We can definetly work on that and take time to do a nice proposal. > > > > >> Keir >> >> >>> >>> >>> 2011/11/9 Daniel Salazar - 3Developer.com >>> >>>> Hi, i see that camera tracker related UI is spread all over the place >>>> with no clear definition. Camera tracking is a corner case use of >>>> Blender, I'd suggest that UI elements belonging to it get clearer >>>> names *and* get pulled together in boxes or their own panels >>>> >>>> ie: follow track constraint >>>> >>>> http://www.pasteall.org/pic/show.php?id=20349 >>>> >>>> why would any regular user of know that this is camera tracking stuff, >>>> or what is a Bundle? >>>> >>>> it's worst in the N Panel >>>> >>>> http://www.pasteall.org/pic/show.php?id=20350 >>>> >>>> Shading, Textured solid.. reconstruction? reconstruction of what?? >>>> bundle, bundle, bundle and then the old quad view! >>>> >>>> Daniel Salazar >>>> 3Developer.com >>>> ___ >>>> Bf-committers mailing list >>>> Bf-committers@blender.org >>>> http://lists.blender.org/mailman/listinfo/bf-committers >>>> >>> >>> >>> -- >>> >>> François Tarlier >>> www.francois-tarlier.com >>> www.linkedin.com/in/francoistarlier >>> ___ >>> 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 >> >> -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Camera tracking UI
Hi, I'll agree with both of Daniel about not perfect exposing into UI and Francois about it's not just c camera to move around :) But anyway, will try to make this stuff more clear next few days. François T. wrote: > yeah I kind of agree with all that. So far all those naming as been chosen > based on a technical naming side (ie bundles means something to a computer > vision developer, doesn't mean a thing to an artist) > Same confusion with, markers, trackers, > Same with algorithm FAST, SAD, ... all technical stuff that doesn't mean a > thing if you havn't done any computer vision dev in your life > But in another hand, matchmove is something you have to get interest in as > well. it is a discipline and not just a camera to move around :p. There are > terms you got to know as well. Reconstruction is a common one for instance. > > So yeah on the overall, lots of cleaning stuff to do, and lets drop the > geeky dev side. This is a tool for artist and not for devs as far as I'm > concern > > > > > 2011/11/9 Daniel Salazar - 3Developer.com > >> Hi, i see that camera tracker related UI is spread all over the place >> with no clear definition. Camera tracking is a corner case use of >> Blender, I'd suggest that UI elements belonging to it get clearer >> names *and* get pulled together in boxes or their own panels >> >> ie: follow track constraint >> >> http://www.pasteall.org/pic/show.php?id=20349 >> >> why would any regular user of know that this is camera tracking stuff, >> or what is a Bundle? >> >> it's worst in the N Panel >> >> http://www.pasteall.org/pic/show.php?id=20350 >> >> Shading, Textured solid.. reconstruction? reconstruction of what?? >> bundle, bundle, bundle and then the old quad view! >> >> Daniel Salazar >> 3Developer.com >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers >> > > -- With best regards, Sergey I. Sharybin ___ 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 [41685] trunk/blender/build_files/scons/ config/win64-vc-config.py: Scons:
Hi,
This looks a bit strange for me. In theory, '${BF_OIIO}/include' and
'#../lib/win64/openimageio/include' should be the same paths and using
${BF_OIIO} is more flexible for build systems (at least for linux).
Maybe error was in how this path is used by SConstruct?
Thomas Dinges wrote:
> Revision: 41685
>
> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=41685
> Author: dingto
> Date: 2011-11-08 21:17:42 + (Tue, 08 Nov 2011)
> Log Message:
> ---
> Scons:
> * Fixing x64 compile with Cycles.
>
> Modified Paths:
> --
> trunk/blender/build_files/scons/config/win64-vc-config.py
>
> Modified: trunk/blender/build_files/scons/config/win64-vc-config.py
> ===
> --- trunk/blender/build_files/scons/config/win64-vc-config.py 2011-11-08
> 20:56:55 UTC (rev 41684)
> +++ trunk/blender/build_files/scons/config/win64-vc-config.py 2011-11-08
> 21:17:42 UTC (rev 41685)
> @@ -157,15 +157,16 @@
>
> WITH_BF_OIIO = True
> BF_OIIO = LIBDIR + '/openimageio'
> -BF_OIIO_INC = '${BF_OIIO}/include'
> +BF_OIIO_INC = '#../lib/win64/openimageio/include'
> BF_OIIO_LIB = 'OpenImageIO'
> BF_OIIO_LIBPATH = '${BF_OIIO}/lib'
> +BF_OIIO_LIBPATH = '#../lib/win64/openimageio/lib'
>
> WITH_BF_BOOST = True
> BF_BOOST = LIBDIR + '/boost'
> -BF_BOOST_INC = '${BF_BOOST}/include'
> +BF_BOOST_INC = '#../lib/win64/boost/include'
> BF_BOOST_LIB = 'libboost_date_time-vc90-mt-s-1_47
> libboost_filesystem-vc90-mt-s-1_47 libboost_regex-vc90-mt-s-1_47
> libboost_system-vc90-mt-s-1_47 libboost_thread-vc90-mt-s-1_47'
> -BF_BOOST_LIBPATH = '${BF_BOOST}/lib'
> +BF_BOOST_LIBPATH = '#../lib/win64/boost/lib'
>
> #Ray trace optimization
> WITH_BF_RAYOPTIMIZATION = True
>
> ___
> Bf-blender-cvs mailing list
> bf-blender-...@blender.org
> http://lists.blender.org/mailman/listinfo/bf-blender-cvs
>
--
With best regards, Sergey I. Sharybin
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender developer IRC meeting, nov 6 2011
Yes, of course. mindrones wrote: > Hey Sergey, > > On 11/07/2011 08:27 AM, Sergey I. Sharybin wrote: > >> mindrones wrote: >>> Is there any docs on Tomato? >> Yes, there's small doc for developer-side: >> http://wiki.blender.org/index.php/User:Nazg-gul/GSoC-2011/Documentation >> (which should be updated a bit). >> Also some video tutorials from me >> http://wiki.blender.org/index.php/User:Nazg-gul/GSoC-2011/Gallery and i >> can collect better video tutorials from Sebastian i think (if needed). > > any chance you and Sebastian can write the doc in text format? > > Regards, > Luca > > _ > > http://wiki.blender.org/index.php/User:Mindrones > http://www.mindrones.com > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender developer IRC meeting, nov 6 2011
Hi, mindrones wrote: > Is there any docs on Tomato? Yes, there's small doc for developer-side: http://wiki.blender.org/index.php/User:Nazg-gul/GSoC-2011/Documentation (which should be updated a bit). Also some video tutorials from me http://wiki.blender.org/index.php/User:Nazg-gul/GSoC-2011/Gallery and i can collect better video tutorials from Sebastian i think (if needed). -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] curves info
Hi,
Points array is stored in Nurb structure Depending of curve type
(bezier or nurbs) Nurb->bezt or Nurb->bp is used. Generally we're checking:
if(nu->bezt) { /* use nu->bezt as array of points */ } else { /* use
nu->bp as array of points */ }
For beziers nu->bezt contains nu->pntsu points, for nurbs it contains
nu->pntsu*nu->pntsv points.
Coordinates in BezTriple are stored in float vec[3][3] property. It is
array of three 3d coordinates: coordinate for left handle, control point
and right handle.
Coordinates in BPoint are stored in float vec[4] property. It's X, Y, Z
coordinates and Weight.
Hope it'll help you/
Fabio Russo wrote:
> Hi,
> I'm implementing a new feature to the AMA: http://projects.blender.
> org/tracker/index.php?func=detail&aid=26662
> and I need access to coordinates of points, circled in red: http://www.
> pasteall.org/pic/20036
> I need help for c, not for the python!
> Thanks in advance for your help and sorry for my English!
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
--
With best regards, Sergey I. Sharybin
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] UI changes from cycles branch
. >>> >>>>> * Black arrows on menu button >>>>> >>>> -1, Way too low contrast, there's almost no point in having them there. >>>> Makes them look like other dark UI widgets like radio buttons, which is not >>>> good. >>> For me the arrows are quite visible but they could be made darker >>> still. I think that if you look at the buttons, you see the arrows, >>> but if you're scanning over buttons they can be skipped over. I think >>> this is a good thing, for example in the 3d view header, there's a few >>> of those in a row. The white arrows distract from the white text/icons >>> and it's harder to scan for the right button. >>> >>>>> * Panel header changed look&smaller >>> The panel header with a single line makes it more difficult to see >>> where one panel ends and the other begins, so I made the entire header >>> darker. There is no longer space between the panels when they are >>> collapsed, but otherwise the header has the same size. They could be >>> made a bit bigger but don't feel cramped to me, maybe they would on a >>> bigger screen. >>> >>>>> * Screen splitting widgets look >>>>> >>>> Not a fan of how it is now, but perhaps if it was the dark triangle with a >>>> hint of the 'gripper' lines blended on top it would work better. >>> Ok, I can try to add some subtle gripper lines. >>> >>>>> * Toolbar/properties expand button look >>> Guess this one was obvious, unconnected (+) buttons are confusing. >>> >>>>> I'd still like to change the font in trunk, but it seems hard to get >>>>> an agreement on this. Some tests: >>>>> >>>> Again, I'd like to hear the rationale - I think the font in trunk right now >>>> is very good. >>>> >>>> If it's to make things smaller and more condensed, be wary of cutting off >>>> one's nose to spite one's face - you *need* whitespace in design, it's not >>>> just wasted areas where more can be crammed in. >>> I don't particularly care about the text being smaller, any gains >>> there are very minor. I just think the current font is hard to read at >>> this size, too 'smudgy', and the shapes of words aren't very >>> distinctive. My impression is that there are fonts that were designed >>> to work better at this font size. >>> >>> Thanks, >>> Brecht. >>> ___ >>> Bf-committers mailing list >>> Bf-committers@blender.org >>> http://lists.blender.org/mailman/listinfo/bf-committers >> >> -- >> Thomas Dinges >> Blender Developer, Artist and Musician >> >> www.dingto.org >> >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers >> > > -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] 2.60a Ahoy
Linux builds are on ftp. tag: blender-2.60a-release blender revision: 41226 addons revision: 2506 Campbell Barton wrote: > Hi, I've merged in the fixes from trunk into the 2.60a tag. > > Tag: > https://svn.blender.org/svnroot/bf-blender/tags/blender-2.60a-release/blender > > Unlike previous releases this isn't a revision from trunk, rather 2.60 > release with specific commits merged from trunk. > If you don't want to do a fresh checkout you can do... > >svn switch > https://svn.blender.org/svnroot/bf-blender/tags/blender-2.60a-release/blender > > This will switch the addons repo too. > The "lib/" dir remains unchanged from 2.60. > > > details - incase people want to know whats been changed... > > --- commits from trunk. > svn merge ^/trunk/blender \ >-c41113 \ >-c41117 \ >-c41128 \ >-c41132 \ >-c41134 \ >-c41151 \ >-c41152 \ >-c41175 \ >-c41197 \ >-c41203 \ >-c41211 \ >-c41214 \ >-c41219 > > --- commits from extensions > svn merge ^/trunk/py/scripts/addons \ >-c2494 \ >-c2495 \ >-c2496 \ >-c2504 > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.60 release AHOY
Linux 32/64bit too pete larabell wrote: > FreeBSD builds are up on d.b.o :) > > On Mon, Oct 17, 2011 at 12:58 PM, Ton Roosendaal wrote: >> Hi all, >> >> The last commit has been done! >> >> Tag: tags/blender-2.60-release >> trunk svn revision: 41098 >> extensions revision: 2473 >> >> I'm only available wednesday morning again for doing final download >> page etc, so there's a 30 hour timeframe for discovering showstoppers >> and re-tagging. >> >> The wiki release log has been copied by me to typo3 on blender.org >> already. >> >> SVN is closed now for any non-showstopper commit, thursday it's open >> for development again. >> >> Thanks for all the work :) >> >> -Ton- >> >> >> Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org >> 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 > -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Call for another RC build
Hi. I need to know exact hardware configuration and versions of drivers. Also, does it happen when running blender-softwaregl? Kel M wrote: > Reporting a bug, on Linux, when you start up Blender, the splash screen > displays for a millisecond, and vanishes. Not really a showstopper, but can > cause problems for new users. -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Camera tracking integration review
Hello everyone, Separated some major changes made in tomato branch to made review simplier. Here are links to codereview pages: Movie cache: http://codereview.appspot.com/5283049/ Sensor size: http://codereview.appspot.com/5274047/ Camera tracking: http://codereview.appspot.com/5285047/ Everyone is welcome to help with re-viewing -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Arabic translation support in the UI script
Glad to hear this. And you're welcome =) ValterVB wrote: > Thanks a lot, now is working. > > -Messaggio originale- > From: Sergey I. Sharybin > Sent: Sunday, October 09, 2011 12:38 PM > To: bf-committers@blender.org > Subject: Re: [Bf-committers] Arabic translation support in the UI script > > Nope, it's incorrect. First install python and compile blender. Then: > > (1) blender --background --factory-startup --python update_msg.py > (2) python update_pot.py > (3) python update_po.py > (4) python clean_po.py > (5) python merge_po.py -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Arabic translation support in the UI script
Nope, it's incorrect. First install python and compile blender. Then: (1) blender --background --factory-startup --python update_msg.py (2) python update_pot.py (3) python update_po.py (4) python clean_po.py (5) python merge_po.py ValterVB wrote: > I use these commands: > > D:\BlenderSVN\install\blender25-win64-vc\blender --background > --factory-startup > --python update_msg.py > D:\BlenderSVN\install\blender25-win64-vc\blender --background > --factory-startup > --python update_pot.py > D:\BlenderSVN\install\blender25-win64-vc\blender --background > --factory-startup > --python update_po.py > > Isn't correct? > > Thanks > -Messaggio originale- > From: Sergey I. Sharybin > Sent: Sunday, October 09, 2011 12:03 PM > To: bf-committers@blender.org > Subject: Re: [Bf-committers] Arabic translation support in the UI script > > Hi, > > Looks like you're trying to run update_po script in way like this: > `blender --python update_po.py it`. It's wrong way. Only update_msg,py > is supposed to be run in blender, all the rest script are supposed to be > run using pyton in way like `python update_po.py` > > ValterVB wrote: >> I have some problem to update the po file. >> I have compiled Blender wih SCONS on Win 7 64 bit, I have changed >> update_pot.py for the problem with GETTEXT. >> Some Solution? >> >> In step 1 I have the following error: >> --- >> Written 9165 messages to: 'D:\\BlenderSVN\\blender\\po\\messages.txt' >> Error: Not freed memory blocks: 1 >> RNA_enum_items_add len: 320 034F5A08 >> >> Blender quit >> --- >> In step 2 No error >> >> In step 3 I have the following Message: >> --- >> *** Running 'D:\\BlenderSVN\\blender\\po\\update_po.py' *** >> >> msgmerge --update --backup=none --lang=it D:\BlenderSVN\blender\po\it.po >> D:\BlenderSVN\blender\po\blender.pot >> >> >> >> >> >> >> >> >> >> ........ >> >> .. done. >> read blend: D:\BlenderSVN\blender\po\it >> Unable to open "D:\BlenderSVN\blender\po\it": Unknown error reading file. >> --- > -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Arabic translation support in the UI script
Hi, Looks like you're trying to run update_po script in way like this: `blender --python update_po.py it`. It's wrong way. Only update_msg,py is supposed to be run in blender, all the rest script are supposed to be run using pyton in way like `python update_po.py` ValterVB wrote: > I have some problem to update the po file. > I have compiled Blender wih SCONS on Win 7 64 bit, I have changed > update_pot.py for the problem with GETTEXT. > Some Solution? > > In step 1 I have the following error: > --- > Written 9165 messages to: 'D:\\BlenderSVN\\blender\\po\\messages.txt' > Error: Not freed memory blocks: 1 > RNA_enum_items_add len: 320 034F5A08 > > Blender quit > --- > In step 2 No error > > In step 3 I have the following Message: > --- > *** Running 'D:\\BlenderSVN\\blender\\po\\update_po.py' *** > > msgmerge --update --backup=none --lang=it D:\BlenderSVN\blender\po\it.po > D:\BlenderSVN\blender\po\blender.pot > > > > > > > > > > > > .. done. > read blend: D:\BlenderSVN\blender\po\it > Unable to open "D:\BlenderSVN\blender\po\it": Unknown error reading file. > --- -- With best regards, Sergey I. Sharybin ___ 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 [40780] trunk/blender: Minor: Other UI strings typos and tweaks.
str "Nom de la contrainte" > > #: bpy.types.Constraint.active bpy.types.FModifier.active > #: bpy.types.KeyMapItem.active bpy.types.MeshColorLayer.active > @@ -4274,9 +4251,8 @@ > msgstr "Actif" > > #: bpy.types.Constraint.active > -#, fuzzy > msgid "Constraint is the one being edited " > -msgstr "Déplier le mesh de l’objet édité" > +msgstr "La contrainte est celle éditée" > > #: bpy.types.Constraint.mute bpy.types.ToolSettings.proportional_edit, > #: 'DISABLED' bpy.types.ANIM_OT_channels_editable_toggle.mode, 'DISABLE' > @@ -4300,13 +4276,12 @@ > msgstr "Désactiver" > > #: bpy.types.Constraint.mute > -#, fuzzy > msgid "Enable/Disable Constraint" > -msgstr "Supprimer contrainte" > +msgstr "(Dés)activer contrainte" > > #: bpy.types.Constraint.show_expanded > msgid "Constraint's panel is expanded in UI" > -msgstr "" > +msgstr "Le panneau de contrainte est développé dans l’UI" > > #: bpy.types.Constraint.influence bpy.types.FModifier.influence > #: bpy.types.NlaStrip.influence > @@ -4318,18 +4293,16 @@ > msgstr "Taux d'influence de la contrainte sur la solution finale" > > #: bpy.types.Constraint.error_location > -#, fuzzy > msgid "Lin error" > -msgstr "Miroir" > +msgstr "Erreur linéaire" > > #: bpy.types.Constraint.error_location > msgid "Amount of residual error in Blender space unit for constraints that > work on position" > msgstr "Montant de l'erreur résiduelle en unités Blender pour les > contraintes influant sur la position" > > #: bpy.types.Constraint.owner_space > -#, fuzzy > msgid "Owner Space" > -msgstr "Espace de texture" > +msgstr "Espace propriétaire" > > #: bpy.types.Constraint.owner_space > msgid "Space that owner is evaluated in" > @@ -4338,67 +4311,59 @@ > #: bpy.types.Constraint.owner_space, 'WORLD' > #: bpy.types.Constraint.target_space, > bpy.types.DriverTarget.transform_space, > #: 'WORLD_SPACE' > -#, fuzzy > msgid "World Space" > -msgstr "Espace des normales" > +msgstr "Espace du monde" > > #: bpy.types.Constraint.owner_space, 'WORLD' > -#, fuzzy > msgid "The constraint is applied relative to the world coordinate system" > -msgstr "Aligner les objets nouvellement créés sur le système de coordonnées > du monde" > +msgstr "La contrainte est appliquée relativement au système de coordonnées > du monde" > > #: bpy.types.Constraint.owner_space, 'POSE' > bpy.types.Constraint.target_space, > -#, fuzzy > msgid "Pose Space" > -msgstr "Nom pose" > +msgstr "Espace de pose" > > #: bpy.types.Constraint.owner_space, 'POSE' > msgid "The constraint is applied in Pose Space, the object transformation > is ignored" > -msgstr "" > +msgstr "La contrainte est appliquée en espace de pose, les transformations > de l’objet sont ignorées" > > #: bpy.types.Constraint.owner_space, 'LOCAL_WITH_PARENT' > #: bpy.types.Constraint.target_space, > -#, fuzzy > msgid "Local With Parent" > -msgstr "Avec cibles" > +msgstr "Local avec parent" > > #: bpy.types.Constraint.owner_space, 'LOCAL_WITH_PARENT' > msgid "The constraint is applied relative to the local coordinate system of > the object, with the parent transformation added" > -msgstr "" > +msgstr "La contrainte est appliquée relativement au système de coordonnées > local de l’objet, avec les transformation du parent comprises" > > #: bpy.types.Constraint.owner_space, 'LOCAL' > #: bpy.types.Constraint.target_space, > bpy.types.DriverTarget.transform_space, > #: 'LOCAL_SPACE' > -#, fuzzy > msgid "Local Space" > -msgstr "Espace des normales" > +msgstr "Espace local" > > #: bpy.types.Constraint.owner_space, 'LOCAL' > msgid "The constraint is applied relative to the local coordinate sytem of > the object" > -msgstr "" > +msgstr "La contrainte est appliquée relativement au système de coordonnées > local de l’objet" > > #: bpy.types.Constraint.is_proxy_local > -#, fuzzy > msgid "Proxy Local" > -msgstr "X local" > +msgstr "Local proxy" > > #: bpy.types.Constraint.is_proxy_local > msgid "Constraint was added in this proxy instance (i.e. did not belong to > source Armature)" > msgstr "La contrainte est ajoutée dans l'instance de proxy (n'appartient > pas à la source Armature)" > > #: bpy.types.Constraint.error_rotation > -#, fuzzy > msgid "Rot error" > -msgstr "Réflexion Ray" > +msgstr "Erreur de rotation" > > #: bpy.types.Constraint.error_rotation > msgid "Amount of residual error in radiant for constraints that work on > orientation" > msgstr "Taux d'erreur résiduelle en radians pour les contraintes qui > fonctionnent sur l'orientation" > > #: bpy.types.Constraint.target_space > > @@ Diff output truncated at 10240 characters. @@ > ___ > Bf-blender-cvs mailing list > bf-blender-...@blender.org > http://lists.blender.org/mailman/listinfo/bf-blender-cvs -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Bump maps flip
Hi, Because of history question black and white colors in bump maps were flipped in Blender so white used to mean concavity, black used to mean salience. Now it was flipped so white means salience and black means concavity. We suspended this change for before 2.60 but now it's time for this change. I've wrote code which flips normal factor for files created in Blender before this change, so this change shouldn't hurt render result. But some issues are known: if you now open file saved by current trunk in, say, Blender 2.59, you'll have wrong render result in 2.59. You can do everything needed in 2.59, save file and open it it current trunk and render result should be fine again. Let me know if some special cases are still wrong and it'll be fixed. Thanks to Morten for patch and Ton for finishing this patch. -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Arabic language support in the UI
Hi, Yousef Hurfoush wrote: > another issue is the current Droid font which lacks some Arabic characters, > here is an UPDATED one i tested and it's OK > https://sourceforge.net/p/batp/code/24/tree/tools/DroidSansArabic.zip DroidSansArabic was merged into current font used for international interface. Probably you're using a bit more recent version, but i need re-doable example of onterface for tests. > here is a test picture of the current and the new fonts > http://www.pasteall.org/pic/18492 Looks like you've got a bit more full translation file which isn't in our repo. Can you share updated ar.po file so we can easily test fonts (or tell how to produce such file from your repo)? -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] 【i18n】JP's latest po file
Hi, Commited to revision 40571. Can't verify it so please test newer build of Blender and tell if something went wrong with translation. "志築 孝広 [Takahiro Shizuki]" wrote: > Hi, > > As talked with kaito on IRC, > I uploaded latest ja.po. > http://www.futuregadget.com/ja.zip > > Could you please commit as "/trunk/blender/po/ja.po"? > (If there are some mistakes in English, I'd like to apologize.) > > Best regards, > shizu > > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender developer meeting, 25 september 2011
Hi, Ton Roosendaal wrote: > - We need reviewer(s) for "Oceansim" for 2.61! > > - Dynamic Paint GSoC project: is ready for review too. Think i can assist with re-viewing but not ready for maintaining this changes -- just code/design review. -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] linux compile error
/AUD_FFMPEGFactory.o] > Error 1 > scons: *** > [/home/interlichtspielhaus/build/linux/intern/audaspace/ffmpeg/AUD_FFMPEGReader.o] > Error 1 > scons: building terminated because of errors. > > > any help with this one ? > > thanks > inS > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] UI Text Strings :: some missing "J" 's
Hi, Can't confirm on linux 64bit, windows 64bit, windows 32bit. There was no global replacements or things like this. Default procedure -- provide all default information for bug report: operation system, exact svn revision, hardware specifications and so. Help -> System Info can help you with collecting needed information. Mike S wrote: > Hi all, > > not able to look at it myself at the moment... but there seem to be some > missing "J" in the UI text. (Blender trunk and cycles) > > Specifically :: > > 3D View -> Object -> (J)oin and (J)oin as UV missing the capital J > > Also noticed that in the User Prefs ->System-> International > Fonts->Language pulldown the choice for Japanese has the missing capital "J" > > Perhaps some global search/replace went wrong? > > Mike. > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Font Workaround
Hi, It would work fine for english locale only. For most of other languages new droid font is a requirenment. I'll try to define new ui style which will be used only if "International Fonts" is checked on. K M wrote: > Blender works just fine without the font folder. It's just there to override > the build font. > > * > * > *"*It's in the to-do list to implement an option in the interface to pick > your > > own font. > In the mean time, as you found out, you can either: > > 1) delete the font (to roll back to the bfont) > 2) pick a new font (2.1) gzip compress it to a file named > droidsans.ttf.gzhttp://www.pasteall.org/pic/show.php?id=18225 > > *) Note the font inside the gz file can have any name. It doesn't even need > to be ttf (it works with ttc and otf as well) > > "Apparently, there's a "font" folder in the Datafiles folder that should not > be there" > ? The font should be there, otherwise Blender can't use it. > > " > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] i18 project pre-merge review
Hi, Also, always make sure you're using latest libs. I've updated them for windows some time ago. Dalai Felinto wrote: > Hi Xiao, > > The only difference with my old win32 and now is that I'm now building with > Collada. > In fact to build Blender32 with Collada I had to install: > - "msvc9 feature pack 1 vs 2008" (my computer didn't have TR1 Support. > > Nathan Letwory would know better (he is the one who suggested me to install > this pack). But I suspect this is the problem. > > I was going to build a win32 garlic with no collada, but it seems that the > Chinese .mo was updated from an outdated .po or so: > http://pasteall.org/25011 > > Another option is to delete your startup.blend file. Sometimes the problem > is there. Is the 64build working for you? Here both work. > -- > Dalai > > 2011/9/19 xiangquan xiao > >> I just cannot startup the program on win32. It crashed without any >> infomation. >> >> Someone has reported this in blender-translation actually. It seems fine >> for >> me at that time, but now I got into the same situation. >> Maybe we both lack something in our system? >> >> 2011/9/19 Sergey I. Sharybin >> >>> Hi, >>> >>> Looks like all issues Dalai and Thomas pointer recently are solved. >>> There are some things i want to happen before merge: >>> >>> - New font have to be confirmed as not worse in charsets coverage. I >>> need native speakers to check because i can't actually say if all chars >>> are fine now (especially in chinese language). Xiao, can you help with >>> this? >>> - I want Campbelland/or Brecht review garlic branch before merge. I hope >>> there's no issues but extra review wouldn't hurt. >>> >>> -- >>> With best regards, Sergey I. Sharybin >>> >>> ___ >>> 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 > -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] i18 project pre-merge review
Hi, Looks like all issues Dalai and Thomas pointer recently are solved. There are some things i want to happen before merge: - New font have to be confirmed as not worse in charsets coverage. I need native speakers to check because i can't actually say if all chars are fine now (especially in chinese language). Xiao, can you help with this? - I want Campbelland/or Brecht review garlic branch before merge. I hope there's no issues but extra review wouldn't hurt. -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Going to GPLv2+
Hi, We discussed possibility of bundling droid fonts into blender installer and release archived yesterday. Problem that droid fonts are under Apache2.0 license which is compatible with GPLv3, and not compatible with GPLv2. So looks like using this fonts would make final archive GPLv3. It's not really so big issue, but all sources should be licensed by GPLv2+ license. I've made some quick check and found this list of files which i'm not sure are under GPLv2+ compatible license: - source/blender/blenkernel/intern/CCGSubSurf.c - source/blender/blenkernel/intern/sound.c - source/blender/editors/uvedit/uvedit_parametrizer.c - source/blender/editors/sculpt_paint/paint_utils.c - source/gameengine/GamePlayer/xembed/npunix.c Would be nice to have respond from authors of this files if they're fine with GPLv2+ license. P.S. It was really quick check so probably some more files should be verified, i'll make deeper check soon. -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Issues with Garlic Branch
Hi,
Thomas Dinges wrote:
> Hey,
> I tested a bit, some things I noticed:
>
> -Enable International Fonts in the User Preferences
>
> 1) Although Interface and Tooltips is disabled, some enums already
> translated, for example the 3D View mode menu. I guess this is because those
> buttons are not using the Layout Engine/ RNA.
Yes, noticed this issue this night but it was really late at night so
didn't want to fix it. Problem that this menus are "hardcoded" -- they
aren't using RNA at all and it's just bunch of sprintf with
gettext("blahblah") which produces string to create menu. It's really
easy to fix.
> 2) Same as above (Interface and Tooltips off) The Panel Names look odd, like
> " i e sio s" instead of "Dimensions" (Render Buttons)
It's strange. Probably windows-related issue, can test it a bit later.
Can't reproduce issue on linux. Which language produces this problem?
> 3) There are some square symbols in the language menu (French
> (Fran*sqare*aise))
>
> I used the latest x64 win build from Dalai. 40311
I hope it should be fine now -- i've updated font.
--
With best regards, Sergey I. Sharybin
___
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 [40308] branches/soc-2011-garlic: i18n: replace gnu unifont with droid sans font
Hi, Dalai Felinto wrote: > Some of the missing glyphs: ñ (you can see this in the "Español" (Spanish) > option in the UI). ç (missing in the Française option). > They are other missing characters visible from the Language selection ui as > well. Should be fine now > Note 2: once we are done with this change would be nice to get rid of bfont > (i.e. to use DroidSans as the Font Object font). > Note 3: ideally we should use the DroidSansMono for the TextEditor, what do > you think? I remember trying it but the character spacing were all messed up > when code syntax was on (I think we have hardcoded values there). Yes, this would be cool, but i don't think it's a goal of garlic before merge. -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] C++ in Blenders Kernel lib (Nav mesh)
Hi, I'm not also fan of having C++ in kernel. Not sure if this navmesh_conversion can be can be easily moved to intern/ -- it uses DNA_meshdata_types and DerivedMesh structures. Was thinking about C-API for recast library, soblender kernel can easily use it. There's at leats one more file which confuses me -- MOD_navmesh.cpp. Think it's better to make it C too. I can try to get rid of this C++ today-tomorrow. Campbell Barton wrote: > Recent navmesh commit adds C++ into blenkernel - > source/blender/blenkernel/intern/navmesh_conversion.cpp > > Until now we didn't have C++ in core libs, so not sure if this is acceptable? > - or what we should do now its in. > > The file is only 450 LOC and doesn't use C++ classes or functionality which > is tricky to convert, the main thing holding it back from going to C is > Recast.h which has initializers inline with structs. > > While I'm not up on C++, to me there seems to be 2 options. > 1) Make Recast.h C compatible, convert navmesh_conversion.cpp to C code. > 2) move navmesh_conversion.cpp into its own lib and have a C API (for such a > small file this is overkill but at least means no mixing C/C++). > > #2 is most straightforward, we can have intern/navmesh and arrange much the > same was as ghost. > > Any comments?, anyone want to put their hands up to do this? :) > > ... or do we just not bother and have C++ in blenkernel? > -- With best regards, Sergey I. Sharybin ___ 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 [40189] trunk/blender: fix compilation for MinGW by substituting qsort_r with qsort.
one of places which uses qsort_r is in extern/, so it can't use BLI. Ofcourse this qsort_r can be placed to extern/ but i don't think it's nice. IMO, better to update recast library. Αντώνης Ρυακιωτάκης wrote: > This is glib's code for qsort: > > http://sourceware.org/git/?p=glibc.git;a=blob;f=stdlib/qsort.c;h=b19e86ece1b576616a1ce5784065071c6da0ba22;hb=ee4d03150a65018f367e3250887ec9c5b2133ce4 > > A modification to something like BLI_qsort_r can't be too hard. > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey I. Sharybin ___ 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 [40189] trunk/blender: fix compilation for MinGW by substituting qsort_r with qsort.
reByData,&context); > #elif defined(__APPLE__) || defined(__FreeBSD__) > qsort_r(trisMapping, ntris, sizeof(int),&context, compareByData); > +#elif defined(FREE_WINDOWS) > + _mingw_context =&context; > + qsort(trisMapping, ntris, sizeof(int), compareByData); > #else > qsort_r(trisMapping, ntris, sizeof(int), compareByData,&context); > #endif > > ___ > Bf-blender-cvs mailing list > bf-blender-...@blender.org > http://lists.blender.org/mailman/listinfo/bf-blender-cvs > -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Branch merging and buildbot - propose to change build cycle
Hi, Nathan Letwory wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Indeed, but it happens regularly that builds break on different platforms, > and even more so because developers *don't build with all features enabled* > (while in theory they should always verify the entire build before doing any > commits). > > Sure, triggering manually is a way, but it is even better to not have to do > that. Developers are lazy beings (hence they are developers). > > With the amount of developers that we have commiting I think its especially > nice if our buildslaves would just build the moment they don't have anything > to do and are notified of changes. Well, just triggering isn't enough. It wouldn't make developers check buildbot logs, IMO. It should also punish developers who breaks something. Or at least notify them. -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Branch merging and buildbot - propose to change build cycle
Hi, Not sure having this behavior always is nice. It's not really needed when you aren't merging and when you're doing merge, you can trigger re-build easily. And there's no need to rebuild Windows build when you're solving issues with Linux platform. About linux slaves.. Looks like there's no version of qsort with one additional argument to callback (like qsort_r and qsort_r) in older versions of libc. We've got two occurrences of this call - one in our navmesh_conversion.cpp and another in recast library. This function isn't used in current raycast svn and i think it can be easily replaced with own implementation of qsort for navmesh_conversion.cpp. Btw, why we've got C++ source in blenkernel? I heard it's because of recats is writtein in C++. But in this case we're writting C-API and storing it in extern//_C-API.c. Nathan Letwory wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi all, > > With the recent amount of branch merging and the amount of post-fixing > it generated, some of it due to different platforms in use by developers > I'd propose to change buildbot to build more often, even on per-commit > basis. This would allow developers to see pretty easy how their work > behaves with all necessary logs available. We know that many developers > turn of lots of features while working on their own beautiful little > garden, sometimes resulting in clipping of nice flowers from other > developers (blenderplayer, cross-platform code, etc.). > > Buildbot is running very well currently and gives useful output, but for > developers the nightly cycle can be too long to wait for. Changing to > build-on-change will make buildbot much more useful. Buildbot output > should become mandatory part of toolset of developers, with the proposed > change it will make actually sense too. > > /Nathan > > ps. right now linux builds both failed due to navmesh code ( > http://builder.blender.org/grid ) > > - -- > Nathan Letwory > Letwory Interactive | Studio Lumikuu > http://www.letworyinteractive.com | http://www.lumikuu.com > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJObaKIAAoJEKtfN7KsE0TtnUcIAKdyAFUyEUWKg1BjcjsrKNTb > pGwvSEJXB/31Afu2LddMosMVVhQO5pEyUpKEwdol2EVqdNeVl88Jto7m/sP9OJUi > ILe8UXrabSyHzOWtiJR0kCsAt83XVsJ+ztL1ijCw27K0Q2kJvAjKLM3GF1/7vrFl > taWZg3SWTEPvQXBJhkJE2thT+EzJ9pwlk0ADEaZCwFKep18bA+TZroMvugmT166f > EMGH046UNhZ4VroL54WUETLNYboCjSspAtZXtPo2NLadLWgMUdDLgAclw5YKUXnz > TeJvfI/d822OUAnZeaBwp/zgsZTZRVLX62jU5Gk6v/s9/lZSrHP4BWJxYFoUydQ= > =f4VP > -END PGP SIGNATURE- > _______ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] i18n branch (garlic) review
Hi,
xiangquan xiao wrote:
> 2011/9/8 Sergey I. Sharybin
>
> - Unnecessary checks in BLF_gettext. msgid shouldn't be NULL here and
>> msgid[0] != '\0' is faster than strlen(msgid)
>>
> These checks didn't exist before, but once I got segment fault there because
> of NULL pointer. Then the checks was added, and errors gone.
I'd prefer to discover case when it's NULL. Looks more like exception
which should be handled in callee function. IMO. Will check this.
>> - In BLF_lang_set(). I think setting locale to smth.UTF-8 should be called
>> first. I.e. in my case locale ru_RU doesn't use UTF-8 codepage -- it uses
>> ISO-8859-5. So i've got errors about invalid utf8 sequences in py scripts
>> when setting locale to ru_RU.
> It's right. I took a look at the "Battle of Wesnoth", which tries set locale
> along with XXX, XXX.UTF-8, XXX.utf-8. So I wrote my code like this.
Hrm. Maybe it'll also fail here. Will check :) And probably it's just
python codec issue -- maybe strings should be encoded from ISO-8859-5 to
UTF-8 before passing them to python =\
Will check.
>> - Not sure about UI_GetStyle function. Looks liek something unfinished.
> I noticed that U.uistyles is a list of uistyles, but nowhere seems to choose
> one based on users' setting. Only in
> source/blender/editors/interface/interface.c
> there is a line saying:
> uiStyle style= *((uiStyle *)U.uistyles.first);// XXX pass on as arg
> We just always use the first style.
>
> In an early version I load unifont as a uistyle after the default one, and
> use UI_GetStyle("Unifont") to get it if an utf8 language is in use. If only
> Latin characters are used, unifont.ttf will not be loaded. This seems memory
> saving.
>
> Later I remove this feature, because the language-selection dialog always
> needs utf8 fonts. The I just load unifont.ttf as the default uistyle, and
> UI_GetStyle() only return the first uistyle as before.
>
> Anyway, in my opinion, UI_GetStyle() is somewhere to get uistyle as users'
> wish, especially after font-selection feature added. If so, another field
> should also be added to the global UserDef.
Just tried to make changes more local. Probably it's ok to have this
function.
>> - Numbers+plurals
> ?
For example: "removed %d vertices". It'll be tricky to translate it to
russian because of case. There was gettext stuff to deal with this
situation.. Not really issue, just not perfect :) I was collecting all
possible issues. I'll let you know when i remember this stuff..
>> - RNA_enum_items_gettexted. Can't it be handles on more lower level?
>> - RNA_types_init_gettext. Dislike list of structures, maybe we already got
>> list of structs somewhere?
> In rna_XXX_gen.c, the properties are actually linked as lists. So I just
> played a trick, maybe ugly.
>
>> - WM_read_homefile(). Is it still have to be splitted?
> Yes, we still need to do these:
> 1. read user def
> 2. init language setting
> 3. init some UI components
> So 1 and 3 are splitted and 2 inserted.
Can't remember source now.. So issue that some UI stuff was made in
WM_read_homefile ?
>> - Language is changing globally. So there's no way to translate only
>> tooltips (like it was in 2.49)
> Add another mark, like T_("tooltip")? Switch off other marks( _ and N_ ),
> then only tooltips translated.
This can work, yes.
Was doing bug-tracker today, not much time for i18n. Will continue tomorrow.
--
With best regards, Sergey I. Sharybin
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] i18n branch (garlic) review
Hi, Made some code checks and collected all found questions/issues: - .Blanguages file is no longer used? - Unnecessary checks in BLF_gettext. msgid shouldn't be NULL here and msgid[0] != '\0' is faster than strlen(msgid) - In BLF_lang_set(). I think setting locale to smth.UTF-8 should be called first. I.e. in my case locale ru_RU doesn't use UTF-8 codepage -- it uses ISO-8859-5. So i've got errors about invalid utf8 sequences in py scripts when setting locale to ru_RU. - blenfont is added as dependency to all editors.. - Not sure about UI_GetStyle function. Looks liek something unfinished. - Numbers+plurals - RNA_enum_items_gettexted. Can't it be handles on more lower level? - RNA_types_init_gettext. Dislike list of structures, maybe we already got list of structs somewhere? - WM_read_homefile(). Is it still have to be splitted? - Language is changing globally. So there's no way to translate only tooltips (like it was in 2.49) Regarding to that _ and N_ macroses. I think it's easy to write operator which will ise kinda DFS and collect all strings used by operators and RNA. In this case BLF dependency would be avoided for editors and py scripts wouldn't be touched. And it can be helpful for case of instant language switch (i.e. Dalai told it can be helpful). But it'll need gettext stuff called on draw. Not sure how slow it'll be. Didn't think much about ways of solving this issues yet, will let you know when got new thoughts on this. -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Fixed garlic's setenv problem on windows
xiangquan xiao wrote:
> Just use gettext_putenv() instead of BLI_setenv().
> Now running blender.exe could change languages freely.
That's how it worked before and how it works in some other apps i've
checked.
> But it's strange I got errors below on linux when opening the User
> Preference:
>
> X Error of failed request: BadMatch (invalid parameter attributes)
>Major opcode of failed request: 155 (GLX)
>Minor opcode of failed request: 11 (X_GLXSwapBuffers)
>Serial number of failed request: 5414
>Current serial number in output stream: 5415
>
> Maybe it's just my system's fault I think.
This happens for me after `apt-get upgrade` when mesa libs are updating.
I have to re-install nvidia driver after this.
>
> About the instant-update of language, we have discussed on IRC. We thought
> the existing notifier cannot change language instantly because the string
> pointers should change. e.g.
> The old _("good") points to "好", while the new _("good") points to "Bonne"
>
> So we think it OK to force users to restart, as language switch will happen
> rarely.
>
>
>
I think for first time it's ok. And probably we can write operators/ui
re-register function (something like scripts reload operator).
Another solution is to make gettext on-display call. But there are some
issues with this:
- Strings for translation can't be collected automatically
- It'll make draw code slower.
Don't think instant language change worth it.
> Then if we cannot get rid of setenv, then so be it.
I've checked gettext documentation and some sample applications where
gettext is used and in each case when translation to non-system locale
was needed, it was the same trick with environment variables. It's just
how gettext works.
We can get rid of this, but it'll require re-writting gettext which i
don't think worth this.
What's the problem with environment variables (after latest Xaio's fix
for windows)?
--
With best regards, Sergey I. Sharybin
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] FFmpeg update instructions
Hi, Yes, it's totally ok. Actually, it's what i wanted to add just you was first :) And i suppose there should be something the same for redhat-based distros like fedora or altlinux. But i'm not actually familiar with this distors so can't actually suggest anything for them. Bastien Montagne wrote: > Hi Serguey, > > I added (the start of) a section about repositories featuring ffmpeg > packages of the right version. For now, there’s just > debian-multimedia.org, which has 0.8.2 for oldstable, stable, testing > and unstable! But I’m sure there are other repos for other distros as > well ;) > > Hope it’s OK with you… > > Cheers, > Bastien. > > Le 02 Sep 2011 20:29:28 +0600, "Sergey I. Sharybin" > a écrit : >> Hi, >> >> I've tried to write a short HOWTO about updating FFmpeg on linux >> platform to be able to compile Blender easily with new proxies stuff. >> >> Here's link to this doc: >> http://wiki.blender.org/index.php/User:Nazg-gul/FFmpegUpdate >> >> I'm almost sure additional changes are needed, but it should be useful >> already. Feel free to contact me about things i've forgot to mention >> there or if you're commiter feel free to update this page. > ___________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] FFmpeg update instructions
Oops. Right. I've plenty times run intothis issue but still continues doing this stupid thing. Thanks again for fix :) Ejner Fergo wrote: > Hi again! > >>> Create a .conf file in /etc/ld.so.conf.d/ (for example ffmpeg.conf) >>> containing the line: >>> /opt/ffmpeg-0.8.2/lib >>> and then run (as root): >>> ldconfig >> Yeah, this can be helpful. > Unfortunately you can't redirect an output with sudo, so instead of: > sudo echo "/opt/ffmpeg-0.8.2/lib"> /etc/ld.so.conf.d/ffmpeg.conf > you can use this command instead: > echo "/opt/ffmpeg-0.8.2/lib" | sudo tee -a /etc/ld.so.conf.d/ffmpeg.conf > > Best regards, > Ejner > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] FFmpeg update instructions
Hi, Thanks you all for feedback. Some answers are inlined. Ejner Fergo wrote: > Hi Sergey, > > Just some points I noticed: > > Where you write > "To use this libraries create the lib/ folder near the folder which > contains blender sources" > and later > BF_FFMPEG = "../lib/linux/ffmpeg" > > I know what you mean, but there may be others that just copy/paste > that relative path but have not checked out the libs at the right > place. Maybe it could be spelled out a bit more: > "To use these libraries create the lib/ folder in the dir containing > the blender source dir" > or something like that, or maybe even > BF_FFMPEG = "/path/to/cloned/lib/linux/ffmpeg" I've write where libs should be cloned. Also, i've just added illustration how directory structure should looks like. > Another thing I've helped some users with, is when compiling ffmpeg be > sure to have the libs in the library search path. This ensures you > don't get a message like "missing libavformat.so.53" when trying to > start blender. In your example: > > Create a .conf file in /etc/ld.so.conf.d/ (for example ffmpeg.conf) > containing the line: > /opt/ffmpeg-0.8.2/lib > and then run (as root): > ldconfig Yeah, this can be helpful. > > Last thing, you have ffmpeg-0.8.1 in places where it should say 0.8.2 Already fixed :) > > Hope the above makes sense. > > Best regrads, > Ejner > > On Fri, Sep 2, 2011 at 4:29 PM, Sergey I. Sharybin wrote: >> Hi, >> >> I've tried to write a short HOWTO about updating FFmpeg on linux >> platform to be able to compile Blender easily with new proxies stuff. >> >> Here's link to this doc: >> http://wiki.blender.org/index.php/User:Nazg-gul/FFmpegUpdate >> >> I'm almost sure additional changes are needed, but it should be useful >> already. Feel free to contact me about things i've forgot to mention >> there or if you're commiter feel free to update this page. >> >> -- >> With best regards, Sergey I. Sharybin >> >> ___ >> 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 > -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] FFmpeg update instructions
Hi, I've tried to write a short HOWTO about updating FFmpeg on linux platform to be able to compile Blender easily with new proxies stuff. Here's link to this doc: http://wiki.blender.org/index.php/User:Nazg-gul/FFmpegUpdate I'm almost sure additional changes are needed, but it should be useful already. Feel free to contact me about things i've forgot to mention there or if you're commiter feel free to update this page. -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Collada does not compile anymore
; error: 'IndexListArray' does not name a type > C:\BlenderSVN\lib\windows\opencollada\include\COLLADAFramework\include/COLLADAFWMeshPrimitive.h:237:35: > error: 'IndexList' has not been declared > C:\BlenderSVN\lib\windows\opencollada\include\COLLADAFramework\include/COLLADAFWMeshPrimitive.h:242:9: > error: 'IndexListArray' does > not name a type > C:\BlenderSVN\lib\windows\opencollada\include\COLLADAFramework\include/COLLADAFWMeshPrimitive.h:247:15: > error: 'IndexListArray' does not name a type > C:\BlenderSVN\lib\windows\opencollada\include\COLLADAFramework\include/COLLADAFWMeshPrimitive.h:252:9: > error: 'IndexList' does not name a type > C:\BlenderSVN\lib\windows\opencollada\include\COLLADAFramework\include/COLLADAFWMeshPrimitive.h:261:15: > error: 'IndexList' does not > name a type > C:\BlenderSVN\lib\windows\opencollada\include\COLLADAFramework\include/COLLADAFWMeshPrimitive.h:270:37: > error: 'IndexList' has not been declared > C:\BlenderSVN\lib\windows\opencollada\include\COLLADAFramework\include/COLLADAFWMeshPrimitive.h: > In member function 'bool COLLADAFW::MeshPrimitive::hasColorIndices() const': > C:\BlenderSVN\lib\windows\opencollada\include\COLLADAFramework\include/COLLADAFWMeshPrimitive.h:232:42: > error: 'mColorIndicesArray' > was not declared in this scope > C:\BlenderSVN\lib\windows\opencollada\include\COLLADAFramework\include/COLLADAFWMeshPrimitive.h: > In member function 'void > COLLADAFW::MeshPrimitive::appendColorIndices(int*)': > C:\BlenderSVN\lib\windows\opencollada\include\COLLADAFramework\include/COLLADAFWMeshPrimitive.h:237:63: > error: 'mColorIndicesArray' > was not declared in this scope > C:\BlenderSVN\lib\windows\opencollada\include\COLLADAFramework\include/COLLADAFWMeshPrimitive.h: > In member function 'void > COLLADAFW::MeshPrimitive::appendUVCoordIndices(int*)': > C:\BlenderSVN\lib\windows\opencollada\include\COLLADAFramework\include/COLLADAFWMeshPrimitive.h:270:67: > error: 'mUVCoordIndicesArray' was not declared in this scope > C:\BlenderSVN\lib\windows\opencollada\include\COLLADAFramework\include/COLLADAFWMeshPrimitive.h: > In member function 'bool COLLADAFW::MeshPrimitive::hasUVCoordIndices() > const': > C:\BlenderSVN\lib\windows\opencollada\include\COLLADAFramework\include/COLLADAFWMeshPrimitive.h:273:44: > error: 'mUVCoordIndicesArray' was not declared in this scope > In file included from > C:\BlenderSVN\blender\source\blender\collada\/ArmatureImporter.h:46:0, > from > C:\BlenderSVN\blender\source\blender\collada\AnimationImporter.cpp:52: > C:\BlenderSVN\blender\source\blender\collada\/MeshImporter.h: At global > scope: > C:\BlenderSVN\blender\source\blender\collada\/MeshImporter.h:106:18: error: > 'COLLADAFW::IndexList' has not been declared > C:\BlenderSVN\blender\source\blender\collada\/MeshImporter.h:109:17: error: > 'COLLADAFW::IndexList' has not been declared > mingw32-make[2]: *** > [source/blender/collada/CMakeFiles/bf_collada.dir/AnimationImporter.cpp.obj] > Error 1 > mingw32-make[1]: *** [source/blender/collada/CMakeFiles/bf_collada.dir/all] > Error 2 > mingw32-make: *** [all] Error 2 > > Greets > Peter > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender Release Cycle
Campbell Barton wrote: > @Nicholas Bishop, +1 for you're suggestions for how to apply changes from a > branch in steps. I'll agree with this. > @Matt, +1 on you're extended items to my initial list - all features in a > branch Im not against either but need to use some common sense here, some > cases this could just be impractical - when to branch, when to share branch, > which feature is so small its not needed etc. As Thomas wrote already, not every new feature should have a branch. Most of developers are commiting almost finished features (almost in terms some additional testing could discover bugs, branches would be affected with the same problem before merging to trunk). We also have got code review which is useful, imo. But we need to be more active there to review patches (simple sample -- i've sent patch there a week ago and still have got no feedback). > @Michael Fox, I find the tone in you're last mail odd and totally not my > impression of the state of blender, I'm interested to know if this is only > you're POV or if many devs/users are thinking this??? > > Reply to 2 points... > > - Blender bug tracker has more bugs because more people are testing blender!, > many bugs that are fixed are not reported so infact the number of bugs in the > tracker should be much higher, and 6months back should have been 100's more > then it was. I'll agree with Campbell here. Some of friends of mine haven't used blender until 2.57 because it was alpha/beta. And i think it's not only my friends (which i know personally) used to think in the same way. > - Regarding "not calling bugs show-stoppers belittling users reports", and > that _any_ bug could be a showstopper eeeh, well yes - of course any bug > can be a showstopper but the line has to drawn somewhere, else we just end up > in release paralysis, I think it should be enough that we try fix bugs when > we find time, holding back a release means users who stick to stable builds > are not getting the fixes we HAVE done, think we just have to try use our > best judgment here. IMO showstopper is only bug which was added in release cycle and which prevents general use case. If bug was in previous cycle or it happens only on special case which isn't so general, then it could be treated as non-stopper. If bug was already in tracker then most probably it wasn't fixed because it's not so critical. If bug was discovered just before release -- i also don't think it was so critical -- otherwise it was already reported (but ofcourse exceptions of this rule happens and we'll handle them). It it's impossible to fix all bugs before release. And i'll also agree with Campbell -- we need that line to know when to release. We aren't so lazy and we're fixing hundreds of bugs each release and adding new features. IMO, it's what users want -- they don't want to wait year or so to have 100% bugless Blender. > @Knapp, don't think comparing blender to kubuntu makes sense in, a collection > of packages and a single software project are very different - Enough distros > manage to get this right so expect they have internal troubles getting enough > maintainers or quality of packages. Linux distro is more a ecosystem which should be stable and predictable and it doesn't release so often. Blender is more a tool so it could be releases more often. We just have to pay a bit more attention of code review for fixes/features to prevent regressions and each next release will bring users bugfixes and new features (which i hope wouldn't have serious problems). > @ *DVCS Issue*, think this is a bigger topic and I'm worry that everyone just > agrees DVCS is awesome, this thread fizzles out and nothing happens. > > DVCS asside we still need to settle on what to do for the release cycle, and > until we do the actual switch to DVCS - or state that some git-svn > combination (for eg) is the way-to-go, we still should set some policy on > merges as Matt and I are suggesting. > > Last I checked moving to DVCS (GIT actually) needs some experienced admin > with time to devote to managing issues with large binary files we have in SVN > so I think we first have to find this person to show its even something we > can pull off. DVCS is nice for code. We have also got libs/regressions tests which are quite large binary repos. Lats time i've tested git it wasn't handling this repos well (but i use git-svn for source tree which works pretty nice). I'm nto such guru of git to tell solution for this problem. But IMO we'd peter host all repos in the save VCS system. Otherwise it'll be more like a chaos and wouldn't be so useful. -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Blender Release Cycle
Hi, devs! We've already got thread about release cycles, but it was a bit long and seems like there's no final decision made. We've discussed that proposal with Campbell and also investigated why we've run into some problems with current release. There are some comments which i'd prefer be final decision about our release cycle (most people are already ok with it, just to make things 100% clear). Few first weeks of cycle (B-Con 1 and B-Con 2) aren't so critical for this discussion and we've already agreed with this levels. More critical to make work clear in few weeks (1-2) before release (i mean before starting commiting new splash/changelogs and so). What is needed there: - Only _critical_ bugs should be fixed. Critical doesn't mean "i can make blender crash in few clicks" but it mostly means this bug was introduced in current cycle and it stops normal workflow. If this bug was present in previous release or if it's not making general usage unusable we'd prefer to keep this bug untouched. Fixing such bugs wouldn't make real sense on general workflow and if it wasn't noticed in previous release then it doesn't annoy artists. But fixing such bugs easily produces new bugs which difficult to predict and we wouldn't have enough time to test everything. - We need clear "FREEZE" and "UNFREEZE" AHOYs. If freezing will happen a bit earlier -- it's not so critical. But unfreezing should be done quite accurate -- when everybody who is familiar with making release would say it's ok to unfreeze. - We'll need tag for every release. It should be created even for "initial" release (not corrective release like 'a' or 'b' releases). this is needed to make platform maintainers' life more clear. If stopper is discovered during archive preparation, fix for this stopper can be easily commited to trunk and merged to tag. It'll help a lot for release process when most of core/BF developers are offline -- no need to wait someone to prepare archive. - Most probably we'll need guy who is familiar with svn who will make tag and solve possible issues of platform maintainers. It shouldn't be "constantly" defined developer, prefer to choose one for each release -- it's needed to be sure he can be available during release. - So, FREEZE happens, new tag is creating and AHOY could happen. Day or two after this normal life of trunk could be restored. But _nobody_ should commit anything than fixes for stopper/fixes for build environment until _official_ unfreeze. Even commit of stylefix could be confusing in the future (if more serious problem was discovered, i.e.). - If 'a' release is needed, we shouldn't re-tag. We should merge fixes for _stoppers only_ into tag and do not include fixes for all bugs which were made since release. This is a way to avoid 'b' releases. So, short summary: fix only _really_ critical bugs last week before release-related commits; make clear FREEZE/UNFREEZE messages in ML. create tag for release just before AHOY, if 'a' release is needed only stoppers for previous release (for which 'a' is creating) should be ported into tag. I hope only Campbell/Ton/Brecht make minor changes to this message or write things i've forgot to tell about. But again. i don't want this message start new discussion thread and i hope it'll be final decision now. -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.59 release AHOY!
I don't think way of fixing discovered bug _so_ bad. There were several crashes there in 2.58 and there was no report in tracker about this -- users simply not using this tool much or using them in safe way. And disabling things which can be unstable ,we can be sure there's no hidden problems and this allows to make release more stable. Jass wrote: > Why don't you just shift the release date (by one week for example), fix the > issues as needed and keep trunk frozen for that period ? Wouldn't that help > to get out an excellent release and avoid to push out 2.59b one week after > 2.59 was released ? -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.59 release AHOY!
Hi, I've got fix for grease pencil in mu branch [1], but it's really that kind of changes which shouldn't be applied in last minute (at least there are several possible issues i wanted to check), so let's limit GP a bit for 2.59. About reloading scripts and so. I've been working on UI in my branch after merging ghash changes there and haven't found any bad sides of this change. About more clear release next time. I'm not sure why this release is so "crazy". Is it our lag, lag of coordination or so.. [1] http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=39313 P.S. linux 32/64 bit would be available soon. Campbell Barton wrote: > Hi, woke up to find a re-release from a revision that contains changes > I made that were *not* intended to be in a stable release - switching > operators and menus to hash lookups. > We should have branched at r39259 stable and applied patches there > before re-releasing. > > > There is also the issue with grease pencil session - where the > operator points to data that can be freed on 'Global Undo' (as opposed > to the crasher with the modal operators own *fake* undo, fixed 39237 > and double undos fixed 39235). > > Sergey's fix means you can't move the viewport while grease pencil > session is enable so the option is now not at all working as it was > meant. > > *Sigh* > Since there were 3 fairly bad bugs in this tool (2 crashers), my > impression is that option isn't used all that much. > A correct fix isn't some small edit, the operator must store data > differently, this should have been picked up during normal > development, IMHO we should not attempt to sort this out as a > last-minute, show-stopper fix. > > > There is the remaining issue: > Do we use current bsd/linux/mac builds from r39304 (and wait on win > build before announcing), > Or re-branch from 39259 and apply a few fixes there and rebuild on all > platforms. > > By not re-branching we break our own guidelines - to unfreeze quick > but use a branch for fixes and it feels very sloppy to me. > On the other hand my change of moving operators/menu's into a hash > isn't that big a deal and works with scripts reloading, freeing, > re-registering operators etc - I would expect any bugs here would be > obvious and break blender immediately, so I *think* they are safe. > > Suggest to go ahead with r39304, but next release be more clear with > release tag/branch, and the following unfreeze. > > - Campbell > > On Fri, Aug 12, 2011 at 3:58 AM, Kent Mein wrote: >> In reply to Sergey I. Sharybin (g.ula...@gmail.com): >> >>> Didn't know OSX still have got issues with non-trunk verison. I've just >>> commited patch from Jens to solve this problems. >>> >>> We prefer to keep revisions synced for all platforms, so please use >>> >>> Trunk: r39307 >>> Extensions: r2241 >>> >> Updated tarball of the source and md5sum are in incoming on ftp.blender.org >> >> Kent >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers >> > > -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.59 release AHOY!
Pardon, guys, Didn't know OSX still have got issues with non-trunk verison. I've just commited patch from Jens to solve this problems. We prefer to keep revisions synced for all platforms, so please use Trunk: r39307 Extensions: r2241 as reference for new release archives. I hope it's last update before real release! Anyway, thanks all! -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.59 release AHOY!
The very recent linux release archives are there: http://download.blender.org/ftp/incoming/linux-release-39304/ Sergey I. Sharybin wrote: > I've made grease pencil block all other operations when using it in > sketching mode. > > It's the only way for now because it's not only undo which can confuse > grease pencil, also > toggling edit mode, transformation and so confuses this operator. > > So we should update release builds to > > Trunk: r39304 > Extensions: r2241 > > Thomas Dinges wrote: >> As a side note, please keep trunk frozen until release is out! No >> unnecessary commits! >> >> Am 11.08.2011 14:37, schrieb Thomas Dinges: >>> Enable "Use Sketching session" (Grease Pencil) in the Toolbar, and draw >>> something into the viewport. Undo. Crash. >>> Confirmed by Sergey and myself on Linux and Windows. >>> >>> Showstopper!? >>> >>> Am 10.08.2011 22:18, schrieb Campbell Barton: >>>> yikes! thats bad!, yes _please_ report bugs like this right away, >>>> especially near release and in the tracker. >>>> but good you found this too, fixed in svn. >>>> >>>> Platform maintainers, these rev's are now needed for building. >>>> >>>> Trunk: r39272 >>>> Extensions: r2241 > > > -- > With best regards, Sergey I. Sharybin -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.59 release AHOY!
I've made grease pencil block all other operations when using it in sketching mode. It's the only way for now because it's not only undo which can confuse grease pencil, also toggling edit mode, transformation and so confuses this operator. So we should update release builds to Trunk: r39304 Extensions: r2241 Thomas Dinges wrote: > As a side note, please keep trunk frozen until release is out! No > unnecessary commits! > > Am 11.08.2011 14:37, schrieb Thomas Dinges: >> Enable "Use Sketching session" (Grease Pencil) in the Toolbar, and draw >> something into the viewport. Undo. Crash. >> Confirmed by Sergey and myself on Linux and Windows. >> >> Showstopper!? >> >> Am 10.08.2011 22:18, schrieb Campbell Barton: >>> yikes! thats bad!, yes _please_ report bugs like this right away, >>> especially near release and in the tracker. >>> but good you found this too, fixed in svn. >>> >>> Platform maintainers, these rev's are now needed for building. >>> >>> Trunk: r39272 >>> Extensions: r2241 -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.59 release AHOY!
Ok, new builds are there http://download.blender.org/ftp/incoming/linux-release-39272/ Please, delete http://download.blender.org/ftp/incoming/linux-new/ and 2.59 builds from root of incoming. Campbell Barton wrote: > yikes! thats bad!, yes _please_ report bugs like this right away, > especially near release and in the tracker. > but good you found this too, fixed in svn. > > Platform maintainers, these rev's are now needed for building. > > Trunk: r39272 > Extensions: r2241 > > removed freebsd build and source code for 2.59 from the download server. > > On Thu, Aug 11, 2011 at 4:39 AM, Alberto Torres wrote: >> In blender 2.59rc, shape keys don't have its value in the list anymore >> like previous versions (so you can't tweak them just by dragging >> them). Is it a bug? Is it fixed? Sorry for putting this here, I've >> just noticed today (I've written this in another thread and it was >> ignored, I guess I should have opened a bug report first). >> >> >> >> 2011/8/10 pete larabell: >>> FreeBSD build are up. :) >>> >>> On Wed, Aug 10, 2011 at 11:22 AM, Campbell Barton >>> wrote: >>>> Hi devs, >>>> >>>> I've been keeping an eye on the tracker for new reports since our >>>> 2.59RC release and am happy we don't have any real show stoppers. >>>> >>>> Thomas committed the splash, we have version bumped so think its time to >>>> build! >>>> >>>> Since there is some secret to tagging trunk, lib& extensions that >>>> Nathan isn't around to impart, for now just build from revisions. >>>> >>>> Trunk: r39263 >>>> Extensions: r2241 >>>> >>>> I'll be available tomorrow to help with getting the uploads copied to >>>> the download dir and update changelog& typo3 pages. >>>> >>>> Really happy with this release :), thanks to everyone for you're >>>> contributions! >>>> >>>> - 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 >> > > -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.59 release AHOY!
Wait! Haven't noticed that regression. New builds are soon.. Sergey I. Sharybin wrote: > Hi, > > Linux 32/64 builds are there http://download.blender.org/ftp/incoming/ > > Campbell Barton wrote: >> Hi devs, >> >> I've been keeping an eye on the tracker for new reports since our >> 2.59RC release and am happy we don't have any real show stoppers. >> >> Thomas committed the splash, we have version bumped so think its time to >> build! >> >> Since there is some secret to tagging trunk, lib& extensions that >> Nathan isn't around to impart, for now just build from revisions. >> >> Trunk: r39263 >> Extensions: r2241 >> >> I'll be available tomorrow to help with getting the uploads copied to >> the download dir and update changelog& typo3 pages. >> >> Really happy with this release :), thanks to everyone for you're >> contributions! >> >> - Campbell >> ___________ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers >> > > > -- > With best regards, Sergey I. Sharybin -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.59 release AHOY!
Hi, Linux 32/64 builds are there http://download.blender.org/ftp/incoming/ Campbell Barton wrote: > Hi devs, > > I've been keeping an eye on the tracker for new reports since our > 2.59RC release and am happy we don't have any real show stoppers. > > Thomas committed the splash, we have version bumped so think its time to > build! > > Since there is some secret to tagging trunk, lib& extensions that > Nathan isn't around to impart, for now just build from revisions. > > Trunk: r39263 > Extensions: r2241 > > I'll be available tomorrow to help with getting the uploads copied to > the download dir and update changelog& typo3 pages. > > Really happy with this release :), thanks to everyone for you're > contributions! > > - Campbell > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] 2.59 RC Builds - SVN trunk now frozen
Hi, Tomas! My builds should be with ndof support. At least it's enabled in rules and there's ndof-related messages at startup. But i haven't got such device so can't give you 100% sure that it works fine. Should i rebuild linux rc with revision 39167? Thomas Dinges wrote: > Commited a mac build fix in SVN 39167. > > I also want to make sure that release builders build with ndof please. > So Mac/Linux Builders, install the necessary drivers please. > > Otherwise those releases will come without ndof support. > > Thanks! > > Am 07.08.2011 21:05, schrieb Thomas Dinges: >> Hey Release Builders, >> please use SVN 39164 for the release candidate builds. >> >> As from now on, only show-stopper fixes are allowed. Don't commit fixes >> which are not really necessary. >> >> Please everyone run the regression test files, so we don't have to make >> an "a" release this time. >> >> Thanks everyone for your great work! >> -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] 2.59 RC Builds - SVN trunk now frozen
Hi, Linux 32/64bit are there http://download.blender.org/ftp/incoming/ Thomas Dinges wrote: > Hey Release Builders, > please use SVN 39164 for the release candidate builds. > > As from now on, only show-stopper fixes are allowed. Don't commit fixes > which are not really necessary. > > Please everyone run the regression test files, so we don't have to make > an "a" release this time. > > Thanks everyone for your great work! > -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] 2.6 Release Cycle Proposal
Ton Roosendaal wrote: > More-over, I prefer to stick to a serious effort to always keep trunk stable, > at any time. Only on well defined moments (branch mergers, patch applying) we > can accept a really short while of instability. Would Mango team work in separated from trunk branch? Or artists would work with stable trunk and develoeprs wouldn't be necessery? :) > What Campbell proposes - to freeze as short as possible - I rather see happen > then. This whole 'a' release tradition should go away once too. It can't be handled by developers/builder only. Even if we'll provide builds week, two week before official release it wouldn't be tested well… Remember our rc period -- nobody reported real regressions (even crash) during rc. Our old idea which isn't still implemented and which is related on "testers" team. It'll help a lot, imo. > One of the ways to solve it is by getting our release team (or the buildbut) > to make more often official builds available. All that linux builds which are building with buildbot are official. Exactly the same environment is used for building it. -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] 2.6 Release Cycle Proposal
Hi, I'll agree with Campbell. It'll be more convenient for some developers (for example, me). This even can work in such way: - Trunk is never frozen - Two weeks before release we create new branch (or replacing branch from previous release). - In trunk usual work could happen. - In that separated branch last changes, fixes, stabilization, blah blah happens. - Some individual fixes can be merged from trunk to that pre-release branch. - After release tagging happens based on that pre-release branch. It's just idea. And about proposal. It can't totally get us free from corrective releases, imo. Sometimes we're updating libraries and time to time errors happens when preparing new libraries -- wrong configuration, wrong compilation flag, forgotten feature to be included. Such things can be handled by corrective releases, but maybe someone got better ideas to handle such kind of problems? Campbell Barton wrote: > > Hi Thomas, This seems good to me, at least - at least we can go ahead > with it and make minor changes if needed. > > I'd like to raise a topic which isn't addressed in you're proposal. > > By taking more care to stabilize before release I think we could > change how we freeze trunk. > > Currently we do a release: > - freeze before release > - release ahoy > - platform maintainers get builds made > - official announcement > - keep trunk (mostly) frozen for ~1week to see if we need an 'a' version > > I worry that we take too much time keeping blender frozen since this > can take approx 3 weeks and with the proposal to do better tested > releases, this will take longer. > > If we need to do an 'a' release individualizer fixes could be applied > from trunk rather then keeping trunk frozen *just in case* we need to > do another release (could branch from the tagged rev and merge only > the fixes from trunk). > > I'd like to know what others think about doing a release and > unfreezing soon after ahoy (1-2 days). > -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Syntax Highlighting & Alternate Languages
Hi, I'll agree that at least it should be patch which would allow to easily define new highlighting schemes. There are several ways how this could be done. Easiest way is defining set of keywrds. That's like current highlighting works. But supporting new languages not only relates on syntax highlighting. Current editor is "optimized" for text blocks and python files. I mean all that indentation things we've got atm. I suppose there should be another indentation policy for GLSL shader files. And such rules also should be configurable from language definition rules. Probably it'll require re-implement scripts attaching to SpaceText and which could be "triggered" on different events -- like Enter key pressed or so. Then all per-language indentation/code style/etc could be implemented as small handlers for such kind of events. And i've also got ideas of attaching scintilla editor here (http://www.scintilla.org/). It allows to define "custom" renderer which could be opengl renderer so probably it wouldn't be so difficult to adopt it for Blender. And if it would: - We'll have fully configurable editor in terms of highlighting schemes, code stylie behavior and so - It'll be pretty simple to add new custom languages (but not via python, it'll uses XML, iirc). - It's more like _normal_ text editor than current text editor in Blender. SpaceText is a very basic text editor. -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender developer IRC meeting notes, July 24 2011
Ton Roosendaal wrote: > 2) Other projects& branches > > - New seamless texture bake in svn, Sergey Sharybin reviewed Morten > Mikkelsen's code. Proposal is to add a short doc online about it, for > example on Blender code blog. > istinfo/bf-committers > Here's link to description of what exactly was changed: http://code.blender.org/index.php/2011/07/new-dilation-for-texture-filtering/ -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender on the Mac App Store
Hi, Personally, I don't think it's a good idea. App Store isn't compatible with GPL license. Even more, it was accident with VLC already -- Apple simply removed this application from App Store due to license incompatibility. Markus Kasten wrote: > Hello everyone. > > what about putting blender on the App Store (the one for Mac applications of > course, not for iOS)? > Blender could reach a lot more popularity. > > Markus K. > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] ubuntu broken build : SDL.h: No such file or directory
Hi, This should be fixed in svn rev38341. INTERLICHTSPIELHAUS wrote: > hi > > my local build broke today after an svn update: > > > Compiling ==> 'GHOST_SystemSDL.cpp' > In file included from intern/ghost/intern/GHOST_SystemSDL.h:34:0, > from intern/ghost/intern/GHOST_SystemSDL.cpp:30: > intern/ghost/intern/GHOST_DisplayManagerSDL.h:35:18: fatal error: SDL.h: No > such file or directory > compilation terminated. > Compiling ==> 'GHOST_DisplayManagerSDL.cpp' > Compiling ==> 'GHOST_SystemX11.cpp' > In file included from intern/ghost/intern/GHOST_SystemSDL.h:34:0, > from intern/ghost/intern/GHOST_DisplayManagerSDL.cpp:28: > intern/ghost/intern/GHOST_DisplayManagerSDL.h:35:18: fatal error: SDL.h: No > such file or directory > compilation terminated. > > > > $ locate SDL.h > returns among other things : > /usr/include/SDL/SDL.h > > > can anyone point me to a solution ? > > > thanks > > inS > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] FFMPEG Problem on Linux (Yes, I think it is a Blender problem).
Carsten Wartmann wrote: > > Yes I am building my own blender with scons on Ubuntu 10.04. > > ffplay and blender seems to use the same libs: > > http://pasteall.org/22804 Hrm, quite old library. We've got quite the same problem when we've tried to upgrade ffmpeg library year ago or so. That's why we've been using "special" magic library which hasn't got such problem. It was created from specified ffmpeg revision or so. Not sure if it's really bug in Blender. I'm not maintaining that part of Blender, but probably trying to fix it could pbreak something else. > I think a official build will not be different because it uses the > system libs on linux anyway. That's not true. If you'll be using builds from http://www.blender.org/download/get-blender/ or from http://builder.blender.org/download/ then ffmpeg from my build environment would be used. I've checked that "pixelization" issues when was setting up environment and there was no such problems (i've been using different video, but when i've been using older ffmpeg it've got quite the same distortions). Would be useful to know if release builds from blender.org or nighlty builds from builder.blender.org works fine for you. > Carsten -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] FFMPEG Problem on Linux (Yes, I think it is a Blender problem).
Hi, First of all, are you using your own builds of Blender or you're using builds from graphicall/buildbot site? Which verison of ffmpeg you've been playing video when it displays right? Carsten Wartmann wrote: > Hi, > > I reported it before but still I can not use Blender on Linux/Ubuntu 64 > for Videoediting: > > http://projects.blender.org/tracker/?group_id=9&atid=498&func=detail&aid=21284 > > This bug was closed because it seemed that the problem was in the system > FFMPEG. > > Todays tests (using a own scons build from today) seems to me that there > must be a problem in Blender. Here is the result in Blender: > > http://www.pasteall.org/pic/14349 > > No matter if I use the sequencer or map the movie onto a plane. See the > jagged edges (seems like some dithering). > > So far so good, could be still a ffmpeg bug? Same clip in ffplay: > > http://www.pasteall.org/pic/14350 > > Much better (same in VLC which is not using ffmpeg I think, and also no > Problem on WinXP and Blender). > > So I am still not 100% sure, but ANY help not to need to boot windows to > make some videowork is appreciated, especially with the procx code from > Peter. > > Greetz, > Carsten -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] 2.58a bugfix release?
Hi, Have somebody checked bug tracker? Maybe there are additional reported issues which we'd better fix before 2.58a? Campbell Barton wrote: > We thought it was all ok, but infact a nasty regression slipped into > 2.58 which breaks image texture tiling in r37342. now fixed. > There are 2 reports about this, it effects projection painting and and > the displace modifier when an image textures used. > > https://projects.blender.org/tracker/index.php?func=detail&aid=27782 > http://projects.blender.org/tracker/index.php?func=detail&aid=27755 > > A handful of other fixes have been made since the release too. > > - thumbnail save crashing blender in editmode with linked meshes > - in some cases, smart-uv-project failed, projections were also wrong. > - multi-res from 2.4x wasn't loading > - loading cached sounds leaked ram > - Wkey toggle bone flags failed in some cases. > - bug clicking in a non-active Blender window > - OSX player now works apparently > > IMHO this is worth a 2.58a. -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender developers irc meeting, June 26, 2011
Hi, I've just run `svn merge ^/trunk/blender` in salad branch and everything was smooth. Now salad should be synced with trunk. Sergey I. Sharybin wrote: > Ton Roosendaal wrote: >> 3) Google Summer of Code >> >> - Salad merging with current trunk gives problems. Who helps? > I could do it tomorrow evening. > > -- > With best regards, Sergey I. Sharybin -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] strcmp->strncmp code update
Hi, I can't see how such kind of replacement would help us. And we can't use cstring dur to Blender is mostly written in C, not C++. Johan C. wrote: > Hi, > > It'd be best to rewrite the strcmp functions with strncmp and using > #include instead of libc string.h . > > So strcmp(1,2) would become std::strncmp(1,2,std::strlen(2)); > > Love, > erana > > PS: You can patch it with a line of perl. > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender developers irc meeting, June 26, 2011
Ton Roosendaal wrote: > 3) Google Summer of Code > > - Salad merging with current trunk gives problems. Who helps? I could do it tomorrow evening. -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.58 release AHOY!
Hi, I could remember OpenCOLLADA was recently updated for Win32/64. But I can't remember update of OSX libraries and I haven't updated OpenCOLLADA in my buildbot environment. I'd prefer to keep libraries versions in sync. So, please do not use my linux builds as builds avalaible for downloading from b.o -- I'll upgrade them in 9hrs (I'll be ~10 a-dam time). And I also want OSX build also use the same OpenCOLLADA version. Ton Roosendaal wrote: > Hi all, > > That went smooth today :) > > Splash commit had r37699, tag is being done now (r37700 most likely, > Nathan will confirm!) > Let them build machines run then! Put builds on the usual places and > notify me. > > During tomorrow (wednesday) logs/docs will be updated too, and all > goes life when the builds are in. > > Thanks a lot everyone for the great work! > > -Ton- > > > Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org > Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.58 release AHOY!
Hi all, I've uploaded linux 32/64 bit builds to http://download.blender.org/ftp/incoming/ It'll be cool if somebody else would check this archives. This week is neurous for me so i could forgot something. P.S. Thx everyone and congrats with release! pete larabell wrote: > FreeBSD 32 and 64 bit are up. > > On Tue, Jun 21, 2011 at 12:24 PM, Nathan Letwory wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 21.6.2011 19:59, Ton Roosendaal wrote: >>> Hi all, >>> >>> That went smooth today :) >>> >>> Splash commit had r37699, tag is being done now (r37700 most likely, >>> Nathan will confirm!) >> Almost r37700 (I did get the revision on my name, but) r37702 became the >> correct revision. So release builders, check out >> https://svn.blender.org/svnroot/bf-blender/tags/blender-2.58-release >> with revision r37702 and do your thing. >> >> /Nathan >> >> - -- >> Nathan Letwory >> Blender Foundation | Letwory Interactive >> http://www.blender.org | http://www.letworyinteractive.com >> -BEGIN PGP SIGNATURE- >> Version: GnuPG v1.4.10 (MingW32) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >> iQEcBAEBAgAGBQJOANPRAAoJEKtfN7KsE0Ttg7IH/26bJ4KQaYgAvgJ7/BjTIj4y >> kVsrPhLXqAGTZNBbTgzFcKITSXB0HzYjYZGc0BAqBpfn39Frer5Ta0f5w0ke+GGn >> yOW4fzqIg2U4fk4l2M/GizhXHtF/HZwlBBKGUA/uzk12ZV+f6q2jMBu+FNkiViYJ >> tG34PYpDaAxI4qRYbDzKYKf0d10wrgrrztv4WQxOXKQDoJs9YJ9nyWQw0ZvBPvUN >> asANTC7rSIKhxFncRfOfeX1dyZAoVwAVk+dJU64xQ2Nu1w2LcKeljijkfNKkyNHE >> AVrgGYHQk/VEDbBRh+CYZ7KkK+bbbr3+/CeyetPocqd7QhKjxdWM0grxp8Ur3t4= >> =nB2L >> -END PGP SIGNATURE- >> ___ >> 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 > -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] progress on new Boolean library
Hi, I'm not sure why this happens, but working sequence for carve3.patch is `cat carve3.patch | patch -p0`. Maybe it's lag of my git svn-diff script.. I've tried to create patch with svn and uploaded it to tracker [1] (name carve4.zip). [1] http://projects.blender.org/tracker/?func=detail&aid=26465&group_id=9&atid=127 Yousef Hurfoush wrote: > > hi all > > @sergey: i tried apply your patch to trunk but it is asking for unknow files, > could you give some hints on applying it. > > thanks in advance :) > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Sensor Size
Hi, I've reviewed patch and the only things which are confusing me: - Vertical sensor size has got no affect - Exportters also weren't handling sensor size correct (they were using default or so) Problem that it's not actully areas of code i've been working before so patch should be reviewed by somebody more familiar with this areas. I could only say that functionality looks useful for me (due to my camera-tracking related job atm) and i haven't noticed serious issues with code style. Ejner Fergo wrote: > Hola, > > I have updated the patch to revision 37009: > http://projects.blender.org/tracker/index.php?func=detail&aid=24427&group_id=9&atid=127 > > I have also written a short documentation: > http://wiki.blender.org/index.php/User:San/Real_Focal_Length > > About code review, I think I read that only committers can upload to > the code review tool? The patch is assigned to Sergey Sharybin > (nazgul) so hopefully he reads this and have the time to do it. I'm > aware that GSOC is in full swing, but still think this patch will be > good to have in 2.58. > > I am prepared to work more on importers/exporters and have so far made > good progress on FBX and .chan and will do my best to make every > script having to do with cameras work with this new code. > > Best regards, > > Ejner > > On Wed, Apr 27, 2011 at 9:08 AM, "Martin Bürbaum" > wrote: >> Ejner Fergo wrote: >>> I am of course hopeful to see this get some attention from the >>> developers, and appreciate you guys seeing the importance of this. I >>> just don't know how to proceed with this to make an inclusion in trunk >>> more likely. It would be really nice to hear some opinions from those >>> with authority. >> I am not a blender developer (sorry, no authority here), but I think a good >> start would be to upload the latest patch to the code review tool [1]. >> And link that in the bug tracker. (> procedures here.) >> >> Then it's pretty easy to review and comment on the patch, which in turn will >> speed up its integration into trunk, I presume. >> >> Saludos, >> Martin >> >> [1] http://codereview.appspot.com >> Example Review: http://codereview.appspot.com/4280080 >> Mailing List: http://lists.blender.org/pipermail/bf-codereview/ >> ___ >> 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 > -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Let us switch to git, pretty please
Hi, Campbell I've been moving our work SVN repo to GIT at my previous job* and Nathan should have script which moves SVN repo into GIT repo with handling all branches and so. So i could make tests too. But i'd prefer to compare speed GIT vs. Mercurial. I haven't used mercurial myself, but there's information that GIT is much faster. I want to confirm this :) * It was script which reads every commit from SVN repo and makes the same commit in GIT repo -- this was made to avoid all that additional messages in commit logs created with git-svn.. Campbell Barton wrote: > paroneayea and I discussed moving to GIT at length and he brought up > some issues which we'd need to resolve. > > - binaries may need to be masked out of SVN history so the initial > checkout of lib/ isn't huge, (paroneayea said its possible with > filter-branch when making the switch but its not trivial). > More general issue is how well it performs once we have 500mb+ of > binary changes in GIT too. > > - bf-extensions would also need to be moved, expect its possible but > another complication, how to merge and keep history for both - not > sure on this one. > > > Another thing thats been discussed is having an SVN hook in our > existing repo which keeps a GIT repo in sync. Currently the available > GIT repos have some lag from trunk, With git matching trunk it would > help us evaluate GIT without having to switch completely (interested > in Nathan's opinion on this), it comes up from time to time as > something we should do. > > > As for moving to GIT (or any DVCS) - It would be good if people > interested in evaluating this could make a local copy of the entire > SVN repo to speed up tests and work out the necessary steps to move to > see if we can even do this. > Id like to look into this myself (hassling Marco for an account on the > new SVN server now :) ). > > On Fri, May 27, 2011 at 5:02 AM, Mathias Panzenböck > wrote: >> As long time bf-committers reader who has committed one or two tiny patches >> in the past I like to add: >> >> Pros for HG: >> More intuitive to use, especially things like revert. >> Nicely extensible using Python (e.g. generic keyring integration for repo >> passwords). >> TortoiseHg> TortoiseGit and cross platform (Qt based). >> >> Pros for GIT: >> The SVN bridge seems to be much faster and transfers less data than HGs SVN >> bridge (last time I tried). >> Some people like this staging thing much. Never used it. >> It is said that a repo with many very different branches is smaller in GIT. >> github/gitourios> bitbucket (but bitbucket is ok) >> >> Many things are possible in both, but the defaults differ. E.g. in HG you >> have to enable several >> extensions (that are included, just not enabled) to get things like >> paging+colors on the shell, >> rebase, squash (which isn't called like that in HG, I think) etc. But then >> in HG there is a built in >> webserver (`hg serve`) that supports pushes (if enabled)! It can also be >> hooked as CGI script with >> about two lines of Python code. But currently HG only supports Python 2.x. >> >> (I somehow like HG better.) >> >> -panzi >> >> On 05/27/2011 05:29 AM, Sergey I. Sharybin wrote: >>> Hi, >>> >>> I'm not sure switching the whole repo to git is a nice idea. Last time >>> i've checked this it was very painful to work with libs/ repo cloned >>> with git -- simple `git status` used to work ages. Maybe this is because >>> of plenty of binary files, not sure. And size of that local cloned repo >>> was also incredible big -- several gigabutes, iirc. >>> >>> Git for codebase works really nice when you've got plenty of branches -- >>> no pain with all this re-branching and so. Simple `git rebase` and here >>> we go. There's also advantage for releases -- tagging happens much nicer >>> with git. >>> >>> It'll be also more useful for pre-realse periods while codebase is >>> frozen -- developers could still commit features to the development >>> branch, but they wouldn't go to master. >>> >>> About clients i could say that git on linux works nice, msysgit works >>> fine for windows. There's also TortoiseGIT. I haven't used it much, but >>> it worked also nice. But i have to admit, that some firends of mine had >>> some occasional troubles with it. >>> >>> P.S. as one more disadvantage, we'll be unable to have that rin >>> splash screen. It could be short com
Re: [Bf-committers] SVN commit: /data/svn/bf-blender [36934] trunk/blender: == FFMPEG ==
Hi, Peter! It's cool that you've removed old code, but i'm unable to compile with ffmpeg 0.6.3 (which is current latest stable version and which would be used for 2.58 release). The same error would happen for libraries from current lib/ repo: [ 72%] Building CXX object source/gameengine/VideoTexture/CMakeFiles/ge_videotex.dir/VideoFFmpeg.cpp.o In file included from /home/nazgul/src/blender/blender/source/gameengine/VideoTexture/VideoFFmpeg.cpp:41:0: /home/nazgul/src/blender/blender/source/gameengine/VideoTexture/VideoFFmpeg.h:37:34: fatal error: libavutil/parseutils.h: No such file or directory I hope it'll be easy for you to fix this :) Original Message Subject: Re: [Bf-committers] SVN commit: /data/svn/bf-blender [36934] trunk/blender: == FFMPEG == From: Peter Schlaile To: bf-committers@blender.org Date: 05/27/2011 05:53 AM > ... did I already mention, that I start to hate OpenSuse for using some > "in-between" version...? > > Please checkout again. > > Cheers, > Peter > >> hm, i got another error. >> >> >> source/blender/blenkernel/intern/writeffmpeg.c: In function >> ?start_ffmpeg_impl?: >> source/blender/blenkernel/intern/writeffmpeg.c:744:32: error: >> ?AVIO_FLAG_WRITE? undeclared (first use in this function) >> source/blender/blenkernel/intern/writeffmpeg.c:744:32: note: each >> undeclared identifier is reported only once for each function it appears in >> scons: *** >> [/home/pepo/zwei5new/build/linux2/source/blender/blenkernel/intern/writeffmpeg.o] >> Error 1 >> scons: building terminated because of errors. >> >> Thanks for fast reply, mib. >> >> >> Am 27.05.2011, 01:23 Uhr, schrieb Peter Schlaile: >> >>> ... added some version checks again. >>> >>> Please try again! >>> >>> Cheers, >>> Peter >>> >>>> Hi, this commit breaks building on opensuse 11.4/64 with scons, system >>>> ffmpeg is 0.62. >>>> http://www.pasteall.org/21955 >>>> Cheers, mib. >>> ___ >>> 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 >> >> >> End of Bf-committers Digest, Vol 82, Issue 52 >> * >> > > Peter Schlaile > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Let us switch to git, pretty please
Hi, I'm not sure switching the whole repo to git is a nice idea. Last time i've checked this it was very painful to work with libs/ repo cloned with git -- simple `git status` used to work ages. Maybe this is because of plenty of binary files, not sure. And size of that local cloned repo was also incredible big -- several gigabutes, iirc. Git for codebase works really nice when you've got plenty of branches -- no pain with all this re-branching and so. Simple `git rebase` and here we go. There's also advantage for releases -- tagging happens much nicer with git. It'll be also more useful for pre-realse periods while codebase is frozen -- developers could still commit features to the development branch, but they wouldn't go to master. About clients i could say that git on linux works nice, msysgit works fine for windows. There's also TortoiseGIT. I haven't used it much, but it worked also nice. But i have to admit, that some firends of mine had some occasional troubles with it. P.S. as one more disadvantage, we'll be unable to have that r in splash screen. It could be short commit SHA, but not sure it'll be useful. Tom M wrote: > It was discussed a bit yesterday on irc as Jason was updating his > sculpt branch to head that it would haven been much less pain with GIT > potentially. > > Brecht and Ideasman and other core maintainers what are your views on > moving to git or mercury? > > Ultimately the decision will be up to Ton of course, but would be good > to get a straw poll on sentiment for it. > > LetterRip > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Unlimited clay patch review
Hi, Blender Community!
I've reviewed unlimited clay patch yesterday. I haven't been able to
apply patch/compile correctly, so i can't give feedback about how things
are working, but i could give some feedback about patch itself.
- First of all it's created against a bit outdated version of trunk --
some files were moved, some functions renamed and so. It lead to plenty
of rejected hunks in patchs.
- Patch contains plenty of non-functional changes: whitespace changes,
somewhere "styling" changes, somewhere changed "logic" -- code in
non-unlimitedclay related code was replaced with different code whick
makes the same things (like normals in getEditMeshDerivedMesh). This
makes patch much more difficult to be applied against newer trunk and
readability of this patch also lower -- can't split what is actually
changes and what's not.
- That including of "ED_mesh.h" in DerivedMesh.c and pbvh.c. It's not
only ugly usage of absolute path. but it's also a breaking of
archeticure -- blenkernel/ and blenlib/ shouldn't use editors/. I
suppose editmesh is needed for easier changing mesh topology, but i also
suppose it could be made without such hacks. For example add some
utility functions to blenkernel/intern/mesh which would provide list of
verts/edges/faces (similar lists as in editmesh). I think it's the most
worth thing for which EditMesh is used atm.
- I also not sure why it's needed to move structures (like
EditMeshDerivedMesh, StrokeCache, PBVH, PBVHNode and so) from .c-fiels
into headers. This structures aren't supposed to be reused outside of
their module and they should be a blackbox for other modules.
- Styling should be checked. I'd prefer to keep only one style inside
one module. Check comments, brackets, spaces and so.
- Also it looks like there's some unused code adding by patch but which
isn't used.
- I'm not fully like all that new fields inside EditVert. Maybe they
could be moved inside tmp union or EditVert->data could be reused? Or as
i mentioned, EditMesh could be replaced by something more light and
common... Or maybe it'll be special structure for unlimited clay
purposes and functions like {make,load}_clayMesh?
- I'm not sure why stuff like BLI_pbvh_iter_end should be changed?
That's all feedback i could give atm.
We discussed a bit ways to split out unneeded changes with Tom, but not
sure that ways would be useful. I'd prefer if manual reading of patch
would be done -- in this case all outdated stuff would be found.
I hope it'll help to make patch better and acceptable to be commited.
--
With best regards, Sergey I. Sharybin
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Normals' baker from multires mesh
Hi everybody, As it was mentioned in minutes today, Morten and me weer working under baker stuff last few weeks. Here's link to tracker http://projects.blender.org/tracker/?func=detail&aid=27331&group_id=9&atid=127 and to thread in BA http://blenderartists.org/forum/showthread.php?216643-Summer-of-Code-Sculpt-and-Paint-Feedback-team Ofcourse, it's not finished at least from source code point of view. It'll require some work to make code good for be commitable into main source tree, but it's not very difficult. It's more important to know if it's really so useful and issue-less. Waiting feedback from you P.S. i'd prefer not to receive feedback about source code style. It'll be cleaned up :) -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender developer IRC meeting notes May 8, 2011
Not with Sean only. Mostly with Morten Mikkelsen who provided almost all math which made able to bake directly from sculpted mesh. Ton Roosendaal wrote: > Hi all, > > Relative short meeting today: > > 1) Blender 2.57+, current projects > > - Ton will move to tracker triaging again. Campbell will work on BMesh > and I/O work more. > > - Quality of code: keep module owners informed and if you add stuff, > check tracker! > > https://projects.blender.org/tracker/index.php?func=detail&aid=27241&group_id=9&atid=498 > > - Peter Schlaile: are you still available this month? FFmpeg update > might have issues. > > 2) GSoC > > - How to add branches for students needs decision soon; some students > could share, mentors will check on who. > > 3) Other projects > > - Brecht: regarding Cycles, this week will focus on integration work, > for Cycles as well as external engines. > > - Sergey: worked with Sean on an option to bake outside 'derivedmesh' > to save memory, makes bakes possible with 5x more faces in same memory > footprint (1.9M -> 9M faces). > > - Cloth work: Joe has a new solver, he'll further work on this in his > branch, coordinate it with module owners Daniel/Janne. > > Laters, > > -Ton- > > > Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org > Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands > > ___________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Sculpting on constructive modifiers
Oops.. That attached patch wasn't the final version (some bad places in code were present) I've just commited final version (with minor chages in RNA name). Have fun! Ronan Zeegers wrote: > Hi Sergey, > > Aaaah! Yes, you can sculpt on shapekeys. It's juste a bit disturbing > when you sculpt on and shape key set to zero... > For me, it's ok to put it in trunk. The sculpt tool is a real pleasure > now. Grrruuu! > > Thank you! > > Ronan > /*Postprod 2D/3D* > + 32 (0) 473 45 20 43 > p...@ronanzeegers.com > www.ronanzeegers.com / > > > Le 3/05/2011 07:20, Sergey I. Sharybin a écrit : >> Hi, >> >> Ronan Zeegers wrote: >>> I did a small test and it seems really cool! >>> 2 smalls thing that can be improved: >>> >>> -There is nothing to tell that you're not able du sculpt on an unpinned >>> shapekey. But I'm not sure that is related to your patch ;) >> As Nathan had already mentioned, you're allowed to sculpt on non-locked >> shapekeys. I've noticed one minor bug with sculpting on such keys and >> undo stack, fix would be in svn soon. >>> -it would be nice to be able to move the mirrored part of the mesh like >>> in B2.49 (when "symmetry X/Y/Z" is on) >> I've got some ideas about this. Will try to implement. >>> It's really cool to be able to play with armature and subsurf and mirror >>> modifier at the same time! Thanx >> So, did i understand correct, that there's no regressions/major bugs and >> patch could be moved to trunk? >> >> P.S. Thanks for testing! >>> Ronan >>> /*Postprod 2D/3D* >>> + 32 (0) 473 45 20 43 >>> p...@ronanzeegers.com >>> www.ronanzeegers.com / >>> >>> >>> Le 2/05/2011 23:11, Sergey I. Sharybin a écrit : >>>> Hi, >>>> >>>> I've prepared linux 32/64 and win64 builds here: >>>> http://nazg-gul.dyndns.org/storage/binaries/blender-constructive-sculpting/ >>>> >>>> Also, win32 build could be downloaded rom graphicall. >>>> >>>> Xavier Thomas wrote: >>>>> cd /where/your/blender/source/is >>>>> patch -p0>>>> >>>>> On windows I think you can apply patch using tortoise svn >>>>> >>>>> cheers >>>>> >>>>> xavier >>>>> >>>>> >>>>> 2011/5/2 Ronan Zeegers: >>>>>> Hi Sergey >>>>>> >>>>>> Thank you for the patch. >>>>>> I now how to make a fresh build from svn under linux (using scons) but >>>>>> I'm not sure how to apply your patch. >>>>>> Can you upload somewhere the full patched sources or make a build? >>>>>> >>>>>> cheers, >>>>>> >>>>>> Ronan >>>>>> /*Postprod 2D/3D* >>>>>> + 32 (0) 473 45 20 43 >>>>>> p...@ronanzeegers.com >>>>>> www.ronanzeegers.com / >>>>>> >>>>>> >>>>>> Le 2/05/2011 14:54, Sergey I. Sharybin a écrit : >>>>>>> Hi everybody! >>>>>>> >>>>>>> I've created this small patch to be able to sculpt on subdivided mesh >>>>>>> again. Main changes: >>>>>>> - Constructive modifiers are enabled by eefault in sculpt mode >>>>>>> - There's option to disable all constructive modifiers in the "Options" >>>>>>> panel of toolbox in scultp mode (maybethis would be useful for >>>>>>> animators?) >>>>>>> - Use one column in ythis options to make strings easier to read >>>>>>> - No modifiers would be applied on multires >>>>>>> - I disliked idea of using that half-transparent mesh to show actual >>>>>>> shape on which brush is applying. It'll make sculpting slower and it's >>>>>>> not too helpful actually. >>>>>>> >>>>>>> It's the very first version of patch, so some issues could present. >>>>>>> >>>>>>> Here's patch itself: http://www.pasteall.org/21318/diff >>>>>>> Waiting both of artists and develoeprs feedback. Let artists tell what >>>>>>> they are still missing and what they want to view improved and other >>>>>>> developers could point me into silly places of patch -- it's always >>>>>>> useful due to everyone could easily overview something.. >>>>>>> >>>>>>> We could also create special builds so artists who want to test but >>>>>>> don't know how to apply patch would also eb able to send us feedbacj. >>>>>>> >>>>>> ___ >>>>>> 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 -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Sculpting on constructive modifiers
Hi, Ronan Zeegers wrote: > I did a small test and it seems really cool! > 2 smalls thing that can be improved: > > -There is nothing to tell that you're not able du sculpt on an unpinned > shapekey. But I'm not sure that is related to your patch ;) As Nathan had already mentioned, you're allowed to sculpt on non-locked shapekeys. I've noticed one minor bug with sculpting on such keys and undo stack, fix would be in svn soon. > -it would be nice to be able to move the mirrored part of the mesh like > in B2.49 (when "symmetry X/Y/Z" is on) I've got some ideas about this. Will try to implement. > It's really cool to be able to play with armature and subsurf and mirror > modifier at the same time! Thanx So, did i understand correct, that there's no regressions/major bugs and patch could be moved to trunk? P.S. Thanks for testing! > Ronan > /*Postprod 2D/3D* > + 32 (0) 473 45 20 43 > p...@ronanzeegers.com > www.ronanzeegers.com / > > > Le 2/05/2011 23:11, Sergey I. Sharybin a écrit : >> Hi, >> >> I've prepared linux 32/64 and win64 builds here: >> http://nazg-gul.dyndns.org/storage/binaries/blender-constructive-sculpting/ >> >> Also, win32 build could be downloaded rom graphicall. >> >> Xavier Thomas wrote: >>> cd /where/your/blender/source/is >>> patch -p0>> >>> On windows I think you can apply patch using tortoise svn >>> >>> cheers >>> >>> xavier >>> >>> >>> 2011/5/2 Ronan Zeegers: >>>> Hi Sergey >>>> >>>> Thank you for the patch. >>>> I now how to make a fresh build from svn under linux (using scons) but >>>> I'm not sure how to apply your patch. >>>> Can you upload somewhere the full patched sources or make a build? >>>> >>>> cheers, >>>> >>>> Ronan >>>> /*Postprod 2D/3D* >>>> + 32 (0) 473 45 20 43 >>>> p...@ronanzeegers.com >>>> www.ronanzeegers.com / >>>> >>>> >>>> Le 2/05/2011 14:54, Sergey I. Sharybin a écrit : >>>>> Hi everybody! >>>>> >>>>> I've created this small patch to be able to sculpt on subdivided mesh >>>>> again. Main changes: >>>>> - Constructive modifiers are enabled by eefault in sculpt mode >>>>> - There's option to disable all constructive modifiers in the "Options" >>>>> panel of toolbox in scultp mode (maybethis would be useful for animators?) >>>>> - Use one column in ythis options to make strings easier to read >>>>> - No modifiers would be applied on multires >>>>> - I disliked idea of using that half-transparent mesh to show actual >>>>> shape on which brush is applying. It'll make sculpting slower and it's >>>>> not too helpful actually. >>>>> >>>>> It's the very first version of patch, so some issues could present. >>>>> >>>>> Here's patch itself: http://www.pasteall.org/21318/diff >>>>> Waiting both of artists and develoeprs feedback. Let artists tell what >>>>> they are still missing and what they want to view improved and other >>>>> developers could point me into silly places of patch -- it's always >>>>> useful due to everyone could easily overview something.. >>>>> >>>>> We could also create special builds so artists who want to test but >>>>> don't know how to apply patch would also eb able to send us feedbacj. >>>>> >>>> ___ >>>> 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 -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Sculpting on constructive modifiers
Hi, I've prepared linux 32/64 and win64 builds here: http://nazg-gul.dyndns.org/storage/binaries/blender-constructive-sculpting/ Also, win32 build could be downloaded rom graphicall. Xavier Thomas wrote: > cd /where/your/blender/source/is > patch -p0 > On windows I think you can apply patch using tortoise svn > > cheers > > xavier > > > 2011/5/2 Ronan Zeegers: >> Hi Sergey >> >> Thank you for the patch. >> I now how to make a fresh build from svn under linux (using scons) but >> I'm not sure how to apply your patch. >> Can you upload somewhere the full patched sources or make a build? >> >> cheers, >> >> Ronan >> /*Postprod 2D/3D* >> + 32 (0) 473 45 20 43 >> p...@ronanzeegers.com >> www.ronanzeegers.com / >> >> >> Le 2/05/2011 14:54, Sergey I. Sharybin a écrit : >>> Hi everybody! >>> >>> I've created this small patch to be able to sculpt on subdivided mesh >>> again. Main changes: >>> - Constructive modifiers are enabled by eefault in sculpt mode >>> - There's option to disable all constructive modifiers in the "Options" >>> panel of toolbox in scultp mode (maybethis would be useful for animators?) >>> - Use one column in ythis options to make strings easier to read >>> - No modifiers would be applied on multires >>> - I disliked idea of using that half-transparent mesh to show actual >>> shape on which brush is applying. It'll make sculpting slower and it's >>> not too helpful actually. >>> >>> It's the very first version of patch, so some issues could present. >>> >>> Here's patch itself: http://www.pasteall.org/21318/diff >>> Waiting both of artists and develoeprs feedback. Let artists tell what >>> they are still missing and what they want to view improved and other >>> developers could point me into silly places of patch -- it's always >>> useful due to everyone could easily overview something.. >>> >>> We could also create special builds so artists who want to test but >>> don't know how to apply patch would also eb able to send us feedbacj. >>> >> ___ >> 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 > -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Sculpting on constructive modifiers
Hi everybody! I've created this small patch to be able to sculpt on subdivided mesh again. Main changes: - Constructive modifiers are enabled by eefault in sculpt mode - There's option to disable all constructive modifiers in the "Options" panel of toolbox in scultp mode (maybethis would be useful for animators?) - Use one column in ythis options to make strings easier to read - No modifiers would be applied on multires - I disliked idea of using that half-transparent mesh to show actual shape on which brush is applying. It'll make sculpting slower and it's not too helpful actually. It's the very first version of patch, so some issues could present. Here's patch itself: http://www.pasteall.org/21318/diff Waiting both of artists and develoeprs feedback. Let artists tell what they are still missing and what they want to view improved and other developers could point me into silly places of patch -- it's always useful due to everyone could easily overview something.. We could also create special builds so artists who want to test but don't know how to apply patch would also eb able to send us feedbacj. -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Need help with building blender-2.57b using python 3.1
I'm afraid building against py3.1 isn't supported anymore -- we've switched to 3.2. There were some critical for bugs fixed there (https connetcions which are used for connection to renderfarm.fi, i.e.) Why do you need your own built of 2.57b? We've got pretty cool release binaries at our site. Dave Plater wrote: > Hi, I'm getting this failure with building blender 2.57b against python 3.1 > which is unfortunately what most major distributions are on. > > cd > /usr/src/packages/BUILD/blender-2.57b/Build/source/blender/python/generic&& > /usr/bin/gcc -D__SSE__ -D__MMX__ -D__SSE2__ > -fomit-frame-pointer -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 > -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g > -pipe -fPIC -funsigned-char -fno-strict-aliasing -g -ggdb > -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -fopenmp > -msse2 -msse -pipe -fPIC -funsigned-char -fno-strict-aliasing -Wall > -Wcast-align -Werror=declaration-after-statement > -Werror=implicit-function-declaration -Werror=return-type -Wstrict-prototypes > -Wno-char-subscripts -Wno-unknown-pragmas -Wpointer-arith > -Wunused-parameter -Wwrite-strings > -I/usr/src/packages/BUILD/blender-2.57b/source/blender/python/generic > -I/usr/src/packages/BUILD/blender-2.57b/source/blender/blenlib > -I/usr/src/packages/BUILD/blender-2.57b/source/blender/makesdna > -I/usr/src/packages/BUILD/blender-2.57b/source/blender/blenkernel > -I/usr/src/packages/BUILD/blender-2.57b/source/blender/blenloader > -I/usr/src/packages/BUILD/blender-2.57b/intern/guardedalloc > -I/usr/src/packages/BUILD/blender-2.57b/extern/glew/include > -I/usr/include/python3.1 -o CMakeFiles/bf_python_ext.dir/py_capi_utils.c.o > -c > /usr/src/packages/BUILD/blender-2.57b/source/blender/python/generic/py_capi_utils.c > /usr/src/packages/BUILD/blender-2.57b/source/blender/python/generic/py_capi_utils.c: > In function 'PyC_LineSpit': > /usr/src/packages/BUILD/blender-2.57b/source/blender/python/generic/py_capi_utils.c:67:2: > error: implicit declaration of function > '_Py_atomic_load_relaxed' > make[2]: *** > [source/blender/python/generic/CMakeFiles/bf_python_ext.dir/py_capi_utils.c.o] > Error 1 > make[2]: Leaving directory `/usr/src/packages/BUILD/blender-2.57b/Build' > make[1]: *** [source/blender/python/generic/CMakeFiles/bf_python_ext.dir/all] > Error 2 > make[1]: *** Waiting for unfinished jobs > > I'm getting emails asking when it will be available. > Thanks > Dave Plater. > _______ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] ffmpeg library update
I've updated ffmpeg used for our linux buildbot. I used config #2 (but with disabled avfilter) from my previous letters and used version 0.6.3 of ffmpeg. Sound and video guru-s: please re-test linux builds from http://builder.blender.org/download/ and tell me if something become broken, something was fixed, or nothing changed and so on. If things would be smooth with this build, i think it'll replace ffmpeg used for 2.5x releases earlier. -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] ffmpeg library update
Made full release build cycle (with blenderplayer, strippng, packing and so on). Archive size with all that codecs enabled growed up from 30 to 33mb for linux64 platforms Sergey I. Sharybin wrote: > Also, forgot to mention. > > Pre-rc1 binaries were 52mb. Not sure why with the same configuration > Ken had got such bigger binary -- maybe it's because of collada (not > sure i've used exactly the same configuration for it). > > Really strange thing that even with binary 10mb bigger tham mine Ken's > archive was 2-3mb smaller. Matbe it's bytes sequence issue. > > So, maybe enabling all that codecs aren't so big issue from binary > side point of view? > > Sergey I. Sharybin wrote: >> Hi, >> >> I've done some testing with configurations. Here are some results. >> >> So, first of all i've disabled version3 and nonfree otions. First of >> them leads to gpl3 or higher library version, second maked libraries >> un-redistributable. Now libraries are gpl2 or higher. >> >> Also, i've disabled debugging symbols (--disable-debug flag). This >> shouldn't affect on size doe to all symbols (strip --strip-all) are >> stripping from blender binary. >> >> Then i've made simple config which gave exactly the same result in >> dependencies as ffmpeg which was used for 2.57a release. >> Conficuration is published in [1]. Blender binary after stripping was >> 43Mb. Don't think it's matetr due to linking happened against >> libraries which are ~1year newer, i think, and codebase of ffmpeg >> became larger (additional checkings, maybe architecture changed so >> some symbols which were unused and stripped now used and so on). >> >> Next test was with initial config from this thread with license >> cleaning and cleaning up flags which Peter and Joerg marked as unused >> and also disabled most of marked as "UNSURE" options. This options >> are related on speech (don't think this kind of audio is useful for >> Blender, but this libraries aren't big -- ~300Kb so could be added if >> they're necessery) and streaming (but dirac and schro keeped enabled >> -- it's algos of encoding/decoding raw videos). Configuration is >> published in [2]. Blender binary growed u[ to 49mb. This is also >> understandable, because all new dependencies (vpx, ogg, vorbis, >> theora, dirac, schro) are ~8mb in total. More codecs -- higher size >> of binary. >> >> Next step was disabled schro and dirac. Configuration posted to [3]. >> This saved 2mb and Blender binary became 47mb. >> >> I haven't tested with rtmp enabled because don't find stream sources >> b useful in Blender and this gives too much dependencies which >> weren't easy to solve -- some libraries came from Debian Sid >> environment, some from Debian Lenny, some from Lenny Backports.. >> Also, this adds ~2mb of Blender binary size. >> >> So, question is: do we want to support more codecs (ogg, vorbis, >> teora, vpx, dirac, schro) and have 8mb bigger Blender binary as we've >> got now? >> >> [1] http://www.pasteall.org/21098 >> [2] http://www.pasteall.org/21099 >> [3] http://www.pasteall.org/21100 >> >> -- >> With best regards, Sergey I. Sharybin > > > -- > With best regards, Sergey I. Sharybin -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] ffmpeg library update
Also, forgot to mention. Pre-rc1 binaries were 52mb. Not sure why with the same configuration Ken had got such bigger binary -- maybe it's because of collada (not sure i've used exactly the same configuration for it). Really strange thing that even with binary 10mb bigger tham mine Ken's archive was 2-3mb smaller. Matbe it's bytes sequence issue. So, maybe enabling all that codecs aren't so big issue from binary side point of view? Sergey I. Sharybin wrote: > Hi, > > I've done some testing with configurations. Here are some results. > > So, first of all i've disabled version3 and nonfree otions. First of > them leads to gpl3 or higher library version, second maked libraries > un-redistributable. Now libraries are gpl2 or higher. > > Also, i've disabled debugging symbols (--disable-debug flag). This > shouldn't affect on size doe to all symbols (strip --strip-all) are > stripping from blender binary. > > Then i've made simple config which gave exactly the same result in > dependencies as ffmpeg which was used for 2.57a release. Conficuration > is published in [1]. Blender binary after stripping was 43Mb. Don't > think it's matetr due to linking happened against libraries which are > ~1year newer, i think, and codebase of ffmpeg became larger > (additional checkings, maybe architecture changed so some symbols > which were unused and stripped now used and so on). > > Next test was with initial config from this thread with license > cleaning and cleaning up flags which Peter and Joerg marked as unused > and also disabled most of marked as "UNSURE" options. This options are > related on speech (don't think this kind of audio is useful for > Blender, but this libraries aren't big -- ~300Kb so could be added if > they're necessery) and streaming (but dirac and schro keeped enabled > -- it's algos of encoding/decoding raw videos). Configuration is > published in [2]. Blender binary growed u[ to 49mb. This is also > understandable, because all new dependencies (vpx, ogg, vorbis, > theora, dirac, schro) are ~8mb in total. More codecs -- higher size of > binary. > > Next step was disabled schro and dirac. Configuration posted to [3]. > This saved 2mb and Blender binary became 47mb. > > I haven't tested with rtmp enabled because don't find stream sources b > useful in Blender and this gives too much dependencies which weren't > easy to solve -- some libraries came from Debian Sid environment, some > from Debian Lenny, some from Lenny Backports.. Also, this adds ~2mb of > Blender binary size. > > So, question is: do we want to support more codecs (ogg, vorbis, > teora, vpx, dirac, schro) and have 8mb bigger Blender binary as we've > got now? > > [1] http://www.pasteall.org/21098 > [2] http://www.pasteall.org/21099 > [3] http://www.pasteall.org/21100 > > -- > With best regards, Sergey I. Sharybin -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] ffmpeg library update
Hi, I've done some testing with configurations. Here are some results. So, first of all i've disabled version3 and nonfree otions. First of them leads to gpl3 or higher library version, second maked libraries un-redistributable. Now libraries are gpl2 or higher. Also, i've disabled debugging symbols (--disable-debug flag). This shouldn't affect on size doe to all symbols (strip --strip-all) are stripping from blender binary. Then i've made simple config which gave exactly the same result in dependencies as ffmpeg which was used for 2.57a release. Conficuration is published in [1]. Blender binary after stripping was 43Mb. Don't think it's matetr due to linking happened against libraries which are ~1year newer, i think, and codebase of ffmpeg became larger (additional checkings, maybe architecture changed so some symbols which were unused and stripped now used and so on). Next test was with initial config from this thread with license cleaning and cleaning up flags which Peter and Joerg marked as unused and also disabled most of marked as "UNSURE" options. This options are related on speech (don't think this kind of audio is useful for Blender, but this libraries aren't big -- ~300Kb so could be added if they're necessery) and streaming (but dirac and schro keeped enabled -- it's algos of encoding/decoding raw videos). Configuration is published in [2]. Blender binary growed u[ to 49mb. This is also understandable, because all new dependencies (vpx, ogg, vorbis, theora, dirac, schro) are ~8mb in total. More codecs -- higher size of binary. Next step was disabled schro and dirac. Configuration posted to [3]. This saved 2mb and Blender binary became 47mb. I haven't tested with rtmp enabled because don't find stream sources b useful in Blender and this gives too much dependencies which weren't easy to solve -- some libraries came from Debian Sid environment, some from Debian Lenny, some from Lenny Backports.. Also, this adds ~2mb of Blender binary size. So, question is: do we want to support more codecs (ogg, vorbis, teora, vpx, dirac, schro) and have 8mb bigger Blender binary as we've got now? [1] http://www.pasteall.org/21098 [2] http://www.pasteall.org/21099 [3] http://www.pasteall.org/21100 -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] ffmpeg library update
Stripping of final binary should remove all unused symbols. Does it make sense if symbols from libraries gets stripped when they're in binary or stripping happens on libraries before symbols are adding to binary? But ok, it shouldn't be difficult to make test tomorrow. Martin Poirier wrote: > You strip the final binary, not the libs. > > Martin > > --- On Sun, 4/24/11, Tom M wrote: > >> From: Tom M >> Subject: Re: [Bf-committers] ffmpeg library update >> To: "bf-blender developers" >> Received: Sunday, April 24, 2011, 4:07 PM >> --disable-stripping >> >> Why is stripping disabled? I thought that we >> generally do stripping... >> >> LetterRip >> >> On Sun, Apr 24, 2011 at 12:04 PM, Sergey I. Sharybin >> wrote: >>> Ok, i've build the latest ffmpeg 0.6.90-rc0 with >> options i've got from >>> debian sid package rules (with some additional flags >> to get static libs >>> which would run on all platofrms -- the same flags >> were used for mesa >>> and openal): >>> >>> ./configure \ >>> --cc="gcc -Wl,--as-needed" \ >>> --extra-ldflags="-pthread -static-libgcc" >> \ >>> --prefix=/opt/ffmpeg \ >>> --enable-static \ >>> --enable-avfilter \ >>> --enable-vdpau \ >>> --enable-bzlib \ >>> --enable-libgsm \ >>> --enable-libschroedinger \ >>> --enable-libspeex \ >>> --enable-libtheora \ >>> --enable-libvorbis \ >>> --enable-pthreads \ >>> --enable-zlib \ >>> --enable-libvpx \ >>> --disable-stripping \ >>> --enable-runtime-cpudetect \ >>> --enable-vaapi \ >>> --enable-libopenjpeg \ >>> --enable-libfaac \ >>> --enable-nonfree \ >>> --enable-gpl \ >>> --enable-postproc \ >>> --enable-x11grab \ >>> --enable-libdirac \ >>> --enable-libmp3lame \ >>> --enable-librtmp \ >>> --enable-libx264 \ >>> --enable-libxvid \ >>> --enable-libopencore-amrnb \ >>> --enable-version3 \ >>> --enable-libopencore-amrwb \ >>> --enable-version3 \ >>> --enable-libdc1394 >>> >>> Haven't noticed that pixelization errors, but size of >> Blender's ELF >>> growed up from 41 to 51 megabytes. Quite noticale, >> i'll say. I think >>> some codecs could be disabled to reduce amount of >> repended libraries. >>> Maybe there's some coding/encoding gurus here who >> could tell which >>> options could be disabled? >>> >>> neXyon wrote: >>>> Am 2011-04-24 11:15, schrieb Sergey Kurdakov: >>>>> just to make it more correct >>>>> http://win32.libav.org/win64/ >>>> Awesome! I've only looked here: http://libav.org/download.html where you >>>> can only find win32 binaries. >>>> >>>> Regards >>>> >>>> ___________ >>>> Bf-committers mailing list >>>> Bf-committers@blender.org >>>> http://lists.blender.org/mailman/listinfo/bf-committers >>>> >>> >>> -- >>> With best regards, Sergey I. Sharybin >>> >>> ___ >>> 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 > -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] ffmpeg library update
If be honest -- have no idea. Anyway, blender get's stripped by builder script, so don't think it's a big issue. As i told, i used options from debian package rules -- i suppose this options are made to be ok for most of users, platforms and needs (to make libs more portable and so on). Tom M wrote: > --disable-stripping > > Why is stripping disabled? I thought that we generally do stripping... > > LetterRip > > On Sun, Apr 24, 2011 at 12:04 PM, Sergey I. Sharybin > wrote: >> Ok, i've build the latest ffmpeg 0.6.90-rc0 with options i've got from >> debian sid package rules (with some additional flags to get static libs >> which would run on all platofrms -- the same flags were used for mesa >> and openal): >> >> ./configure \ >> --cc="gcc -Wl,--as-needed" \ >> --extra-ldflags="-pthread -static-libgcc" \ >> --prefix=/opt/ffmpeg \ >> --enable-static \ >> --enable-avfilter \ >> --enable-vdpau \ >> --enable-bzlib \ >> --enable-libgsm \ >> --enable-libschroedinger \ >> --enable-libspeex \ >> --enable-libtheora \ >> --enable-libvorbis \ >> --enable-pthreads \ >> --enable-zlib \ >> --enable-libvpx \ >> --disable-stripping \ >> --enable-runtime-cpudetect \ >> --enable-vaapi \ >> --enable-libopenjpeg \ >> --enable-libfaac \ >> --enable-nonfree \ >> --enable-gpl \ >> --enable-postproc \ >> --enable-x11grab \ >> --enable-libdirac \ >> --enable-libmp3lame \ >> --enable-librtmp \ >> --enable-libx264 \ >> --enable-libxvid \ >> --enable-libopencore-amrnb \ >> --enable-version3 \ >> --enable-libopencore-amrwb \ >> --enable-version3 \ >> --enable-libdc1394 >> >> Haven't noticed that pixelization errors, but size of Blender's ELF >> growed up from 41 to 51 megabytes. Quite noticale, i'll say. I think >> some codecs could be disabled to reduce amount of repended libraries. >> Maybe there's some coding/encoding gurus here who could tell which >> options could be disabled? >> >> neXyon wrote: >>> Am 2011-04-24 11:15, schrieb Sergey Kurdakov: >>>> just to make it more correct >>>> http://win32.libav.org/win64/ >>> Awesome! I've only looked here: http://libav.org/download.html where you >>> can only find win32 binaries. >>> >>> Regards >>> >>> ___ >>> Bf-committers mailing list >>> Bf-committers@blender.org >>> http://lists.blender.org/mailman/listinfo/bf-committers >>> >> >> -- >> With best regards, Sergey I. Sharybin >> >> ___ >> 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 > -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] ffmpeg library update
Ok, i've build the latest ffmpeg 0.6.90-rc0 with options i've got from debian sid package rules (with some additional flags to get static libs which would run on all platofrms -- the same flags were used for mesa and openal): ./configure \ --cc="gcc -Wl,--as-needed" \ --extra-ldflags="-pthread -static-libgcc" \ --prefix=/opt/ffmpeg \ --enable-static \ --enable-avfilter \ --enable-vdpau \ --enable-bzlib \ --enable-libgsm \ --enable-libschroedinger \ --enable-libspeex \ --enable-libtheora \ --enable-libvorbis \ --enable-pthreads \ --enable-zlib \ --enable-libvpx \ --disable-stripping \ --enable-runtime-cpudetect \ --enable-vaapi \ --enable-libopenjpeg \ --enable-libfaac \ --enable-nonfree \ --enable-gpl \ --enable-postproc \ --enable-x11grab \ --enable-libdirac \ --enable-libmp3lame \ --enable-librtmp \ --enable-libx264 \ --enable-libxvid \ --enable-libopencore-amrnb \ --enable-version3 \ --enable-libopencore-amrwb \ --enable-version3 \ --enable-libdc1394 Haven't noticed that pixelization errors, but size of Blender's ELF growed up from 41 to 51 megabytes. Quite noticale, i'll say. I think some codecs could be disabled to reduce amount of repended libraries. Maybe there's some coding/encoding gurus here who could tell which options could be disabled? neXyon wrote: > Am 2011-04-24 11:15, schrieb Sergey Kurdakov: >> just to make it more correct >> http://win32.libav.org/win64/ > Awesome! I've only looked here: http://libav.org/download.html where you > can only find win32 binaries. > > Regards > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender IRC meeting, sunday 24 april 2011
There should also tagging happen Thomas Dinges wrote: > We still have to check with Ton when we do a 2.57b release. > No need to make builds yet. :) > > Am 24.04.2011 20:12, schrieb pete larabell: >> Sorry I'm a bit unclear on this then... >> >> Are we, or are we not, having new release builds sent to ftp by >> official builders? If so, what revision should we check out to build >> releases? >> >> Cheers! >> >> On Sun, Apr 24, 2011 at 9:42 AM, Sergey I. Sharybin >> wrote: >>>Hi all >>> >>> Here's a summary of topics: >>> >>> 1) Blender 2.57 release: >>> >>> - One more crash was detected in Blender 2.57a release (crash when using >>> Enter in menus which load file). >>> >>> - There was no final decision about update release, but everybody agreed >>> it's annoying bug and it would be cool to get updated official release >>> builds. >>> >>> - Sculpting on non-locked keys was commited by Sergey. Also, he wanetd >>> to mention that sculpting on constructive modifiers isn't disabled >>> forever and returning of this option with better implementation is >>> already in his TODO list. >>> >>> 2) Other projects >>> >>> - Lukas Toenne is working under cleaning up his particles-2010 branch. >>> He mentioned that core changes he made to the node system would be very >>> beneficial. >>> >>> 3) Google Summer of Code >>> >>> - Official announcement of accepted students would be tomorrow, April 25 >>> 19:00 UTC. >>> >>> -- >>> With best regards, Sergey I. Sharybin >>> >>> ___ >>> 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 > -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Blender IRC meeting, sunday 24 april 2011
Hi all Here's a summary of topics: 1) Blender 2.57 release: - One more crash was detected in Blender 2.57a release (crash when using Enter in menus which load file). - There was no final decision about update release, but everybody agreed it's annoying bug and it would be cool to get updated official release builds. - Sculpting on non-locked keys was commited by Sergey. Also, he wanetd to mention that sculpting on constructive modifiers isn't disabled forever and returning of this option with better implementation is already in his TODO list. 2) Other projects - Lukas Toenne is working under cleaning up his particles-2010 branch. He mentioned that core changes he made to the node system would be very beneficial. 3) Google Summer of Code - Official announcement of accepted students would be tomorrow, April 25 19:00 UTC. -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] ffmpeg library update
Hi, We're still using quite old version of ffmpeg for linux release builds at least (this libraries were compiled from ffmpeg sources which were used in blender source tree just before their remooving from the svn). This was caused because some problems with pixelization which was discussed here some weeks ago. I was planning to update this libraries before 2.58 release but met one thing which i'm not sure how to solwe: ffmpeg community was splitted into two parts -- ffmpeg and libav. I'm not sure which community now is more active and which library we should use in the future. Maybe somebody could make things clear for us (and me particularly) so we could update builder environments with the most perspective library and version of this library. -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.57a AHOY!
Linux 32/64 are also uploaded, It took some time to solve to double-check gzopen64 problem recently posted to our tracker. It works fine now, pete larabell wrote: > FreeBSD builds are up. :) > > On Thu, Apr 21, 2011 at 9:14 AM, Ton Roosendaal wrote: >> Hi all, >> >> Revision: 36273 >> Tagged: >> https://svn.blender.org/svnroot/bf-blender/tags/blender-2.57a-release >> >> Release builders can put builds in the usual locations :) >> >> If all goes fine - yes we can! - svn opens up as usual for work on >> 2.5x related targets and more bugfixing tomorrow. >> >> Thanks, >> >> -Ton- >> >> >> Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org >> 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 > -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] No more subsurf and mirror modifier with scupt mode?
Ronan Zeegers wrote: > Hello Sergey, > > Why not keeping the old approach for the subsurf and mirror modifier? > Like you said, at least supporting some simple cases. > The intuitiveness of this approach seems to be subjective. Current approach was introduced becaue plenty of artists missed predictable sculpting on armatured mesh and to implement this i had to disable old behaviour (otherwise, things can't be predictable enough and both of implementation/working as user was quite difficult task) > To defend the old behavior, I think that a 3D artist know that he is > scuplting/moving vertex of the base mesh. Not the "virtual" vertex of > the subsurf/mirrored/displaced mesh. > It never disturbed me to not moving the shape because I was not clicking > in an area where there was vertex. It's just two different cases which can't live togeter well, but current implementation could be used as "basis" for easier re-implement old behaviour for constructive modifier. Actually, i don't think it's contructive to continue discussion like "things were cool, now it's not so cool" -- it's different cases and returning of (at least some of) constructive modifiers is in my sculpting todo list. I'd prefer to collect as much opinions as it's possible to find out which behaviour should be used by default, which additional modes should be added and so on (everything, which could help to make sculpting in blender useful for wide audience of artists). Currently, me and Tom (a.k.a Letterrip) dicussed this things and we found that re-implementing my old derived-cage patch would help a lot with supporting constructive modifiers. Idea is the same as it used for edit mode: draw final shape solid and mesh, which is actually editing be half-transparent. It wouldn't be helpful for case of deformation modifiers because things are becaming much more difficult to see in the screen, but should work fine for constructive modifiers and also it'll help to visualize "sculpting layer" for difficult cases. Personally, i don't think supporting of constructive mosidiers should be enabled by default -- i'd prefer to have things enabled by default if their behaviour is well predictable. Maybe i'm wrong, but it'll be simple to change. Also, that half-transparent derived cage could be toggleable, so it could be easily hidden. P.S. Maybe i forgot to mention that disabling all constructive modifiers gives advantage in case of mixed constructive/deformation modifiers in the stack. In this case i'll see quite final shape of object (maybe without vonstructed elements as mirrored part and so on), but shape itself is final. P.P.S. Difference from previous implementation of derived-cage patch, this half-transparent part could be crated from mesh with applying all leading deformation modifiers. Maybe it'll be useful. I just not sure about which combinations of modifiers are actually used by artists -- but you could help me with it ;) > cheers, > > Ronan Zeegers > /*Postprod 2D/3D* > + 32 (0) 473 45 20 43 > www.ronanzeegers.com / > > > Le 21/04/2011 09:45, Sergey I. Sharybin a écrit : >> Looks like it was implemented in 2.49 exactly in the same way as it >> was before enabling sculpting on deformed mesh in 2.5 and i don't find >> it intuitive. >> >> I'm not sure what do you mean "properly" -- i can't make strokes on >> mirrored part of mesh. And what about sculpting on deformed/armatured mesh? >> >> Problem that we can't deal with all kinds of modifier stack content and >> now we allow only that modifiers, which could be handled ~100% correct. >> Of course, we could support simple cases like Bse mesh -> mirror -> >> subsurf or Base mesh -> armature, but cases like Base mesh -> mirror -> >> armature can't be handled correct. And things could be much more >> complicated here and you've got no idea where stroke happens (even in >> 2.49 troke isn't happening on that point of subdivided default cube -- >> try to grab vertex -- it's movenment would be "delayed", it's because of >> distance between dragging vertex and prush posiiton). >> >> That's why ide of sculpt cage was burn -- just to visualize kinda >> "sculpting level" which is used for brushes just to make things more >> clear about where sculpting happens. Otherwise, in a bit more >> complicated modifier stack you should be making strokes far from place >> you want to add some displacement. It's not intuitive at all. >> >> Matt Ebb wrote: >>> On Thu, Apr 21, 2011 at 5:07 PM, Sergey I. Sharybin >>> wrote: >>>>
Re: [Bf-committers] No more subsurf and mirror modifier with scupt mode?
Looks like it was implemented in 2.49 exactly in the same way as it was before enabling sculpting on deformed mesh in 2.5 and i don't find it intuitive. I'm not sure what do you mean "properly" -- i can't make strokes on mirrored part of mesh. And what about sculpting on deformed/armatured mesh? Problem that we can't deal with all kinds of modifier stack content and now we allow only that modifiers, which could be handled ~100% correct. Of course, we could support simple cases like Bse mesh -> mirror -> subsurf or Base mesh -> armature, but cases like Base mesh -> mirror -> armature can't be handled correct. And things could be much more complicated here and you've got no idea where stroke happens (even in 2.49 troke isn't happening on that point of subdivided default cube -- try to grab vertex -- it's movenment would be "delayed", it's because of distance between dragging vertex and prush posiiton). That's why ide of sculpt cage was burn -- just to visualize kinda "sculpting level" which is used for brushes just to make things more clear about where sculpting happens. Otherwise, in a bit more complicated modifier stack you should be making strokes far from place you want to add some displacement. It's not intuitive at all. Matt Ebb wrote: > On Thu, Apr 21, 2011 at 5:07 PM, Sergey I. Sharybin > wrote: >> Hi Ronan! >> >> Yep, you're right -- constructive modifiers (like array, mirror, >> subsurf,...) were disabled when sculpting. This was made to make >> sculpting more obvious and enable sculpting on deformed mesh. > I forget the issues involved here, but I recall sculpting (modifying > base level mesh, as you would in edit mode) with mirror and subsurf on > was supported properly in 2.49 - a modeller friend I've worked with > relied on this a lot - using the sculpt tools to tweak poly modelled > objects. What's the difference between how it worked in 2.49 and now? > is it possible at all to restore similar functionality as 2.49? > > cheers > > Matt > ___________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] No more subsurf and mirror modifier with scupt mode?
Hi Ronan! Yep, you're right -- constructive modifiers (like array, mirror, subsurf,...) were disabled when sculpting. This was made to make sculpting more obvious and enable sculpting on deformed mesh. Main problem of old approach was using undeformed mesh to calculate strokes, which was invisible. This was giving reasonable results while you hasn't tried to sculpt on armatured mesh or on lo-poly mesh with high level of subdivision modifier. Now you could easiy sculpt on armatured/deformed mesh and see actual result of your sculpt, no need to predict place of brush to make stroke as it was with previous implementation. And also deformation became a bit more "correct" -- it's more about direction of displacement on highly deformed mesh (developer's name for such reverse-deformation-calculation si crazyspace) About plans.. Yep, we don't have plans in terms of when and what would be implemented, but we discussed this in out IRC channel and got an idea of re-animating old derived-cage approach which showed both of geometry used for brushes and final result like it's made in edit mode. Problem that we can't use the both of crazyspace correction and constructive modifiers at the same time. So, idea was to use current crazyspace approach by default, but give option to switch to derived-cage approach to be able to sculpt on constructed mesh. But there would be some limitaion, of cource. You'll be still unable to make strokes on constructed parts of mesh and if you've got armatured mesh which is subdivided you'll be able to sculpt on base mesh only (or maybe on deformed mesh by deformation modifiers before constructive modifiers). And there's also quite unclear for such derived-cage approach when we should use it. I'm not sure if automatic entering such mode is good idea, maybe it'll be option in sculpt panels to use such mode.. Anyway, ideas and implementation ways of this are still discussing.. Ronan Zeegers wrote: > Hello Blender developpers! > > I'm a little bit sad to see that 2 really important features where > removed in the latest 2.57 release: being able to work in sculpt mode > with the subsurf and mirror modifier. > Those features are really important for characters/organic modelling... > > After a bit of browsing, a found a word from Sergey: > http://code.blender.org/index.php/2011/01/sculpting-on-armatured-mesh/ > > If I read correclty, there is no plan to put those features back in Blender. > Please... Don't do this... > Right now, my workflow is a bit broken. I'm constantly switching betwen > Blender 2.49 and 2.57. Making me losing a lot of time... > > I know that I'm not the only artist to be annoyed by this: > http://blenderartists.org/forum/showthread.php?215198-Blender-2.57-3-Bad-things-that-we-found...%28at-this-time%29 > http://forums.cgsociety.org/showthread.php?f=59&t=972277&page=2&pp=15 > > Thanx for reading me! > Ronan Zeegers > > /*Postprod 2D/3D* > + 32 (0) 473 45 20 43 > www.ronanzeegers.com / > > ___________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.57 Release AHOY! (1)
To download them you should use link http://download.blender.org/ftp/incoming/ rafa wrote: > El 12/04/11 21:53, Sergey I. Sharybin escribió: >> Both of 32 and 64bit linux builds were uploaded to >> ftp.blender.org/incoming. I hope there's no issues with them. The only >> thing which i'd prefer to check -- content of the archive. Should it be >> something special there? >> >> And i've been able to make quick tests at my home computer only (no all >> that ubuntu/fedora/etc), so if somebody will make additional quick test >> before publishing -- would be useful. > Hi > I could test it on some machines with ubuntu 32bits (Maverick, Natty) > and Centos but It is no possible to download from ftp.blender.org/incoming. > How could I do it without having to build them by myself ? > > Rafael Rios > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.57 Release AHOY! (1)
Both of 32 and 64bit linux builds were uploaded to ftp.blender.org/incoming. I hope there's no issues with them. The only thing which i'd prefer to check -- content of the archive. Should it be something special there? And i've been able to make quick tests at my home computer only (no all that ubuntu/fedora/etc), so if somebody will make additional quick test before publishing -- would be useful. Nathan Letwory wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 12.4.2011 21:17, Nathan Letwory wrote: >> On 12.4.2011 21:14, Ton Roosendaal wrote: >>> Hi all, >> >> Before we awesome builders do our building job, I want to first do the >> actual tagging of both bf-blender and bf-extensions. I'll reply to this >> message with the correct revision to get of blender-2.57-release tag >> when I'm done. > Blender sources: > > svn co > https://svn.blender.org/svnroot/bf-blender/tags/blender-2.57-release/blender/@36129 > blender-2.57-release > > also get your platform lib/* folder if necessary > > svn co > https://svn.blender.org/svnroot/bf-blender/tags/blender-2.57-release/lib/windows/@36129 > lib/windows > > (of course getting everything from under the tag is allowed too ;): svn > co > https://svn.blender.org/svnroot/bf-blender/tags/blender-2.57-release/@36129 > blender-2.57-release ) > > Have fun building! > > /Nathan > > - -- > Nathan Letwory > Letwory Interactive | Studio Lumikuu > http://www.letworyinteractive.com | http://www.lumikuu.com > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJNpJ4eAAoJEKtfN7KsE0Ttw8gIAIn+e68Wvb6jYxsVgPXITxXB > F+M+rhn1CyUPpnwMf9I4Gi7/yPdxYwgL3MSgZpEFbytXKeeJDENfSl8KSn2kJ8rt > anCbZusAqEIgF1GvdN6FOFf0rHeEvi7MtEpFr4mPpZ+mxI5gM8oLQHsg2qgQYU16 > RH29zHCPT3NbIM4C2pGgw0WS6fcrqdupvPC/zoit9VjpZ+h8TL/yWNM0/SK9DYgI > dva53RS9WJNBt/B8A0QeP3H2PiU1syoFaiWbfm/RJ7M87Ols6lIkJ/8NCFkbwxOP > 1pBYeRxN1e4Y4g9bVJaJfBEbx2zvJhdyA8NjAJ7pw5b6Ka/Z2DqIIqUubNxI8lc= > =ymP2 > -END PGP SIGNATURE- > _______ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey I. Sharybin ___ 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 [36104] trunk/blender/intern/ghost/intern/ GHOST_WindowWin32.cpp: FIx crash when opening User Preferences even with NVidia card
This requires special case to happen, but it _used_ to happen. Even for my intel videocard configuraiton when i forsed to set current context to NULL. Anyway, both of crash and fix are approved by Dalai jmso...@free.fr wrote: > Selon Sergey Sharybin: > >> Revision: 36104 >> >> > http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=36104 >> Author: nazgul >> Date: 2011-04-11 19:22:43 + (Mon, 11 Apr 2011) >> Log Message: >> --- >> FIx crash when opening User Preferences even with NVidia card > > ?? > Rev 35102 : no crash here with a nvidia GeForce GTS 250 and win 7. > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender developer IRC meeting minutes, April 10 2011
I need more sleep: not ommited, but commited Sergey I. Sharybin wrote: > Glad to hear this! > > Anyway, i've ommited one fix to this stuff this night. It prevented > crash for Dalai's NVidia configuration and it could also prevent crash > for other configurations bue to it happend NULL-pointer dereference > for special cases (when current contest was set to NULL by redraw stuff). > > I heard there was crash when calling userprefs from neu but no crash > whel calling by hotkey. This case could be fixed now. > > Anyway, we need power of our community to test builds. Win32 could be > found here http://builder.blender.org/download/ and win64 is still at > graphicsall.org (you need revision >= 36104) > > Gustav Göransson wrote: >> Hi >> >> The driver update seems to do the trick. I had to uninstall the older >> driver first in order to install Intels generic driver (otherwise you could >> only install drivers provided by the vendor (acer), which were quite >> outdated). Thanks for your help. >> >> /Gustav >> >> On Mon, Apr 11, 2011 at 18:10, ValterVB wrote: >> >>> Sergey, I can't update the driver. >>> I haven't administrator privilege. It's my job laptop and I don't use it >>> with Blender, but if you need some test I can do it. >>> >>> Ciao >>> Valter >>> >>> >>> -Messaggio originale- >>> From: Sergey I. Sharybin >>> Sent: Monday, April 11, 2011 5:14 PM >>> To:bf-committers@blender.org >>> Subject: Re: [Bf-committers] Blender developer IRC meeting minutes, April >>> 10 >>> 2011 >>> >>> Valter and Gustav, >>> >>> I've checked google a bit and found that 1-2 years old drivers crashes >>> at second call of wglMakeCurrent when using shared contexts. Is it >>> possible to you to update your driver to the newer version? >>> >>> I'm preparing newer version with more debug prints after context >>> creation to be sure you've got crash exactly at wglMakeCurrent or >>> somewhere else, would be useful if you'll investigate posibility of >>> driver upgrade during i'm working. >>> >>> P.S. To get log of blender you could try to use "blender.exe -d> >>> log.txt" in the console -- should work fine. >>> >>> ValterVB wrote: >>>> If you are interested: I have a crash with >>>> "blender-2.57-prerelease-intelgfx-debug-r36098M-win32.exe" >>>> Here the log (print screen)http://www.pasteall.org/pic/10909 and here >>> the >>>> system infohttp://www.pasteall.org/20734 >>>> >>>> Ciao >>>> VB >>>> >>>> -Messaggio originale- >>>> From: Gustav Göransson >>>> Sent: Monday, April 11, 2011 3:45 PM >>>> To: bf-blender developers >>>> Subject: Re: [Bf-committers] Blender developer IRC meeting minutes,April >>>> 10 >>>> 2011 >>>> >>>> Hi >>>> >>>> I did some more testing with various official builds. There was no >>>> problems >>>> opening 2 new windows with the older build. However I did get a crash >>> when >>>> switching from triple buffer to any other drawing mode with the 64-bit >>>> builds, but that might be a separate issue?... >>>> >>>> 2.56a 32-bit: OK >>>> 2.56a 64-bit: OK (however crashes when switching form tripple buffer to >>>> any >>>> other mode) >>>> 2.57 RC2 32-bit: OK >>>> 2.57 RC2 64-bit: OK (however crashes when switching form tripple buffer >>> to >>>> any other mode) >>>> Blender 32-bit r36097 from buildbot: Crash >>>> Debug 32-bit: Crash >>>> Debug 64-bit: Crash >>>> >>>> Is the debug log stored anywhere, cause I didn't manage to find it? >>>> However >>>> here's some print screens of the frozen console windows: >>>> http://gustavgoransson.com/temp/32.png >>>> http://gustavgoransson.com/temp/64.png >>>> >>>> I also answered in the thread at BA.org >>>> http://blenderartists.org/forum/showthread.php?214584 >>>> >>>> /Gustav >>>> >>>> >>>> On Mon, Apr 11, 2011 at 14:07, Sergey I. >>>> Sharybinwrote: >>>> >>>>>Ooops.. Mistakes are here... >>>>> >>>>> And if
Re: [Bf-committers] Blender developer IRC meeting minutes, April 10 2011
Glad to hear this! Anyway, i've ommited one fix to this stuff this night. It prevented crash for Dalai's NVidia configuration and it could also prevent crash for other configurations bue to it happend NULL-pointer dereference for special cases (when current contest was set to NULL by redraw stuff). I heard there was crash when calling userprefs from neu but no crash whel calling by hotkey. This case could be fixed now. Anyway, we need power of our community to test builds. Win32 could be found here http://builder.blender.org/download/ and win64 is still at graphicsall.org (you need revision >= 36104) Gustav Göransson wrote: > Hi > > The driver update seems to do the trick. I had to uninstall the older > driver first in order to install Intels generic driver (otherwise you could > only install drivers provided by the vendor (acer), which were quite > outdated). Thanks for your help. > > /Gustav > > On Mon, Apr 11, 2011 at 18:10, ValterVB wrote: > >> Sergey, I can't update the driver. >> I haven't administrator privilege. It's my job laptop and I don't use it >> with Blender, but if you need some test I can do it. >> >> Ciao >> Valter >> >> >> -Messaggio originale- >> From: Sergey I. Sharybin >> Sent: Monday, April 11, 2011 5:14 PM >> To: bf-committers@blender.org >> Subject: Re: [Bf-committers] Blender developer IRC meeting minutes, April >> 10 >> 2011 >> >> Valter and Gustav, >> >> I've checked google a bit and found that 1-2 years old drivers crashes >> at second call of wglMakeCurrent when using shared contexts. Is it >> possible to you to update your driver to the newer version? >> >> I'm preparing newer version with more debug prints after context >> creation to be sure you've got crash exactly at wglMakeCurrent or >> somewhere else, would be useful if you'll investigate posibility of >> driver upgrade during i'm working. >> >> P.S. To get log of blender you could try to use "blender.exe -d> >> log.txt" in the console -- should work fine. >> >> ValterVB wrote: >>> If you are interested: I have a crash with >>> "blender-2.57-prerelease-intelgfx-debug-r36098M-win32.exe" >>> Here the log (print screen) http://www.pasteall.org/pic/10909 and here >> the >>> system info http://www.pasteall.org/20734 >>> >>> Ciao >>> VB >>> >>> -Messaggio originale- >>> From: Gustav Göransson >>> Sent: Monday, April 11, 2011 3:45 PM >>> To: bf-blender developers >>> Subject: Re: [Bf-committers] Blender developer IRC meeting minutes,April >>> 10 >>> 2011 >>> >>> Hi >>> >>> I did some more testing with various official builds. There was no >>> problems >>> opening 2 new windows with the older build. However I did get a crash >> when >>> switching from triple buffer to any other drawing mode with the 64-bit >>> builds, but that might be a separate issue?... >>> >>> 2.56a 32-bit: OK >>> 2.56a 64-bit: OK (however crashes when switching form tripple buffer to >>> any >>> other mode) >>> 2.57 RC2 32-bit: OK >>> 2.57 RC2 64-bit: OK (however crashes when switching form tripple buffer >> to >>> any other mode) >>> Blender 32-bit r36097 from buildbot: Crash >>> Debug 32-bit: Crash >>> Debug 64-bit: Crash >>> >>> Is the debug log stored anywhere, cause I didn't manage to find it? >>> However >>> here's some print screens of the frozen console windows: >>> http://gustavgoransson.com/temp/32.png >>> http://gustavgoransson.com/temp/64.png >>> >>> I also answered in the thread at BA.org >>> http://blenderartists.org/forum/showthread.php?214584 >>> >>> /Gustav >>> >>> >>> On Mon, Apr 11, 2011 at 14:07, Sergey I. >>> Sharybinwrote: >>> >>>>Ooops.. Mistakes are here... >>>> >>>> And if there'll be still issues, please show us console output for >>>> `blender -d` using binaries >>>> >>>> >> http://letworyinteractive.com/builds/blender-2.57-prerelease-intelgfx-debug-r36098M-win64.exe >>>> or >>>> >>>> >> http://letworyinteractive.com/builds/blender-2.57-prerelease-intelgfx-debug-r36098M-win32.exe >>>> Sergey I. Sharybin wrote: >>>>> And if there'll be still issues, please show us console ou
