[Bf-committers] REVIEW: Premultiplied alpha viewing option in viewer.
Offering up a patch for review that fixes images with premultiplied alpha being incorrectly rendered in the UV Image Editor window. Discussed at length with Lukas Tonne. It seems that a CompBuf doesn't retain any information regarding the type of alpha being passed through it. As a result, it is impossible to detect currently. Even then, it is likely prudent to leave this decision up to the artist. The patch includes a toggle that appears when an artist chooses to display the image with alpha in the UV Image Editor. It has a separate button with a custom designed icon. The patch turns on the proper glBlendFunc mode to GL_ONE for associated alpha images and GL_SRC_ALPHA for unassociated alpha. It should also be noted that for some legacy ATI card implementation reasoning, that by default the viewer only displays 8bpc sources. The code is more or less intact but commented out for float support. It may be worth considering either offering up a WITH_FLOAT_GL in the compile options or a GL depth selection between 8bpc and 32bpc float. With respect, TJS http://projects.blender.org/tracker/index.php?func=detail&aid=28782&group_id=9&atid=127 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] redo operator with last used settings (patch)
On Thu, Sep 29, 2011 at 10:31 PM, Martin Poirier wrote: > When you switched to edit mode, the add grid operator is no longer the last > one on the stack and can no longer be tweaked. > > Don't enter edit mode before tweaking the properties. > > Martin Problem is that if you press num 7 top view and add a grid you can't see what is there until you go into edit mode and at that point you can't change it. I know that in a perfect calculated world you would just figure out what you need beforehand but it often does not work out that way. After all we are artists and not math students. :-) You get that same problem with a smooth sphere sometimes to, I want to SEE the verts and lines as I adjust it. I like the sounds of Jonathan's idea. Is it doable? -- Douglas E Knapp Creative Commons Film Group, Helping people make open source movies with open source software! http://douglas.bespin.org/CommonsFilmGroup/phpBB3/index.php Massage in Gelsenkirchen-Buer: http://douglas.bespin.org/tcm/ztab1.htm Please link to me and trade links with me! Open Source Sci-Fi mmoRPG Game project. http://sf-journey-creations.wikispot.org/Front_Page http://code.google.com/p/perspectiveproject/ ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] REVIEW: Predivide for premultiplied images patch. ATTN: Brecht
Thanks for looking Brecht. Some clarifications as discussed via IRC but put here for posterity and searching: On Fri, Sep 30, 2011 at 7:37 AM, Brecht Van Lommel wrote: > * The BLI_CM_ should not be in blenlib, there should be separate flags > in DNA_image_types.h and IMB_imbuf_types.h. This adds a bit more code, > but these things should be decoupled. Not entirely clear here. At some point relevant color management flags should migrate to the colormanagement.c/h file when we end up with one. I dropped the flags into math_color.h as it seemed the most appropriate location for color management related flags. I can easily move them somewhere else. > * I'd also be inclined to not add a separate cm_flags but use the > existing flag members in ImBuf and Image. At a bare minimum we will likely require two additional elements for a color management system. An int value is sub-optimal as it is currently implemented, and probably isn't terribly future friendly. I'd suggest we will probably require a color management struct or, alternatively, a 240ish char string and an int flag. This should initially cover OCIO implementation. A struct may make even more sense here in the event that the CM system widens in the future, requiring ICC strings or like details. > * Predivide should check if the alpha is zero and avoid dividing in such > cases. Check. > * It would help performance to compute invalpha = 1.0f/alpha; and then > multiply by that instead of doing 3 divisions. Check. > * I think the predivide flag from the scene should be set in a few > more places, like for compositing out nodes, viewer nodes, .. . Now > it's only being done on rendering an animation to disk. It seems to take there when set in the Shading panel according to tests. > * It's also not clear to me yet that the predivide happens in all > places it's needed, will need to check this more closely. Not sure we will ever know that with certainty within our current system. Luckily with the solid test images, relevant developers and artists can test the impact, and perhaps even tag code paths with comments. Unfortunately there are two layers of complexity here, and they both look extremely similar to the eye: 1) Blender not properly handling premultiplied alpha in all instances via GL calls (GL_ONE versus GL_SRC_ALPHA in glBlendFunc as an example) and Image / ImBuf flags. 2) Blender not handling linearization with premultiplied alpha images correctly. Coupled with above. > I think of this as a temporary solution that we have to leave off by > default for compatibility now, but should be turned on by default once > we have a better premul/key system, where we actually know which > buffers are in which alpha format. Agree. If the flags are available and cover 80% use case, it should be sufficient for the time being. With respect, TJS ___ 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 [40717] branches/bmesh/blender/source/ blender/editors/mesh/bmesh_select.c: Fix a memory leak in loop-to-region tool
A problem with bmesh build under msvc : source\blender\editors\mesh\mesh_navmesh.c(97) : error C2039: 'getFaceArray' is not a member of 'DerivedMesh' jms ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] REVIEW: Predivide for premultiplied images patch. ATTN: Brecht
Hi, A quick review: * The BLI_CM_ should not be in blenlib, there should be separate flags in DNA_image_types.h and IMB_imbuf_types.h. This adds a bit more code, but these things should be decoupled. * I'd also be inclined to not add a separate cm_flags but use the existing flag members in ImBuf and Image. * Predivide should check if the alpha is zero and avoid dividing in such cases. * It would help performance to compute invalpha = 1.0f/alpha; and then multiply by that instead of doing 3 divisions. * I think the predivide flag from the scene should be set in a few more places, like for compositing out nodes, viewer nodes, .. . Now it's only being done on rendering an animation to disk. * It's also not clear to me yet that the predivide happens in all places it's needed, will need to check this more closely. I think of this as a temporary solution that we have to leave off by default for compatibility now, but should be turned on by default once we have a better premul/key system, where we actually know which buffers are in which alpha format. Brecht. On Thu, Sep 29, 2011 at 7:30 AM, Troy Sobotka wrote: > In the ever ongoing deluxe saga of trying to get Blender to correctly > ingest premultiplied alpha images such as TIFFs, the following patch > is offered for review. Special thanks go to Brecht for his extreme > patience and sagely advice. > > ATTN: This patch also adds in the three lines of code to properly > update the window region when the update signal is set. This code was > supplied by Brecht. > > Based on feedback from Brecht, the patch now is purely artist driven. > The artist toggles are available via the Image Input node and the UV > Image propertiers pane for ingestion. For output, if Color Management > is selected, a Predivide box is offered in the Properties box in the > Shading region. > > Q: What does it do? > A: The patch predivides the RGB values when the artist driven toggles > are selected. This permits accurate sRGB to linear and vice versa > conversions. > > Q: Does it allow me to load premultiplied alpha TIFF images correctly > or use my premultiplied Blender renders in the VSE? > A: Yes. In the case of the latter, you will need to unmangle the > existing renders via the following technique. > > Q: Does it allow me to unmangle or reuse legacy renders I have made > with Blender using premultiplied alpha? > A: Yes. In the case of previously mangled alpha images, the correct > process would be to leave Predivide off for ingestion and turn > Predivide on for output. > > Q: What is the correct workflow involved with premultiplied data > ingestion into a linear environment? > A: The correct workflow is to select Predivide for all sRGB > premultiplied alpha images and only select Predivide if you are saving > with a premultiplied alpha. > > Q: Is there a set of images to test this with? > A: Yes. In the attached bug report there is a well crafted > premultiplied alpha foreground plate and a complimentary fully opaque > background. This pattern designed by Guillermo Espertino will quickly > reveal inconsistencies in sRGB premultiplied conversions. It would be > excellent if Blender experts of their respective domains would use the > two images to test where we need to extend this technique. > > http://projects.blender.org/tracker/?func=detail&atid=498&aid=28085&group_id=9 > > Technical details: > > 1) Adds one flag to ImBuf and the corresponding iff for plugins. > 2) Adds one variable to Image to hold the cm_flags. > 3) Adds one bitwise flag define for use with the color_mgt_flag in > RenderData for Scene access. > 4) Modifies the IMB_linear_from_rect and IMB_rect_from_linear to honor > the input and output flags. > 5) Modifies pipeline.c to honor the Scene setting flag. > 6) A few adjustments within image.c to copy the new cm_flags in the > Image struct to the ImBuf struct. > 7) Updates the update window manager code according to instructions by Brecht. > > With respect, > TJS > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Awards!
Ah Ah Ah :D Brillant ! 2011/9/30 Ton Roosendaal > Hi devs, > > Congrats with the Autodesk-3Dworld award for Blender 2.5 :) > http://www.blender.org/bf/IMG_0101.JPG > > -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 > -- 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
Re: [Bf-committers] redo operator with last used settings (patch)
I wonder if there would be a way to detect whether or not you actually made any edits in edit-mode, and save the previous operator a little bit longer until you do. That way if you enter edit-mode on accident, or realize that you wanted one more column in that grid, you could go back without making any changes and fix it. Jonathan On Fri, Sep 30, 2011 at 4:19 AM, Knapp wrote: > On Thu, Sep 29, 2011 at 9:09 AM, "Martin Bürbaum" > wrote: > >> A few times this has been requested on IRC so I decided to look into it. > >> This is so if you add a cylinder for with 3 sides, the next time you > >> add it will use 3 sides again. > > > > Can't say much about the code, but from a user perspective a small button > to "Reset to default values" might be a good idea. If this is supposed to be > the default behaviour that is. > > > > Otherwise the change sounds pretty useful - especially for repeated use > of more complex operators/parameters. > > > > Cheers, > > Martin > > > > Not sure if this falls into the same coding. > When I add a grid in object mode and switch to edit mode, I can no > longer change the number of sides/grids. It would be really good to be > able to do so. At this point I add the grid switch to edit, delete all > the verts and then re-add the grid. I would think this problem also > exists for other shapes and their settings? > > Best > > -- > Douglas E Knapp > > Creative Commons Film Group, Helping people make open source movies > with open source software! > http://douglas.bespin.org/CommonsFilmGroup/phpBB3/index.php > > Massage in Gelsenkirchen-Buer: > http://douglas.bespin.org/tcm/ztab1.htm > Please link to me and trade links with me! > > Open Source Sci-Fi mmoRPG Game project. > http://sf-journey-creations.wikispot.org/Front_Page > http://code.google.com/p/perspectiveproject/ > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Awards!
Hi devs, Congrats with the Autodesk-3Dworld award for Blender 2.5 :) http://www.blender.org/bf/IMG_0101.JPG -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] 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] obj location & matrix
super cool thx guys ! 2011/9/30 Campbell Barton > This has come up a few times, documented it in the gotcha's section: > > http://www.blender.org/documentation/blender_python_api_2_59_3/info_gotcha.html#no-updates-after-setting-values > > On Fri, Sep 30, 2011 at 9:33 AM, Matt Ebb wrote: > > Oh, my mistake - I've actually completely misunderstood your original > > question (serves me right for replying without coffee..) > > > > To get a new matrix, you might need to update the depgraph via > > scene.update() etc. after you've modified the object's position. > > > > cheers > > > > Matt > > > > > > On Fri, Sep 30, 2011 at 9:26 AM, François T. >wrote: > > > >> oups sorry didn't even know about it. I'll subscribe to it then. > >> just one thing though, so this is updated only if the user moved the > object > >> himself, but not if we change position via py script ? that's what you > are > >> saying ? > >> > >> thx > >> > >> 2011/9/29 Matt Ebb > >> > >> > On Fri, Sep 30, 2011 at 8:02 AM, François T. < > francoistarl...@gmail.com > >> > >wrote: > >> > > >> > > > >> > > > empty_tmp.matrix_world.to_translation().x > >> > > > >> > > >> > afaik, matrix.to_translation() returns a vector copy of the > translation > >> > component. It's not modifying the values in the original matrix. > >> > > >> > btw, bf-python mailing list is better for this :) > >> > > >> > matt > >> > ___ > >> > 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 > > > > > > -- > - Campbell > ___ > 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
Re: [Bf-committers] About moving the blender-translation to blender.org?
Hi, Nathan Letwory will help out with it, just get him connected in irc :) -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 28 Sep, 2011, at 18:15, xiangquan xiao wrote: > At the beginning I just wanted to manage Chinese PO at [1], > but later more and more guys came and started to work on their > languages. > The repository is at [2], the tree is like > ---/trunk: Just a copy of blender trunk's /po directory. > ---/branches: Every running translation thread. They update themselves > according to the /trunk/blender.pot, and merge into trunk when most > translations done. > > Now we think it's time for moving the program to the official > location and > under official management. Right, Ton? I noticed that it has been in > the > weekly meeting notes. > > It must be an easy work. is a root member, > he can > help on everything, I think.( I myself is on a two weeks' vacation, > traveling around the country ^_^ ) > > === > [1] http://code.google.com/p/blender-translation > [2] https://blender-translation.googlecode.com/svn > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [40709] trunk/blender: fix for crash generating messages.txt, I wasn' t getting this crash because I had 'WITH_PYTHON_SAFETY' enab
But It should have crashed :), every dynamic enum was accessing freed memory.
This is still precarious - any one of these enums stored for access
after the iterator ends can crash on access.
On Fri, Sep 30, 2011 at 5:51 PM, Dalai Felinto wrote:
> Using windows default python setting wasn't crashing either, just so you
> know. (Built with Scons+msvc 32bits)
>
> --
> Dalai
>
> Campbell Barton wrote:
>
>>Revision: 40709
>>
>> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=40709
>>Author: campbellbarton
>>Date: 2011-09-30 07:47:45 + (Fri, 30 Sep 2011)
>>Log Message:
>>---
>>fix for crash generating messages.txt, I wasn't getting this crash because I
>>had 'WITH_PYTHON_SAFETY' enabled which was using different iterators (which
>>dont crash), now there on by default.
>>
>>made headless and no-python configurations work again and added
>>--factory-startup to doc building command.
>>
>>Modified Paths:
>>--
>> trunk/blender/GNUmakefile
>> trunk/blender/po/README.txt
>> trunk/blender/source/blender/editors/interface/interface_draw.c
>> trunk/blender/source/blender/python/intern/bpy_rna.h
>> trunk/blender/source/blender/windowmanager/intern/wm_init_exit.c
>> trunk/blender/source/blender/windowmanager/intern/wm_operators.c
>>
>>Modified: trunk/blender/GNUmakefile
>>===
>>--- trunk/blender/GNUmakefile 2011-09-30 05:36:56 UTC (rev 40708)
>>+++ trunk/blender/GNUmakefile 2011-09-30 07:47:45 UTC (rev 40709)
>>@@ -164,7 +164,7 @@
>> # Other Targets
>> #
>> translations:
>>- $(BUILD_DIR)/bin/blender --background --python po/update_msg.py
>>+ $(BUILD_DIR)/bin/blender --background --factory-startup --python
>>po/update_msg.py
>> python3 po/update_pot.py
>> python3 po/update_po.py
>> python3 po/update_mo.py
>>
>>Modified: trunk/blender/po/README.txt
>>===
>>--- trunk/blender/po/README.txt 2011-09-30 05:36:56 UTC (rev 40708)
>>+++ trunk/blender/po/README.txt 2011-09-30 07:47:45 UTC (rev 40709)
>>@@ -37,9 +37,10 @@
>>
>> If there's no message in .po file you want to translate, probably .po file
>> should be updated.
>> Use the following steps for this:
>>-- With newly compiled blender run `blender --background --python
>>update_msg.py` to update
>>- messages.txt file (this file contains strings collected automatically from
>>RNA system and
>>- python UI scripts)
>>+- With newly compiled blender run:
>>+ `blender --background --factory-startup --python update_msg.py`
>>+ to update messages.txt file (this file contains strings collected
>>+ automatically from RNA system and python UI scripts)
>> - Run update_pot.py script which will update blender.pot file. This file
>> contains all
>> strings which should be transated.
>> - Run update_po.py script to merge all .po files with blender.pot (so all
>> .po files
>>
>>Modified: trunk/blender/source/blender/editors/interface/interface_draw.c
>>===
>>--- trunk/blender/source/blender/editors/interface/interface_draw.c
>>2011-09-30 05:36:56 UTC (rev 40708)
>>+++ trunk/blender/source/blender/editors/interface/interface_draw.c
>>2011-09-30 07:47:45 UTC (rev 40709)
>>@@ -466,6 +466,7 @@
>> {
>> #ifdef WITH_HEADLESS
>> (void)rect;
>>+ (void)but;
>> #else
>> ImBuf *ibuf= (ImBuf *)but->poin;
>> //GLint scissor[4];
>>
>>Modified: trunk/blender/source/blender/python/intern/bpy_rna.h
>>===
>>--- trunk/blender/source/blender/python/intern/bpy_rna.h 2011-09-30
>>05:36:56 UTC (rev 40708)
>>+++ trunk/blender/source/blender/python/intern/bpy_rna.h 2011-09-30
>>07:47:45 UTC (rev 40709)
>>@@ -44,9 +44,6 @@
>> /* support for inter references, currently only needed for corner case */
>> #define USE_PYRNA_STRUCT_REFERENCE
>>
>>-/* use real collection iterators rather than faking with a list */
>>-#define USE_PYRNA_ITER
>>-
>> #else /* WITH_PYTHON_SAFETY */
>>
>> /* default, no defines! */
>>@@ -67,6 +64,11 @@
>> * so prefer the leak to the memory bloat for now. */
>> // #define PYRNA_FREE_SUPPORT
>>
>>+/* use real collection iterators rather than faking with a list
>>+ * this is needed so enums can be iterated over without crashing,
>>+ * since finishing the iteration frees temp allocated enums */
>>+#define USE_PYRNA_ITER
>>+
>> /* --- end bpy build options --- */
>>
>> struct ID;
>>
>>Modified: trunk/blender/source/blender/windowmanager/intern/wm_init_exit.c
>>===
>>--- trunk/blender/source/blender/windowmanager/intern/wm_init_exit.c
>>2011-09-30 05:36:56 UTC (rev 40708)
>>+++ trunk/blender/source/blender/windowmanager/intern/wm_init_exit.c
>>2011-09-30 07:47:45 UTC (rev 40709)
>>@@ -427,6 +
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [40709] trunk/blender: fix for crash generating messages.txt, I wasn' t getting this crash because I had 'WITH_PYTHON_SAFETY' enab
Using windows default python setting wasn't crashing either, just so you know.
(Built with Scons+msvc 32bits)
--
Dalai
Campbell Barton wrote:
>Revision: 40709
>
> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=40709
>Author: campbellbarton
>Date: 2011-09-30 07:47:45 + (Fri, 30 Sep 2011)
>Log Message:
>---
>fix for crash generating messages.txt, I wasn't getting this crash because I
>had 'WITH_PYTHON_SAFETY' enabled which was using different iterators (which
>dont crash), now there on by default.
>
>made headless and no-python configurations work again and added
>--factory-startup to doc building command.
>
>Modified Paths:
>--
>trunk/blender/GNUmakefile
>trunk/blender/po/README.txt
>trunk/blender/source/blender/editors/interface/interface_draw.c
>trunk/blender/source/blender/python/intern/bpy_rna.h
>trunk/blender/source/blender/windowmanager/intern/wm_init_exit.c
>trunk/blender/source/blender/windowmanager/intern/wm_operators.c
>
>Modified: trunk/blender/GNUmakefile
>===
>--- trunk/blender/GNUmakefile 2011-09-30 05:36:56 UTC (rev 40708)
>+++ trunk/blender/GNUmakefile 2011-09-30 07:47:45 UTC (rev 40709)
>@@ -164,7 +164,7 @@
> # Other Targets
> #
> translations:
>- $(BUILD_DIR)/bin/blender --background --python po/update_msg.py
>+ $(BUILD_DIR)/bin/blender --background --factory-startup --python
>po/update_msg.py
> python3 po/update_pot.py
> python3 po/update_po.py
> python3 po/update_mo.py
>
>Modified: trunk/blender/po/README.txt
>===
>--- trunk/blender/po/README.txt2011-09-30 05:36:56 UTC (rev 40708)
>+++ trunk/blender/po/README.txt2011-09-30 07:47:45 UTC (rev 40709)
>@@ -37,9 +37,10 @@
>
> If there's no message in .po file you want to translate, probably .po file
> should be updated.
> Use the following steps for this:
>-- With newly compiled blender run `blender --background --python
>update_msg.py` to update
>- messages.txt file (this file contains strings collected automatically from
>RNA system and
>- python UI scripts)
>+- With newly compiled blender run:
>+ `blender --background --factory-startup --python update_msg.py`
>+ to update messages.txt file (this file contains strings collected
>+ automatically from RNA system and python UI scripts)
> - Run update_pot.py script which will update blender.pot file. This file
> contains all
> strings which should be transated.
> - Run update_po.py script to merge all .po files with blender.pot (so all .po
> files
>
>Modified: trunk/blender/source/blender/editors/interface/interface_draw.c
>===
>--- trunk/blender/source/blender/editors/interface/interface_draw.c
>2011-09-30 05:36:56 UTC (rev 40708)
>+++ trunk/blender/source/blender/editors/interface/interface_draw.c
>2011-09-30 07:47:45 UTC (rev 40709)
>@@ -466,6 +466,7 @@
> {
> #ifdef WITH_HEADLESS
> (void)rect;
>+ (void)but;
> #else
> ImBuf *ibuf= (ImBuf *)but->poin;
> //GLint scissor[4];
>
>Modified: trunk/blender/source/blender/python/intern/bpy_rna.h
>===
>--- trunk/blender/source/blender/python/intern/bpy_rna.h 2011-09-30
>05:36:56 UTC (rev 40708)
>+++ trunk/blender/source/blender/python/intern/bpy_rna.h 2011-09-30
>07:47:45 UTC (rev 40709)
>@@ -44,9 +44,6 @@
> /* support for inter references, currently only needed for corner case */
> #define USE_PYRNA_STRUCT_REFERENCE
>
>-/* use real collection iterators rather than faking with a list */
>-#define USE_PYRNA_ITER
>-
> #else /* WITH_PYTHON_SAFETY */
>
> /* default, no defines! */
>@@ -67,6 +64,11 @@
> * so prefer the leak to the memory bloat for now. */
> // #define PYRNA_FREE_SUPPORT
>
>+/* use real collection iterators rather than faking with a list
>+ * this is needed so enums can be iterated over without crashing,
>+ * since finishing the iteration frees temp allocated enums */
>+#define USE_PYRNA_ITER
>+
> /* --- end bpy build options --- */
>
> struct ID;
>
>Modified: trunk/blender/source/blender/windowmanager/intern/wm_init_exit.c
>===
>--- trunk/blender/source/blender/windowmanager/intern/wm_init_exit.c
>2011-09-30 05:36:56 UTC (rev 40708)
>+++ trunk/blender/source/blender/windowmanager/intern/wm_init_exit.c
>2011-09-30 07:47:45 UTC (rev 40709)
>@@ -427,6 +427,8 @@
>* the pyDriver bug can be fixed if it happens again we can
> deal with it then */
> BPY_python_end();
> }
>+#else
>+ (void)do_python;
> #endif
>
> GPU_global_buffer_pool_free();
>
>Modified: trunk/blender/source/blender/windowmanager/intern/wm_operators.c
>=
Re: [Bf-committers] obj location & matrix
This has come up a few times, documented it in the gotcha's section: http://www.blender.org/documentation/blender_python_api_2_59_3/info_gotcha.html#no-updates-after-setting-values On Fri, Sep 30, 2011 at 9:33 AM, Matt Ebb wrote: > Oh, my mistake - I've actually completely misunderstood your original > question (serves me right for replying without coffee..) > > To get a new matrix, you might need to update the depgraph via > scene.update() etc. after you've modified the object's position. > > cheers > > Matt > > > On Fri, Sep 30, 2011 at 9:26 AM, François T. wrote: > >> oups sorry didn't even know about it. I'll subscribe to it then. >> just one thing though, so this is updated only if the user moved the object >> himself, but not if we change position via py script ? that's what you are >> saying ? >> >> thx >> >> 2011/9/29 Matt Ebb >> >> > On Fri, Sep 30, 2011 at 8:02 AM, François T. > > >wrote: >> > >> > > >> > > > empty_tmp.matrix_world.to_translation().x >> > > >> > >> > afaik, matrix.to_translation() returns a vector copy of the translation >> > component. It's not modifying the values in the original matrix. >> > >> > btw, bf-python mailing list is better for this :) >> > >> > matt >> > ___ >> > 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 > -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
