Re: [Bf-committers] Accepted for GSoC 2014 :)
On Mon, Feb 24, 2014 at 10:51 AM, Ton Roosendaal wrote: Just a note, we're in Google Summer of Code for the 10th time! > Does anyone else envision someone modeling a GSoC cake with ten candles as a result (maybe with an opened present of a blender logo'd toy next to it in the scene), or is it just me? =) Or has this already been done for a previous year? "Simpsons did it! --South Park" Maybe one just in time for the 2.71 splash screen artwork? ;) -Chad ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Importing Assets: FBX VS Collada
Just curious.. Would it not be possible to include a generic sub-process/pipe import/export feature in blender. This would allow an external utility to be run (transparent to the user, once install) which would be given the filename (and/or sent the data via the stdio pipe) and in return it would send a .blend formatted file (or sub-set of) back. Then it would be processed like a file append. Exporting would be similar, only with reversed data along the pipe. After that, create a separate add-on [sub-]project with code that uses the FBX SDK with a compatible license, which users could install if needed. It would also allow other formats to better supported if license incompatible native libraries exist for them. -Chad ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Importing Assets: FBX VS Collada
On Sun, Apr 27, 2014 at 11:29 PM, Toni Alatalo wrote: > @Chad yes that is possible, it was discussed on IRC the other day and > Ton dismissed (I think sanely) due to it being too difficult for > people to install the separate converter (for FBX for example) due to > the licenses preventing the distribution of the FBX SDK together with > Blender. > So it isn't possible/not trivial to have an automatic installer that (upon initiation by the user) downloads and installs the convertor and does the SDK license acceptance and downloads and installs that also? And would there be any GPL conflicts with having that bootstrap download/installer script bundled with blender that does it on request (maybe just a pseudo add-on that does when "enabled"). One of my pre-installed computers did that where Skype (and I think so other software) wasn't installed by default, but there was a program menu item that would install the first time it was used. And as far as those users having to accept a license.. that isn't really any different than accepting their OS license or other apps, as long as it is not directly linked to any GPL code (or GPL code linked to it -- the converter being BSD/MIT based or something). It's just from some of the messages in the list, I got the feeling that collada might had some issues (on long term support, or data mappings). Maybe the external SDK route could [potentially] just be a usable stop-gap solution while collada work is being refined, and/or enough RE'd FBX knowledge is gained that it could be done well directly. It might even help the RE effort, since then the SDK output of blender data could be more quickly/easily inspected. -Chad ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Code cleanup rules
Just a style question.. Wouldn't it be better for the BLI_*.h files to do the WIN32 (or other) ifdefs and otherwise be used platform generic, rather than make each C file that uses them do the ifdef? -Chad On Wed, Apr 30, 2014 at 2:27 PM, Thomas Dinges wrote: > Hi, > Next time you do such massive cleanup, you can also just spend 10mins of > your time and boot your Windows installation before commit. > I spend 30min of my time now to fix the issues, and then you revert that > 5minutes afterwards. Very nice. > > I clearly vote for more strict rules in regards to code cleanups that > affect all areas/and OS. This madness has to stop. > > Am 30.04.2014 23:21, schrieb Campbell Barton: > > Commit: af86b008b2a3dacc33b4987c50d8ffa24f6f9817 > > Author: Campbell Barton > > Date: Thu May 1 07:21:08 2014 +1000 > > https://developer.blender.org/rBaf86b008b2a3dacc33b4987c50d8ffa24f6f9817 > > > > Include removal gave problems with windows, ifdef some back in for > windows only > > > > === > > > > M source/blender/blenkernel/intern/customdata.c > > M source/blender/blenkernel/intern/ipo.c > > M source/blender/blenlib/intern/path_util.c > > M source/blender/blenlib/intern/smallhash.c > > M source/blender/bmesh/intern/bmesh_mesh.c > > M source/blender/editors/interface/interface_style.c > > M source/blender/editors/screen/area.c > > M source/blender/editors/space_outliner/outliner_tree.c > > M source/blender/editors/space_view3d/view3d_ops.c > > M source/blender/imbuf/intern/allocimbuf.c > > M source/blender/python/intern/bpy_interface.c > > M source/blender/python/intern/bpy_rna_array.c > > M source/blender/python/intern/bpy_traceback.c > > > > === > > > > diff --git a/source/blender/blenkernel/intern/customdata.c > b/source/blender/blenkernel/intern/customdata.c > > index fd43501..57758ac 100644 > > --- a/source/blender/blenkernel/intern/customdata.c > > +++ b/source/blender/blenkernel/intern/customdata.c > > @@ -63,6 +63,10 @@ > > #include > > #include > > > > +#ifdef WIN32 > > +# include "BLI_alloca.h" > > +#endif > > + > > /* number of layers to add when growing a CustomData object */ > > #define CUSTOMDATA_GROW 5 > > > > diff --git a/source/blender/blenkernel/intern/ipo.c > b/source/blender/blenkernel/intern/ipo.c > > index 6f7ee31..7385322 100644 > > --- a/source/blender/blenkernel/intern/ipo.c > > +++ b/source/blender/blenkernel/intern/ipo.c > > @@ -77,6 +77,10 @@ > > > > #include "MEM_guardedalloc.h" > > > > +#ifdef WIN32 > > +# include "BLI_math_base.h" /* M_PI */ > > +#endif > > + > > /* *** */ > > /* Old-Data Freeing Tools */ > > > > diff --git a/source/blender/blenlib/intern/path_util.c > b/source/blender/blenlib/intern/path_util.c > > index 2c24a89..f207329 100644 > > --- a/source/blender/blenlib/intern/path_util.c > > +++ b/source/blender/blenlib/intern/path_util.c > > @@ -50,6 +50,8 @@ > > #include "GHOST_Path-api.h" > > > > #ifdef WIN32 > > +# include "MEM_guardedalloc.h" > > + > > # include "utf_winfunc.h" > > # include "utfconv.h" > > # include > > diff --git a/source/blender/blenlib/intern/smallhash.c > b/source/blender/blenlib/intern/smallhash.c > > index d6b2383..e8e3387 100644 > > --- a/source/blender/blenlib/intern/smallhash.c > > +++ b/source/blender/blenlib/intern/smallhash.c > > @@ -56,6 +56,10 @@ > > > > #include "BLI_utildefines.h" > > > > +#ifdef WIN32 > > +# include "BLI_alloca.h" > > +#endif > > + > > #include "BLI_smallhash.h" > > > > #include "BLI_strict_flags.h" > > diff --git a/source/blender/bmesh/intern/bmesh_mesh.c > b/source/blender/bmesh/intern/bmesh_mesh.c > > index e9d3c36..6b040ef 100644 > > --- a/source/blender/bmesh/intern/bmesh_mesh.c > > +++ b/source/blender/bmesh/intern/bmesh_mesh.c > > @@ -40,6 +40,10 @@ > > #include "BKE_editmesh.h" > > #include "BKE_multires.h" > > > > +#ifdef WIN32 > > +# include "BLI_alloca.h" > > +#endif > > + > > #include "intern/bmesh_private.h" > > > > /* used as an extern, defined in bmesh.h */ > > diff --git a/source/blender/editors/interface/interface_style.c > b/source/blender/editors/interface/interface_style.c > > index bbdfd1d..fa31c20 100644 > > --- a/source/blender/editors/interface/interface_style.c > > +++ b/source/blender/editors/interface/interface_style.c > > @@ -55,6 +55,9 @@ > > > > #include "interface_intern.h" > > > > +#ifdef WIN32 > > +# include "BLI_math_base.h" /* M_PI */ > > +#endif > > > > /* style + theme + layout-engine = UI */ > > > > diff --git a/source/blender/editors/screen/area.c > b/source/blender/editors/screen/area.c > > index 151764d..05659f6 100644 > > --- a/source/blender/editors/screen/area.c > > +++ b/source/blender/editors/screen/area.c > > @@ -68,6 +68,10 @@ > > > > #include "screen_intern.h" > > > > +#ifdef WIN32 > > +# i
Re: [Bf-committers] Do drivers have to be blocked as python scripts?
Just wondering.. has anyone out there wrote a python interpreter *in* python that has security/sandbox functionality/hooks? Then it could offer the option (as another user selectable security level) of "secure but slow", which might be adequate for simple or non-intensively called scripts. Since it would be a python script itself, it would/should be portable across the underlying implementation. Depending on the features of such a hypothetical library/module, if the parsed expression tree can be checked and determined to be simple (i.e. no field assignments, no arbitrary function calls, etc..) and known safe, it could be then be directly eval'd by the real python and not just emulated. Essentially a variation of one of the ideas previously mentioned in this thread. -Chad ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Do drivers have to be blocked as python scripts?
On Sun, May 25, 2014 at 12:34 AM, Campbell Barton wrote: On Sat, May 24, 2014 at 7:21 AM, Chad Fraleigh wrote: > > Just wondering.. has anyone out there wrote a python interpreter *in* > > python that has security/sandbox functionality/hooks? Then it could offer > > the option (as another user selectable security level) of "secure but > > slow", which might be adequate for simple or non-intensively called > > scripts. Since it would be a python script itself, it would/should be > > portable across the underlying implementation. > > > > Depending on the features of such a hypothetical library/module, if the > > parsed expression tree can be checked and determined to be simple (i.e. > no > > field assignments, no arbitrary function calls, etc..) and known safe, it > > could be then be directly eval'd by the real python and not just > emulated. > > Essentially a variation of one of the ideas previously mentioned in this > > thread. > > > > > > -Chad > > Someone has done just this: > > http://pypy.org > > > Which also provides a sand-boxed execution environment to prevent > scripts doing things you may want to prevent: > > http://pypy.readthedocs.org/en/latest/sandbox.html > > But that seems to be just another implementation of python at the binary library level. What I meant was a python language interpreter that is written purely in python code itself, which will run on top of the existing python runtime that blender uses (not replace it). It would need to only support the parsing of scripts, access checking/hooks, and the minimum execution of the language itself. Since it would run on top of the real python, any standard modules needed would be done by delegating it to the underlying ones (so it would have a very minimalistic runtime). -Chad ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] 2.71 installer contains subversion workspace data
I just installed the 64-bit version of 2.71, and it seems to have a subversion directory bundled. It only uses about 847K of installed space, but still a bunch of junk files. I thought someone said there was a related (same?) issue after a previous release. C:\Program Files\Blender Foundation\Blender\2.71\python\lib\site-packages\.svn C:\Program Files\Blender Foundation\Blender\2.71\python\lib\site-packages\.svn\entries C:\Program Files\Blender Foundation\Blender\2.71\python\lib\site-packages\.svn\format C:\Program Files\Blender Foundation\Blender\2.71\python\lib\site-packages\.svn\pristine C:\Program Files\Blender Foundation\Blender\2.71\python\lib\site-packages\.svn\pristine\02 C:\Program Files\Blender Foundation\Blender\2.71\python\lib\site-packages\.svn\pristine\02\0275d6ded4583e8c6fb90ca90434d334a65cc418.svn-base C:\Program Files\Blender Foundation\Blender\2.71\python\lib\site-packages\.svn\pristine\02\02f453139cf29afebeba57b7e3bc860be9419d73.svn-base C:\Program Files\Blender Foundation\Blender\2.71\python\lib\site-packages\.svn\pristine\05 C:\Program Files\Blender Foundation\Blender\2.71\python\lib\site-packages\.svn\pristine\05\05200c6868058a01f3b8cd7aadecf15f8d2c4e54.svn-base C:\Program Files\Blender Foundation\Blender\2.71\python\lib\site-packages\.svn\pristine\0d C:\Program Files\Blender Foundation\Blender\2.71\python\lib\site-packages\.svn\pristine\0d\0db635cdad4612898a160008f989508be6d1030f.svn-base C:\Program Files\Blender Foundation\Blender\2.71\python\lib\site-packages\.svn\pristine\10 C:\Program Files\Blender Foundation\Blender\2.71\python\lib\site-packages\.svn\pristine\10\10475cb6987f61ea1fdd7e69931a73bf4c5c7293.svn-base C:\Program Files\Blender Foundation\Blender\2.71\python\lib\site-packages\.svn\pristine\10\106ad5b383cc3020171cfcf86625fa8ecf9f0b2c.svn-base C:\Program Files\Blender Foundation\Blender\2.71\python\lib\site-packages\.svn\pristine\13 C:\Program Files\Blender Foundation\Blender\2.71\python\lib\site-packages\.svn\pristine\13\130c02438b3ba5c2193b11ee4384bba41b9f4735.svn-base C:\Program Files\Blender Foundation\Blender\2.71\python\lib\site-packages\.svn\pristine\13\13f1ea969a85086536cec254d33a954b309ee62f.svn-base C:\Program Files\Blender Foundation\Blender\2.71\python\lib\site-packages\.svn\pristine\1c C:\Program Files\Blender Foundation\Blender\2.71\python\lib\site-packages\.svn\pristine\1c\1c2d3d766de169436345e49ac43cd2a18377b170.svn-base C:\Program Files\Blender Foundation\Blender\2.71\python\lib\site-packages\.svn\pristine\1c\1c84bd8594196ba5acc34d9f6948d67cb87028fa.svn-base C:\Program Files\Blender Foundation\Blender\2.71\python\lib\site-packages\.svn\pristine\29 C:\Program Files\Blender Foundation\Blender\2.71\python\lib\site-packages\.svn\pristine\29\2978d7c0ad339e1442a23c7434429e3ba02ff232.svn-base C:\Program Files\Blender Foundation\Blender\2.71\python\lib\site-packages\.svn\pristine\29\29e7dae8b0ce96dc0787404f57446c778f9141f3.svn-base C:\Program Files\Blender Foundation\Blender\2.71\python\lib\site-packages\.svn\pristine\2b C:\Program Files\Blender Foundation\Blender\2.71\python\lib\site-packages\.svn\pristine\2b\2bc8f095dd596a7e98463acd5e3d10b2fa859957.svn-base C:\Program Files\Blender Foundation\Blender\2.71\python\lib\site-packages\.svn\pristine\2c C:\Program Files\Blender Foundation\Blender\2.71\python\lib\site-packages\.svn\pristine\2c\2c5777e8997d0c14ec38502f1cf8fc3dad303b8d.svn-base C:\Program Files\Blender Foundation\Blender\2.71\python\lib\site-packages\.svn\pristine\34 C:\Program Files\Blender Foundation\Blender\2.71\python\lib\site-packages\.svn\pristine\34\342b57b8e2bb15632fe23a933feb707059162ec9.svn-base C:\Program Files\Blender Foundation\Blender\2.71\python\lib\site-packages\.svn\pristine\41 C:\Program Files\Blender Foundation\Blender\2.71\python\lib\site-packages\.svn\pristine\41\415e5c6a766ef17188e9bfdcc23e39029c2aba17.svn-base C:\Program Files\Blender Foundation\Blender\2.71\python\lib\site-packages\.svn\pristine\44 C:\Program Files\Blender Foundation\Blender\2.71\python\lib\site-packages\.svn\pristine\44\444b8e7b09dbff9cac2f733f4cd26f456ad1e1cb.svn-base C:\Program Files\Blender Foundation\Blender\2.71\python\lib\site-packages\.svn\pristine\55 C:\Program Files\Blender Foundation\Blender\2.71\python\lib\site-packages\.svn\pristine\55\55407456664e0493b6a219b5eb0f14e161b0af20.svn-base C:\Program Files\Blender Foundation\Blender\2.71\python\lib\site-packages\.svn\pristine\55\554c119fdaaf5d4f22bc06e4f81ff01b06df1a10.svn-base C:\Program Files\Blender Foundation\Blender\2.71\python\lib\site-packages\.svn\pristine\60 C:\Program Files\Blender Foundation\Blender\2.71\python\lib\site-packages\.svn\pristine\60\60d5a3a8da009bb8f9864b35e89ef05c448067ba.svn-base C:\Program Files\Blender Foundation\Blender\2.71\python\lib\site-packages\.svn\pristine\62 C:\Program Files\Blender Foundation\Blender\2.71\python\lib\site-packages\.svn\pristine\62\621ee9c4a82cdef5d45271bb6d51264953631749.svn-base C:\Program Files\Blender Foundation\Blender\2.71\python\lib\site-packages\
Re: [Bf-committers] can we update ffmpeg to have RTSP support?
On Tue, Jul 15, 2014 at 8:49 AM, Fazekas László wrote: > What if the Blender game engine receives only a very simple > (uncompressed pixel?) stream from a fifo and an external program > converts the required format? Or instead of a fifo, maybe it is possible > to use shared memory mapping. > > I'm sure it is possible in Linux but perhaps not in Windows. Is the game > engine able to do this? > > While not as dependency clean as blender supporting it internally, this should be possible using ffmpeg and a loopback network connection: ffmpeg -vcodec rawvideo -f rawvideo -pix_fmt rgb32 -s x -i tcp://127.0.0.1: Also ffmpeg has a 'pipe:' protocol, so it could read from an arbitrary file descriptor (that is connected to a spawned child process): ffmpeg -vcodec rawvideo -f rawvideo -pix_fmt rgb32 -s x -i pipe: I don't know if those features are enabled in ffmpeg by default, but since they are rather basic, they might be part of its core code and always available. However, if going with the blender built-in route, supporting mjpeg in addition to raw/uncompressed would probably be useful. Since blender already has libjpeg, and mjpeg is just a sequence of jpegs. Audio would still need to be taken in account, if needed. > 2014-07-15 16:37 keltezéssel, Dalai Felinto írta: > > Hi, > > > > > > What do I want: > > - > > FFmpeg libs to be compiled with: "--enable-network > > --enable-protocol=tcp --enable-demuxer=rtsp --enable-decoder=h264" > > > > > > Why do I need that for: > > - > > RTSP is used for 'remote camera' viewing, which in turn is a > > requirement for some VR (Virtual Reality) installations. BlenderCAVE > > (a VR framework) is in need that at the moment, and although they may > > be able to fix their issue with patching their Blender, I would rather > > see this available to more people. > > > > Bug report: https://developer.blender.org/T41004 > > > > > > I'm ok with RTSP but why the enable-decoder=h264? > > > - > > When I found the rtsp building instructions in the internet, the h264 > > was together, so it may be required. Also there is a known issue of > > the game engine being extremely slow to playback some video formats. > > I'm suspecting the lack of some decoders may be a reason for that. > > > > That said I'm getting some mixed google results on the license of h264 > > for playback (decoding). I'm no lawyer so does anyone know if there is > > any license issue with that? Maybe the h264 bit is not needed only the > > rtsp ... to be investigated. > > > > > > Thanks for the consideration, let me know your thoughts, > > Dalai > -Chad ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] OpenMP issues with msvc2013 builds
On Wed, Aug 6, 2014 at 1:23 AM, Sergey Sharybin wrote: > We've spent quite a while trying to solve the upcoming stream of reports > about high CPU usage with builds made with msvs2013 in certain situations. > Root of the issue goes to the change made to OMP inplementation back to > msvc2010 days -- they've forced threads to spin for a while after they did > a work. This is a know issue in the library and nobody actually gonna to > fix it [1]. > > There's one woekaround to solve the issue which is to set OMP_WAIT_POLICY > environment variable to PASSIVE. Unfortunately, since openmp is a dynamic > library and can't be linked statically at all we can't modify environment > variables from within blender using putenv(), this is to be done > externally, before blender.exe starts. > Here's the list of possible solutions: > > - Declare msvc full of crap, switch to intel compilers > MinGW still won't do everything, huh? ;) > - Try to hack into vcomp120.dll, trying to figure out the variable, linking > to it and modifying if (so called brain surgery from the blender side). No > idea if it's doable. > Base on a quick look with Olly, where it looks up the OMP_WAIT_POLICY variable, it then compares it to "active" and "passive" and sets a memory byte to 1 or 0, respectively. Then that byte is checked two other places just before some calls to GetTickCount() and SwitchToThread(). So figure out a way to reference that location by name, and changing a byte might be all that is needed. Hypothetically at least. > - Ask users to set this variable in their environment (Control Panel -> > System -> Environment Variables). For this we can create a .bat script. > > - Same as mentioned above, make it a step of the blender installation > process Or make it so blender.exe modivies the registry. Personally i don't > really like this approach. > > - Create a small .exe which we put next to blender.exe and will call it > blender-launcher.exe or so. This application will modify the environment > variable and start blender.exe. We could also make it called blender.exe > and rename real blender.exe to blender.bin.exe so all the links and so > continues to work. Here's a quick code of this application [2], would need > to create an icon for it and so but that's details. > Or add a check at the very beginning of blender.exe's main() that checks for the variable, and if it isn't set yet, set it, and then exec itself. Making sure it is well tested to never get caught in infinite loop (which really should only happen if the environment change failed to take hold some how). With the separate executable, using the convention blender-bin.exe might be better (as I've seen that style with several other applications. Plus bin doesn't look like a sub-extension, e.g. .tar.gz). -Chad ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] OpenMP issues with msvc2013 builds
On Wed, Aug 6, 2014 at 2:44 AM, Sergey Sharybin wrote: > On Wed, Aug 6, 2014 at 3:32 PM, Chad Fraleigh > wrote: > > > > - Try to hack into vcomp120.dll, trying to figure out the variable, > > linking > > > to it and modifying if (so called brain surgery from the blender side). > > No > > > idea if it's doable. > > > > > > > Base on a quick look with Olly, where it looks up the OMP_WAIT_POLICY > > variable, it then compares it to "active" and "passive" and sets a memory > > byte to 1 or 0, respectively. Then that byte is checked two other places > > just before some calls to GetTickCount() and SwitchToThread(). So figure > > out a way to reference that location by name, and changing a byte might > be > > all that is needed. Hypothetically at least. > > > > That's kinda hackish and not real sure how to do this. Also not really fan > of investing time in this. Any volunteers to look into? :) > > It's not ideal, and would be coded to each specific vcompXXX.dll (and patched/updated versions). However, assuming the location of that flag is a fixed offset from the dll image, the general idea might be: - Call GetModuleHandle() for each supported target (i.e. vcomp120.dll, vcomp120d.dll), until one is found. - Calculate the address of the flag from the module base. - Calculate the address of the code where it does the OMP_WAIT_POLICY active/passive checks and verify a few of the static opcode bytes (either verbatim, or with a checksum/hash). - Get the address that code references for the flag, and if it matches the earlier calculation, then consider it validated, and change the flag at that address. - If no supported dll's were found, or couldn't be verified, output a warning to stderr about bad performance. > > - Create a small .exe which we put next to blender.exe and will call it > > > blender-launcher.exe or so. This application will modify the > environment > > > variable and start blender.exe. We could also make it called > blender.exe > > > and rename real blender.exe to blender.bin.exe so all the links and so > > > continues to work. Here's a quick code of this application [2], would > > need > > > to create an icon for it and so but that's details. > > > > > > > Or add a check at the very beginning of blender.exe's main() that checks > > for the variable, and if it isn't set yet, set it, and then exec itself. > > Making sure it is well tested to never get caught in infinite loop (which > > really should only happen if the environment change failed to take hold > > some how). > > > > Not really sure it'll work. If you start exe file which is linked against > the DLL, the DLL will be loaded (and hence it'll have a copy of the > environment already) before loader will give it a contorl to your main() > function. You need to modify the enviornment before the dll was loaded. > > Maybe i'm wrong and running self from the main will load omp dll again? > Basically it would the same as having a small wrapper exe (i.e. a completely new process spawned), only without an extra binary. The only down side with a self execute is when debugging, since the child process will be the real thing to debug. Using a small wrapper or self exec has the same issues (just less obvious when self exec'd). As long as the user manually sets OMP_WAIT_POLICY ahead of time, then it would act normal for debugging (so something that would need to be made clear in the documentation). -Chad ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] OpenMP issues with msvc2013 builds
On Wed, Aug 6, 2014 at 1:45 PM, Martijn Berger wrote: > On Wed, Aug 6, 2014 at 10:33 PM, Chad Fraleigh > wrote: > > > It's not ideal, and would be coded to each specific vcompXXX.dll (and > > patched/updated versions). > > > > However, assuming the location of that flag is a fixed offset from the > dll > > image, the general idea might be: > > > > - Call GetModuleHandle() for each supported target (i.e. vcomp120.dll, > > vcomp120d.dll), until one is found. > > > > - Calculate the address of the flag from the module base. > > > > - Calculate the address of the code where it does the OMP_WAIT_POLICY > > active/passive checks and verify a few of the static opcode bytes (either > > verbatim, or with a checksum/hash). > > > We can most likely also just look at specific dll version and see if we > "know" it. > The extra sanity check was just to make sure the wrong address wasn't accidentally clobbered under unexpected conditions. > > - Get the address that code references for the flag, and if it matches > the > > earlier calculation, then consider it validated, and change the flag at > > that address. > > > > - If no supported dll's were found, or couldn't be verified, output a > > warning to stderr about bad performance. > > > > Looks good on paper. It is good to realize that we re-distribute vcomp and > thus have pretty good control over what version we use. > Yeah.. I was looking at the dll in my system32 directory, so I was thinking it was a system lib. Actually, if blender controls the dll being used, and assuming it is allowed within the distro license when bundled as a private dll, that could make things far easier. Simply patch the dll (a one byte change) so that it defaults to the passive value. -Chad ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] OpenMP issues with msvc2013 builds
On Wed, Aug 6, 2014 at 1:45 PM, Martijn Berger wrote: > Main problem is that someone needs to actually try this by implementing it > :) For the pre-patch fix, the byte at offset 0x000169A0 in the 32-bit vcomp120.dll (assuming the same one in 2.71) should be changed to 0x00 (the 'bool' for active, which defaults to 0x01). The prior contents in that area are: 00016980:FD 83 8F AF 06 94 7D 11 E4 2D DE 9F CE D2 C8 04 ..}..-.. 00016990:DD A6 D8 0A FF FF FF FF 01 00 00 00 01 00 00 00 000169A0:01 01 00 00 01 00 00 00 00 00 00 00 00 00 00 00 000169B0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 I ran an install of 2.71 with a patch dll and it didn't give any errors loading it (e.g. checksum/signature mismatch). But since I don't know what to look for with the CPU issue manifestation, I couldn't test it further. Since Olly only supports 32-bit code, I couldn't easily identify the location for the 64-bit dll. I would have to resort to using WinDbg or something (ugg!). But since this is only a proof of concept, I assume it shouldn't be needed at this point. -Chad ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] BKE_object_defgroup_clear() / use_selection inconsistency
While looking at some of the vertex group code I noticed something that
doesn't look right. In BKE_object_defgroup_clear() [from object_deform.c]
it contains the following:
if (me->dvert) {
MVert *mv;
int i;
mv = me->mvert;
dv = me->dvert;
for (i = 0; i < me->totvert; i++, mv++,
dv++) {
if (mv->flag & SELECT) {
if (dv->dw &&
(!use_selection || (mv->flag & SELECT))) {
MDeformWeight *dw =
defvert_find_index(dv, def_nr);
defvert_remove_group(dv, dw); /* dw can be NULL */
changed = true;
}
}
}
}
It is always checking/requiring the SELECT flag, regardless of the
use_selection parameter (and then checks the flag again as expected). Is
this some kind of valid work around for something else, legacy code that is
never reached, or a bug? I see some other functions calling
BKE_object_defgroup_clear() with use_selection as false.
-Chad
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] seq_hash_render_data() includes undefined results due to out of range bitshift
The hash function seq_hash_render_data() in
blender/source/blender/blenkernel/intern/seqcache.c includes a value
shifted 32 bits for a 32-bit int.
static unsigned int seq_hash_render_data(const SeqRenderData *a)
{
unsigned int rval = a->rectx + a->recty;
. . .
rval ^= ((a->scene->r.views_format * 2) + a->view_id) << 32;
return rval;
}
Compile warning given by VS 2013:
warning C4293: '<<' : shift count negative or too big, undefined
behavior...\blender\source\blender\blenkernel\intern\seqcache.c
That part of the value could be removed (since it may currently be a no-op)
or changed to a lower shift value (e.g. << 28).
-Chad
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender VSE exported video goes from 1440p to 1080p
Also, have you done a sanity check by uploading the videos again (including the first as a control set) to verify it wasn't due to youtube [temporarily] breaking something on their end, that may be working (or consistently broken) now? I've heard of stories where people have called up tech support for software because of issues and it ended up being something like their their internet was down or something else external that the software needed to work right. But because the user was only thinking in the context of "that" software, they assumed it was the cause of the problem and didn't verify anything else. If your problems are based on an observations of a single [failed] attempt that hadn't been verified as repeatable with the same outcome, then it is hypothetically possible you are asking blender developers to fix a problem that never existed (in blender, at least). "When the outcome doesn't make sense, test/validate all assumptions, no matter how obvious/trivial they may seem." -- An important rule in software development (and other things) -Chad On Sun, May 8, 2016 at 11:26 PM, blubee blubeeme wrote: > What's the point of being able to edit clips but not export them properly? > Does that make sense to anyone, so blender costumes the video clips and > then > > Whenever an actual user of blender sends issues to this mailing list there > seems to be this dismissive attitude like, you're doing it wrong or > whatever. Eating your own dog food means do you actually use blender in > real world to produce finished product, if you didn't know. > > ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Possible uninitialized code error in init_structDNA()
While looking at init_structDNA() in
source/blender/makesdna/intern/dna_genfile.c (line 316 in v2.63a), I
noticed these fragments of code:
int *data, *verg, gravity_fix= -1;
char str[8], *cp;
verg= (int *)str;
data= (int *)sdna->data;
strcpy(str, "SDNA");
if ( *data == *verg ) {
I must assume that 'str' is declared as char[8] to hold space for
either a 32-bit or 64-bit integer, which 'verg' is then cast as later.
A string of 4 characters is then copied into it to initialize the
array, after which it's value is compared through out the function. So
if run on a 32-bit system, everything is fine.. but on a 64-bit system
there could be problems. Since 'str' is allocated on the stack it's
contents are by default undefined/random. The strcpy() will fill in
the first 5 bytes (4 letters and the null), but the last 3 bytes will
still be potential junk. This would imply that any 64-bit int compares
would be unreliable.
So am I missing something here, or is the compiler _always_ being
forced to zero-initialize stack data using some switch, that would
make this code not really a problem, ever (and I'm just being
paranoid)? If it is a potential issue, then 'str' should be
pre-initialized with memset(str, 0, 8); or something equivalent for
the last 3 bytes.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Thinking about a "community edit mode" for blender
What about instead of trying to keep the internal data directly in sync it was treated more like a high level database replay log. Sync the operations, like select vertex #5, begin move action, move by x/y, end move action; or set modifier #1 field X to value Y. Assuming all instances started out with logically identical data/state and have the same capabilities (i.e. same blender version, and same [active] addons), then in the end each edited copy should be identical. Of course this also assumes that all "actions" (whether UI or script triggered) can be hooked/captured and replicated to the other node(s). One catch would be any local system specific data (like non-relative filenames) that might get applied would not be portable across nodes. If support for virtual/aliased/mapped file resources existed, then both sides could have their system dependent resources mapped, and then these virtual "filenames" could be passed back and forth. While not a complete solution, it would allow even those that have a collection of [non-common directory] external data on incompatible directory structures (or OS's) to still work together. For that matter there could even be exported virtual resources.. so if resource X wasn't mapped on one side it could pull the data remotely from another node that does have it (when allowed). Another issue would be error handling. So for example of user A loads a texture file, but that file doesn't exist on the user B's side (or it does but is an invalid image) then user B would get an error dialog. This would place them in inconsistent states. Best case the error is semi-ignorable (e.g. one side just doesn't have a nice texture showing, but works otherwise), however worst case is the data structures get out of sync (e.g. texture slot #2 is missing on side B). Maybe an error catching hook that gives a dialog "There was an error that didn't occur on the other node... would you like to resync your blender data?" Yes, not ideal (especially if it is a big file and happens a lot with a slow network connection). On Sun, Nov 18, 2012 at 9:29 AM, Brecht Van Lommel wrote: > Hi, > > There was indeed experimental Verse integration for this sort of > thing, but it never got to a finished state. The idea was that Verse > would be integrated in various applications and game engines, and that > you could then interchange data. The main issue I guess is that > synchronizing data is a hard problem, and that it's difficult to add > this into Blender or other 3D app designs which weren't designed from > the ground up with this in mind. > > For exporting to a game engine, I think this can work and could be > implemented as an addon. But it's still a hard problem, especially if > you want to do 2-way syncing. For Blender-Blender syncing, I don't see > it happening, syncing all data structures is too much work to get > reliable, with a game engine you only have to consider a subset, same > as when writing an exporter. > > One mistake with Verse in my opinion is that it tried to be too fine > grained in syncing, it's nice in theory to only send changed vertices, > but this all just becomes incredibly complex when you consider that > you have to sync all data at this level. It's better to work at the > level of entire datablocks in my opinion, and if you want to optimize > data transfer then maybe use an rsync like algorithm. > > Brecht. > > On Sun, Nov 18, 2012 at 5:05 PM, Gaia wrote: >> I remember there was some attempt to add a multi user mode for blender >> (I think there was something setup in 2.4) The key idea was that 2 or >> more users could share one Blender 3dView and do concurrent editing on >> the objects right in blender. >> >> I would like to even add another thought: Maybe it is possible to setup >> a bridge between blender and an online world, such that you can edit an >> object in blender which is actually located in an online environment (or >> visualize an object that is actually located in blender in an online >> world) . I guess that all of this is far from trivial. But maybe it >> would be fun to start thinking about how that could be done. Or if the >> groundwork has already been done, maybe it makes sense to make a >> "production ready" tool (Addon?). As far as i know there was some work >> on this done for "RealExtent" a while ago... >> >> Do you have any opinion on such a development ? Does it make sense, are >> there better ways to go, is it doable, feasible ? Anybody working on it >> even ? >> >> cheers, >> Gaia -Chad ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Thinking about a "community edit mode" for blender
Oh and one thing that would definitely have to be done for security is locking out access to arbitrary file paths while in shared edit mode (perhaps defining a drive and/or directory white-list ahead of time). That way remote users couldn't manipulate your system via special files/devices that have side affects from just opening them. And I just remembered watching a macro tutorial recently, which implies that a lot of what is needed do high level replication already exists. While on this subject it got me thinking of another feature (which may or may not already exist somewhere).. If actions can be "replay" replicated between multiple instances of blender, then why not to itself? The Smalltalk IDE by VisualWorks has image files (a snapshot of the VM) and a change list/log. Because of this if the VM crashes (or hangs and you have to kill it off) not all is lost from the last image save. You can simply replay the change file (or even select parts of it) and get back to where you left off. So if something like this existed in blender (or an addon) then when blender crashes (which I get the impression happens often with the newer features before they have a few releases to become stable) it would be trivial to recover. Maybe even when opening a "crashed" file it would ask if you want to replay the changes. There are other examples of this (like 'vi' and other editors), but VisualWorks could also do more with change lists than just recover that session (which is the general limit in text editors). If done right it could be used to export a set of changes as a diff/patch like mechanism for .blend files (unless that's not very useful in practice). Anyway that's enough on these side tangents. On Sun, Nov 18, 2012 at 3:07 PM, Chad Fraleigh wrote: > What about instead of trying to keep the internal data directly in > sync it was treated more like a high level database replay log. Sync > the operations, like select vertex #5, begin move action, move by x/y, > end move action; or set modifier #1 field X to value Y. Assuming all > instances started out with logically identical data/state and have the > same capabilities (i.e. same blender version, and same [active] > addons), then in the end each edited copy should be identical. Of > course this also assumes that all "actions" (whether UI or script > triggered) can be hooked/captured and replicated to the other node(s). > > One catch would be any local system specific data (like non-relative > filenames) that might get applied would not be portable across nodes. > If support for virtual/aliased/mapped file resources existed, then > both sides could have their system dependent resources mapped, and > then these virtual "filenames" could be passed back and forth. While > not a complete solution, it would allow even those that have a > collection of [non-common directory] external data on incompatible > directory structures (or OS's) to still work together. For that matter > there could even be exported virtual resources.. so if resource X > wasn't mapped on one side it could pull the data remotely from another > node that does have it (when allowed). -Chad ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Can BGE be relicensed?
While re-licensing existing code may take some extended effort, what about the option of changing the licensing of any new code added (sooner than later) to dual GPL/LGPL (or even more at the option of the submitter - PD/GPL+LGLP/MIT/BSD/XYZ...)? If a list was maintained for all licenses that each contributor would find acceptable for their part (even if blender/BGE doesn't use all of them itself).. then if there are any later licensing modifications (in part or whole) the change consent issue would be much easier. The only real effort would be for those committing others' code to note a reference to the that author's licensing entry (presumably by some unambiguous identifier, not just name - in case two authors are named John Smith or something). Of course this is already being done for giving credits, so probably not too much of a change. Maybe some of this is already being done (I took a quick look at the development page on the wiki and nothing of licensing requirements/policies for contributors stood out). So either I didn't look in the right place, or it is just understood that being a GPL released project that all code must be GPL (or compatible, like PD). Personally I prefer a BSD license for my code, but when contributing to some [L]GPL project I just accept using their license instead. I wouldn't be surprised if others also frequently contribute code outside their preferred license. On Fri, Nov 30, 2012 at 12:11 PM, Sinan Hassani wrote: > I have started a thread on BlenderArtists asking whether BGE can be > relicensed to LGPL based on the news that VLC is being relicensed from > GPL to LGPL: > > http://blenderartists.org/forum/showthread.php?273712-VLC-coming-to-iOS-Can-BGE-be-relicensed-to-LGPL > > So one thing is for sure, a major open source, free software project > that spans 10 years can indeed be relicensed. Whether that's good or > bad, I don't know and it's not the subject of this topic. This subject > is about whether BGE can be and should be relicensed to be more > competitive as a game engine in the current environment we find our self > in (App Stores, people spending more time on mobile devices, consumers > that want to get their software from a familiar and convenient app > repository, i.e. iOS App Store, Google Play). > > In the second link I post in that thread, it explains why LGPL is more > suitable than GPL for App Stores (also based on a podcast from FSF I > listened to): > > According to the LGPL terms, developers “are not responsible for > enforcing compliance by third parties with this License.” With the > project now licensed as LGPL software, there’s no longer an issue with > Apple’s App Store policy that limits installation to five devices. > > Link: > http://www.geek.com/articles/mobile/vlc-re-licensed-as-lgpl-ready-to-head-back-to-the-app-store-20121115/ > > > So my question is, can BGE be relicensed separate from Blender? If yes, > then which parts can be relicensed? > > Additional points: > > -I'd like to get a reply from all major BGE contributors on whether they > are okay with relicensing. And if yes, are they okay with LGPL, or do > they want a more liberal license? Like MIT? -Chad ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Conversion to a dynamic/plugable modifier system
I've been looking into the idea of having blender support dynamic (and thus plugable) modifiers. Right now it requires any new ones to be merged into the base code and a new version of blender compiled and released. If the Addons and python scripting required this overhead then those contributions would likely have grown very slowly.. so imagine what useful/cool modifiers others could create if not limited to the normal blender development cycle (not to mention the needed approvals that keep dozens of user-specific modifiers from being added and cluttering up blender, but could also discourage useful ones due the extra effort). Some possibilities being: * Adding a custom modifier for a large project (like those open source movie initiatives) where utilizing the modifier stack reduces overhead compared to running a script update to do the same (and is reversible/togglable unlike most mesh scripts). * Override a built-in modifier with a better version. * Could allow early access to new bundled modifier(s) without the instability of using an entire blender version while it is under new development. This assumes the new modifier is compiled as a dynamic module and the so/dll can be just copied (or something to this effect). * Prototype new modifiers and testing/refining them before contributing them as a bundled one. * Might help with implementing true python based modifiers. Technically dynamic modifiers aren't required for python based ones, but may have some common framework changes related to mapping ad-hoc handlers. I'm keeping a list of issues, ideas on required changes, and general notes on a [semi-]private wiki. Here is it's current list of issues that need to be accounted for: * A static compile-time ModifierType enumeration exists which has values that are stored in the .blend files and must remain predictable. With a dynamic system (in which arbitrary authors can write their own modifiers at will) the potential loss of a central Type ID would need to be accounted for. Perhaps a UUID based system in this event. There is also a NUM_MODIFIER_TYPES constant used for a static array allocation in source/blender/blenkernel/intern/modifier.c. * Hard-coded modifier types are checked in various [non-modifier specific] code to perform custom handling. For these few well-known types this could still be used [statically], where the rest are code-coupling free. Or ideally, there might be a better way to do it and eliminate this coupling all together. * In source/blender/blenloader/intern/readfile.c conversions (e.g. addresses remapped, cache clearing, version updates) are done for several ModifierData references (for both object held modifier data and the modifier list). This would need to be done by each modifier directly via a hook function. * In source/blender/blenloader/intern/writefile.c referenced data is written. This would need to be done by each modifier directly via a hook function. * Most (or all) of the modifiers have a custom icon in the UI. A hook to provide icon data would be useful. * There is RNA data for each modifier. Currently this is statically defined in source/blender/makesrna/intern/rna_modifier.c. * It is documented when adding a modifier that property_data_modifier.py needs to be updated to include a method of the new modifier name. * Accessing fields of compiled internal blender structures may break between blender versions. Limiting to a specific blender version range, or using SDNA information to validate and/or access that data in a portable way may be needed. So now that all that is out of the way.. would anyone be offended if I did work toward this goal? Was there someone already doing this who's feet I would step on? In my vision it would ideally require inverting the packaging of modifier related code (i.e. all code related to a specific modifier being in that modifier C file [or modifier directory if grouped that way] rather than being scattered in readfile, writefile, rna_modifier, and other global "activity" files). -Chad ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Conversion to a dynamic/plugable modifier system
On Tue, Dec 4, 2012 at 11:49 PM, José Ricarte wrote: > Hi, about plugins system support in Blender, IMHO, as user. I think > it would be to consider a milestone in future versions. Something specific to modifiers, or a generic one that does all the work common to anything that might use plugins (e.g. scanning plugins directory(s) and probing the so/dll's, a UI to list and allow disabling/enabling specific ones)? Then it could be used for modifiers, render engines, specialized [input] devices maybe, etc.. If so, this could be done independent (more or less) of changes needed to support plugable modifiers.. Just getting the modifiers to a state that they could be compiled and as pre-linked shared library modules is a needed leap before actually being plugable and using such an API/system. -Chad > > -Ciriaco > > El 05/12/2012 8:26, Brecht Van Lommel escribió: >> Hi, >> >> As you have found from reading the code, Blender wasn't really >> designed with plugins in mind. Code for things like modifiers tends to >> be scattered over many files. I fear that making a C/C++ plugin system >> work is a far bigger project than you might think. Getting all the >> components like DNA/RNA/blenloader/UI/.. ready for this would be great >> but I don't think it's a feasible task for one developer. >> >> Making Blender more modular is one of those things that should be >> tackled as a bigger project, like the 2.5 UI refactor or the planned >> dependency graph upgrade. For python we have some mechanisms to make >> extensions work, and I can imagine python modifier support being >> feasible to add using the bmesh python api. >> >> Brecht. >> >> On Wed, Dec 5, 2012 at 12:29 AM, Chad Fraleigh wrote: >>> I've been looking into the idea of having blender support dynamic (and >>> thus plugable) modifiers. Right now it requires any new ones to be >>> merged into the base code and a new version of blender compiled and >>> released. If the Addons and python scripting required this overhead >>> then those contributions would likely have grown very slowly.. so >>> imagine what useful/cool modifiers others could create if not limited >>> to the normal blender development cycle (not to mention the needed >>> approvals that keep dozens of user-specific modifiers from being added >>> and cluttering up blender, but could also discourage useful ones due >>> the extra effort). >>> >>> Some possibilities being: >>> >>> * Adding a custom modifier for a large project (like those open >>> source movie initiatives) where utilizing the modifier stack reduces >>> overhead compared to running a script update to do the same (and is >>> reversible/togglable unlike most mesh scripts). >>> >>> * Override a built-in modifier with a better version. >>> >>> * Could allow early access to new bundled modifier(s) without the >>> instability of using an entire blender version while it is under new >>> development. This assumes the new modifier is compiled as a dynamic >>> module and the so/dll can be just copied (or something to this >>> effect). >>> >>> * Prototype new modifiers and testing/refining them before >>> contributing them as a bundled one. >>> >>> * Might help with implementing true python based modifiers. >>> Technically dynamic modifiers aren't required for python based ones, >>> but may have some common framework changes related to mapping ad-hoc >>> handlers. >>> >>> >>> I'm keeping a list of issues, ideas on required changes, and general >>> notes on a [semi-]private wiki. Here is it's current list of issues >>> that need to be accounted for: >>> >>> * A static compile-time ModifierType enumeration exists which has >>> values that are stored in the .blend files and must remain >>> predictable. With a dynamic system (in which arbitrary authors can >>> write their own modifiers at will) the potential loss of a central >>> Type ID would need to be accounted for. Perhaps a UUID based system in >>> this event. There is also a NUM_MODIFIER_TYPES constant used for a >>> static array allocation in >>> source/blender/blenkernel/intern/modifier.c. >>> >>> * Hard-coded modifier types are checked in various [non-modifier >>> specific] code to perform custom handling. For these few well-known >>> types this could still be used [statically], where the rest are >>> code-coupling free. Or ideally,
Re: [Bf-committers] Conversion to a dynamic/plugable modifier system
On Tue, Dec 4, 2012 at 11:26 PM, Brecht Van Lommel wrote: > As you have found from reading the code, Blender wasn't really > designed with plugins in mind. Code for things like modifiers tends to > be scattered over many files. I fear that making a C/C++ plugin system > work is a far bigger project than you might think. Getting all the > components like DNA/RNA/blenloader/UI/.. ready for this would be great > but I don't think it's a feasible task for one developer. I knew (as a whole) it wouldn't be a trivial thing. But the general plan was to add some [API backward compatible] modifier framework/interface changes over time, and then convert an existing modifier or two to be in a self-contained module as a proof of concept and to work the kinks out. At some point after this making them actual run-time loadable plugins would be a next step. Just being modular could allow them to be compiled as a shard library and linked during standard blender compile time.. the plugin stuff would just be some linking glue added on (albeit not trivial in itself). And while in the long term it would certainly be cleaner and better to do the same for all the other legacy modifier code, technically they should still work as-is (if the new code checks what it needs first and falls through to old code on NULL hook functions and such). Of course once a couple are done and a basic example is laid down, then other developers could jump in and each try to convert other modifiers.. and if new "issues" are encounter in the more complex modifiers, at worse the change could reverted for those specific modifier(s) until more framework updates can be made to support it. The worse case scenario is that even if the end goal ends up a failure, in the effort the code would be made much more modular and code-coupling for them reduced and hopefully make later attempts easier. > Making Blender more modular is one of those things that should be > tackled as a bigger project, like the 2.5 UI refactor or the planned > dependency graph upgrade. For python we have some mechanisms to make > extensions work, and I can imagine python modifier support being > feasible to add using the bmesh python api. -Chad ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Development Environments
While attempting to setup various environments in which I could edit/build/test source pulled from trunk, I came across some issues: The wiki directions for FreeBSD (http://wiki.blender.org/index.php/Dev:2.5/Doc/Building_Blender/FreeBSD) are now incomplete (for trunk at least). Since blender now seems to require python 3.3 and [currently] FreeBSD's ports system only has up to 3.2, it would require the developer to manually compile and install the newer python first. Up through blender 2.64 still seems ok. The directions for Windows says to use Visual Studio 2008 and states that the 2010 version doesn't work. However they now have a 2012 version. So.. has anyone tried it with 2012 yet? If I try it, would it be obvious that it's broke (like a compile error), or something more subtle like blender crashes (or acts strange) when run? -Chad ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Development Environments
On Thu, Dec 6, 2012 at 4:07 AM, Antony Riakiotakis wrote: > We face the same issues for all platforms. Recently I tried to build > blender with MinGW gcc 4.7 and it failed due to incompatibility > between 4.6 and 4.7 ABIs on libraries (thankfully all our libraries > still work with 4.6). We should add a notice of these issues on our > build pages too so interested builders don't find themselves wondering > why their builds crash on startup/fail to link. It must have been the > same for linux distros with our old linux lib folders, thankfully gone > now :) This makes me wonder if it would be worth blender having standard build environment VM images (for VirtualBox and maybe VMWare). Basically a very minimalistic OS install (for a small image size) with all the external tools and libraries needed to compile blender already there, and a default user account. That way developers don't each have to go through all the same headaches, nor muck with what might be their own workstation environments.. just d/l the image, create a machine instance, boot and mount the source (or svn checkout it on a secondary virtual drive). One image could be done for each of: * Linux 32-bit * Linux 64-bit * FreeBSD 32-bit * FreeBSD 64-bit The Linux versions would also contain mingw cross-compile resources needed to build the Windows binaries since native Windows OS images couldn't be distributed due to licensing. This would only leave Mac developers with the environment setup problems (unless there is a working cross-compiler for that too???). -Chad ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Development Environments
On Fri, Dec 7, 2012 at 12:08 AM, Dean Giberson wrote: > Also, just to point out VS2008 is hitting end of life. VS2008 Pro has a > date of April 9, 2013. > http://support.microsoft.com/lifecycle/search/?sort=PN&alpha=Visual+Studio. > I imagine 2008 Express will be similar. A switch to VS2012 Express might > not be a bad thing to look at in the near future. Not a small task but > an important one. VS2008 won't suddenly stop working at this date but it > will get increasingly harder to get any kind of support. > > Is there a team in place to do a VS2012 update? I would be willing to > help out with this if you need the people. The python 3.3 source already has project files for Visual Studio bundled, but it is v11 (i.e. VS2012) format. Are there any free tools that will convert v11 projects to v9 or v10? ;). Oh and I don't know about VS2010, but 2012 only allows a 30-day evaluation without a registration code (but that part is claimed to be free). P.S. I finally got blender to build under Windows (VS2008). Y!! =) But then I hit that assertion error on exit bug. Booo! =( -Chad ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Development Environments
On Wed, Dec 5, 2012 at 9:57 PM, Campbell Barton wrote: > FreeBSD devs will have to build and install python3.3, > Since Blender sometimes uses newer versions of Python then Linux > disto's provide, we have a section at the top of the linux build > instructions [1] (Linking to troubleshooting page [2]). > > So the FreeBSD instructions could do something similar. Seems that the python 3.3 ports might be added to FreeBSD around the end of December. Since I initially didn't know how long it would be, I submitted my own port and as a result found out someone else was already working on it. Since the change also updates a base ports file they have to wait till after the upcoming OS release, around Dec 20th (I assume due to a code freeze). So let's hope the schedule doesn't slip too much for them. ;) -Chad ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Development Environments
On Fri, Dec 7, 2012 at 12:08 AM, Dean Giberson wrote: > Hey, just a note I've been running VS2010 Win64 + Scons without issue > until recently. The current issues are around changes to the OpenEXR > header layout (VS2008 & VS2010 don't have the same layout) & the OSL > lib's not using path-less references into OpenEXR (I can just turn off > OpenEXR & OSL for now). Also there is no python33.lib yet. > > Is there a full build script for the VS2010 libs? Or is it just a matter > DL-ing and compiling each by hand? Other than the docs about switches at > https://svn.blender.org/svnroot/bf-blender/trunk/lib/win64/Readme.txt > are there is there anything to help in doing this task? A continuous > build or such? I've managed to build python lib/dll's (debug & release) for the following: * Visual Studio 2010 32-bit * Visual Studio 2012 32-bit * Visual Studio 2012 64-bit I couldn't get 2010 to build in x64 mode - it just kept skipping the pythoncore project due to some error (which of course it doesn't explain). Though, it may be possible to just use the 2012 versions for 2008/2010 builds too. So should I submit those compiled binaries, or is it preferred I just give the instructions (not much to them, just time and repetition to run them)? I can just hear the thoughts now -- "I'm not using binaries from an untrusted source!" ;) Right now I'm trying to get the boost libs compiled. The build.bat seems to generate 2010 versions, even if run in a 2012 command prompt.. so building 2012 versions ones may not be so easy. -Chad ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Development Environments
I read a comment stating that boost 1.52 has native support for VS2012. Would it be too confusing to start using that version for just windows without upgrading the other platforms (not that they couldn't [eventually] -- it would just be extra work with no real gain, except consistency). Also, I'm guessing the bundled VS2010 compiled boost is from an old version? It is using -s- (release?) instead of -sgd- (debug?) for the lib names and some headers are missing. -Chad ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.65 release AHOY!
On Wed, Dec 12, 2012 at 8:21 AM, pete larabell wrote: > Hey guys, > > I'm out of town all week this week and don't have access to my build > boxes (FreeBSD). > > If there is anyone out there who could make one for 2.65 feel free, or > wait till the weekend when I return home. Unless you/someone were to compile and bundle a copy of python 3.3 with blender it won't work anyway since there won't be a native FreeBSD port entry for that python until [at least] the end of December. Maybe a note should be added to the download page for FreeBSD that "Due to technical difficulties beyond Blender's control, we are unable to provide a compiled version at this time" (or something to that affect). -Chad ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Development Environments
On Tue, Dec 11, 2012 at 1:58 AM, Brecht Van Lommel wrote: > Further, I could commit your libraries but what we really need is a > proper plan to clean up of this stuff. There have been complaints that > our lib/ directory is getting too big, so we should try to split it > up. Usually you only need libraries for one visual studio version, and > only a few developers need the debug libraries which tend to be huge. > > We should figure out a directory structure to make it possible to > checkout only the needed subset, before we start adding a new batch of > libraries for vs2012. Headers can be shared, maybe some (C only?) > libraries can be as well. And then cmake/scons build systems should > also be updated to follow this new structure. Ok, plan #2.. Instead of having all the pre-compiled windows libraries in the checkout we maintain copies of the needed external libs as source code (in compressed tarballs). Then have something like what the linux install_deps.sh script, only it builds all the needed libs and installs them in a structure like lib/windows has now (only simpler since there would be no need to have special directories for various tools). As a side option there could be a set of per-environment, pre-compiled "drop-in" binaries that one could download and extract in the same place the build script would, so the truly lazy people (or ones having problems building them) could still work. Only these would just be zip (or tar) files for download and not part of subversion. I've started creating a MSVC based script (well, nmake file) to do such a task. So far it batch builds the following libs: boost png jpeg tiff python zlib. It also only does the 32-bit versions right now (I wanted to start out with something VS 2008 would use). I also got rid of that annoying vc9/vc100/vc110 name in the boost lib names using the --layout= option (so no special cmake/scons link names needed there). The hardest part is that it is s tedious to locate the right site for each package, then find the version blender currently has (or something close), and figure out how to compile it (where there is no blender build.bat already).. so it's slow work. Here is what I have so far (remember it's a work in progress, but shows the idea). The first section is for compile environment specific settings, and the second general configuration. Eventually the first section would be auto-configured via a .bat script or something which would then run nmake. It also assumes the UnxUtils tools (http://unxutils.sourceforge.net/) is bundled since I needed a reliable way to uncompress/untar the code, and xcopy is still giving me issues that cp doesn't. -<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>- # # @(#) Makefile.nmake # PLATFORM=x32 VS_PLATFORM=Win32 VC_VERSION=9.0 #VC_VERSION=10.0 #VC_VERSION=11.0 CMAKE_GENERATOR=Visual Studio 9 2008 #CMAKE_GENERATOR=Visual Studio 11 PYTHON_PCBUILD=PC\VS9.0 #PYTHON_PCBUILD=PCbuild # # MAXCPU_COUNT=2 SOURCE_DIR=..\source STAGE_DIR=stage-$(PLATFORM) INSTALL_DIR=$(MAKEDIR)\install-$(PLATFORM) # # BOOST_VERSION=1_52_0 BOOST_TARBALL=boost_$(BOOST_VERSION).tar.gz BOOST_INSTALL_DIR=$(INSTALL_DIR)\boost BOOST_STAGE_DIR=$(STAGE_DIR)\boost_$(BOOST_VERSION) BOOST_DEPS=$(BOOST_INSTALL_DIR)\include\boost\version.h JPEG_VERSION=8d JPEG_TARBALL=jpegsrc.v$(JPEG_VERSION).tar.gz JPEG_INSTALL_DIR=$(INSTALL_DIR)\jpeg JPEG_STAGE_DIR=$(STAGE_DIR)\jpeg-$(JPEG_VERSION) JPEG_DEPS=$(JPEG_INSTALL_DIR)\include\jpeglib.h PNG_VERSION=1.5.13 PNG_TARBALL=libpng-$(PNG_VERSION).tar.gz PNG_INSTALL_DIR=$(INSTALL_DIR)\png PNG_STAGE_DIR=$(STAGE_DIR)\libpng-$(PNG_VERSION) PNG_DEPS=$(PNG_INSTALL_DIR)\include\png.h PYTHON_VERSION=3.3.0 PYTHON_TARBALL=Python-$(PYTHON_VERSION).tgz PYTHON_VERSION_LIBNAME=33 PYTHON_INSTALL_DIR=$(INSTALL_DIR)\python PYTHON_STAGE_DIR=$(STAGE_DIR)\Python-$(PYTHON_VERSION) PYTHON_DEPS=$(PYTHON_INSTALL_DIR)\include\python.h TIFF_VERSION=3.9.2 TIFF_TARBALL=tiff-$(TIFF_VERSION).tar.gz TIFF_INSTALL_DIR=$(INSTALL_DIR)\tiff TIFF_STAGE_DIR=$(STAGE_DIR)\tiff-$(TIFF_VERSION) TIFF_DEPS=$(TIFF_INSTALL_DIR)\include\tiff.h ZLIB_VERSION=1.2.7 ZLIB_TARBALL=zlib-$(ZLIB_VERSION).tar.gz ZLIB_INSTALL_DIR=$(INSTALL_DIR)\zlib ZLIB_STAGE_DIR=$(STAGE_DIR)\zlib-$(ZLIB_VERSION) ZLIB_DEPS=$(ZLIB_INSTALL_DIR)\include\zlib.h # # UNXUTILS=$(MAKEDIR)\UnxUtils CMAKE=cmake CP=$(UNXUTILS)\usr\local\wbin\cp -p CP_R=$(UNXUTILS)\usr\local\wbin\cp -Rp GZIP=$(UNXUTILS)\usr\local\wbin\gzip MKDIR=mkdir #MKDIR=$(UNXUTILS)\usr\local\wbin\mkdir -p RM=del /f #RM=$(UNXUTILS)\usr\local\wbin\rm -f RM_R=rmdir /s /q #RM_R=$(UNXUTILS)\usr\local\wbin\rm -rf TAR=$(UNXUTILS)\usr\local\wbin\tar # # all:boost zlib png jpeg tiff python clean: boost-clean jpeg-clean png-clean python-clean tiff-clean zlib-clean cleanall: boost-cleanall jpeg-cleanall png-cleanall python-cleanall tiff-clean zlib-cleanall # # Boost # boost: $(BOOST_DEPS) $(BOOST_DEPS): boost-extract boost
Re: [Bf-committers] MSVC2010 maintainer? Python 3.3 libs missing, or only me?
On Mon, Dec 17, 2012 at 11:48 AM, Dalai Felinto wrote: > Hello everyone. > Is there anyone actively maintaining the MSVC2010 platform? > > It would be nice if the docs [1] could account for this platform too. Sure, > we have the msvc10 folders for some of the libs, does that mean I have to > move those libs to their top folder? and how about the python issue, do we > have any perspective on having Py3.3. libs in the lib/win64 folder?). I've been attempting to create a MSVC based batch (not .bat) build script/makefile for all the external libs needed by blender. Currently I'm just trying to get everything to compile for 2008 / 32-bit, after which I will add the changes (where needed) for 2010/2012 and 64-bit. However the python builds are one of the less messy ones and I've been able to use 2010/32-bit (and 64-bit should just be a two line config change, but I don't seem to have the 64-bit tools installed yet). If you want to try it for yourself (I assume you DO have the full 64-bit tools if you need those libs), you can download a preview (WIP) copy of it: http://www.triularity.org/download/blender/winlibbuilder.zip (134M) http://www.triularity.org/download/blender/winlibbuilder-nosrc.zip (3.6M) If you use the nosrc version (as it is significantly smaller), you will also need to get the source distros for the libs you want to compile. The build/source/README.txt file contains info on where they can be acquired. The builder expects these versions/file names: build/source/boost_1_52_0.tar.gz build/source/freetype-2.4.10.tar.gz build/source/ilmbase-1.0.2.tar.gz build/source/jpegsrc.v8d.tar.gz build/source/libpng-1.5.13.tar.gz build/source/libsamplerate-0.1.8.tar.gz build/source/llvm-3.1.src.tar.gz build/source/openal-soft-1.15.1.tar.bz2 build/source/openexr-1.7.0.tar.gz build/source/Python-3.3.0.tgz build/source/SDL-1.2.15.tar.gz build/source/tiff-3.9.2.tar.gz build/source/zlib-1.2.7.tar.gz Since the core python build doesn't need any other libs you won't need any of the others for that. Just edit the top of build/Makefile.nmake and comment out/uncomment the appropriate architecture and tool version sections. Also I haven't done much testing the produced libs with compiling blender (just getting something to batch build is the first step). -Chad ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Another Slow Day [Maya Mini-Contest]
For those that don't read through all the blender contest entries (maybe you're too busy coding), my response to the recent Maya contest that some might find humorous (or offensive - one of the two): http://www.blendernation.com/2012/12/14/weekend-mini-contest-the-maya-were-right/#comment-618160 or a direct link to the resulting [concept] creation: http://www.triularity.org/download/blender/TheMayaWereRight.pdf -Chad ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] MSVC2010 maintainer? Python 3.3 libs missing, or only me?
On Tue, Dec 18, 2012 at 9:40 AM, Dalai Felinto wrote: > Hi Chad, > Thanks for waving in. > > I get the following error after commenting the proper lines for x64/vc2010 > and installing Python 2.7: > http://www.pasteall.org/38156 Yeah, unless you're compiling for 2008 there's only a 50/50 chance it will work at the moment.. and if doing x64, even less. It seems that freetype doesn't come with an x64 platform config for visual studio. This is one of those "I've gotta eventually hack the configuration" things (and at this point I have no idea how to add x64 to one). Anyway, on a side note there was a couple makefile fixes, one for the 2010 freetype project (that uses that standard Debug/Release names, unlike the 2008 one which used LIB Debug/LIB Release. Also I fixed the install for python x64 (since the project builds into an amd64 subdir for some reason). Anyway, this file should replace the one under build/Makefile.nmake: http://www.triularity.org/download/blender/Makefile.nmake Also, since I still don't have a working 2010 x64 environment (stupid M$ - I guess they didn't want people to easily make modern software for their OS), I have to use 2012 x64. But between 2010 x32 and 2012 x32/x64, hopefully it will be enough for me to make a usable builder script even for 2010 x64. -Chad ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] MSVC2010 maintainer? Python 3.3 libs missing, or only me?
Hmm.. I've been able to get most everything (building so far in VS2008) to work for VS2010/32-bit except the ilmbase/openexr ones (even VS2012/32-bit gets that far after a missing win32.mak kludge for jpeg). I've tweaked the config some (mostly for VS2012), but I didn't think it was that much. Things to note: - Make sure to compile them in dependency order. Right now this may only be the zlib ones (as png expects that). - Are you using the SP1 version of VS2010 (assuming that doesn't break your 64-bit stuff, if using the Express version) I've uploaded a new version of the builder: http://www.triularity.org/download/blender/lib-builder.zip (151M) http://www.triularity.org/download/blender/lib-builder-nosrc.zip (3.6M) Changes include: - The base directory was renamed from 'build' to 'builder'. - The *vc* directory names are now using *vs*. Even though people seem to use them interchangeably, technically MSVC (M$ Visual C) [what cl.exe gives] seems to be versions 15.0/16.0/17.0 for the Visual Studio of 9.0/10.0/11.0 (aka 2008/2010/2012). - I replace using msbuild with nmake for cmake based configs (VS2012 wouldn't compile otherwise -- something about the toolset not found, even though the VS2012 gui built them fine. -- Thanks for the consistency M$!). And the reason I wasn't using the nmake form in the first place was flawed. - Selecting the configuration doesn't require editing the makefile anymore. Just use: nmake [PLATFORM=x32|x64] [TOOLSET_VERSION=9.0|10.0|11.0] [PYTHON27_BIN=xxx] ... - Also you can skip the extra time it takes to build the debug version of libs with the nmake var: NODEBUG=1 (note - didn't actually test that yet) Oh.. and has anyone that's tried using this builder seen random errors that tend to work fine if run again? Usually it's like an 'access denied' error updating an .exe manifest, as if something else had the file it just created open (I had the max cpu set to 1 to avoid parallel commands but with no difference). Ever since last week when I tried to compile cmake from source and AVG reported blocking some trojan in one of it's exe's and then triggered AVG again in some of the eval programs while running ./configure for another open source source distro, I've been a little paranoid. Its like is it just a false positive in some commonly compiled code fragments, or did someone manage to hack the popular config utilities (like that one compiler many years ago that would silently create another infected compiler if used to build itself from source). On Wed, Dec 19, 2012 at 8:58 PM, Dalai Felinto wrote: >> Anyway, this file should replace the one under build/Makefile.nmake: >> http://www.triularity.org/download/blender/Makefile.nmake > > With a bit more testing I found out that almost nothing builds in > either 32 or 64 bits (on msvc2010). It would be nice if someone else > with MSVC2010 could test this too. > > I created a simple batch to help me to generate a log for each library > I wanted to build (the nasm stops running at the first error, so not > so nice to test them all). > > The basic command invoked by the script was: > nmake /f Makefile.nmake %LIB% 1>../build_logs/%LIB%_%PLATFORM%_out.txt > 2>../build_logs/%LIB%_%PLATFORM%_err.txt > > Logs: > http://www.dalaifelinto.com/ftp/tmp/win_blenderlibs_log.zip > > Batch file to generate the logs: > http://www.dalaifelinto.com/ftp/tmp/library_build.bat -Chad ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] MSVC2010 maintainer? Python 3.3 libs missing, or only me?
On Thu, Dec 20, 2012 at 7:03 AM, Dalai Felinto wrote: > I tried in a different machine (windows 7 x64 running a 32 bits MSVC > 9.0) and things are even worse there. Lots of errors. > > Bottomline for me: I don't think I can spend much more time testing > this. So although I appreciate the efforts into streamlining the > libraries build, it would be great if someone could tackle the most > immediate problem: to provide the missing libraries to build blender > (in vc9/vc10 32/64) at least. When I tried to download/unzip your compile logs the file was invalid/truncated: http://www.dalaifelinto.com/ftp/tmp/win_blenderlibs_log.zip So I couldn't look at those errors for comparison. After using procmon to figure out it was Window's file indexing service that was distrupting my compiles and then making changes to stop that made my compiles much smoother. You'd think that a company that creates a background indexing system that is bundled with their *own* OS would be able to make it non-intrusive [like a flag on open() that allows it to trumped by all others in I/O].. but I guess that's Micro$oft quality for you. S a note to anyone doing these builds under C:\Users\... are likely to have the same random problems unless disk indexing has been disabled (at least for your build directory tree). Using these [updated] builders: http://www.triularity.org/download/blender/lib-builder.zip (148M) http://www.triularity.org/download/blender/lib-builder-nosrc.zip (4.3M) I did VS9/x32, VS10/x32, and VS10/x64 builds for all the libraries and uploaded them for anyone that wants to try them out. Also included are the build logs (including those that didn't work) for reference: http://www.triularity.org/download/blender/install-vs9.0-x32.zip (131M) http://www.triularity.org/download/blender/install-vs10.0-x32.zip (129M) http://www.triularity.org/download/blender/install-vs10.0-x64.zip (141M) Here is the list of libs that worked for each: install-vs9.0-x32: boost freetype ilmbase jack ** jpeg lcms llvm openal openexr png python samplerate sdl sndfile ** tiff zlib zlibwapi install-vs10.0-x32: boost freetype jack ** jpeg lcms llvm openal png python samplerate sdl sndfile ** tiff zlib zlibwapi install-vs10.0-x64: boost jack ** jpeg llvm openal png sndfile ** tiff zlib zlibwapi ** jack and sndfile are just from pre-compiled distros as there is no bundled support for MSVC (or there's claims that MSVC won't compile it do to C99 requirements). -Chad ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] MSVC2010 maintainer? Python 3.3 libs missing, or only me?
And to be thorough, the VS2012 scripted builds I could manage at this time: http://www.triularity.org/download/blender/install-vs11.0-x32.zip (141M) http://www.triularity.org/download/blender/install-vs11.0-x64.zip (154M) install-vs11.0-x32: boost freetype jack jpeg lcms llvm openal png python samplerate sdl sndfile tiff zlib zlibwapi install-vs11.0-x64: boost jack llvm openal png sndfile tiff zlib zlibwapi -Chad ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] External libs builder for Windows [v2013.01.18]
After some more work, a few breaks to avoid insanity fighting with some of the VS and cmake configs, and a lot of hacking of the various build scripts/projects (the patches it has to do is a mess!), I got farther. Now I'm able to build all the following libs under VS2008/32-bit, VS2010/32-bit, VS2010+SDK7.1/32-bit, and VS2010+SDK7.1/64-bit: boost freetype ilmbase jpeg lcms llvm openal opencollada opencolorio openexr openimageio png pthreads python samplerate sdl tiff tinyxml yaml zlib zlibwapi I'll try to install the 6.1 SDK soon and see if it also works for VS2008 x64. Unfortunately when I reinstalled my VS's, VS2012 decided to manifest a bug where it doesn't install any of the C header files (thanks M$!).. so I can't do any more testing on them at the moment. The builder setup (with and without source tar/zip distros): http://www.triularity.org/download/blender/lib-builder.zip (186M) http://www.triularity.org/download/blender/lib-builder-nosrc.zip (4.5M) The results of my compiles (the VS10+SDK7.1 x32 was omitted due to size and being mostly redundant if someone just needs the 2010 binaries). http://www.triularity.org/download/blender/install-vs9.0_x32_sdk6.0.zip (217M) ** http://www.triularity.org/download/blender/install-vs10.0_x32_sdk7.0.zip (214M) http://www.triularity.org/download/blender/install-vs10.0_x64_sdk7.1.zip (254M) ** install-vs9.0_x32_sdk6.0.zip is still uploading as of composing this message, so give it half an hour or so if you want that one. The logs for each of those builds (generated by the buildall.bat script) for reference: http://www.triularity.org/download/blender/logs-vs9.0_x32_sdk6.0.zip (275K) http://www.triularity.org/download/blender/logs-vs10.0_x32_sdk7.0.zip (471K) http://www.triularity.org/download/blender/logs-vs10.0_x32_sdk7.1.zip (472K) http://www.triularity.org/download/blender/logs-vs10.0_x64_sdk7.1.zip (498K) All the old install-*.zip's have been deleted (to free up space). -Chad ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] External libs builder for Windows [v2013.01.18]
On Sat, Jan 19, 2013 at 9:59 AM, Brecht Van Lommel wrote: > Great work! So have you been able to build Blender with these > libraries, does it need build system changes too or do things get > installed in the same directory structure as before? I haven't tried them with blender itself yet. Right now I'm still trying to verify that others can repeat the builds without the same compile errors that were experienced on my earlier script releases. I suppose I could copy some into my normal blender lib/ directory and try a few. It wasn't until I did openimageio that I realized that boost was still compiling 32-bit mode (even though I was giving it a 64-bit compiler environment). Right now I've gone back to building only the static libs (where it easily let me) to reduce static/dynamic conflicts. But I was wondering if eventually using the dynamic ones for most in blender would be of value? I see it has some dll's in the blender install, but not many. Since not much would be sharing the libs (really only moving stuff from blender.exe to dll's), it may just be extra work with no real benefit. Maybe the thumbhandler could share some (why _can't_ its code be in the normal build area again??) > So let's see how we can get this stuff in svn. Can we get some > feedback from Windows platform maintainers, do you all agree with the > general idea here? Does anyone want to review the scripts and setups > here? Just a note -- the makefile is still ugly. Eventually I would like to move the section for each lib to it's own .mk file with the base one including them all, or each being a standalone make (and including a .mk for common parts), rather than the monolithic thing it is now. > The question then is also still what kind of directory structure we > want to use for windows libraries. In my opinion we should just have a > lib/windows-arch-vsxxx directory for each combination we support. This > gives a minimal and simple download for users. The include directories > would be duplicated, but that's also an advantage if not all platforms > get updated to a new library version at the same time, otherwise the > build might break. That's what I had in mind also.. since there is already include duplication with the x32-vs-x64 and mingw, it wouldn't be a major change (and the cmake config for blender itself would be simplified -- just configure the base lib path). There would be a few binary duplicates for the few packages that won't compile under VS (due to no vs/cmake config, C99 support, or just being fortran *grin*). I might try to write cmake files for the simple cases (but then someone would need to tweak them with each new lib version). The 'jack' and 'sndfile' libs are the only ones I've found [so far] with predictable sources of precompiled ones for both 32-bit and 64-bit for the VS-no-go list. Also I include a VERSION.txt file (and LICENSE.txt when I can find one in the source) in the install directory for each.. one for license compliance and the other since it is sometimes hard to tell what version a lib is (sometimes in the lib name, sometimes in a header, other times haven't a clue). I appended the .txt part since it might be easier for windows users to open [via double-click] (not counting it running notepad and the file having unix newlines). If these files are added for the other platforms it would be nice to make the names the same (be it with or without the extension). Oh, and the VERSION[.txt] file is always installed last -- so it can be used as a generic "is this lib completely here" test. Also, I don't know what is done now but I think a library manifest (just a txt file would due) that lists all the external libs bundled with blender and their versions to be included with each release so if there are any concerns about security issues with those libs, one can also look at the list. This of course can be pulled from the VERSION.txt files during the blender build. Speaking of mingw.. eventually I would like to have support for that in the builder (not the same makefile since this is nmake specific), but another makefile or script that does those environments (and maybe osx and/or android). It could use any common resources like the source zip/tar distros, and maybe the patches where applicable. -Chad > On Sat, Jan 19, 2013 at 6:47 AM, Chad Fraleigh wrote: >> After some more work, a few breaks to avoid insanity fighting with >> some of the VS and cmake configs, and a lot of hacking of the various >> build scripts/projects (the patches it has to do is a mess!), I got >> farther. Now I'm able to build all the following libs under >> VS2008/32-bit, VS2010/32-bit, VS2010+SDK7.1/32-bit, and >> VS2010+SDK7.1/64-bit: >> >> boost >> freetype >> ilmbase >>
Re: [Bf-committers] External libs builder for Windows [v2013.01.18]
On Sat, Jan 19, 2013 at 2:21 PM, Thomas Dinges wrote: > Hi, > What does that mean for the current x32/x64 MSVC 2008 libs? (VC 2008 is > what we use for official releases). > Will they stay the same, but if we have to upgrade a library we can use > your script? They could be.. at least when updated (no reason to necessarily go replace them all with recompiled ones that are equivalent just for the sake of doing so). > I don't really see the benefit here (yet). It's not the same situation > as on Linux imo. > We don't update libs that often on Windows and if I have to rebuild one > lib or two in weeks/months I rather do it manually with full control, > rather than with a script (which sounds like a big hack if I get you > right). The problem with manual is it is not as reliable. For example for some of the [svn-ed] libs there is a readme file that described how to build it, which was useful.. on the other hand some things were obviously missing because when I followed only those instructions I got errors in some cases without doing more work. With a script everything is effectively documented (maybe not user friendly docs, but everything is there). And there is no need to even know how to use the Visual Studio GUI (just install it and bring up a VS configured prompt). The hacks that need to be done will still be there, only they would have to all be done manually if not scripted (either by editing files or changing various project config options). It also forces that there is a build for VS2010 (and eventually VS2012) for those developers that use those and things, like having no python 3.3 for VS2010 for awhile, shouldn't happen (just because the one compiling that lib manually only did it for VS2008). In some cases (too bad not most) changing versions of a lib is just dropping in the new tar/zip for the source and changing the version tag in the makefile. In fact I remembered recently seeing a security advisory for freetype prior 2.4.11 (the blender win32 svn binary is still 2.4.4), so I _just_ downloaded the 2.4.11 tar (2.4.10 is what they had when I started this builder), changed the version line in the makefile and compiled and installed (in the builder install tree) 2008/32, 2010/32, 2010/64 with one nmake run in each VS command prompt. If done manually it would have required extracting the compressed tar (maybe not obvious for some windows only developers), creating a new x64 platform (as it only comes with Win32) in Visual Studio, selecting the correct configuration (from the multiple choices in freetype), compile, then find and copy all the include, lib, and license files to the right place and ideally create a version file).. and this is if the developer already has experience with this lib's specific build needs. NOTE to anyone that didn't read between the lines in the previous paragraph: freetype*.lib needs to be updated for security fixes!!! (via scripted or manual) At minimum it has these problems: <2.4.11 http://portaudit.FreeBSD.org/1ae613c3-5728-11e2-9483-14dae938ec40.html <2.4.9 http://portaudit.FreeBSD.org/462e2d6c-8017-11e1-a571-bcaec565249c.html <2.4.7 http://portaudit.FreeBSD.org/54075e39-04ac-11e1-a94e-bcaec565249c.html <2.4.6 http://portaudit.FreeBSD.org/5d374b01-c3ee-11e0-8aa5-485d60cb5385.html freetype/freetype.h will have its version, e.g.: #define FREETYPE_MAJOR 2 #define FREETYPE_MINOR 4 #define FREETYPE_PATCH 4<-- Ugg < 11 ! In the end the scripts are for the same reasons that linux has build scripts for their package source distros. Yes, those linux packages could all be compiled manually by the various authors/venders and then distributed in binary packages for use by the masses.. and in the cases where the few (well, few relative to the entire user base) want to compile something themselves, then it is up to them to reinvent the compile wheel. Maybe blender doesn't have as many needed libs, but it is the same principle. Soo.. there's my 2 cents (give or take $5). =) -Chad > Regards, > Thomas > > Am 19.01.2013 06:47, schrieb Chad Fraleigh: >> After some more work, a few breaks to avoid insanity fighting with >> some of the VS and cmake configs, and a lot of hacking of the various >> build scripts/projects (the patches it has to do is a mess!), I got >> farther. Now I'm able to build all the following libs under >> VS2008/32-bit, VS2010/32-bit, VS2010+SDK7.1/32-bit, and >> VS2010+SDK7.1/64-bit: >> >> boost >> freetype >> ilmbase >> jpeg >> lcms >> llvm >> openal >> opencollada >> opencolorio >> openexr >> openimageio >> png >> pthreads >> python >> samplerate >> sdl >> tiff >> tinyx
[Bf-committers] Libs on windows?
While attempting to test my script compiled libs with a blender build I noticed some things: iconv doesn't seem to be used for windows [blender] builds. The only place I see it in the cmake config is for "if(APPLE)", and even then it is only a -liconv entry (so a system lib I assume). So is this something that isn't used anymore (and should be removed from trunk/lib/win*), a windows lib added but never included in the cmake config, or something that is needed by other lib (that I have yet to try compiling) and gets inlined into their dll? Is OSL currently working for windows? When I enabled WITH_CYCLES_OSL (in VS2008/32-bit) it crashes with some invalid pointer when I start blender. Also, just wondering.. what determines if something goes in blender/extern/ vs lib/x/? -Chad ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] External libs builder for Windows [v2013.01.18]
On Sat, Jan 19, 2013 at 9:59 AM, Brecht Van Lommel
wrote:
> Great work! So have you been able to build Blender with these
> libraries, does it need build system changes too or do things get
> installed in the same directory structure as before?
I was able to build blender (VS2008/32-bit) with the following libs
replaced with ones I built by script:
boost
freetype
jpeg
lapack
lcms
llvm
openal
opencollada
opencolorio
openexr
openimageio
png
pthreads
python
samplerate
sdl
tiff
zlib
I had to do some more tweaks with the scripts to fix the include names
in some cases and copying some libs to legacy names, and roll boost
back to 1.49 (while updating libs one-by-one since old boost name
implib's existed -- but now I can try 1.52 again). I'll try to upload
an updated lib-builder zip soon. I also had to make a few temp mods to
the cmake files since I split out some of the bundled libs into their
own package:
-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-
Index: blender/source/creator/CMakeLists.txt
===
--- blender/source/creator/CMakeLists.txt (revision 54059)
+++ blender/source/creator/CMakeLists.txt (working copy)
@@ -599,7 +599,7 @@
install(
FILES
${LIBDIR}/openal/lib/OpenAL32.dll
- ${LIBDIR}/openal/lib/wrap_oal.dll
+# ${LIBDIR}/openal/lib/wrap_oal.dll
DESTINATION ${TARGETDIR}
)
endif()
Index: blender/CMakeLists.txt
===
--- blender/CMakeLists.txt (revision 54059)
+++ blender/CMakeLists.txt (working copy)
@@ -903,6 +903,7 @@
set(OPENAL ${LIBDIR}/openal)
set(OPENAL_INCLUDE_DIR ${OPENAL}/include)
set(OPENAL_LIBRARY wrap_oal)
+set(OPENAL_LIBRARY OpenAL32)
set(OPENAL_LIBPATH ${OPENAL}/lib)
endif()
@@ -1070,7 +1071,9 @@
if(WITH_IMAGE_OPENEXR)
set_lib_path(OPENEXR "openexr")
set(OPENEXR_INCLUDE_DIR ${OPENEXR}/include)
+set(OPENEXR_INCLUDE_DIR ${OPENEXR_INCLUDE_DIR} ${LIBDIR}/ilmbase/include)
set(OPENEXR_INCLUDE_DIRS ${OPENEXR}/include/OpenEXR)
+set(OPENEXR_INCLUDE_DIRS ${OPENEXR_INCLUDE_DIRS}
${LIBDIR}/ilmbase/include/OpenEXR)
set(OPENEXR_LIBPATH ${OPENEXR}/lib)
set(OPENEXR_LIBRARIES
${OPENEXR_LIBPATH}/Iex.lib
@@ -1079,6 +1082,13 @@
${OPENEXR_LIBPATH}/Imath.lib
${OPENEXR_LIBPATH}/IlmThread.lib
)
+set(OPENEXR_LIBRARIES
+ ${LIBDIR}/ilmbase/lib/Iex.lib
+ ${LIBDIR}/ilmbase/lib/Half.lib
+ ${OPENEXR_LIBPATH}/IlmImf.lib
+ ${LIBDIR}/ilmbase/lib/Imath.lib
+ ${LIBDIR}/ilmbase/lib/IlmThread.lib
+)
endif()
if(WITH_IMAGE_TIFF)
@@ -1164,6 +1174,9 @@
set(OPENCOLORIO_LIBRARIES OpenColorIO)
set(OPENCOLORIO_LIBPATH ${LIBDIR}/opencolorio/lib)
set(OPENCOLORIO_DEFINITIONS)
+set(OPENCOLORIO_LIBRARIES ${OPENCOLORIO_LIBRARIES} optimized tinyxml
debug tinyxml_d)
+set(OPENCOLORIO_LIBRARIES ${OPENCOLORIO_LIBRARIES} optimized
libyaml-cppmt debug libyaml-cppmtd)
+set(OPENCOLORIO_LIBPATH ${OPENCOLORIO_LIBPATH} ${LIBDIR}/tinyxml/lib
${LIBDIR}/yaml/lib)
endif()
-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-
Those changes could be done with something more permanent by adding
WITH_TINYXML, WITH_YAML, WITH_ILMBASE, and maybe WITH_OPENAL_SOFT (the
soft version doesn't need/have wrap_oal anymore) which would allow old
or new libs to be used during a [good 'old known libs vs iffy new
sparkly libs] transition phase.
I can build/link and start blender fine, but I didn't do any real
testing to exercise each lib. Also, since I built the soft version of
openal, it comes up with this message on start:
AL lib: (EE) UpdateDeviceParams: Failed to set 44100hz, got 48000hz instead
I saw some other references to this online (with linux where I guess
openal-soft is the system version). I'm not sure if it is a serious
error. I also saw mention of another openal problem where someone's
code worked fine until they switched to the soft version and had to
correct their code -- this might imply the soft lib is less forgiving
of API usage errors than the old one, if there are also such broken
usages in the blender code.
But on the plus side, some of the 32-bit vs 64-bit lib names would be
simplified as these scripts always build the same names (no more
special case for libz on win64). I also build a debug version of each
lib (which only exist for some svn ones now), so debugging of errors
Re: [Bf-committers] Libs on windows?
On Thu, Jan 24, 2013 at 3:40 AM, Brecht Van Lommel
wrote:
> On Thu, Jan 24, 2013 at 2:18 AM, Chad Fraleigh wrote:
>> iconv doesn't seem to be used for windows [blender] builds. The only
>> place I see it in the cmake config is for "if(APPLE)", and even then
>> it is only a -liconv entry (so a system lib I assume). So is this
>> something that isn't used anymore (and should be removed from
>> trunk/lib/win*), a windows lib added but never included in the cmake
>> config, or something that is needed by other lib (that I have yet to
>> try compiling) and gets inlined into their dll?
>
> It seems indeed this is not used anymore and was replaced by boost locale.
In the case where it is included, it seems iconv is for boost_locale
to use itself.
The portion of CMakeLists.txt:
if (WITH_INTERNATIONAL)
list(APPEND BOOST_LIBRARIES boost_locale-mt)
set(PLATFORM_LINKFLAGS "${PLATFORM_LINKFLAGS} -liconv")
#
boost_locale needs it !
endif()
It is odd that boost_locale would need iconv for APPLE, but not other platforms.
>> Is OSL currently working for windows? When I enabled WITH_CYCLES_OSL
>> (in VS2008/32-bit) it crashes with some invalid pointer when I start
>> blender.
>
> It's working with the library in svn now, not sure why it crashes for
> you. Make sure to match all the build options from build.bat for OSL
> and OIIO.
This is with just the standard svn windows libs. I first noticed it
when I was attempting to test my lib builds (so I enabled a few of the
WITH_* settings that are OFF by default) and it crashed. So I
eventually put them all back to svn and did a fresh build (or at least
I thought I did) and still had the problem. After some trial and error
flipping WITH_* options it seemed to be the WITH_CYCLES_OSL one (via
some llvm callback in the stack trace).
The configure used was:
cmake -G 'Visual Studio 9 2008' -DWITH_OPENCOLLADA:BOOL=ON
-DWITH_LLVM:BOOL=ON -DWITH_CYCLES_OSL:BOOL=ON
-DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DWITH_INTERNATIONAL:BOOL=ON
-DCMAKE_BUILD_TYPE:STRING=Debug ../blender
Just to be sure I'm running another fresh build using only the svn'd
libs (at least this time I can go sleep while it runs, rather than
wait around for it like the rest [talk about tedious testing]).
>> Also, just wondering.. what determines if something goes in
>> blender/extern/ vs lib/x/?
>
> I think usually things go into extern if there is no maintained
> library can be expected to become a linux package, or if it's a small
> library. But there is no clear rule that is always applied.
I did notice that openjpeg is used in the build but no
lib/windows/openjpeg/ install. My first thought was "why doesn't
windows use it".. then I realized it was auto built in the extern
directory (I only ever saw libmv building there it since that one
takes so long). But I have noticed that openimageio can use openjpeg,
if available. So would including it in openimageio (and the things
that use it, like OSL) be worth moving it to lib/ (or openimageio to
extern/ [which also would pull in OSL], at the price of making it a
very heavy build)? This was the idea I had with making a script to
build all the libs, only just once up front (or when something
changed) for each developer's specific "build environment". So it
wouldn't not compile them _every_ time, like extern/, and not static
(except "when someone updates svn for a given build environment")
either, but half way between.
-Chad
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Libs on windows?
On Thu, Jan 24, 2013 at 4:51 AM, Chad Fraleigh wrote:
> The configure used was:
>
> cmake -G 'Visual Studio 9 2008' -DWITH_OPENCOLLADA:BOOL=ON
> -DWITH_LLVM:BOOL=ON -DWITH_CYCLES_OSL:BOOL=ON
> -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DWITH_INTERNATIONAL:BOOL=ON
> -DCMAKE_BUILD_TYPE:STRING=Debug ../blender
>
> Just to be sure I'm running another fresh build using only the svn'd
> libs (at least this time I can go sleep while it runs, rather than
> wait around for it like the rest [talk about tedious testing]).
I confirmed that an svn-only build does crash with those cmake
settings. Other env info:
- Visual Studio 2008 Express
- 32-bit compile
- VS Built-in SDK (so 6.0A).
- OS - Win7 x64.
The trunk/blender was r54059 and trunk/lib/windows was r54014 (but no
lib/windows changes occurred between the two revs).
If WITH_CYCLES_OSL is removed from the options then it runs fine.
Stack trace:
blender.exe!memcpy(unsigned char * dst=0x074c7d8c, unsigned char *
src=0xcdcdcdcd, unsigned long count=15) Line 314 Asm
blender.exe!memcpy_s(void * dst=0x074c7d8c, unsigned int
sizeInBytes=15, const void * src=0xcdcdcdcd, unsigned int count=15)
Line 67 + 0x11 bytesC
> blender.exe!std::char_traits::_Copy_s(char * _First1=0x074c7d8c,
> unsigned int _Size_in_bytes=15, const char * _First2=0xcdcdcdcd, unsigned int
> _Count=15) Line 465 + 0x15 bytes C++
blender.exe!std::_Traits_helper::copy_s
>(char * _First1=0x074c7d8c, unsigned int _Size=15, const char *
_First2=0xcdcdcdcd, unsigned int _Count=15,
std::_Secure_char_traits_tag __formal={...}) Line 597 + 0x15
bytes C++
blender.exe!std::_Traits_helper::copy_s
>(char * _First1=0x074c7d8c, unsigned int _Size=15, const char *
_First2=0xcdcdcdcd, unsigned int _Count=15) Line 589 + 0x28 bytes C++
blender.exe!std::basic_string,std::allocator
>::assign(const
std::basic_string,std::allocator > &
_Right=, unsigned int _Roff=0, unsigned int
_Count=4294967295) Line 1057 + 0x25 bytes C++
blender.exe!llvm::cl::opt_storage,std::allocator
>,1,1>::setLocation() + 0x4b bytes C++
blender.exe!llvm::cl::opt,std::allocator
>,1,llvm::cl::parser,std::allocator
> > >::opt,std::allocator
>,1,llvm::cl::parser,std::allocator
> > >,std::allocator
> > >() + 0x85 bytes C++
blender.exe!`anonymous namespace'::DefaultVLIWScheduler::`vector
deleting destructor'() + 0x32aa44 bytesC++
blender.exe!_cinit(int initFloatingPrecision=1) Line 307 + 0xf bytes
C
blender.exe!__tmainCRTStartup() Line 249 + 0x7 bytes C
blender.exe!mainCRTStartup() Line 182 C
kernel32.dll!756533aa()
[Frames below may be incorrect and/or missing, no symbols loaded for
kernel32.dll]
ntdll.dll!77ea9ef2()
ntdll.dll!77ea9ec5()
The source line it crashed on:
static _Elem *__CLRCALL_OR_CDECL _Copy_s(_Out_cap_(_Size_in_bytes)
_Elem *_First1, size_t _Size_in_bytes, _In_count_(_Count) const _Elem
*_First2,
size_t _Count)
{ // copy [_First1, _First1 + _Count) to [_First2, ...)
// _DEBUG_POINTER(_First1);
// _DEBUG_POINTER(_First2);
_CRT_SECURE_MEMCPY(_First1, _Size_in_bytes, _First2, _Count);
<<-- This Line!
return _First1;
}
Debugger Local Vars:
+ _First1 0x074c7d8c " " char
*
_Size_in_bytes 15
unsigned int
+ _First2 0xcdcdcdcd const char *
_Count 15
unsigned int
-Chad
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Libs on windows?
On Thu, Jan 24, 2013 at 3:29 PM, Brecht Van Lommel wrote: > Hi, > > On Thu, Jan 24, 2013 at 11:15 PM, Chad Fraleigh wrote: >> On Thu, Jan 24, 2013 at 4:51 AM, Chad Fraleigh wrote: >> >>> The configure used was: >>> >>> cmake -G 'Visual Studio 9 2008' -DWITH_OPENCOLLADA:BOOL=ON >>> -DWITH_LLVM:BOOL=ON -DWITH_CYCLES_OSL:BOOL=ON >>> -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DWITH_INTERNATIONAL:BOOL=ON >>> -DCMAKE_BUILD_TYPE:STRING=Debug ../blender >>> >>> Just to be sure I'm running another fresh build using only the svn'd >>> libs (at least this time I can go sleep while it runs, rather than >>> wait around for it like the rest [talk about tedious testing]). > > The backtrace doesn't tell me much, what I would check is that > everything is compiled with the same configuration (i.e. using /MT, > debug/release). There are build.bat files in lib/windows for llvm, > openimageio and windows, I'm not sure if you used the flags from there > to build the libraries but I had to carefully set these when I built > these libraries. > > Further, from libraries you listed I see openimageio and llvm listed > but not OSL. So is this still the existing OSL library but newer llvm > and openimageio? In that case they might not be compatible until you > also build OSL against these newer versions. This is _all_ out of the box blender svn code and libs. None of my own compiled libs or any custom changes (beyond the shown cmake args) used. -Chad ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Windows x32 issues
I wonder if that is the same error I get with CYCLES_OSL enabled builds. I'm rolling my checkout back to that rev and seeing if a build from it stops my crash issue too (my builds are run on a fairly new AMD laptop, so it would discount old hardware if it is the same problem). -Chad On Fri, Jan 25, 2013 at 10:39 AM, Thomas Dinges wrote: > Hi, > we have two reports in tracker with fatal crash on startup, which make > me wonder what happened. > > http://projects.blender.org/tracker/index.php?func=detail&aid=33996&group_id=9&atid=498 > http://projects.blender.org/tracker/index.php?func=detail&aid=33993&group_id=9&atid=498 > > Both use old hardware (Pentium 3 / old Intel chipsets) but both claim > that it worked for them in SVN 53922 / 53924. > > Normally I would just reject those (Non-SSE2 CPU / old Intel GPU) but > the similar time frame and revision which still works, indicates a > possible issue in our code base. > > Regards, > Thomas > > -- > 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 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Minimal Blender specs - 5 year old systems & OS
On Tue, Jan 29, 2013 at 7:11 AM, Thomas Dinges wrote: > I can only fully agree with this. > It becomes a pain to support old systems, especially Windows XP and old > GPUs. > > Not only do we support hardware / software longer than other 3D > software, as Blender is free people can also always stick to an older > version. A question then.. if some older versions use bundled libs with security bugs in them, how do they use blender on old hardware without the risk of being hacked (perhaps just from opening an image file)? Also, I'm a little iffy on assuming large screen resolutions (as that is just realestate, not a technical support issue). If developers just assume larger and larger screens, then they tend to waste/abuse it. Has anyone here ever used the AWS console.. one of their windows *assumes* people have a large screen and some apply/confirm buttons are placed at the bottom (with NO vertical scrollbar) even though there is a big gap of space above them. I have to open it in it's own window since the tabs in my browser make my content window just small enough not to be able to reach these buttons. Also in general, I don't run my windows maximized -- this isn't DOS with one app at a time (or the same effect by taking over the entire screen). I have to shrink my blender window down some every time I start it so I can see some of my other windows (I guess there is a way to change that default, maybe, but I haven't searched very hard to find it yet). I'm not saying old hardware should be supported forever, but don't assume "if newer hardware can do it that users use it that way". -Chad ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Minimal Blender specs - 5 year old systems & OS
On Tue, Jan 29, 2013 at 3:59 PM, Campbell Barton wrote: > On Wed, Jan 30, 2013 at 9:53 AM, Chad Fraleigh wrote: >> On Tue, Jan 29, 2013 at 7:11 AM, Thomas Dinges wrote: >>> I can only fully agree with this. >>> It becomes a pain to support old systems, especially Windows XP and old >>> GPUs. >>> >>> Not only do we support hardware / software longer than other 3D >>> software, as Blender is free people can also always stick to an older >>> version. >> >> A question then.. if some older versions use bundled libs with >> security bugs in them, how do they use blender on old hardware without >> the risk of being hacked (perhaps just from opening an image file)? > > They would have to build (or get someone to build) an older blender > version linking to newer libs. > This shouldn't be too hard, I still have 2.49 building on arch linux > with recent libs. What about windows? While some blender users could eventually figure out how to do everything needed to compile an old svn branch with current(ish) trunk libs.. most I expect wouldn't have a clue what MSVC or MinGW is (they just want to be artist -- or at least "play one at home"). I can imagine cases where parents give their older computers to their [younger] kids, since they'd be less worried of being broken.. and if we'd like those kids to become hooked on blender. ;) Same for schools that might not be able to upgrade computers as often due to budget cuts. If M$ can give schools free or cheap software to try trick kids into using their junk, why not ensure as many of them also use something useful (the CG movie market isn't going away any time soon). So if blender officially drops support for old hardware in trunk, would it be unreasonable to at least continue limited support for some of the older versions (i.e. 2.49, 2.59, eventually 2.69, ...)? At least when there are security updates for ones they had bundled (when the corresponding libs in trunk get updated), or if a serious security hole is every found in the blender code itself. So we might (well, definitely if freetype gets fixed in them) have a 2.49c (and so on) binary release. Of course for any platform where a patch doesn't affect it (maybe it was a standard system lib for that OS), it would just skip that patch version (e.g. windows might get a 2.49d while linux stayed with 2.49c, then later linux (and others) would have a 2.49e (where applicable). This is why I've mentioned that I think each release should have a "bundled lib" manifest included with each build/install so that anyone can see what versions of what are there.. it would also make things like this easier to track. Also, re-reading part of the initial statement regarding GPU's.. Maybe we would want older GPU support (in some form). I mean you hear about someone that took and made a high scale cluster out of some legacy hardware now and then. With cycles having parallel support, it would be nice [for some] to use cheap[er] hardware in a cluster (or at least one to augment their workstation). Does blender have built-it support for offloading rendering yet? I know I've seen add-ons for some, but typically are 3rd party renders. It would be cool if, out of the box, one was able to run a blender process in background on one or more machines, then just configure their workstation blender with the other host names (and maybe ports, auth key) and it would just use them. No complicated cluster config, extra software, or anything like that. Just a [pipe] dream thought moment there. =) Oh, and if GPU (well, really co-processing hw in any form) support was more generalized [long term] to be able to support a wider range of venders (still just Nvidia?), it may need less overhead to support legacy GPUs (with-in reason of course). -Chad ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Minimal Blender specs - 5 year old systems & OS
On Thu, Jan 31, 2013 at 8:25 AM, Jed Frechette wrote: > FWIW, I see 3D content creation as a fundamentally high-end endeavor. > Being able to start learning Blender on low-end systems is great. However, > I want Blender to be taken seriously as a professional tool, not just > something you play with until you are able to afford "real" hardware and > software. That sounds like a rather narrow view. Wouldn't this be like telling musicians that they _can't_ make a career unless they sign up with some major recording label that has "real" resources (that then takes 90% of the artists' money). It is a good thing those people that wrote that software for commodity hardware that does much of what costly recording studios used to only do didn't think this way. Or maybe start charging $500 for blender to filter out all those pesky users that can't afford (or prefer not to waste that much money on) $2000 "real" systems. This must be the Maya philosophy, given the [are you &$^* kidding me] US$3675 price tag (it probably requires $10,000 hardware minimum). > If development is being held back by attempting to support old hardware > and OS versions and no one is willing to step up and support those bits > then their use should be depreciated.I would much rather see the limited > developer hours available put towards moving Blender forward rather than > attempting to maintain compatibility with an ever increasing list of > legacy hardware and OS versions. And if the product _only_ caters to the rich (or "professionals" that write it off as an expense) and significantly limit its target audience, then interest in development will drop (the nature of OSS). It seems part of the issue here is all these generic statements that blender should drop support for X and Y, but not many specifics on what "development effort" it would actually unhinder (OpenGL is maybe the only one that has had some specific reasons mentioned [I think]). For example, "Drop XP".. Ok, if support for just XP was dropped, what would be different? I mean if I was to go out and buy some $5000 top-of-the-line system and then install XP on it (assuming the drivers all worked fine), then what about this machine would be harder to support in blender? Similar vagueness goes with RAM.. the suggested new minimum is 2G. I assume this is what the machine has total, not what is available to blender after the OS, any background apps/processes (and what if one runs a Windows VM on their linux box?). So how much memory does blender typically "get" after overhead on a 2G system running XP, how about Vista, Win7, Win8, or Linux? Each newer OS version tends to use more memory that prior ones for itself.. so requiring a new OS is likely to artificially "require" more system memory to let blender do the same thing. So maybe the better thing to do would be state what specific developmental/runtime requirements will be minimally supported instead of what some assumed hardware/OS, that may or may not meet those true requirements, when blender is executed on a user's system. This goes back to my previously stated principle of "don't assume just because a system _has_ resource X that application Y will get that due to user's choices of how that system is used overall" (give or take however I originally phrased it). Oh, and when the minimums do change.. would it be better to do it on major 2.x lines? So we don't have users going "Feature X in 2.67 is great (despite the crashes).. I can't wait for the stabilized form in 2.68, the next minor release. What? I can't run 2.6x anymore _with_ a stable feature X?!" -Chad ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Minimal Blender specs - 5 year old systems & OS
On Fri, Feb 1, 2013 at 3:31 AM, Ton Roosendaal wrote: > I don't think this response justifies the careful and positive way everyone > who works on Blender is handling this topic. But I realize it might not be > well visible whether people who talk here are also contributing to Blender > though. > > Knowing all of the active devs here quite well, I can only ensure you they're > all very responsible, and proud to contribute to a program that runs on > nearly everything. > > But we have to cope with open source dynamics, which depends on the singular > fact that nothing happens without people contributing to it. That's > democratic & fair. I have nothing against the blender developers.. in fact I've been trying to help and _be_ one of those developers (part time anyway). It is just that when someone makes a comment that seems to imply "play with blender if you like, but if you're serious and don't have _real_ hardware, then don't bother", it comes off a little insulting.. especially for those that don't try to "keep up with Joneses", so to speak. This is what I was trying to point out that _IF_ such a view was applied to an open source project (like blender), then interest in contributing would drop. Letting blender do new and great things, giving the average user the potential to create amazing things (and without shelling out an insane amount of money for Maya) is the best goal.. but alienation effects (which will always happen no mater what) should be balanced in. And I know I'm not anywhere near the best "professional grade" user of blender in the world, and it took me a long time to get the hang of it. When I first started I would try it for a while, learn all the [effectively] minimum shortcuts, then stop for awhile, and then had to relearn all the shortcuts I forget. Mostly this was because there was a bug in my laptop video driver that would lock up the system about %80 of the time I used the selection box (B), followed by a hardboot, and filesystem check. There was no driver update available and being a laptop I couldn't install a new video card. I even tried running an Xserver and displaying blender back from my BSD box, but hit the same bug. Eventually when I did get a new laptop, part of the criteria was it _had_ to have a keypad and not use the same series video card, so that I could run blender without the problems (see.. that's how much I like blender!). > For non-developers this 5 year guideline might seem arbitrary or unclear, but > for everyone who's been working - especially on support and bugs - it's a > growing frustration that we can't help people anymore using old hardware or > OSes. > > Also... developers and users also want the best product possible, utilizing > current hardware and OS developments. To balance this I proposed this > guideline, which still offers a far better platform support you'd get from > any commercial 3d software. Maya wouldn't even be supported 5 years ago on > systems we still do! > > At some moment people who are stuck in the past with hardware, also need to > accept they cannot get new software for it either. We will do our very best > here, but in cases where support is really impossible we can use the proposed > guideline to define what to do. If it is _just_ a suggested minimum [for the user] and official support criteria [for the developers], then that isn't so bad. But most of the time when software comes with an OS minimum, they mean it -- if it said XP minimum, then it generally _wouldn't_ run on Win98 at all. If all blender is changing is that it will only support bugs that they can reproduce on "these" officially supported OS's (even if the bug was seen on an old OS by the user), then that is different. This is why I kept asking "what" those minimum changes really mean (e.g. "Don't expect to run newer blenders on XP [at some point] at all" vs. "It is known to run on XP, but we can no longer provide support for XP specific problems"). Ideally Win32 is Win32 is Win32 and something written for that spec, running on Vista, Win7, etc, should still run on XP (and maybe even Win98?) But in reality M$ is M$ is M$ and when library calls that work on XP Pro don't always work on XP Home, the whole ideal thing goes out the window. Having said all that, I have no delusions that the current blender should run on old systems forever, like a 32M RAM system running Win98 (though I was a little disappointed many years ago when I could no longer install FreeBSD on an old 4M RAM laptop). Maybe I'm just too much of an idealist developer, in that if done right, you don't always have to make sacrifices (or complete sacrifices) to move forward (the Capt. Kirk/Kobayashi Maru opinion of software I suppose). Or maybe I've been burned too many times by vendor support and gotten a little sensitive.. like that laptop video card -- seems like every hardware vender declares EoL on their products just after (if not before) people buy their product from a stor
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [54299] trunk/blender/intern/cycles: Fix cycles intersection issue with overlapping faces on windows 32 bit and CPU
Does the new minimum hardware specs imply SSE required? If not then either OCIO should be compiled without SSE (i.e. cmake -DOCIO_USE_SSE=OFF ... ), or the minimum hardware list be updated to specifically state SSE also (the minimum proposal email didn't state any specific CPU [features], that I saw). The only other option is have both an SSE and non-SSE lib for OCIO and then use each in an optimized and non-optimized blender distro, or have both as DLL's in the installer and let the user chose if they don't want the SSE version during install. -Chad On Mon, Feb 4, 2013 at 8:23 AM, Thomas Dinges wrote: > Hi Brecht, > I think we could drop the non optimized Kernel (no SSE), as we don't > support CPUs without SSE2 any more since Blender 2.65. > Rendering already crashes on those systems (Windows at least), as OCIO > requires SSE2 too. > > Best regards, > Thomas > > Am 04.02.2013 17:12, schrieb Brecht Van Lommel: >> Revision: 54299 >> >> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=54299 >> Author: blendix >> Date: 2013-02-04 16:12:37 + (Mon, 04 Feb 2013) >> Log Message: >> --- >> Fix cycles intersection issue with overlapping faces on windows 32 bit and >> CPU >> without SSE3 support, due to 80 bit precision float register being used for >> one >> bounding box but not the one next to it. >> > -- > 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 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] CPUDevice and implementation selection (native/sse2/sse3)
Two questions.. Currently in CPUDevice/CPUDeviceTask where optimization can be used it first calls the system_cpu_support_sse2() check, and then if that is unavailable tries system_cpu_support_sse3(). I guess this is also a two part in itself - 1) Is it false to assume SSE3 would be better than SSE2? If SSE3 is better then shouldn't this check be first followed by the less ideal SSE2 (followed by the even less ideal basic impl)? 2) If a cpu supports SSE3, would it always also support SSE2, and effectively never use the SSE3 implementation (as SSE2 always gets used instead) as-is. The other thing is since CPUDeviceTask is already OO-based, rather than doing checks each time an optimizable method is called to determine what implementation to use, wouldn't it be cleaner to make CPUDeviceTask semi-abstract and create three sub-classes (e.g. BasicCPUDeviceTask, SSE2CPUDeviceTask, SSE3CPUDeviceTask) with each custom impl and just have task_add() [or something] decide which to create? Depending on how often these methods are called it may or may not have much time saving (by not doing those checks each time), but would seem more maintainable than having several related #ifdef's and system_cpu_support_*()'s scattered about. It might also eventually help allow other implementations to be dropped in without needing large chucks of the core CPUDeviceTask modified (i.e. if plugable support for devices is ever reached/to be reached). Also, for CPU's that support (and thus require SSE), how hard would it be to compile the non-optimize calls (and functions) out to reduce the final executable size, as that code will never be called in these cases? If the final 'else' part of the 'if/else if' was removed and used an #else instead (on WITH_OPTIMIZED_KERNEL) for the non-optimized parts. Ok.. this makes is 3.5 questions total! =) -Chad ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] CPUDevice and implementation selection (native/sse2/sse3)
On Mon, Feb 11, 2013 at 2:58 PM, Chad Fraleigh wrote: > The other thing is since CPUDeviceTask is already OO-based, rather > than doing checks each time an optimizable method is called to > determine what implementation to use, wouldn't it be cleaner to make > CPUDeviceTask semi-abstract and create three sub-classes (e.g. > BasicCPUDeviceTask, SSE2CPUDeviceTask, SSE3CPUDeviceTask) with each > custom impl and just have task_add() [or something] decide which to > create? Oops.. drop the 'Task' suffixes from those comments. I saw CPUDeviceTask being declared mid way through CPUDevice and thought the methods after it where in that class instead. This is a _very_ confusing place to declare another class! -Chad ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Rigify addon causes error, error, error,....
This question probably has already be discussed, but are there any plans to implement an addon deployment like mozilla applications (firefox/thunderbird/seamonkey 2.x) uses where the client (blender) can just browse a central http://addons.blender.org/ site (or something) and with a click or two, install/upgrade what they want. Then there would be few (or none) bundled by default. And if they are bundled, they would act as defaults (i.e. only if that plugin hasn't already been installed for the user, regardless of versions). Then newer addons could be published without needing to align with the blender release cycle. Making sure already installed ones are compatible with potential internal blender changes will still be an issue. But if addon deployers (assuming more than just core blender developers could maintain these addons) would keep what versions of blender that each of their addons (by version) are compatible with. From that a single metafile could be generate automatically/daily/whatever for blender to download/check (with user consent) automatically when it detects a different blender version installed. Maybe .bap (Blender Addon Package) files (which are just zipfiles)? =) And I assume python can be used [client side] to do all this, as-is, and that resorting to trying a [much?] harder C implementation could be avoided. -Chad On Sun, Feb 17, 2013 at 11:28 PM, Knapp wrote: >> Is there some way that we could rework addon loading such that local >> versions of addons (e.g. in .config/blender/x.x/scripts/addons) >> override and take precedence over official repo versions? That way it >> is easy to have local versions of addons. With a lot of addons that >> might seem pointless, but with Rigify it's actually an important >> use-case. >> >> --Nathan > > Why not make the official version a dumby/empty that then seeks to > load a version. Then just load up the one you want. > > > -- > 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] YAML insecurity run a muck
So with all the discussions about the YAML security hole (that tends to read more like "chicken little" in most blogs), and that it could affect other languages (like python) under certain conditions.. has anyone looked at any potential [security] impact for blender? Also since the OpenColorIO lib uses it, it hypothetically might be a problem too. Currently I'm not sure how blender deals with python scripts embedded in .blend files to prevent the blender equivalent of a macro virus, but even if sand-boxed, could things like YAML be used to bypass any protections? A page that talks about risks in PyYAML: http://nedbatchelder.com/blog/201302/war_is_peace.html -Chad ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] www.blender.org server ok?
Is everything ok with the blender web server? I keep getting timeouts accessing it with a browser (but I can ping the host fine). If this is old news, then just ignore me.. otherwise, this is your heads up! =) -Chad ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Rigify addon causes error, error, error,....
On Mon, Feb 18, 2013 at 9:12 PM, Campbell Barton wrote: > On Mon, Feb 18, 2013 at 7:38 PM, Chad Fraleigh wrote: >> This question probably has already be discussed, but are there any >> plans to implement an addon deployment like mozilla applications >> (firefox/thunderbird/seamonkey 2.x) uses where the client (blender) >> can just browse a central http://addons.blender.org/ site (or >> something) and with a click or two, install/upgrade what they want. >> Then there would be few (or none) bundled by default. And if they are >> bundled, they would act as defaults (i.e. only if that plugin hasn't >> already been installed for the user, regardless of versions). Then >> newer addons could be published without needing to align with the >> blender release cycle. >> >> Making sure already installed ones are compatible with potential >> internal blender changes will still be an issue. But if addon >> deployers (assuming more than just core blender developers could >> maintain these addons) would keep what versions of blender that each >> of their addons (by version) are compatible with. From that a single >> metafile could be generate automatically/daily/whatever for blender to >> download/check (with user consent) automatically when it detects a >> different blender version installed. >> >> Maybe .bap (Blender Addon Package) files (which are just zipfiles)? =) >> >> And I assume python can be used [client side] to do all this, as-is, >> and that resorting to trying a [much?] harder C implementation could >> be avoided. >> >> >> -Chad > > Gaia Clary has a working online addon browser, I'm not sure of the > status right now though of if she intends to further develop it. Is there a link to a demo somewhere that would give an idea of what features it has? > As I see it. the issue with this is we end up having to write our own > package manager which is simple to begin with but gets complicated > fast > (consider existing extension repositories of mature applications - > firefox and eclipse for example). Are you specifically referring to the client side, server side repository data (no UI), server side HTML repository browser (read-only), and/or server side package CMS? The first two I expect are simple enough, the third more effort, and the last being the hardest (especially if updatable by "general users"). > So we need someone to write & maintain it, then buy-in from existing > extension developers. As a transition, the core addons could stay in subversion with maybe just some metadata files added, but otherwise be maintained nearly the same. > Since we already have a hard time maintaining existing addons in > subversion, I'm not sure this would be a success at the moment. Is this because there aren't enough core developers to maintain them (including the contrib ones), or simply that they are "second class" code that is mostly ignored until someone wants to improve one (or something unexpectedly breaks due to an internal application change)? If it is a developer resource problem, then if the contrib ones could be more directly maintained by their contributors (instead of being quasi-part of blender's code), in the long term it could reduce the blender side maintenance (just like google doesn't "maintain" publisher's individual android apps much beyond allowing them add/update them on the google play site). If mainly for other reasons, then I guess there isn't as much of a maintenance benefit beyond offloading some contrib related codebase change requests. Also, I'm guessing that the addons, as-is now, aren't generally [some form of] unit test friendly to allow automated testing before each release (assuming manually testing all of them is even done now). I threw together a document (~14k text) of how I would envision (give or take) a [remote] repository based addon/package system. While I'm not sure how it compares to that addon browser that was already done, I could post it (after I clean up the formatting a little) to see what everyone thinks (that feels like doing some "lite reading" ;) ). -Chad ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Hypothetical take on client/server based addon/package repositories
Here are some ideas/notes/comments/[delusions?] on what a
client/server for blender addon's could look like. Basically it is how
I would go about a basic implementation of such a system (give of take
some refinements along the way). Unfortunately, not being python
person, if I tried to write a prototype client, it would probably be
considered cruel and unusual punishment to the project. ;) I could
create a small demo repository using some of the existing addons, if
anyone thinks that would help. Otherwise, maybe some will read this
and point out any design flaws (that hopefully can be accounted for).
And, since I haven't seen the other repository addon manager demo, I
have no idea how this differs (or is redundant of) that one.
Anyway.. here it is (warning! it is a _little_ long)..
-Chad
Package Side Format
===
Zip structure
-
myaddon.bap:
manifest.txt The package meta-data (required)
license.txtThe full license text (optional)
icon.png An icon of the addon (optional).
python/The base directory for python
(equivalent to each addon directories as-is now)
(required if python based)
lib32/freebsd/ Various platform specific directories for holding
lib32/linux/ binaries (i.e. DLL's/.so's) The os-mnemonic would
lib32/osx/ be a fixed defined value in blender for each OS.
lib32/windows/
lib64/freebsd/
lib64/linux/
lib64/osx/
lib64/windows/
Manifest Format (MIME style)
For general package manifest information, a simple MIME header style
should be adequate. This could be a modified form (no line
continuation, max line length ~200 characters maybe, UTF-8 allowed for
some field values).
Package-Version: 1
ID: {----}
Legacy-ID: myaddon
Name: My Add-on
Version: 1.0
Icon: icon.png
Type: addon/python
Creator: John Doe
Copyright: Copyright, 2013, John Doe Industries
License: GPL/3.0
Description: Do the things an add-on should do.
Description: A really long description is continued with multiple
Description: lines.
URL:http://myaddon.example.com/
Platform: linux/32
Platform: windows/32
Platform: linux/64
Platform: windows/64
Target-Application: blender:2.69-2.78
The breakout would be (some based on the firefox addon meta names):
Package-Version (required)
The spec version of all meta-fields in this group.
Ideally this should rarely need to change.
Suggested as first field, but not required as such.
ID (required)
The unique ID. This should be considered case insensitive.
For UUIDs, it would be enclosed in braces (i.e. {}).
Also could potentially use domain based identifier rules
(e.g. org.blender.addon.rigify), but this alone doesn't
account for domain ownership changes over time (without a
datestamp encoded with it, in a consistent format). Maybe
more like org.blender.addon.rigify@201302, with the date
being a MM[DD] with-in the domain ownership period
(doesn't have to be the domain registration date like some
schemes use), as long as the same date is always used for
the same addon.
Legacy-ID (optional)
Used to match again the legacy name.
Maybe this wouldn't be needed, but was a thought.
Also could be called Friendly-ID (see below - far below)
Name (required/utf8)
The simple addon name.
Version (required)
The addon version (in "unbound" dot notation).
1.0
3.0.2
1.5.2.1
2.3.2013.02.18.1 (no, that's not a stardate!)
The versions parts would be compared as text (no assumption of
value ranges as integers). So 1.0.92800018178901018117191011.2
is a valid version. Missing [right side] parts are same as 0.
Possible a single letter suffix could be supported (which
would be treated as an addition .## notation of: X - 'a' + 1).
2.63 --> 2.63
2.63a --> 2.63.1
Icon (optional/multi?)
The package relative path of an icon file (always png?).
If multiple are allowed to be specified, then the "best fit"
would be used (each assumed to be a different resolution,
or maybe even format [like SVG over a bitmap]).
Type (required)
The [hierarchical] type mnemonic of what the package contains.
addon/python -- Standard addon (python)
[Bf-committers] Modifier modularity/[plugability] - writefile
With the goal of blender [eventually/one day] having dynamically
loadable modifiers, there would be a long road of steps needed to get
there. Some of them, like making the modifier code base more modular,
appears to be relatively easy (moving the same code [for the most
part] around). Even without the loadable modifiers goal, doing this
seems worthy (less monolithic do-everythings-implementation code,
better cohesion). So with this sub-goal in mind, I would like to start
with relocating modifier-specific portions of the writefile.c code to
the module files themselves. Other cohesion areas would follow later.
The initial pass would involve mostly just moving the code from the
monolithic writefile.c to each module's .c file and have a call to the
modular function be left in it's place. A later phase would be to add
a 'writeData' hook to ModifierTypeInfo, and then it would be the same
as the other polymorphic modifier hooks. However in the first part the
new function wrappers are written in a generic/common way so switching
to ModifierTypeInfo hook form doesn't require any changes except maybe
making the function static (and even that is only because it no longer
has to be global).
In the example (see below), C++ style comments ('//') are used as
example notations and not literal "would be" comments in the code.
Another issue also dealt with (since "fixing" it lines up well with
the changes anyway).. Currently little (if any) of the writefile code
does/handles errors. So if there is an I/O error mid-way, or invalid
data structure detected while writing (e.g. a NULL field that should
_never_ be NULL), it just ignores the error and keeps on writing more
elements. This could easily lead to corrupted save files with no
feedback to the user that there was a problem. So in the new functions
a status code is always returned, which eventually the calling code
would check (and also return any errors upstream). In these examples I
use an 'int' status code (where 0 means error, and non-0 is success)
for a "success boolean" type value, but this could potentially use a
typedef-ed enum if more than just pass/fail is needed (but at the
price of a simple "if(!x(...))" calling expression). Another fix
is using const for arguments that point to data that won't be altered
by the function (like [blo_]write_struct() in the example).
There are some local write_X() functions used in the existing
code. To minimize the risk of hypothetical side breakage I add a
"public" wrapper using the blo_ prefix (and including a status code
placeholder) for those that would need to be called from relocated
"modifier" code. Eventually once nothing references the legacy
function(s) directly, they would be merged with/changed to be the
public version (and ideally return a real status code, if available).
I also wasn't sure which case convention to use for function prefixes
(i.e. mod_ vs MOD_ or blo_ vs BLO_) as existing code doesn't always
use one form consistently.
I would be willing to do most of the conversion leg-work.. Move/update
the code from writefile to the appropriate modules, add the
[available] error checking, etc.. and submit the patch files. Then
someone with commit would simply have to look it over and commit it,
or reject it because I missed something in that conversion, or reject
it if the patch didn't apply cleanly (i.e. the svn code changed in
between). In the later case I would just create and submit a new patch
from the updated code (as not to waste the commiter's time with
[messy?] merge work). For each modifier conversion I would first send
out a message to bf-committers a day ahead with the planned files to
change, in case anyone has significant commits pending in those areas
(which another large change might interfere with), so they can veto
it. In situations like that I would just skip/delay that modifier and
go to another. After submitting the patch to the tracker, I would post
the reference to bf-committers for a commiter to [hopefully] handle
[more] quickly (and reduce the chance of a patch conflict). The other
option, if some commiter was willing, I could just email the patches
directly to that person and skip the tracker and bf-committers
notification parts (the bf-committers heads up would still go out).
Also, presumably these efforts/changes would be done in the period
starting when the codebase is unfrozen after a release, which I assume
the the best time for more "radical" (but not really that radical)
changes.
The example conversion [fragments] (below) is of the "hook" and
"cloth" modifiers (written back in December [wow, has it really been
that long], so if any changes where made since, they will not be
reflected here).
-Chad
>> blender/source/blender/blenloader/BLO_writefile.h
// Forward declaration (private otherwise)
struct _WriteData;
// Add some "public" API declarations
typedef struct _WriteData WriteData;
int blo_write_data(WriteData *wd, int filecode, int len, const void *addr);
[Bf-committers] .../blenkernel/intern/modifier.c [modifiers_getVirtualModifierList() comment]?
In the file blender/source/blender/blenkernel/intern/modifier.c there
is a comment above modifiers_getVirtualModifierList():
-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-
/* NOTE: these aren't used anymore */
ModifierData *modifiers_getVirtualModifierList(Object *ob)
{
/* Kinda hacky, but should be fine since we are never
* re-entrant and avoid free hassles.
*/
static ArmatureModifierData amd;
static CurveModifierData cmd;
.
.
.
-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-
Does anyone know what "these aren't used anymore" refers to? The
functions after the comment? Something in this function? Something
else? Nothing (i.e. an old comment about some already deleted code)? I
see that modifiers_getVirtualModifierList() is called by others
functions.
-Chad
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Please turn off Auto Run Python Scripts by default
On Thu, Jun 6, 2013 at 11:13 AM, Campbell Barton wrote: > On Thu, Jun 6, 2013 at 6:47 PM, Ton Roosendaal wrote: > > > I think you give up too easily here. :) For example, we could also make > a bpy.os module, and mark scripts that use this as 'trusted'. Scripts using > the os.module itself then require a user to explicitly run it, or being > embedded in a file marked trusted (own files etc). > > You know I already attempted this and have been shown by developers > more expert in CPython internals then me, that CPython makes not > effort to support such limitations and that is trivial to workaround > them. > > You assume there is an effective way to control module importing (that > we could even stop a script from using any of CPythons bundled modules > - `os` included). > > I'd want good evidence this can be done, until someone shows this - > I'll assume it can't. > > https://pypi.python.org/pypi/pysandbox/ ? ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Please turn off Auto Run Python Scripts by default
On Fri, Jun 7, 2013 at 2:48 AM, Thomas Dinges wrote: > Hi, > this is a bad idea (especially the first one). > Adobe Reader also doesn't tell me on first start "Thanks for using Adobe > Reader, be aware of evil .pdfs". > > I bet inexperienced people will get afraid reading that and come to the > conclusion, that this blend format is very insecure and shouldn't be > used at all. > I am sure we can improve security, without frightening our user base. ;) > While the threat exists and is trivial to exploit, maybe users _should_ be afraid. :\ Imagine if users had been more wary about opening emails from unknown sources, that the "I Love You" virus wouldn't have run a muck as badly (and this doesn't even accounting all the other attachments blindly opened by users). I'm not saying that blind fear (and not being unable to tell the difference of "what" to be afraid of) is any good.. but when the alternative is highly vulnerable ignorance, which is worse. Sure.. users can turn it off in their preferences (and load window?), but only if they know the threat exists to begin with. I have the feeling that most novice/intermediate users of blender think of the .blend files no differently than a text or JPEG file. That it isn't a "program" that can do just about anything it likes beyond the editor (baring an "un"-intentional bug in the viewer/editor like a buffer overflow vulnerability), but simply 3D modeling data. I mean realistically, how hard would it be for someone with a little too much [spare] time on their hands to write a python autorun script that scans for other .blend files and infects them with copies of itself (including a malicious payload presumably)? <<-- Lets just hope NOBODY takes that as a challenge. =| Anyone that thinks turning users off because of blender being too nagging is a problem, just wait until some mass infection spreads through the community.. then you'll see users turned off _and_ pissed. Did we learn nothing from Microsoft's "convenience over security" mistakes? -Chad ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Please turn off Auto Run Python Scripts by default
On Sat, Jun 8, 2013 at 11:55 AM, Harley Acheson wrote: > Something quite important has to happen in order to turn a one-to-one > attack into a virus-like problem. > > As "patient zero" I get the first bad blend. It can't immediately do > something bad to me or that is the end of the infection as I will not be > able to infect anyone else. Instead it needs to make it so that any new > files I create (and/or old ones) contain the same bad behavior. Otherwise > it can't replicate. > > So isn't the answer simple? Just not allow a *script* to set any settings > related to the auto-running of scripts? > Unless it manipulates the to-be infected files directly. Old boot sector viruses could do what they needed in a few hundred bytes (if not far less) and only with basic BIOS/DOS services available.. Now compare that with what power a python script has at its disposal and try to imagine what it "can't" do. All that is needed is to get a [normally] "trusted" source of .blend files to open one infected file with autorun (due to overconfidence, being rushed, sleep deprivation, distracted by pets/kids/spouse, etc..) and now everyone using future releases of their "trusted" files are at high risk. This is Virus Propagation 101. Even that [presumed safe] commercial DVD of blender media isn't 100% immune to passing viruses along.. many years ago I worked somewhere in which there was a virus on the mouse driver floppy as-is from the computer vendor. While things like this are rare, they can happen (admittedly more so when virus scanners were uncommon/non-existent). -Chad ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Python security - proposal
On Mon, Jun 10, 2013 at 11:05 AM, Jürgen Herrmann wrote: > Hmm... > > First of all we should assume that Linux user won't usually run blender as > root or in a sudo environment. So a "rm / -rf" attack shouldn't work by > default. > Not from a full OS attack perspective, but it should would wipe out any file/directory writable by the running user. For personal blender users, this would just make them hate blender and wish they did backups.. but for users in shared environments (maybe with mounted drives that are group writable) a single blender user might wipe out significant parts of the work of their entire team. Having it download and install botnet clients would be more likely (given that it seems to be the fad now a days). > We should start small and look at the PGP signing possibility first. This could also incorporate a > third party signing process. For instance some signing authority sort of thing. Something like adding a "SIG1" data block to the [near] end of the .blend file that signs all data before it (any blocks following it, except END, would either be ignored or cause the signature to be invalid). It would be ignored by older versions of blender, like any other unknown block, so backward compatible. Possibly something based on a sub-set of S/MIME [RFC3851] or OpenPGP [RFC4880] (so an existing standard can be followed). The biggest [legal] problem might be the exportability of blender with any bundled crypto libs (you know those pesky governments/regulations). While not as clean, having it hand off the data and signature parts to an external program, if available (that can be downloaded and installed along side blender, but keep blender itself untainted), is possible. Can PGP [the implementing application(s)] be used this way, including blender specific/driven key management? And would CA's be needed or are just entity public keys (I get the impression PGP doesn't use CA's) enough? Also, assuming a self-key is automatically generated by blender for each user (so they can implicitly sign anything they've created), settings whether to auto-sign (and which key to use), whether to auto-trust their own or not (i.e. they open something untrusted, make a small change, and re-save it with their signature), and options to export/import their (or really any) key(s) from one blender install to another would need to be accounted for. Oh, and if the original comment just meant to create a second signature file (e.g. .blend.sig), that might be simple for a "quick implementation", but then forces users to always upload/download two files (when signed). Also if you rename/move the .blend, you have to do the same for any signature file. Hassles that might cause many to opt out (i.e. just ignore the .sig) which puts things back where they started (only with users complaining more when legit scripted blender files don't work right because the validation was skipped). While a Blender Foundation public key could be bundled with blender easily.. how would any .blend or addons (if signing for them is done [at some point]) be signed? Since not just any developer would have access to the BF private signature key, presumably only a _very_ few would do any "official" signing.. but if signing had to be done somewhere between compiling and building the distro file, how would this work for each developer that produces official build for their platform(s)? If per-addon signature data was just kept in static file (e.g. manifest.sig) for each file in the addon (think signed jars style), then I suppose the "holder of the keys" would just do a batch signing of all addons just before a release (for any out of date at least). Speaking of that.. it might be nice to have a standalone cmdline program for batch .blend signing. Also.. in any case, any content being validated _must_be the same data read by blender itself. Having another program re-read the "same" blender file directly to validate is not secure (such race conditions are simple enough to write attacks for). And while it seems like anything that can manipulate files to exploit such race conditions _already_ has compromised that system, it could be attempting to exploit a different user or even different machine (using a shared filesystem with an infected machine). So.. there's some thoughts and warnings if signing was to get added. Everyone can wake up now after reading all that boring, technical, mumbo jumbo. -Chad ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Building Blender
On Sun, Apr 29, 2018 at 11:05 AM, John Emmas wrote: > On 29/04/2018 15:27, Ray Molenkamp wrote: > >> the libs are a couple of gigabytes and having to do it twice is sometimes >> problematic >> >> > Thanks Ray, > > This might seem like a dumb question but can the subversion modules be > downloaded incrementally somehow? I installed a proper copy of subversion > and began my download. It downloaded about 1.2GB and then just stopped... > ;-( > > To limit downloads to directory level granularity (not perfect, since some libraries are still large): Option #1: Create a skeleton directory structure of the repo, then checkout each individual library directory with-in it. This will require updating each checkout separately to keep them current. Option #2 (if it still works in svn): Use "svn co -N" to checkout the base directory, followed by "svn update -N" for each intermediate directory (if any), and finally a normal "svn update" for each leaf directory (i.e. library). Once all significant directories are updated, run "svn update" on the base directory to tidy up/fill in anything missing. After this, only a single update will be required to keep the entire tree current. Note: After "svn co -N", the sub-directories won't be visible (or if doing option #1). You can use "svn ls [/]" to get the names for the yet-to-be created directories. -Chad ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] 2.7x to 2.8x Migration
While it might be the best practical solution (given the current environment), I wouldn't consider it ideal. An "ideal solution" might be something along the lines of it detecting a potentially incompatible old .blend file, notifying the user, and automatically converting it (via a bundled external program, if need be). Something like this, if done right, could conceivably also convert very old files (like 2.4x) without forcing users to go through great efforts to use older models in modern blender versions. When someone wants to open an old version of a word doc, they generally aren't expected to install the old version of word, just so they can convert their document to something the new version of word can use. But again, ideal may not be in practical reach. At the very least, it should warn users when it loads a .blend file that *might* have data loss due to dropped data structures (that aren't perfectly auto migrated), so that novice-to-immediate users don't stare at pitch black objects and wonder why the "cool looking model" file they just download doesn't look like the preview image. On Wed, May 2, 2018 at 3:51 AM, Dalai Felinto wrote: > Hi there, > > We now have a page to help users with migrating 2.7 files to 2.8: > https://wiki.blender.org/index.php/Dev:2.8/Source/Migration > > The big topic that is open for discussion and external contribution is the > Blender Internal conversion. > > The ideal solution would be a Python script for Blender 2.79 that converts > Blender Internal materials to EEVEE-compatible Cycles materials. It doesn't > need to be a perfect conversion, but at least a way for users to not stare > at pitch black objects when opening their 2.7x files in EEVEE. > > We are not prioritizing this at the moment. So this is a perfect > opportunity for someone from the community to help the Blender 2.8 project > :) > > Thank you, > Dalai > -- > blendernetwork.org/dalai-felinto > www.dalaifelinto.com > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Use of semantic versioning
On 12/8/2018 3:58 AM, Mick Lawitzke wrote: it is really awesome to see the latest development of Blender. I am super impressed and hyped for what is coming. Anyway i think there is a big flaw that also results in a problem with marketing: Your versioning numbers suggest that 2.80 is just a minor update to 2.79 and people call it 2.8 (eight) instead of 2.80 (eighty). I am a software developer for 15 years now and i highly recommend you to use semantic versioning: - Current version is Blender 2.79 but what if you do bugfixes on 2.79, you would not call it 2.80 right? A better approach would be to call it 2.79.0 and then a bugfix makes it 2.79.1. The current latest version might be 2.79.102 if there were 102 patches on that version. - The next version would be 2.80.0. But since you worked 3 years on that and introduce so many awesome improvements and changes this is a major update and would introduce Blender 3.0.0 (Or short just Blender 3). It does use semantic [compatible] versioning, just not in standard dot-notation. Think of it more like 2.[], where the leading 2 is [mostly] meaningless (similar to JDK versions 1.2, 1.3, 1.4, ... where the 1 part is basically ignored). Blender -> "standard" dot notation examples: 2.7 -> 2.7.0.0 2.70 -> 2.7.0.0 2.78 -> 2.7.8.0 2.78a -> 2.7.8.1 7.78b -> 2.7.8.2 From marketing perspective a "Blender 3" would have a much bigger impact than just an update from "2.79" to "2.80" which is also incorrectly called "2.8", too. 2.8 is shorthand for 2.8x, like "version 4" is shorthand for 4.x (in standard dot notation). In addition to that i just wanted to mention, that some big projects skipped a version to make the latest update even more obvious: - Windows jumped from 8 to 10 - PHP jumped from 5 to 7 This could be an option for Blender, too, to improve the marketing even further: Jump from 2.79 to Blender 4. But in my opinion a jump to 3 would already do the job. Ugh.. manipulative, fake version jumps is for products that care more about PR than actual quality. And it is anti-semantic versioning, since it breaks the logical/meaningful progression it was designed for (instead of projects just picking versions out of a hat, all willy nilly). Personally, I've always thought it was a little confusing, too, but for backward compatibility, that's what it is. Of course, when it eventually gets past version 2.99, there might be an opportunity to move to standard notation (e.g. 3.[.], then 4.x.x, ...) without breaking the 2.x numbering style. Another option could be to market it as "Blender 8" (where the 2.* is ignored), but still use 2.8x elsewhere (however, that is confusing just like what java/JDK did). Maybe "jumping" to version 8.x (for technical realignment, not trying-to-impress PR reasons). Really, 9.x would be the earliest this could be done since 2.8x is already so heavily ingrained. The last option would be my vote, given that 2.9x planning is probably little more than a concept at this point and could easily be made 9.x. So there's my 2 1/2 cents on the subject. Any similarity between my thoughts and those of a raving madman may be more than just coincidental. =) -Chad ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Should we change the splash image when theversion number changes?
On 10/11/2019 5:42 PM, Stephen Swaney wrote: We should *definitely* keep the new splash reveal at the very end, both for the excitement and the ritual. For a development splash, let's just take the last release splash and overlay it with some yellow police tape and Under Construction signs. I was thinking of something similar.. it would be the previous splash with an "under construction" overlay (e.g. scaffolding, paint cans, tools, etc), but have small portion(s) of it masked out with the new splash peeking through. So it keeps its context (i.e. it is specific to between those releases), but isn't a full spoiler (more of an enticing preview). And, of course, the construction overlay itself could be updated and evolve over time. -Chad ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] 2.90 per-module roadmap
Is the semantic versioning style migration (e.g. 3.x [or maybe 9.x]) being revisited for 2.9x? Since last time it was after 2.80 was started and would have been too confusing to try then. On 6/10/2020 6:25 AM, Dalai Felinto via Bf-committers wrote: Hi, Yesterday there were meetings with all the module owners regarding the 2.90 targets. As always these are initial plans and are expected to change. For a more detailed list, check the complete meeting notes: https://devtalk.blender.org/t/2020-06-09-blender-2-90-roadmap/13788 User Interface (*) === * Modifiers new layout / drag & drop * Statistics * Cursors (and tools) final design. Modeling === * Fast mesh editing T73360 (not the entire milestone) * UV Editing polishing. * Add Object Tool polishing. * Polishing other tools. Python & Add-ons == * No API breakage. Sculpt, Paint, Texture (*) * Multires wrapping up. * Vertex paint in sculpt. * Technical debts Animation & Rigging * Performance and bug fixing. Nodes & Physics = * Particles nodes as experimental feature - won’t be production ready * Initial point cloud support * OpenVDB integration with mantaflow * Mantaflow usability polishing VFX & Video == * Distortion nodes. * Compositor - bug fixing. * VSE - bug fixing but no refactor. EEVEE & Viewport === * Motion blur. * Stereoscopy polishing. * Point cloud rendering. * Vulkan groundwork (GL encapsulation, cleanups). * Fix MacOS volume drawing. Data, Assets & I/O == * Alembic refactor. * USD exporter improvements. * More work on static override Grease Pencil === * Annotation arrows. * Blocking and 3d-2d pipeline. Render & Cycles = * Embree. * OIDN. * Sampling patches. * Other smaller patches. -- (*) - both "User Interface" and the "Sculpt, Paint, Texture" modules need an extra module-wide meeting to help clarify the targets. Both are scheduled for next week. Thank you, -Dalai- Dalai Felinto - da...@blender.org - www.blender.org Blender Development Coordinator ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] move prebuilt libs from svn to git?
I've been kind of wondering if they would eventually be migrated too. I only update my local libs occasionally, so it has a tenancy to fail if doing a large update spanning many revisions. Plus the benefit of not having to use two different tools. Now with Git LFS being more widespread, it should mitigate the issue with all the large binary libraries. On 6/16/2022 11:43 AM, Tom M via Bf-committers wrote: > When checking out the libraries from SVN following the directions on > > https://wiki.blender.org/wiki/Building_Blender/Windows > > The svn checkout of the libraries fails with significant frequency, > > if you google you might stumble across using make svnfix > > https://www.mail-archive.com/bf-blender-cvs@blender.org/msg151996.html > > Even after using it, I'm still having to do Ctrl C, and then make > svnfix repeatedly (it downloads some files, than randomly freezes, > sometimes after 20-50 files, sometimes after 100's of files). > > Git doesn't seem to have any problems, though. > > So might we consider migrating the libs to git, rather than using SVN? > > LetterRip > ___ > Bf-committers mailing list > Bf-committers@blender.org > List details, subscription details or unsubscribe: > https://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org List details, subscription details or unsubscribe: https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] move prebuilt libs from svn to git?
On 6/16/2022 11:51 PM, Ankit via Bf-committers wrote: > Tom: > 1. Unlike SVN checkout, git checkout cannot be resumed. It starts > over if interrupted. > 2. .git folder's size will blow up with every release. Git is not > so good for binary files. Yes, plain vanilla git would be bad with them. If I understand LFS correctly, it only holds object references. So even if the pull can't be restarted, it would only have the [small] references to download. The actual downloading of the [large] binary files is moved to the checkout phase (which doesn't appear to be an all-or-nothing step). But I could be wrong. > > Chad: > > https://developer.blender.org/T73511 > https://developer.blender.org/T73394 These are from about 2 years ago. So if there were still any blocking issues back then, support for LFS should have grown since (at least enough to re-evaluate the feasibility of migration). > > Cheers > Ankit > > > On 17/06/22 00:45, Chad Fraleigh via Bf-committers wrote: >> I've been kind of wondering if they would eventually be migrated too. I only >> update my local libs occasionally, so it has a tenancy to fail if doing a >> large update spanning many revisions. Plus the benefit of not having to use >> two different tools. >> >> Now with Git LFS being more widespread, it should mitigate the issue with >> all the large binary libraries. >> >> On 6/16/2022 11:43 AM, Tom M via Bf-committers wrote: >>> When checking out the libraries from SVN following the directions on >>> >>> https://wiki.blender.org/wiki/Building_Blender/Windows >>> >>> The svn checkout of the libraries fails with significant frequency, >>> >>> if you google you might stumble across using make svnfix >>> >>> https://www.mail-archive.com/bf-blender-cvs@blender.org/msg151996.html >>> >>> Even after using it, I'm still having to do Ctrl C, and then make >>> svnfix repeatedly (it downloads some files, than randomly freezes, >>> sometimes after 20-50 files, sometimes after 100's of files). >>> >>> Git doesn't seem to have any problems, though. >>> >>> So might we consider migrating the libs to git, rather than using SVN? >>> >>> LetterRip >>> ___ >>> Bf-committers mailing list >>> Bf-committers@blender.org >>> List details, subscription details or unsubscribe: >>> https://lists.blender.org/mailman/listinfo/bf-committers >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> List details, subscription details or unsubscribe: >> https://lists.blender.org/mailman/listinfo/bf-committers > ___ > Bf-committers mailing list > Bf-committers@blender.org > List details, subscription details or unsubscribe: > https://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org List details, subscription details or unsubscribe: https://lists.blender.org/mailman/listinfo/bf-committers
