Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [34732] trunk/blender/release/bin/ blender-thumbnailer.py: patch [#25972] blender-thumbnailer.py: GVFS support
Hi Campbell,
I would like to know if the Blender thumbnailer deactivate python scripts
inside the blend.
Thumbnailers are big security issues. A malisous .blend on a USB memory
stick could serve as infection vector on all platform. Executing some of the
py scripts inside would make it too easy.
Xavier
2011/2/9 Campbell Barton
> Revision: 34732
>
> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=34732
> Author: campbellbarton
> Date: 2011-02-09 02:09:30 + (Wed, 09 Feb 2011)
> Log Message:
> ---
> patch [#25972] blender-thumbnailer.py: GVFS support
> from Shinsuke Irie (irie) with some minor edits.
>
> Shinsuke's description from the tracker:
> ---
> I have implemented GVFS framework support of blender-thumbnailer.py which
> allows some file managers like Nautilus and Thunar to show thumbnails in
> trash or network directories. If Python's gio module is available, the
> thumbnailer uses it to access to filesystems mounted via GVFS. This change
> shouldn't affect desktop environments other than GNOME and XFCE.
>
> A function gvfs_open() in this patch is defined to solve a stupid
> incompatibility between Python file object and GIO Seekable object.
>
> On Ubuntu 10.10, I confirmed thumbnails can be generated for file://,
> trash://, sftp://, and smb://.
>
> Modified Paths:
> --
>trunk/blender/release/bin/blender-thumbnailer.py
>
> Modified: trunk/blender/release/bin/blender-thumbnailer.py
> ===
> --- trunk/blender/release/bin/blender-thumbnailer.py2011-02-09 02:09:25
> UTC (rev 34731)
> +++ trunk/blender/release/bin/blender-thumbnailer.py2011-02-09 02:09:30
> UTC (rev 34732)
> @@ -24,27 +24,49 @@
> Thumbnailer runs with python 2.6 and 3.x.
> To run automatically with nautilus:
>gconftool --type boolean --set
> /desktop/gnome/thumbnailers/application@x-blender/enable true
> - gconftool --type string --set
> /desktop/gnome/thumbnailers/application@x-blender/command
> "blender-thumbnailer.py %i %o"
> + gconftool --type string --set
> /desktop/gnome/thumbnailers/application@x-blender/command
> "blender-thumbnailer.py %u %o"
> """
>
> import struct
>
>
> +def open_wrapper_get():
> +""" wrap OS spesific read functionality here, fallback to 'open()'
> +"""
> +
> +def open_gio(path, mode):
> +g_file = gio.File(path).read()
> +g_file.orig_seek = g_file.seek
> +
> +def new_seek(offset, whence=0):
> +return g_file.orig_seek(offset, [1, 0, 2][whence])
> +
> +g_file.seek = new_seek
> +return g_file
> +
> +try:
> +import gio
> +return open_gio
> +except ImportError:
> +return open
> +
> +
> def blend_extract_thumb(path):
> import os
> +open_wrapper = open_wrapper_get()
>
> # def MAKE_ID(tag): ord(tag[0])<<24 | ord(tag[1])<<16 | ord(tag[2])<<8
> | ord(tag[3])
> REND = 1145980242 # MAKE_ID(b'REND')
> TEST = 1414743380 # MAKE_ID(b'TEST')
>
> -blendfile = open(path, 'rb')
> +blendfile = open_wrapper(path, 'rb')
>
> head = blendfile.read(12)
>
> if head[0:2] == b'\x1f\x8b': # gzip magic
> import gzip
> blendfile.close()
> -blendfile = gzip.open(path, 'rb')
> +blendfile = gzip.GzipFile('', 'rb', 0, open_wrapper(path, 'rb'))
> head = blendfile.read(12)
>
> if not head.startswith(b'BLENDER'):
>
> ___
> Bf-blender-cvs mailing list
> bf-blender-...@blender.org
> http://lists.blender.org/mailman/listinfo/bf-blender-cvs
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] CMake question - adding a library in Blender CMakeLists.txt
Hi developers,
while of cause it is possible to become master of general CMake,
still existing CMakeLists.txt s are done specifically for building Blender.
Now my task:
I'd like to link Blender with external lib ( I do it on windows
(win64) if it is important).
I see an example for jpeg library:
set(JPEG_LIBRARIES libjpeg)
if I comment the line - jpeg won't appear, OK
but if I rename a line
to
set(JJPEG_LIBRARIES libjpeg)
I again won't get a library in project.
still there are no any JPEG_LIBRARIES being used anywhere in other txt files.
so question is - how lib is actually added after being set a value?
if to extend question to libpaths then - where LIBPATH s are added such as
set(ZLIB_LIBPATH ${ZLIB}/lib)
as there is the same problem - while nowhere else ZLIB_LIBPATH is
mentioned - but it works,
now making
set(ZZLIB_LIBPATH ${ZLIB}/lib)
would make nothing.
so where these definitions are enacted, so that
libraries and library paths are added?
as
link_directories CMake directive is not used
and these libraries seems are not added to
BLENDER_SORTED_LIBS
which go to
target_link_libraries(blender ${BLENDER_SORTED_LIBS} )
?
Regards
Sergey
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Problems with premultiplied alpha channel in 8 bit images
I use PNG files a lot for my work. I found that 8-bit RGBA files (non-linear, with premultiplied alpha channel) saved from the compositor have some sort of alpha contamination in the semi-transparent pixels that makes them imposible to compose correctly in other than Blender's compositor. If the output has straight alpha (converted from premul with an alpha convert node), there are no bright artifacts. If the stored file is in linear space, there are no artifacts (both with premul and straight alpha). The artifacts become evident only in viewer* (checkers background) or taking the premulled file into a different application (GIMP, Nuke) or to Blender's VSE. Inside Blender's compositor there are no visible artifacts. Samples: http://dl.dropbox.com/u/255376/alpha-bug/Alpha-Bug-Nuke.jpg http://dl.dropbox.com/u/255376/alpha-bug/result%28VSE%20or%20GIMP%29.jpg *) phonybone did some changes in the viewer and now the bright halo is somewhat hidden. Now it's darker, but there's still alpha contamination in the image pixels Theory: Linear>log and log>linear conversions are affecting alpha channel in premultiplied alpha images. The bright artifacts are caused by the division of the corrected R*A,G*A,B*A pixels by the un-corrected alpha. I tried to re-create this incorrect behaviour by gamma-correcting the alpha channel artificially (I know it's wrong, I did it intentionally trying to confirm the bug) According to this graphic (http://www.blender.org/typo3temp/pics/ea3a513824.jpg) all 8bit images are converted to linear when used as inputs in compositor and converted from linear to log in the output stage. What happens with premultiplied alpha in that case? Is it divided before linearizing and multiplied before gamma corrected or it is not? I described the problem to phonybone in an IRC chat yesterday. He told me that seb könig recently pointed out that displaying the alpha channel (in image editor or compo backdrop) differs from color decompose result. That might be the same problem. Any ideas? ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] CMake question - adding a library in Blender CMakeLists.txt
Hi, > Now my task: > I'd like to link Blender with external lib ( I do it on windows > (win64) if it is important). > OK got it - it is in macros.cmake Regards Sergey ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Problems with premultiplied alpha channel in 8 bit images
On Thu, Feb 10, 2011 at 7:27 AM, gespert...@gmail.com wrote: > I use PNG files a lot for my work. I found that 8-bit RGBA files > (non-linear, with premultiplied alpha channel) saved from the > compositor have some sort of alpha contamination in the > semi-transparent pixels that makes them imposible to compose correctly > in other than Blender's compositor. Troy mentioned this to me a bit earlier but I didn't have a chance to look into it deeply yet. One thing that comes to mind though, is that does this only happen with PNG files? or TIFFs as well? According to the PNG spec [1], alpha is meant to be saved un-associated (un-premultiplied). If Blender is saving premultiplied alpha in a PNG then it's in violation of the spec, and I'm wondering if this may cause problems later on. It would be good to see some testing with different image formats. cheers Matt [1] http://www.libpng.org/pub/png/spec/1.2/PNG-Rationale.html -> 12.8 ___ 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 [34732] trunk/blender/release/bin/ blender-thumbnailer.py: patch [#25972] blender-thumbnailer.py: GVFS support
Thumbs are generated by Blender on save and stored in the file as RGBA
pixels. There is no risk.
On this topic, I keep wanting to submit my Windows thumbnail handler but
I don't know where it should go in the source tree. It has to be a
dynamic lib, but it's not exactly external...any suggestions?
On 09/02/2011 2:34, Xavier Thomas wrote:
> Hi Campbell,
>
> I would like to know if the Blender thumbnailer deactivate python scripts
> inside the blend.
>
> Thumbnailers are big security issues. A malisous .blend on a USB memory
> stick could serve as infection vector on all platform. Executing some of the
> py scripts inside would make it too easy.
>
> Xavier
>
>
> 2011/2/9 Campbell Barton
>
>> Revision: 34732
>>
>> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=34732
>> Author: campbellbarton
>> Date: 2011-02-09 02:09:30 + (Wed, 09 Feb 2011)
>> Log Message:
>> ---
>> patch [#25972] blender-thumbnailer.py: GVFS support
>> from Shinsuke Irie (irie) with some minor edits.
>>
>> Shinsuke's description from the tracker:
>> ---
>> I have implemented GVFS framework support of blender-thumbnailer.py which
>> allows some file managers like Nautilus and Thunar to show thumbnails in
>> trash or network directories. If Python's gio module is available, the
>> thumbnailer uses it to access to filesystems mounted via GVFS. This change
>> shouldn't affect desktop environments other than GNOME and XFCE.
>>
>> A function gvfs_open() in this patch is defined to solve a stupid
>> incompatibility between Python file object and GIO Seekable object.
>>
>> On Ubuntu 10.10, I confirmed thumbnails can be generated for file://,
>> trash://, sftp://, and smb://.
>>
>> Modified Paths:
>> --
>> trunk/blender/release/bin/blender-thumbnailer.py
>>
>> Modified: trunk/blender/release/bin/blender-thumbnailer.py
>> ===
>> --- trunk/blender/release/bin/blender-thumbnailer.py2011-02-09 02:09:25
>> UTC (rev 34731)
>> +++ trunk/blender/release/bin/blender-thumbnailer.py2011-02-09 02:09:30
>> UTC (rev 34732)
>> @@ -24,27 +24,49 @@
>> Thumbnailer runs with python 2.6 and 3.x.
>> To run automatically with nautilus:
>> gconftool --type boolean --set
>> /desktop/gnome/thumbnailers/application@x-blender/enable true
>> - gconftool --type string --set
>> /desktop/gnome/thumbnailers/application@x-blender/command
>> "blender-thumbnailer.py %i %o"
>> + gconftool --type string --set
>> /desktop/gnome/thumbnailers/application@x-blender/command
>> "blender-thumbnailer.py %u %o"
>> """
>>
>> import struct
>>
>>
>> +def open_wrapper_get():
>> +""" wrap OS spesific read functionality here, fallback to 'open()'
>> +"""
>> +
>> +def open_gio(path, mode):
>> +g_file = gio.File(path).read()
>> +g_file.orig_seek = g_file.seek
>> +
>> +def new_seek(offset, whence=0):
>> +return g_file.orig_seek(offset, [1, 0, 2][whence])
>> +
>> +g_file.seek = new_seek
>> +return g_file
>> +
>> +try:
>> +import gio
>> +return open_gio
>> +except ImportError:
>> +return open
>> +
>> +
>> def blend_extract_thumb(path):
>> import os
>> +open_wrapper = open_wrapper_get()
>>
>> # def MAKE_ID(tag): ord(tag[0])<<24 | ord(tag[1])<<16 | ord(tag[2])<<8
>> | ord(tag[3])
>> REND = 1145980242 # MAKE_ID(b'REND')
>> TEST = 1414743380 # MAKE_ID(b'TEST')
>>
>> -blendfile = open(path, 'rb')
>> +blendfile = open_wrapper(path, 'rb')
>>
>> head = blendfile.read(12)
>>
>> if head[0:2] == b'\x1f\x8b': # gzip magic
>> import gzip
>> blendfile.close()
>> -blendfile = gzip.open(path, 'rb')
>> +blendfile = gzip.GzipFile('', 'rb', 0, open_wrapper(path, 'rb'))
>> head = blendfile.read(12)
>>
>> if not head.startswith(b'BLENDER'):
>>
>> ___
>> Bf-blender-cvs mailing list
>> bf-blender-...@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-blender-cvs
>>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Problems with premultiplied alpha channel in 8 bit images
I forgot to link the blend file where I tried to reproduce the bug inside the compositor by gamma-correcting alpha channel. http://ubuntuone.com/p/ROq/ This forces the bright halo artifact inside compositor and the resulting appearance is the same you get when you compose the premulled PNGs from blender in other application (or Blender's VSE) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] (no subject)
> Troy mentioned this to me a bit earlier but I didn't have a chance to > look into it deeply yet. One thing that comes to mind though, is that > does this only happen with PNG files? or TIFFs as well? It also happens when the premulled output of the compositor is used as a scene strip in Blender's VSE, so I guess it isn't related to PNG files only. http://ubuntuone.com/p/ROq/ I also tried with 8-bit tiff files with the same result. Oh, I just noticed that I sent the same link in the previous message saying it was a test where I tried to reproduce the bug with the gamma-corrected alpha. Sorry! The right link for that test is: http://dl.dropbox.com/u/255376/alpha-bug/premul-bug-my-theory.blend ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Problems with premultiplied alpha channel in 8 bit images
> Troy mentioned this to me a bit earlier but I didn't have a chance to > look into it deeply yet. One thing that comes to mind though, is that > does this only happen with PNG files? or TIFFs as well? It also happens when the premulled output of the compositor is used as a scene strip in Blender's VSE, so I guess it isn't related to PNG files only. http://ubuntuone.com/p/ROq/ I also tried with 8-bit tiff files with the same result. Oh, I just noticed that I sent the same link in the previous message saying it was a test where I tried to reproduce the bug with the gamma-corrected alpha. Sorry! The right link for that test is: http://dl.dropbox.com/u/255376/alpha-bug/premul-bug-my-theory.blend P.s.: sorry for the previous mail without subject. Courtesy of gmail + list in digest mode :( ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Problems with premultiplied alpha channel in 8 bit images
The changes to the viewer node were only related to the gl blend mode when drawing image pixels. Those were rendered with unmodified background color, which leads to plain addition of colors and excessive brightness in opaque areas. I changed the blend mode from (src*alpha + dst) to (src*alpha + dst*(1-alpha)), which should be the correct blend mode for straight-alpha (!) images. For pre-multiplied alpha it should be (src + dst*(1-alpha)), but i don't know if there is any way to determine this from a given image in blender? If there is no flag or similar to automatically set the correct blend mode, this could be a fourth user option for image drawing, so users can at least get the correct display if they know what alpha mode the image uses: 1. color only 2. straight alpha (s*a + d*(1-a)) 3. premultiplied (s + d*(1-a)) 4. only alpha as b/w However, this problem is probably not related to the bug described here (it might just have hidden it from earlier notice). My first attempt at finding the cause was not successful, but this png issue sounds promising ... On Wed, Feb 9, 2011 at 10:20 PM, gespert...@gmail.com wrote: > I forgot to link the blend file where I tried to reproduce the bug > inside the compositor by gamma-correcting alpha channel. > > http://ubuntuone.com/p/ROq/ > This forces the bright halo artifact inside compositor and the > resulting appearance is the same you get when you compose the > premulled PNGs from blender in other application (or Blender's VSE) > ___ > 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] Problems with premultiplied alpha channel in 8 bit images
A solution/workaround would be to add a "unpremultiply" option for image input in the compositor. It is bad pratice to composite or color correct premultiplied image anyway so it might be useful even if the bug is corrected. 2011/2/9 Lukas Tönne > The changes to the viewer node were only related to the gl blend mode > when drawing image pixels. Those were rendered with unmodified > background color, which leads to plain addition of colors and > excessive brightness in opaque areas. I changed the blend mode from > (src*alpha + dst) to (src*alpha + dst*(1-alpha)), which should be the > correct blend mode for straight-alpha (!) images. For pre-multiplied > alpha it should be (src + dst*(1-alpha)), but i don't know if there is > any way to determine this from a given image in blender? If there is > no flag or similar to automatically set the correct blend mode, this > could be a fourth user option for image drawing, so users can at least > get the correct display if they know what alpha mode the image uses: > > 1. color only > 2. straight alpha (s*a + d*(1-a)) > 3. premultiplied (s + d*(1-a)) > 4. only alpha as b/w > > However, this problem is probably not related to the bug described > here (it might just have hidden it from earlier notice). My first > attempt at finding the cause was not successful, but this png issue > sounds promising ... > > On Wed, Feb 9, 2011 at 10:20 PM, gespert...@gmail.com > wrote: > > I forgot to link the blend file where I tried to reproduce the bug > > inside the compositor by gamma-correcting alpha channel. > > > > http://ubuntuone.com/p/ROq/ > > This forces the bright halo artifact inside compositor and the > > resulting appearance is the same you get when you compose the > > premulled PNGs from blender in other application (or Blender's VSE) > > ___ > > 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] Nouveau and Blender - success?
I don't know if this has been asked before, but has Blender been tested under the Nouveau driver? If so, what are the results? For those who are not familiar, the Nouveau driver is a FOSS driver for Nvidia graphics cards. They do not officially support 3D, but basic OpenGL is supported on most modern graphics cards, so I think Blender would work. ___ 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 [34732] trunk/blender/release/bin/ blender-thumbnailer.py: patch [#25972] blender-thumbnailer.py: GVFS support
@Xavier,
blender-thumbnailer.py is a standalone script and runs without blender
in py2.x - 3.x
its included so tools may extract thumbnails from blender without
loading blender.
blender does this internally in C, from thumbs_blend.c: loadblend_thumb.
@Tom Edwards, there doesn't seem to be a good place for this to go in
blenders source.
For now how about: ./source/tools/windows_thumbnail/ ?
On Wed, Feb 9, 2011 at 9:20 PM, Tom Edwards wrote:
> Thumbs are generated by Blender on save and stored in the file as RGBA
> pixels. There is no risk.
>
> On this topic, I keep wanting to submit my Windows thumbnail handler but
> I don't know where it should go in the source tree. It has to be a
> dynamic lib, but it's not exactly external...any suggestions?
>
> On 09/02/2011 2:34, Xavier Thomas wrote:
>> Hi Campbell,
>>
>> I would like to know if the Blender thumbnailer deactivate python scripts
>> inside the blend.
>>
>> Thumbnailers are big security issues. A malisous .blend on a USB memory
>> stick could serve as infection vector on all platform. Executing some of the
>> py scripts inside would make it too easy.
>>
>> Xavier
>>
>>
>> 2011/2/9 Campbell Barton
>>
>>> Revision: 34732
>>>
>>> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=34732
>>> Author: campbellbarton
>>> Date: 2011-02-09 02:09:30 + (Wed, 09 Feb 2011)
>>> Log Message:
>>> ---
>>> patch [#25972] blender-thumbnailer.py: GVFS support
>>> from Shinsuke Irie (irie) with some minor edits.
>>>
>>> Shinsuke's description from the tracker:
>>> ---
>>> I have implemented GVFS framework support of blender-thumbnailer.py which
>>> allows some file managers like Nautilus and Thunar to show thumbnails in
>>> trash or network directories. If Python's gio module is available, the
>>> thumbnailer uses it to access to filesystems mounted via GVFS. This change
>>> shouldn't affect desktop environments other than GNOME and XFCE.
>>>
>>> A function gvfs_open() in this patch is defined to solve a stupid
>>> incompatibility between Python file object and GIO Seekable object.
>>>
>>> On Ubuntu 10.10, I confirmed thumbnails can be generated for file://,
>>> trash://, sftp://, and smb://.
>>>
>>> Modified Paths:
>>> --
>>> trunk/blender/release/bin/blender-thumbnailer.py
>>>
>>> Modified: trunk/blender/release/bin/blender-thumbnailer.py
>>> ===
>>> --- trunk/blender/release/bin/blender-thumbnailer.py 2011-02-09 02:09:25
>>> UTC (rev 34731)
>>> +++ trunk/blender/release/bin/blender-thumbnailer.py 2011-02-09 02:09:30
>>> UTC (rev 34732)
>>> @@ -24,27 +24,49 @@
>>> Thumbnailer runs with python 2.6 and 3.x.
>>> To run automatically with nautilus:
>>> gconftool --type boolean --set
>>> /desktop/gnome/thumbnailers/application@x-blender/enable true
>>> - gconftool --type string --set
>>> /desktop/gnome/thumbnailers/application@x-blender/command
>>> "blender-thumbnailer.py %i %o"
>>> + gconftool --type string --set
>>> /desktop/gnome/thumbnailers/application@x-blender/command
>>> "blender-thumbnailer.py %u %o"
>>> """
>>>
>>> import struct
>>>
>>>
>>> +def open_wrapper_get():
>>> + """ wrap OS spesific read functionality here, fallback to 'open()'
>>> + """
>>> +
>>> + def open_gio(path, mode):
>>> + g_file = gio.File(path).read()
>>> + g_file.orig_seek = g_file.seek
>>> +
>>> + def new_seek(offset, whence=0):
>>> + return g_file.orig_seek(offset, [1, 0, 2][whence])
>>> +
>>> + g_file.seek = new_seek
>>> + return g_file
>>> +
>>> + try:
>>> + import gio
>>> + return open_gio
>>> + except ImportError:
>>> + return open
>>> +
>>> +
>>> def blend_extract_thumb(path):
>>> import os
>>> + open_wrapper = open_wrapper_get()
>>>
>>> # def MAKE_ID(tag): ord(tag[0])<<24 | ord(tag[1])<<16 | ord(tag[2])<<8
>>> | ord(tag[3])
>>> REND = 1145980242 # MAKE_ID(b'REND')
>>> TEST = 1414743380 # MAKE_ID(b'TEST')
>>>
>>> - blendfile = open(path, 'rb')
>>> + blendfile = open_wrapper(path, 'rb')
>>>
>>> head = blendfile.read(12)
>>>
>>> if head[0:2] == b'\x1f\x8b': # gzip magic
>>> import gzip
>>> blendfile.close()
>>> - blendfile = gzip.open(path, 'rb')
>>> + blendfile = gzip.GzipFile('', 'rb', 0, open_wrapper(path, 'rb'))
>>> head = blendfile.read(12)
>>>
>>> if not head.startswith(b'BLENDER'):
>>>
>>> ___
>>> Bf-blender-cvs mailing list
>>> bf-blender-...@blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-blender-cvs
>>>
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/l
Re: [Bf-committers] Nouveau and Blender - success?
In short, yes it does work but I can't speak for more advanced features like GLSL shaders or VBO's. I ran the Nouveau drivers for a while to fix a reported bug: http://projects.blender.org/tracker/?func=detail&group_id=9&aid=24339&atid=498 >From my experience the main problem is copying the depth buffer from the 3d view into memory is very slow compared to closed source nvidia drivers. Since nouveau are not the only drivers that are slow at this and blender was being very in-efficient, copying entire view when only a few pixels were needed, I made some updates to auto-depth and particle brush modes so they should not be so slow. On Thu, Feb 10, 2011 at 12:28 AM, Max B wrote: > I don't know if this has been asked before, but has Blender been tested > under the Nouveau driver? If so, what are the results? For those who are not > familiar, the Nouveau driver is a FOSS driver for Nvidia graphics cards. > They do not officially support 3D, but basic OpenGL is supported on most > modern graphics cards, so I think Blender would work. > ___ > 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
