[Bf-committers] Blender 2.43 RC1

Giuseppe Ghibò ghibo at mandriva.com
Mon Jan 8 20:13:21 CET 2007

Giuseppe Ghibò ha scritto:

> I've still two points/question/suggestion for the yafray section as well as the current maximum
> number of threads, but for this, later.

Here is, though it's just cosmetic.

1) I noticed now it's possible to use more than 2 threads for rendering. Indeed
in the past I did a test with official 2.42a and with up to 16 CPU (see this:
and the result was that beyond 8 processors blender rendering time
wasn't scaling anymore, so I guess your choice of limit to max 8 threads per 
blender sessions comes from this. Indeed the current blender behaviour is this:

a) as default blender starts always with 1 thread set.

b) if one would modify the # of threads, and then would save the configuration
with CTRL+U the # of saved threads is preserved.

Would be possible to have behaviour a) (i.e. default) to start instead from "1",
from a number of threads equal to the number of CPU recognized (at least under
Linux). In the past I made a patch for this, but to complete it I need that the 
number of current threads to be passed to the UI should be given before the
configuration is loaded from file (otherwise it would override the save
configuration which is not good). Any idea where to place this value (of
course NOT in .B.blend)?

2) The second problem regards Yafray rendering. When blender is started
and yafray choosen as rendering engine the default behaviour is to write
the scene to a temporary XML file in /tmp/YBtest.tga|xml or in a YBtest.tga|xml 
file in a dir defined in yafray_path.c_str(). Indeed the TEMP environment 
variable is checked, but this variable is used under Windows and not under Linux 
(which uses instead $TMP and|or $TMPDIR). Now don't consider the case where
one would save the configuration, but if one have the yafray plugin/lib working, 
generally is preferable to have yafray called trough the library rather
than trough a system("yafray /tmp/YBtest.xml"). A trivial solution
would be to remove the XML button and force always the calling of the plugin
forcing R.r.YFexportxml=1 somewhere. Indeed, as found our friend Mario found, 
this is not the best solution since often one could be interested in having the 
scene exported in a XML file for later modify this file manually (although this 
  actually can be considered a side-effect)
So my request is actually, how the calling of:

uiDefButBitS(block, TOGN, 1, B_REDR, "xml", 5,180,75,20, 
&G.scene->r.YFexportxml, 0, 0, 0, 0, "Export to an xml file and call yafray 
instead of plugin");

in source/blender/src/buttons_scene.c should be modified for having
the "default" behaviour of the XML button toggled instead of untoggled
(or viceversa)? Note that I mean only the toggling position not reverting
the behaviour of the action of the XML button. And second
the code where it writes the YBtest.tga|YBtest.xml IMHO needs a bit more checking:

2a) use TMP and TMPDIR as env enviroment var under Linux. in this way two
     blender user on the same machine won't write on the same file name.
2b) use of mktemp() function (well not available on every platform) to do
     the temporary XML file for yafray.

If you want for 2a) and eventually 2b) behaviour I could write the patch code.

As high end (e.g. beyond 2.43) the export to an XML file could maybe used as 
feature in the File/Export menu (e.g. one might be interested in achieving the 
XML file but still using the plugin for yafray rendering).



More information about the Bf-committers mailing list