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
Hi again, Commited some interface changes to tomato branch, Please check commit message for details: http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=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
)... 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.comzan...@gmail.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] [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=revroot=bf-blenderrevision=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=detailaid=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
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 Roosendaalt...@blender.org 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
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 language you want to update (4) python clean_po.py language you want to clean (5) python merge_po.py destination file source file 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
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.pylanguage you want to update (4) python clean_po.pylanguage you want to clean (5) python merge_po.pydestination file source 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.
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] 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 xiaoxiaoxiangq...@gmail.com 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. Sharybing.ula...@gmail.com 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
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] 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
[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] 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] 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/library/library_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] 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] i18n branch (garlic) review
Hi, xiangquan xiao wrote: 2011/9/8 Sergey I. Sharybing.ula...@gmail.com - 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
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
[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] 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!
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!
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!
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!
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=revroot=bf-blenderrevision=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 Meinm...@cs.umn.edu 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!
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!
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 Torreskungfoo...@gmail.com 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 larabellxgl.asyl...@gmail.com: FreeBSD build are up. :) On Wed, Aug 10, 2011 at 11:22 AM, Campbell Bartonideasma...@gmail.com 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] 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
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] 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] 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).
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=9atid=498func=detailaid=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] 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] 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] 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] 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 #includecstring 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 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 Letworynat...@blender.org 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] 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] 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=detailaid=26465group_id=9atid=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=detailaid=24427group_id=9atid=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 martin.buerb...@gmx.at wrote: Ejner Fergoejner...@gmail.com 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. (? I don't know about the exact 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 grosser.meister.mo...@gmx.net 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 rnumberin 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 ___ Bf-committers mailing list Bf-committers@blender.org http
[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
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=detailaid=27241group_id=9atid=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
[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=detailaid=27331group_id=9atid=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] 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 -p0patch.diff On windows I think you can apply patch using tortoise svn cheers xavier 2011/5/2 Ronan Zeegersblen...@ronanzeegers.com: 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
[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] 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 -p0patch.diff On windows I think you can apply patch using tortoise svn cheers xavier 2011/5/2 Ronan Zeegersblen...@ronanzeegers.com: 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
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 -p0patch.diff On windows I think you can apply patch using tortoise svn cheers xavier 2011/5/2 Ronan Zeegersblen...@ronanzeegers.com: 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] 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
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
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
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
[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
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] 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. Sharybing.ula...@gmail.com 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
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 Mletter...@gmail.com wrote: From: Tom Mletter...@gmail.com Subject: Re: [Bf-committers] ffmpeg library update To: bf-blender developersbf-committers@blender.org 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. Sharybing.ula...@gmail.com 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
[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] 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=59t=972277page=2pp=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] 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. Sharybing.ula...@gmail.com 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] 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 Roosendaalt...@blender.org 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] 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] 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 developer IRC meeting minutes, April 10 2011
And if there'll be still issues, please show us console output for `blender -d` isunf 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 Gustav Göransson wrote: On Sun, Apr 10, 2011 at 17:53, Ton Roosendaalt...@blender.org wrote: - There's now code in svn that should prevent Intel graphics cards to crash on opening 2nd windows (like User Preferences). Please report if this can be confirmed. For me it had the opposite effect. I have not experienced any problems earlier with opening a 2nd window. However with the latest revision blender crashes immediately when opening the User Preferences. I'm running win 7 with Intel 4500MHD graphics... ___ 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
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. Sharybing.ula...@gmail.comwrote: 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 output for `blender -d` isunf 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 Gustav Göransson wrote: On Sun, Apr 10, 2011 at 17:53, Ton Roosendaalt...@blender.org wrote: - There's now code in svn that should prevent Intel graphics cards to crash on opening 2nd windows (like User Preferences). Please report if this can be confirmed. For me it had the opposite effect. I have not experienced any problems earlier with opening a 2nd window. However with the latest revision blender crashes immediately when opening the User Preferences. I'm running win 7 with Intel 4500MHD graphics... ___ 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 ___ 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 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, ValterVBvalte...@live.com 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. Sharybing.ula...@gmail.comwrote: 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 output for `blender -d` isunf 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 Gustav Göransson wrote: On Sun, Apr 10, 2011 at 17:53, Ton Roosendaalt...@blender.org wrote: - There's now code in svn that should prevent Intel graphics cards to crash on opening 2nd windows (like User Preferences). Please report if this can be confirmed. For me it had the opposite effect. I have not experienced any problems earlier with opening a 2nd window. However with the latest revision blender crashes immediately when opening the User Preferences. I'm running win 7 with Intel 4500MHD graphics... ___ 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] RC2 builds please!
So, here's first version of article: http://wiki.blender.org/index.php/User:Nazg-gul/LinuxBuildbotEnvironment I quite sure something was missed here, but general things are described and it'll be easy to write missed things :) pete larabell wrote: A wiki-page with description of building environment for release builds would be very useful. I found that when I started build on FreeBSD, I could certainly compile fine, but had no idea there even WAS a difference between those builds and release builds until I found out I had been doing it wrong. :) On Tue, Apr 5, 2011 at 2:15 AM, Sergey I. Sharybing.ula...@gmail.com wrote: @Rafael: sure @all: maybe wiki-page with description of setting of building environment for releases would be useful? rsaave...@ono.com wrote: Thanks Sergey, I will check them. Could I mail you if there are something I can't figure out ? -- Rafael Rios Mensaje original De: g.ula...@gmail.com Fecha: 04/04/2011 20:17 Para:bf- committ...@blender.org Asunto: Re: [Bf-committers] RC2 builds please! Rafael, We aren't using default scons rules for release builts. Things are much complicated to make binary file which would run on the most of platforms. U could check build_files/config/*.py if u want to see configs we're using for release builds ;) rsaave...@ono.com wrote: Hi, I am not the builder of the official release, I am only a blender follower wanting to help I have compiled r36007 on ubuntu Maverick (i686) (10.10) and Natty (i686) (11.04 beta1) using scons. The only but is that for Natty I have to create an user-config.py with the following line: BF_PYTHON_ABI_FLAGS = 'mu' because of python3.2- dev package. For the Maverick, I have python3.2 compiled by myself, so I have to indicate the path to python in BF_PYTHON. The compiling went smooth in both enviroments. Rafael Rios -- 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] RC2 builds please!
@Rafael: sure @all: maybe wiki-page with description of setting of building environment for releases would be useful? rsaave...@ono.com wrote: Thanks Sergey, I will check them. Could I mail you if there are something I can't figure out ? -- Rafael Rios Mensaje original De: g.ula...@gmail.com Fecha: 04/04/2011 20:17 Para:bf- committ...@blender.org Asunto: Re: [Bf-committers] RC2 builds please! Rafael, We aren't using default scons rules for release builts. Things are much complicated to make binary file which would run on the most of platforms. U could check build_files/config/*.py if u want to see configs we're using for release builds ;) rsaave...@ono.com wrote: Hi, I am not the builder of the official release, I am only a blender follower wanting to help I have compiled r36007 on ubuntu Maverick (i686) (10.10) and Natty (i686) (11.04 beta1) using scons. The only but is that for Natty I have to create an user-config.py with the following line: BF_PYTHON_ABI_FLAGS = 'mu' because of python3.2- dev package. For the Maverick, I have python3.2 compiled by myself, so I have to indicate the path to python in BF_PYTHON. The compiling went smooth in both enviroments. Rafael Rios -- 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] RC2 builds please!
Ok, will write it tomorrow. pete larabell wrote: A wiki-page with description of building environment for release builds would be very useful. I found that when I started build on FreeBSD, I could certainly compile fine, but had no idea there even WAS a difference between those builds and release builds until I found out I had been doing it wrong. :) -- 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
We've got some quite big issues with new normals calculation and tools like solidify/displace modifiers, scale along normals, smooth subdivision and probably even more tools. I think this issues better be fixed before RC2. Thomas Dinges wrote: So let's not wait for this other solution, and make a RC 2 call soon please, so we get out the final asap. I am wondering why such scripts have to come in a few days before release... ;-) DingTo Am 04.04.2011 12:57, schrieb Tom M: After testing of the bevel script, it appears to only give correct results for the default cube and other quite simple cases (ie even such a simple thing as scaling the cube to be rectangular gives incorrect results). So some other bevel solution will be needed to be looked at. LetterRip ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- 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] RC2 builds please!
Rafael, We aren't using default scons rules for release builts. Things are much complicated to make binary file which would run on the most of platforms. U could check build_files/config/*.py if u want to see configs we're using for release builds ;) rsaave...@ono.com wrote: Hi, I am not the builder of the official release, I am only a blender follower wanting to help I have compiled r36007 on ubuntu Maverick (i686) (10.10) and Natty (i686) (11.04 beta1) using scons. The only but is that for Natty I have to create an user-config.py with the following line: BF_PYTHON_ABI_FLAGS = 'mu' because of python3.2- dev package. For the Maverick, I have python3.2 compiled by myself, so I have to indicate the path to python in BF_PYTHON. The compiling went smooth in both enviroments. Rafael Rios -- 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] RC2 builds please!
Linux 32/64 bit are laso there pete larabell wrote: correctly named files uploaded :) On Mon, Apr 4, 2011 at 1:24 PM, Ton Roosendaalt...@blender.org wrote: Hi, Haha, argh here too! I copied files over without checking, and then removed the freebsd RC1s there ;) Please reupload :) -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 4 Apr, 2011, at 20:22, pete larabell wrote: ARG! Ton, sorry I messed up the names on the FreeBSD builds... I was reading the email while making them and I actually named them RC1 (read it right off the screen.. eh). They are RC2. Can you rename or need I upload again? On Mon, Apr 4, 2011 at 12:02 PM, Ton Roosendaalt...@blender.org wrote: Hi all, Let's do the last official test build! It has looptools.py in the addons, but not on as default now. - Try to stick to r36004 - Put in the regular locations, I'll find/copy them and can align names too. - Names used will be like blender-2.57-RC1-r36004-platform.etc Platform builders: - Sergey Sharybin offered to do Linux builds - Jens Verwiebe will do OSX again. He can only do 10.5/10.6, we could use someone do 10.4 - Nathan Letwory: makes Windows zip and exe - Pete Larabell: got a FreeBSD test for us too? 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 ___ 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 RC1 build!
I've got static libs installed from debian-multimedia repo. They leads to some additional library dependencies, which i've solved with static linking too. Not big issue due to --strip-all (my blender binary have got smaller size than in rc0). Quick tests were fine. So maybe it's no so big issue with using ffmpeg from multimedia repo? Double-checking configuration atm (to be sure i haven't missed stuff) and making rules for blenderplayer and 32 bit (playing with 64bit builts atm). Original Message Subject: Re: [Bf-committers] Blender RC1 build! From: Ken Hughes khug...@pacific.edu To: bf-blender developers bf-committers@blender.org Date: 03/30/2011 09:42 PM I use the libraries from the blender svn trunk, prior to us removing them sometime around 2.52. I was never able to successfully build static ffmpeg libraries from elsewhere. Ken On 03/30/2011 07:38 AM, Juan Pablo Bouza wrote: Ken, is there anything special that you do with ffmpeg when compiling for linux? Cause me and some friends here have troubles with ffmpeg display in our own compilations, everything looks pixalated. Your compilations don't have this issue... If you do anything strange regarding this, Sergey should know :) and I want to know too :p From: t...@blender.org To: bf-committers@blender.org Date: Wed, 30 Mar 2011 15:53:48 +0200 Subject: [Bf-committers] Blender RC1 build! Hi platform team, Let's do another official test build! This one should have fixed openAL for linux, and for Windows the installer too. - Try to stick to r35899 - Put in the regular locations, I'll find/copy them and can align names too. - Names used will be like blender-2.57-RC1-r35899-platform.etc Platform builders: - Sergey Sharybin offered to do Linux builds, Ken has little time... and openAL and Collada are giving issues. - Damien: can you do OSX again? - Nathan L: Windows zip and exe - Pete Larabell: got a FreeBSD test for us? 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 ___ 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 RC1 build!
Ahh,, noticed this now. It doesn't happen in some frames, so was difficult to notice. Will try to fall back to ffmpeg from release builts (have no time to try newer builts/built myself). Will do this after 2.57. Andre Tibben wrote: I noticed this pixalation also when compiling with dynamic libraries in previous versions of Ubuntu. There where some patches applied to swscale in trunk svn, so these probably where the reason. It doesn't happen anymore for me in Ubuntu 10.10. Current version of ffmpeg (libswscale0) I have is 4:0.6-2ubuntu6. Andre On Wed, Mar 30, 2011 at 5:42 PM, Ken Hugheskhug...@pacific.edu wrote: I use the libraries from the blender svn trunk, prior to us removing them sometime around 2.52. I was never able to successfully build static ffmpeg libraries from elsewhere. Ken On 03/30/2011 07:38 AM, Juan Pablo Bouza wrote: Ken, is there anything special that you do with ffmpeg when compiling for linux? Cause me and some friends here have troubles with ffmpeg display in our own compilations, everything looks pixalated. Your compilations don't have this issue... If you do anything strange regarding this, Sergey should know :) and I want to know too :p From: t...@blender.org To: bf-committers@blender.org Date: Wed, 30 Mar 2011 15:53:48 +0200 Subject: [Bf-committers] Blender RC1 build! Hi platform team, Let's do another official test build! This one should have fixed openAL for linux, and for Windows the installer too. - Try to stick to r35899 - Put in the regular locations, I'll find/copy them and can align names too. - Names used will be like blender-2.57-RC1-r35899-platform.etc Platform builders: - Sergey Sharybin offered to do Linux builds, Ken has little time... and openAL and Collada are giving issues. - Damien: can you do OSX again? - Nathan L: Windows zip and exe - Pete Larabell: got a FreeBSD test for us? 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 ___ 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 developer IRC minutes, 27 March 2011
Have u checked if it still crashes in openal? I mean maybe it's more buggy libraries. And as i wrote u in private letter, i've published the same environment i'm using for my own builts. I've got lenny there and only python+openal compiled by hand. All the rest are from official repo and debian-mutimedia repo. Anyway, maybe it'll be ok for to to give me your user-config.py and `dpkg -l` from chroot environemnt (also list of self-compiled packages would be really cool). In this case we'll have to advantages: 1. I'll be able to investigate why it crashes (i've got quite enough free time nowadays) 2. We could setup buildbot environment very close to env. for release builts Ken Hughes wrote: Downloaded the openal-soft source from squeeze, compiled it statically under lenny, and rebuilt. Still getting the crash. Ken On 03/28/2011 08:32 AM, Sergey I. Sharybin wrote: Ken Hughes wrote: I get the crash also, however the chroot has the latest version of OpenAL available with debian lenny. Sounds like there's problem in lenny's openal. I've noticed no problems with openal 1.12.854 (from squeeze) or 1.13 (own built from orig sources). Anyway, lenny is getting to be quite old, so mayeb it's not big deal to upgrade this library in build environment and link staticlu against is? ___ 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 [35500] trunk/blender: update Bullet physics sdk to latest trunk/version 2.78
Hi, This commit broked compilation with cmake. First issue was fixed by me in rev35501 (simple typo in sources list). But the second issue is related to function prototype. It should be foo(void) (not foo()) if function takes no arguments. There are two ways: 1. Remove such restriction in extern/bullet2/CMakeLists.txt 2. Change prototypes in extern/bullet2/src/Bullet-C-Api.h to this rule. Original Message *Subject: *[Bf-blender-cvs] SVN commit: /data/svn/bf-blender [35500] trunk/blender: update Bullet physics sdk to latest trunk/version 2.78 *From: *Erwin Coumans blen...@erwincoumans.com *To: *bf-blender-...@blender.org *Date: *03/13/2011 01:34 AM Revision: 35500 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=35500 Author: erwin Date: 2011-03-12 20:34:17 + (Sat, 12 Mar 2011) Log Message: --- update Bullet physics sdk to latest trunk/version 2.78 add PhysicsConstraints.exportBulletFile(char* fileName) python command I'll be checking the bf-committers mailing list, in case this commit broke stuff scons needs to be updated, I'll do that in a second. ... @@ 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
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [35338] trunk/blender/source/blender: bugfix #26267
Hi, Ton! I'm afraid this commit broke to much things. - After some changes to render settings/node tree render result could be incorrect (black textures) - Sculpt mode with texture is unworkable after undo - Fixed Texture isn't workable First two things are quite easy to be fixed, but i have no idea how to handle Fixed Texture for image piting and Tiled for sculpting. Idea of initializing image when stroke begins wouldn't work well from artists point of view. As i showed you in IRC texture could be procedural and when it's sized to brush radius it could have noticable boundary between different tiles, but if it'll be re-calculated for needed relative coord (from initial brush pos) it'll be continious. You could compare http://www.pasteall.org/pic/9577 and http://www.pasteall.org/pic/9578 (first image is made with texture image created form node at initial step, second one - with re-calculation on-demand (how it's implemented atm)). In both cases i've used Magic texture node. Not sure if it's really bad. If not -- i've already got fix for paiting mode and could make changes to sculpting mode. If not -- we should create something smarter. And i'm not 100% sure what's happening with this ntreeBeginExecTree/ntreeEndExecTree. I've tried to add this near texture recalculation in fixed texture brush handler and it worked fine (but really slow). But why it's not affected with threading issues? I mean what would happen if preview widget would be triggered to redraw between my ntreeBeginExecTree/ .. ntreeEndExecTree block? Wouldn't it also lead to wrong texture recalculation? And if it've got copy of node tree why this BeginExec/EndExec is necessery? And i'm also afraid of preview refresh triggering between ntreeBeginExecTree() and actual image generating from texture. One more thing, suclpting uses openmp threads and texture re-calculation in them. looks like this also wouldn;t work correct. P.S. I'm afraid i'll be online only after ~12 a-dam time, so trunk could be a bit unusable in this areas until this time. Original Message Subject: [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [35338] trunk/blender/source/blender: bugfix #26267 From: Ton Roosendaal t...@blender.org To: bf-blender-...@blender.org Date: 03/03/2011 11:53 PM Revision: 35338 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=35338 Author: ton Date: 2011-03-03 18:53:07 + (Thu, 03 Mar 2011) Log Message: --- bugfix #26267 ImageWindow + 3D view texture paint + texture preview render + texture nodes. Threading hell! But it works now :) Modified Paths: -- trunk/blender/source/blender/blenkernel/BKE_texture.h trunk/blender/source/blender/blenkernel/intern/node.c trunk/blender/source/blender/blenkernel/intern/texture.c trunk/blender/source/blender/editors/render/render_preview.c trunk/blender/source/blender/editors/sculpt_paint/paint_image.c ... -- 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] New MinGW Maintainer
Welcome aboard, Ervin! Nathan Letwory wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2.3.2011 16:02, Campbell Barton wrote: Ervin Weber (lusque) has been added to to keep MinGW supported tested since no active devs were supporting it well. While this isn't a glamorous job it helps devs who were getting kicked for breaking MinGW (mostly me!). He would like to learn other areas of blender too so it might not all be tedious maintenance :) Welcome Ervin! Hurray! /Nathan - -- Nathan Letwory Letwory Interactive http://www.letworyinteractive.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNbk4gAAoJEKtfN7KsE0TtGS4H/RnSDyONGI+0KW+ad4Bvak6E HeewkdrVzX0SUbuwljvX45lGtjtBBxlvDPv2m2ZKnc8NQitisSISELvoZLbfz3V0 CgaL91odwyakKogzQtWQR2BbbkFkdLeddYLsqs7AkUhaU9WLpmHSUDcsPp1y6E7A Yyr/z8KeLucDJcUYtupgjSj6wV4LH671El7KyjvGhHVgn1Imk/GN1mImaeTkPnwG xxj7ndcD6oP8rTLKLj1BVtg5sF7BJLTSNopi8nXzRea3ganNA0fHu111jizPBhfF IxXjQ3/4emoapR6aGSe7ZZGYel75WZivJI+xhuInU4mL37UL6bxoY9CDJHe6sOg= =7/Go -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] Sculpting on deformed mesh. Renewed version
It's just testing troubles with ML... Sergey I. Sharybin wrote: Hello, Blender Community! Last two-three weeks i've been working under sculpting on deformed mesh TODO item. Got patch which is ready for testing. You'll find this patch and some additional notes here: http://projects.blender.org/tracker/index.php?func=detailaid=25665group_id=9atid=127 -- 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] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [34333] trunk/blender/source/blender/ editors/sculpt_paint: IRC bugreport fix: thumb brush works incorrect when using tablet by Da
Hi everybody! I've been discussing this fix with Ton today (it tooked ~1.5hr). This makes things work fine, but fix isn't very elegant from theretical point of view. Ton proposed idea of splitting cursor moving, pressure changing events (end tilt/angle changes in the future), so brushed would be able to avoid events they don't need. It's very brief description, but we'd better meet online all together and discuss things. Mailing list could be too slow for this, so maybe we could meet in IRC? Sergey Sharybin wrote: Revision: 34333 http://projects.blender.org/plugins/scmsvn/viewcvs.php?view=revroot=bf-blenderrevision=34333 Author: nazgul Date: 2011-01-15 14:48:44 + (Sat, 15 Jan 2011) Log Message: --- IRC bugreport fix: thumb brush works incorrect when using tablet by Dan McGrath (troubled) Quite silly fix, not sure if it could be smarter with current events/brushes design. Use pressure_value from first brush step for brushes which don't support strokes -- thumb. brush, brushes with anchored stroke method. Should be fixed in nicer way after events redesigning. P.S. Tried to place pressure saving into invaliants update fuunction, but it seens that this function wouldn't know about pressure yet. trunkated to prevent overquote ___ 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 meeting, sunday 12 dec, 2010
have u got all needed environments with needed static libs, needed version, etcetera? pete larabell wrote: I am able to build FreeBSD i386, amd64, and sparc64 (if we need spark64???) -- 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, sunday 12 dec, 2010
Ken Hughes uses special chroot-ed environments to get release builds. Reason of keeping this environments is quite simple -- dependend libraries should have the same version and not all of this libraries links staticly, so some twekas are needed. I could run any of Ken's builds, but, unfortunatelly, i've been unable to launch builds from graphicall at my home computer (missed ependencies, mistmatched lib versions...) That's what i meant pete larabell wrote: I've been building and uploading to graphicall.org (haven't in a few weeks... but otherwise have been). I'm not sure exactly what you are asking... I'm sorry :( Can you elaborate on your question a bit? On Wed, Dec 15, 2010 at 11:28 AM, Sergey I. Sharybing.ula...@gmail.comwrote: have u got all needed environments with needed static libs, needed version, etcetera? pete larabell wrote: I am able to build FreeBSD i386, amd64, and sparc64 (if we need spark64???) -- 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] Couple of patches for MinGW compilation
Personally i think it's not good idea to use tdm-gcc to build libraries -- better to use official mingw-gcc with sjlj exceptions model atm. Especially if library contains c++ code, but there could be other problems, maybe with glibc, not sure. Original Message Subject: [Bf-committers] Couple of patches for MinGW compilation From: alex liquidi...@ya.ru To: bf-committers@blender.org Date: 11/02/2010 07:01 AM Hi MinGW compilation broken at the time, firstly by outdated python library files and later by outdated Freetype library. I submitted couple of very simple patches https://projects.blender.org/tracker/index.php?func=detailaid=24461group_id=9atid=127 and https://projects.blender.org/tracker/index.php?func=detailaid=24495group_id=9atid=127 ___ 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] New Developer Doug Hammond (dougal2)
Congrats, Doug! Doug's recent work with Blender 2.5's render integration projects - LuxBlend Blendigo has resulted in an Exporter Framework (EF). Doug has been granted commit access to move EF into Blender's python modules directory for Addons to use. Welcome Doug! ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committer -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Proposal for sculpting on deformed mesh
Hi, Blender Community! I've been working under fixing problems with sculpting on deformed mesh and prepared small page with brief description of problem and way of getting rid of it. This page could be find there: http://wiki.blender.org/index.php/User:Nazg-gul/DeformedMeshSculpt I need to get your feedback to know if it's good approach, or it should be improved, or it shouldn't be used at all and there should be something else. P.S. Link to patch could be find at that page. Binary builds could also be found there (but it's first time I've publishing my own builds, so there could be troubles) NOTE: Linux builds linked agains glibc 2.8, haven't got enviroment with glibc2.7 atm, so this build would be avaliable later. -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Fixes for sculpting on shape keys
Hi, Blender Community! I've been working under sculpting on shape keys (to fix troubles reported in http://projects.blender.org/tracker/?func=detailaid=22262group_id=9atid=498). I've wrote about problems, which were leading to such behaviour and attached patch here: https://projects.blender.org/tracker/?func=detailaid=22601group_id=9atid=127 It'll be very good if Brecht will look at this fix and tell his opinion. And i've got one more qyestion. It's about undo stuff. If i do such sequence: 1. create object with two keys (i.e. basis and key 1) 2. lock key 1 3. Enter sculpt mode 4. make several strokes 5. switch to basis 6. make one more stroke 7. try to undo this stroke After the last action shape from key 1 would be propagated to basis, which isn't good. So, question: which behaviour would be the most expected and maybe somebody have any ideas how this behaviour could be reached? -- 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] Behaviour of Select every Nth for curves
Hi, This patch not fixing situation, when suer creates beizer curve from grease pencil and tries to select every nth vertex, but maybe this should be changing pencil-curve conversion to avoid situation, when handles has got the same coordinates as curve point. But there is another thing, which confed me in this patch. Why only one point should be selected? For example i've got curve consists of two non-connected splines and want to select every Nth of each of this splines? And maybe to avoid confusing things, we'd better select first point and then every Nth of each spline if nothing is selected? P.S. Should we change greas pencil-curve conversion to avoid troubles with handles i've wrote in fist paragraph? Rohith B.V. wrote: Hi Sergey, I made a small fix for this, see if it suits your requirements. https://projects.blender.org/tracker/?func=detailaid=21881group_id=9atid=127 On Thu, Apr 15, 2010 at 1:31 AM, Sergey I. Sharybing.ula...@gmail.comwrote: Hi, Blender community! There is such bug report in the tracker: http://projects.blender.org/tracker/?func=detailaid=21766group_id=9atid=498 I can't start working under it because i don't know how *should* this operator work. There are two ways: 1. Use selection strategy when user selects some base points and then every Nth point from selected would be selected. In this approach i've got two questions: how should this operator if nothing is selected? and if only beizer point's handle is selected should such point become selected (it's about curve created from grease pencil where handles have got the same coordinates as point and when user tries to select point only handle become selected so select every Nth does nothing)? 2. Deselection strategy (as it's done for meshes). In this case i've got one question: from which point calculation of every Nth should be started? there is no information about the last selected point. So in which way i should change this operator? -- 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-committer -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Behaviour of Select every Nth for curves
Hi, Blender community! There is such bug report in the tracker: http://projects.blender.org/tracker/?func=detailaid=21766group_id=9atid=498 I can't start working under it because i don't know how *should* this operator work. There are two ways: 1. Use selection strategy when user selects some base points and then every Nth point from selected would be selected. In this approach i've got two questions: how should this operator if nothing is selected? and if only beizer point's handle is selected should such point become selected (it's about curve created from grease pencil where handles have got the same coordinates as point and when user tries to select point only handle become selected so select every Nth does nothing)? 2. Deselection strategy (as it's done for meshes). In this case i've got one question: from which point calculation of every Nth should be started? there is no information about the last selected point. So in which way i should change this operator? -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
