Re: [Bf-committers] It is a build error in filetype.c of r60621.
err can you past the complete build error? (use pasteall.org) or poke me on irc (dfelinto) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] It is a build error in filetype.c of r60621.
I guess you are on windows? buildbot worked linux and OSX builds fine too. buildbot error log: http://builder.blender.org/builders/win32_scons/builds/1276/steps/compile/logs/stdio Do you have a patch to make it build for you? Otherwise I'll look at it. Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2013/10/8 Dalai Felinto > err can you paste the complete build error? (use pasteall.org) > or poke me on irc (dfelinto) > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] PSD file is not displayed with a file choice screen of Image Editor.(r60621)
Hi, If you open an image (alt+o) psd files will be visible: http://www.pasteall.org/pic/show.php?id=60478 In case it does not, can you please report in the tracker? Thanks, Dalai ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] PSD file is not displayed with a file choice screen of Image Editor.(r60621)
Hi, > However, an error occurs when I open the PSD file. There is not much I can do with this information alone. Please use the tracker to bug report this. There you can attach a problematic file, show the error, a screenshot, ... and we can investigate it properly. Thanks, Dalai ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [60692] trunk/blender/source/blender: Fix build scripts related to PSD support.
Hi,
Thanks for the fix. My Xcode was not cleaning its cache during my tests and
I ended up overseen this PSD.
For CMake I think the actual fix would be only changing
//source/blender/CMakeLists.txt
"”"
Modified: trunk/blender/source/blender/CMakeLists.txt
===
--- trunk/blender/source/blender/CMakeLists.txt 2013-10-11 22:37:24 UTC
(rev 60691)
+++ trunk/blender/source/blender/CMakeLists.txt 2013-10-11 23:14:01 UTC
(rev 60692)
@@ -117,7 +117,7 @@
add_subdirectory(imbuf/intern/openexr)
endif()
-if(WITH_IMAGE_PSD)
+if(WITH_OPENIMAGEIO)
add_subdirectory(imbuf/intern/oiio)
endif()
"”"
I won't be in front of a computer before ~18 hours. So if you want to
test/commit the above, it would be much appreciated.
(It require reverting the non scons part of your patch though)
Your patch works and fixed the immediate issue so there is no real rush.
Thanks,
Dalai
On Oct 11, 2013 8:14 PM, "Shinsuke Irie" wrote:
> Revision: 60692
>
> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=60692
> Author: irie
> Date: 2013-10-11 23:14:01 + (Fri, 11 Oct 2013)
> Log Message:
> ---
> Fix build scripts related to PSD support. Both CMake and SCons builds
> were broken.
>
> Modified Paths:
> --
> trunk/blender/source/blender/CMakeLists.txt
> trunk/blender/source/blender/blenkernel/SConscript
> trunk/blender/source/blender/editors/space_file/CMakeLists.txt
> trunk/blender/source/blender/editors/space_image/CMakeLists.txt
> trunk/blender/source/blender/imbuf/CMakeLists.txt
> trunk/blender/source/blender/imbuf/intern/oiio/CMakeLists.txt
> trunk/blender/source/blender/makesrna/SConscript
> trunk/blender/source/blender/makesrna/intern/CMakeLists.txt
> trunk/blender/source/blender/python/intern/CMakeLists.txt
>
> Modified: trunk/blender/source/blender/CMakeLists.txt
> ===
> --- trunk/blender/source/blender/CMakeLists.txt 2013-10-11 22:37:24 UTC
> (rev 60691)
> +++ trunk/blender/source/blender/CMakeLists.txt 2013-10-11 23:14:01 UTC
> (rev 60692)
> @@ -117,7 +117,7 @@
> add_subdirectory(imbuf/intern/openexr)
> endif()
>
> -if(WITH_IMAGE_PSD)
> +if(WITH_IMAGE_OPENIMAGEIO)
> add_subdirectory(imbuf/intern/oiio)
> endif()
>
>
> Modified: trunk/blender/source/blender/blenkernel/SConscript
> ===
> --- trunk/blender/source/blender/blenkernel/SConscript 2013-10-11
> 22:37:24 UTC (rev 60691)
> +++ trunk/blender/source/blender/blenkernel/SConscript 2013-10-11
> 23:14:01 UTC (rev 60692)
> @@ -102,7 +102,7 @@
> defs.append('WITH_SDL')
>
> if env['WITH_BF_OIIO']:
> -defs.append('WITH_OIIO')
> +defs.append('WITH_OPENIMAGEIO')
>
> if env['WITH_BF_OPENEXR']:
> defs.append('WITH_OPENEXR')
>
> Modified: trunk/blender/source/blender/editors/space_file/CMakeLists.txt
> ===
> --- trunk/blender/source/blender/editors/space_file/CMakeLists.txt
> 2013-10-11 22:37:24 UTC (rev 60691)
> +++ trunk/blender/source/blender/editors/space_file/CMakeLists.txt
> 2013-10-11 23:14:01 UTC (rev 60692)
> @@ -58,7 +58,7 @@
> add_definitions(-DWITH_OPENEXR)
> endif()
>
> -if(WITH_OPENIMAGEIO)
> +if(WITH_IMAGE_OPENIMAGEIO)
> add_definitions(-DWITH_OPENIMAGEIO)
> endif()
>
>
> Modified: trunk/blender/source/blender/editors/space_image/CMakeLists.txt
> ===
> --- trunk/blender/source/blender/editors/space_image/CMakeLists.txt
> 2013-10-11 22:37:24 UTC (rev 60691)
> +++ trunk/blender/source/blender/editors/space_image/CMakeLists.txt
> 2013-10-11 23:14:01 UTC (rev 60692)
> @@ -50,7 +50,7 @@
> add_definitions(-DWITH_INTERNATIONAL)
> endif()
>
> -if(WITH_OPENIMAGEIO)
> +if(WITH_IMAGE_OPENIMAGEIO)
> add_definitions(-DWITH_OPENIMAGEIO)
> endif()
>
>
> Modified: trunk/blender/source/blender/imbuf/CMakeLists.txt
> ===
> --- trunk/blender/source/blender/imbuf/CMakeLists.txt 2013-10-11
> 22:37:24 UTC (rev 60691)
> +++ trunk/blender/source/blender/imbuf/CMakeLists.txt 2013-10-11
> 23:14:01 UTC (rev 60692)
> @@ -106,7 +106,7 @@
> endif()
>
>
> -if(WITH_OPENIMAGEIO)
> +if(WITH_IMAGE_OPENIMAGEIO)
> add_definitions(-DWITH_OPENIMAGEIO)
> endif()
>
>
> Modified: trunk/blender/source/blender/imbuf/intern/oiio/CMakeLists.txt
> ===
> --- trunk/blender/source/blender/imbuf/intern/oiio/CMakeLists.txt
> 2013-10-11 22:37:24 UTC (rev 60691)
> +++ trunk/blender/source/blender/imbuf/intern/oiio/CMakeLists.txt
> 2013-10-11 23:14:01 UTC (rev 60692)
> @@ -44,7 +44,7 @@
> openimageio_api.cpp
> )
>
> -if(WITH_OPENIM
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [60692] trunk/blender/source/blender: Fix build scripts related to PSD support.
Hi, > it causes unwanted behavior that the PSD support is enabled even if WITH_IMAGE_OPENIMAGEIO=OFF and WITH_CYCLES=ON This is actually the wanted behaviour. Bear with me ... If the average user just builds Blender, she gets Cycles, PSD, all the goodies. If the advanced user/developer doesn't want to build Cycles but wants PSD support, she does WITH_CYCLES=OFF and WITH_IMAGE_OPENIMAGEIO=ON If the user doesn't want anything to use OIIO, she simply does WITH_CYCLES=OFF. I believe (may be wrong) that one of main ideas of having those defines in the code is to speed up building (less code to build, less libraries to link to ...). Thus I think we should tie the defines to the library, not the feature. Dalai // mobile ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [60692] trunk/blender/source/blender: Fix build scripts related to PSD support.
I actually think we should have WITH_OPENIMAGEIO instead of WITH_IMAGE_OPENIMAGEIO. It's how it was already in CMakeLists.txt and there is no big compelling argument to change that. I committed the fix in rev.60718 [to get PSD working by default - even if WITH_OPENIMAGEIO is OFF, assuming WITH_CYCLES is ON] Cheers, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2013/10/12 IRIE Shinsuke > Got it, but I think the CMake variable WITH_OPENIMAGEIO is not needed. > It should be replaced with WITH_IMAGE_OPENIMAGEIO, and Cycles should > simply depend on WITH_IMAGE_OPENIMAGEIO like this: > > > # auto enable openimageio for cycles > if(WITH_CYCLES) > set(WITH_IMAGE_OPENIMAGEIO ON) > endif() > > # auto enable openimageio linking dependencies > if(WITH_IMAGE_OPENIMAGEIO) > set(WITH_IMAGE_OPENEXR ON) > set(WITH_IMAGE_TIFF ON) > endif() > > > IRIE Shinsuke > > 13/10/12, Dalai Felinto wrote: > > Hi, > > > >> it causes unwanted behavior that the PSD support is enabled even if > > WITH_IMAGE_OPENIMAGEIO=OFF and WITH_CYCLES=ON > > > > This is actually the wanted behaviour. Bear with me ... > > > > If the average user just builds Blender, she gets Cycles, PSD, all the > > goodies. > > > > If the advanced user/developer doesn't want to build Cycles but wants PSD > > support, she does WITH_CYCLES=OFF and WITH_IMAGE_OPENIMAGEIO=ON > > > > If the user doesn't want anything to use OIIO, she simply does > > WITH_CYCLES=OFF. > > > > I believe (may be wrong) that one of main ideas of having those defines > in > > the code is to speed up building (less code to build, less libraries to > > link to ...). Thus I think we should tie the defines to the library, not > > the feature. > > > > Dalai // mobile > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > http://lists.blender.org/mailman/listinfo/bf-committers > > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Joining objects and merging UV Layouts has Changed in Behaviour (2.69)
Hi Gaia, What would the "Combine UV Layers" operator do exactly? How to solve conflicts in a predictable way when the same face has UV information in multiple layers. > this would allow old behavior which works very well in most cases (since i guess most objects only have one layer) For most of the objects that have one layer the layer is also most likely called UVMap, so in that case the old behaviour is already accomplished. Note that in case the user joined the objects and regretted later (way past the Ctr+Z point) she can still separate the objects, delete the empty UVMaps, rename them, and re-join it. Finally it doesn't make sense to have join by id if we can't even order the UV maps up and down in the list. (thus joining by name gives the user way more control and is a lossless solution). Cheers, Dalai ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] lib maintainers, remember to stick to the same version across OSs
Hi all, That was said a few times, but we are again in a situation that illustrates well the problem of version mismatching. OpenImageIO versions used: [0] - OSX: 1.1.9 [1] - Linux: 1.1.10 [2] - Windows vc9 : 1.1.11 [3] - Windows vc11: 1.2.2 (I'm not making that up, check the links ;) That small difference was enough to have PSD loading working in Windows builds made with vc11, OSX, and Linux (no idea which version Linux is using). But it fails in Windows builds with msvc9 (aka what we use in the buildbot and in official releases). [4] . We should have a call for update soon (pending some work Brecht wants to write/commit to openimageio upstream). So no need to update things right now. But please, let's stick to the matching-versions rule. [0] - https://svn.blender.org/svnroot/bf-blender/trunk/lib/darwin-9.x.universal/openimageio/include/OpenImageIO/version.h [1] - https://svn.blender.org/svnroot/bf-blender/trunk/blender/build_files/build_environment/install_deps.sh [2] - https://svn.blender.org/svnroot/bf-blender/trunk/lib/windows/openimageio/include/OpenImageIO/version.h [3] - https://svn.blender.org/svnroot/bf-blender/trunk/lib/windows_vc11/openimageio/include/OpenImageIO/version.h [4] - https://projects.blender.org/tracker/index.php?func=detail&aid=37023&group_id=9&atid=498 Thanks, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Joining objects and merging UV Layouts has Changed in Behaviour (2.69)
The report doesn't make much sense. I replied it there. Not that we shouldn't have per-id merging (that be still be discussed) , but his example doesn't makes a valid point for that in my opinion 2013/10/22 Bastien Montagne > Another complain about new behavior (this time, he’d like to *not* merge > his UVMaps…): > > https://projects.blender.org/tracker/?func=detail&atid=498&aid=37182&group_id=9 > > I really think we should allow that as well (so merge by name, merge by > index, no merge), does not really complicate that much the code, and > allows much more flexibility in workflows… > > On 15/10/2013 17:54, Dalai Felinto wrote: > > Hi Gaia, > > > > What would the "Combine UV Layers" operator do exactly? > > How to solve conflicts in a predictable way when the same face has UV > > information in multiple layers. > > > >> this would allow old behavior which works very well in most cases (since > > i guess most objects only have one layer) > > > > For most of the objects that have one layer the layer is also most likely > > called UVMap, so in that case the old behaviour is already accomplished. > > > > Note that in case the user joined the objects and regretted later (way > past > > the Ctr+Z point) she can still separate the objects, delete the empty > > UVMaps, rename them, and re-join it. > > > > Finally it doesn't make sense to have join by id if we can't even order > the > > UV maps up and down in the list. (thus joining by name gives the user way > > more control and is a lossless solution). > > > > Cheers, > > Dalai > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > http://lists.blender.org/mailman/listinfo/bf-committers > > > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Monday Developer Meeting, Blender Institute
Dear all, We didn't have the traditional 'dev meeting' during the Blender Conference, but we have enough developers present at the Blender Institute today and we decided to go over some topics. Developers Present: Andrea Weikert , Bastien Montagne (montagne), Brecht van Lommel, Dalai Felinto, Lukas Toenne, Keir Mierle, Sergey Sharybin and Thomas Dinges Blender 2.69 == * Pending two show-stoppers, Sergey and Brecht will look at it * It can be done today, we look at tracker and ahoy tonight GSOC = * BGE LOD and Bug Fixing/Polishing: ** Ready for trunk * Painting tool improvements: ** Lukas on charge to handle that ** Proposal: Campbell, Sergey/Brecht to review it ** UI needs more work, to be reviewed by Brecht ** The rest will be reviewed by Sergey * Cycles projects under Brecht responsibility ** “Texturing for Volume Rendering in Cycles” ** “Cycles Deformation Motion Blur” * Sketch Mesh Editing: ** Howard Trickey is going to review. ** To consider whether it’s worthy stripping off the mergeable parts * Viewport VFX II: ** Brecht will handle it ** He will try to break it down in merge-able pieces ** OPENGL ES should be extensively tested * Expand and improve motion tracking: ** Keir may take over the development, it should be partially ready by the merging window * Dependency Graph and Evaluation: ** It's up to Joshua * Threaded Object update for dependency graph ** Brecht will finish review and Sergey will merge soon * Rigid Body Simulation: ** Sergey will contact Sergej/Mint * Cycles: Add new shader nodes ** Done and merged * “Towards a full User action replay system”: ** Bastien Montagne will review everything non-toolbar ** UI team (lead by Brecht) will review the toolbar part of it 2.70 Targets == * UI TEAM: ** Organize the tasks and roles ** Refresh defaults (e.g, LMB/RMB) ** Layouts ** [temptative] Toolbar (GSOC project) ** Other low-hanging fruits * New Developer Site ** Phabricator ** git.blender.org ** Open first for developers ** Sandbox for people to try the system first * Hives will be an addon_contrib * No new release in a while - stretching the current release cycle * Bastien and Dalai work can be merged as they get ready, to coordinate with Campbell (Normals, Triangulation, FPS navigation) * OpenImageIO remaining fixes: Dalai may take over on Brecht’s alpha duties * Make sure we have some of the pre-established targets for 2.7x in time for 2.70 ** http://code.blender.org/index.php/2013/06/blender-roadmap-2-7-2-8-and-beyond/ ** we don’t want 2.70 to just be a natural number increment from 2.69 Unity Tests = ** It should be considered as part of 2.7x targets to allow scalability for Blender Development (a must for Gooseberry) ** It’s a big task that is orphan. It may not make for 2.7 (unless someone volunteers) Module Organization * Tied to the new developer website Automatic Builds == * No one to take over this work, but for the sake of records: ** To have automatic build for trunk/master always working ** To have an option for developers to manually trigger build of branches in 3 OSs ** To hook up automatic update of pydocs to BI machines -- blendernetwork.org/dalai-felinto www.dalaifelinto.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Monday Developer Meeting, Blender Institute
Hi Brecht, Thanks for the clarifications. I guess irc meetings have their advantages after all ;) As for Hives I ended up writing my 2 cents as (non active but present) bge maintainer. But I'll assess this with Sjoerd and the rest of the team. It was a really good meeting by the way. I wish we could have those moments more often. (And with more developers present ;) Dalai On Oct 30, 2013 1:44 PM, "Brecht Van Lommel" wrote: > A few comments on this to clarify. > > On Mon, Oct 28, 2013 at 5:04 PM, Dalai Felinto wrote: > > * Viewport VFX II: > > ** Brecht will handle it > > ** He will try to break it down in merge-able pieces > > ** OPENGL ES should be extensively tested > > I didn't say I would break it down into merge-able pieces or merge it > myself, maybe that ends up happening, but no such decision was taken. > Only mentioned that the best merging strategy could be to do it in > smaller pieces, to avoid making all of Blender unstable, and it would > make it easier to detect which exact changes caused which graphics > drivers / cards to fail. > > > * Hives will be an addon_contrib > > I don't think this was an actual decision that was made, just that it > made sense to the people there to add it there first like most addons. > But this is the decision of addon and BGE maintainers and they weren't > at this meeting. > > > * No new release in a while - stretching the current release cycle > > Also no hard decisions on dates taken here, but people seemed to agree > that this would very likely be a longer release cycles than the > typical 2-3 month schedule. > > Brecht. > ___ > 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] Git migration preview repo available
Where are the names/nicks/photos coming from now? It seems to be coming from github but I wonder if it's just a side effect of the repo being temporarily there? Cheers, Dalai On Nov 2, 2013 7:37 AM, "walid shouman" wrote: > On Nov 2, 2013 10:32 AM, "Campbell Barton" wrote: > > > > Hi, since we're still aiming to have this done quite soon, heres an > > upload of the converted subversion repo in case anyone is interested > > to review how the conversion goes and give feedback. > > > > Its currently only ~260mb - small enough to download and check with > > gitk or other tools. > > > > > > # note were not using github, this is just temp location > > https://github.com/ideasman42/blender-git-migration > > > > It may be a contentious issue which branches are kept and which are > > archived (stored in svn only). > > Just to note that this isn't final. > > > > > > # conversion todo list > > > > https://gitorious.org/blender-git-migration/blender-git-migration/raw/todo.txt > > > > > > # script used for conversion (incase anyones interested) > > > > https://gitorious.org/blender-git-migration/blender-git-migration/raw/blender.lift > > > note: the auto generated list includes the meshdata transfer branch ... > while its still under a rewrite WIP > > > > -- > > - Campbell > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > http://lists.blender.org/mailman/listinfo/bf-committers > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] uiList: ctrl-clic-edit name
For multiview I have two items in the list that are not rename-able (i.e., left and right). Is there a way to make them non-clickable (or at least to manually write the rename function), while the others views are still clickable/rename-able? Cheers, Dalai 2013/11/10 Bastien Montagne > Hi devs, > > Here is a patch enabling clic-edit of items' names in an uiList: > http://www.pasteall.org/47150/diff > > The only change needed from user POV is to add the "rename_propname" > parameter to its template_list() call. > > The proposed solution is a bit hackish (but works perfectly afaict), but > I can't see any who wouldn't, given the fact that we want to avoid > having to change all uiLists code to use something else than label() for > items' names... What it does basically is: > > * In uilist handler, detect ctrl-lmb clic on a listrow button; > * Mark the uiList as pending renaming on related item; > * In draw function, change first LISTLABEL of the relevant item in a TEX > one, and add a fake event to force uilist handler to be run again. > * Back in uilist handler, when a rename is pending, try to find our TEX > button (which abuses UI_BUT_COLOR_CUBIC as marker) and activate it. > > As usual, any feedback is much welcomed! :) > > PS: Do not take into account changes in properties_data_mesh.py, these > are mostly used for testing, not to be committed! > > Best regards, > Bastien > ___ > 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] developer.blender.org status
> - Manually update submodule's SHA regularly, like once a week. I think this is reasonable, and how we do for translations already. Apart from that I think it's a nice workflow. Cheers, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2013/11/11 Sergey Sharybin > Notes about git submodules. > > Intention is to use git submodules as a replacement for svn:externals which > we used for "integrating" translations and addons into main tree. > > Tricky part about submodules is that submodules in git are poiting to a > specific SHA revision of external repository. So if you want to use latest > addons you'll need to update blender's repository to use latest SHA > revision from from adons repository. > > This is what we'll want for release tags. Basically, we'll create tag in > addons/translations repositories and make release tag in blender repository > track submodules with given tag name. > > This is done by adding/modifying "branch" setting in .submodules file. > > Now, how to deal with regular development. It is possible to update > submodules to their latest SHA: > > git submodule update --remote > > --remote means submodules will be updated to latest HEAD of an external > repo instead of hash stored in parent repository. > > Bad thing about this is that this marks parent repository as changed with > uncommited changes (because submodule update modifies SHA of submodule > stored in parent repository). We don't want such changes to be commited by > an accident, and seems there's a workaround for this. > > If you add ignore=all to .gitmodules, then parent repository will ignore > all the changes made to submodule, ingcluding modifying/adding files there > or updating HEAD of submodule. This way doing `git submodule update > --remote` will pull all the changes from submodule's repository but > wouldn't mark parent repository as changes. Roughly speaking, `git commit > -a` invoked from parent repo will say "no changes to commit" which is nice. > > Fortunately, if you make changes to submodule itself (like, fix bug in an > addon) you still able to commit changes to addons repository directly from > submodule. To do this you just cd to addons submodule and do regular git > commit followed by push. > > As a sideeffect of such approach, you owuldn't be able to commit changes > made to submodule together with changes made to parent repository. But in > fact, this is also rather good. Generally speaking, you would NOT want to > commit chnages to submodule and parent repo with the same commit and will > want to commit changes to submodule first and then update parent > repository. Otherwise you'll run into all sorts of possible issues. > > So, the proposal is: > - Attach blender-addons, blender-addons-contrib and blender-translations to > main git's tree as a submodule (`git submodule add git:// > git.blender.org/blender-addons/ ./release/scripts/addons` and so on) > - Add ignore=all to .gitsubmodules. This will be stored in blender's > repository, so you only need to do this once. No need for all the > develoeprs to modify their .gitsubmodules. > - To checkout checkout the repository: `git clone --recursive git:// > git.blender.org/blender`. This will also download all the submodules. You > would need to `run git submodule update --remote` after this manually, coz > submodule's SHA might not be updated in blender repo yet. > - To update the checkout: `git pull && git submodules update --remote`. > This will pull all the changes made to blender itself and changes made to > all the external repos. This will NOT add changes from submodules to parent > repository, > - Commits from blender repo would NOT include changes made to addons > - To commit changes made to addons you simply cd to > ./release/scripts/addons and do git commit and push from there > > There's one weak aspect still, which is it's not clear which SHA submodules > should point to. This doesn't affect workflow proposed above, but would be > nice to have some trict policy about when and how to update submodule's > SHA. Couple of ways: > - Submodule's SHA will point to previous release's tag during current > development cycle. All the changes made to those repos will be pulled with > `git remote update --remote`, so not a bit isue wor dveelopers/regular > users. > - Update submodules's SHA with commit hook of external repositories. This > will clutter our main repo's history with bunch of "update submodule SHA" > commits. > - Manually update submodule's SHA regularly, like once a week. > > And one last note about changes ma
Re: [Bf-committers] Revision number in the splash screen
We can add last stable release + day/month/year (or even hour, Amsterdam time) + hash Though I think a counting number (ala svn) may be easier to talk about specific issues (e.g., bug happens in 60354 but not in 60843) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] HOWTO transplant development branches coming from git-svn to git.blender.org
Julien, Thanks for the crazy amount of work you put on it. Stereographers will have you in good account - even though you made it sound as if my branch was the worse user-case for branch migration, but that's fair enough since it was my first time using git for real ;) Even following the instructions seem to be extremely time consuming, but I'll try to go over them later this week. Best regards, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2013/11/18 Julien RIVAUD (_FrnchFrgg_) > Le 17/11/2013 19:36, Julien RIVAUD (_FrnchFrgg_) a écrit : > > Hi everyone, > > > > I'd like to give you notice of a somewhat advanced git HOWTO for > > people that used previout git mirrors of blender (as the mirror by > > jesterKing). The HOWTO is here: > > http://wiki.blender.org/index.php/User:Frnchfrgg/Transplant > I found three typos in the HOWTO, including a "root0" instead of "base0" > in the second script that you'll have to get anew for it to work. > > My sincere apologies for that. > > _FrnchFrgg_ > ___ > 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] submodules and external repositories (github, ...)
Hi there, FIrst of all, congratulations and a thank you for everyone who worked in the git/phabricator/arc migration. Kudos big time here :) Now, I'm patiently waiting for an official github.com/gitorious repository from Blender Foundation. Meanwhile I pushed my own copy of git. blender.orgto my github account. For me everything works fine. I can update the submodules content, fetch/pull/push master smoothly. The problem I'm facing, is when someone tries to checkout the repository with the submodules: * mkdir multiview * cd multiview * git clone https://github.com/dfelinto/blender.git --single-branch -b multiview blender * git submodule update --init --recursive --remote (boom) Submodule 'release/datafiles/locale' (https://github.com/dfelinto/ blender-translations.git) registered for path 'release/datafiles/locale' (...) (full log http://www.pasteall.org/47514) So, it seems that the repository expects me to clone ALL blender external submodules. Any suggestions? Am I doing anything wrong? Any official instructions on that? . . . Thanks, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] submodules and external repositories (github, ...)
Just to clarify, My goal is to have two set of instructions: 1) how to setup a remote repository, clone of git.blender.org, in github/gitourious 2) how can someone check it out, and build it Both from scratch, for someone who has not a branch of git.blender.org yet. And maybe with notes for someone who already has it. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] arc diff no longer waits for my comment editing ...
If you didn't change anything the problem may be with subsequent patches (i.e., the second time you run arc diff from the same branch). The easy way to test is by creating a new branch and see if you get the old or the new behaviour. Another option is doing arc init (may be wrong, away from PC now). But this will not append to the original patch. Anyways, Brecht's suggestion is better but it may be interesting to isolate the problem regardless On Nov 29, 2013 6:53 PM, "Gaia" wrote: > arc diff used to behave like this (until about 8 pm CEST): > > arc diff > - asks me to add a comment and opens the configured editor > - waits for me until i have edited the comment, and saved the file > - sends the diff plus my comment to phabricator. > > > But suddenly it changed its behaviour slightly: > > arc diff > - asks me to add a comment and opens the configured editor > - does NOT wait for me and just sends the diff to phabricator > > So my edits no longer get uploaded. > arc does not tell me about any error. > I did not change (intentionally) any configuration, > maybe i did something unintentionally though. > > Any hint what could have gone wrong ? > > -gaia- > ___ > 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] Library Update OIIO/OSL
> Dalai: Does this contain the patches you need already? It’s their latest > stable one. Yes it does contain my PSD alpha fix. It would be nice to test if the new libs fix this problem in Windows: http://developer.blender.org/T37023 Cheers, Dalai ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Library Update OIIO/OSL
PerfectionCat, the report is here: http://developer.blender.org/T37023 I asked Thomas to look at it and he tested with the x64 libraries successfully already. The x86 will be tested later. -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2013/12/3 PerfectionCat : > Is the report still left? > Because it had been already improved in the environment of my windows XP/SP3 > 32bits msvc9+SCONS, I forgot the thing. > > PerfectionCat > > > - Original Message ----- >>From: Dalai Felinto >>To: bf-blender developers >>Date: 2013/12/3, Tue 22:14 >>Subject: Re: [Bf-committers] Library Update OIIO/OSL >> >>> Dalai: Does this contain the patches you need already? It’s their latest >>> stable one. >>Yes it does contain my PSD alpha fix. >> >>It would be nice to test if the new libs fix this problem in Windows: >>http://developer.blender.org/T37023 >> >>Cheers, >>Dalai >>___ >>Bf-committers mailing list >>Bf-committers@blender.org >>http://lists.blender.org/mailman/listinfo/bf-committers >> >> >> > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] I created a branch accidentally, but I have no 'git rights' to delete it
Hi, Short Story: = $ git push upstream :fix-fly-center gives me the error: ``` remote: *** Deleting a branch is not allowed in this repository remote: error: hook declined to update refs/heads/fix-fly-center To g...@git.blender.org:blender.git ! [remote rejected] fix-fly-center (hook declined) error: failed to push some refs to 'g...@git.blender.org:blender.git' ``` Can anyone with administrator rights remove this branch? Thanks Long Story: 'arc land' landed the branch in my github repository * arcanist defaults to origin for most of its operations, and since .arcconfig is part of our repository, I can't change it without arcanist itself complaining of non-committed changes in my branch. I think I will rename git.blender.org to origin, and my github to something else. After I realized what happened I did the following command following arcanist suggestion: $ git checkout -b 'fix-fly-center' 'cacaad40ac1be0dca73e26f62edc03d361cba85a' so far so good, I then did: $git push upstream While I should have done: $git push upstream fix-fly-center:master And now I ended up with a branch in git.blender.org that I cannot delete. It's no big harm, but it wouldn't hurt to delete the branch and pretend this never happened ;) Cheers, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] smpte support - patch for review/discussion
Hi, We [*] needed SMPTE support for a 3rd party project, and ended up with a patch for Blender. I remember seeing smpte in roadmap/todo lists from time to time, so it may be of interest for more people: http://developer.blender.org/D71 If the needed changes are too big I may only have time to address them next year. Discussion and review can take place in the tracker. [*] we = Benoit Bolsee and me, contributions from both of us. Thanks, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] error on updating submodules
Hi, I'm setting up a new computer and after getting the git repository I'm failing to update the submodules: $ git submodule update --init --recursive Submodule 'release/datafiles/locale' () registered for path 'release/datafiles/locale' Submodule 'release/scripts/addons' () registered for path 'release/scripts/addons' Submodule 'release/scripts/addons_contrib' () registered for path 'release/scripts/addons_contrib' Submodule 'scons' () registered for path 'scons' fatal: Needed a single revision Unable to find current revision in submodule path 'release/datafiles/locale' I left the repository cloning happening over night, so I suspect something may have gone wrong in the end. git fetch upstream (which is BF) works fine too. I even tried to re-setup the submodules but it didn't make any difference: $ git config submodule.scons.url git://git.blender.org/scons.git $ git config submodule.release/scripts/addons_contrib.url git://git.blender.org/blender-addons-contrib.git $ git config submodule.release/scripts/addons.url git://git.blender.org/blender-addons.git $ git config submodule.release/datafiles/locale.url git://git.blender.org/blender-translations.git $ git submodule update --init --recursive (same error as above, after the update command) I'm on a Ubuntu 12.04 LTS, git 1.7.9.5 Any help is appreciated. Thanks, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] error on updating submodules
Thanks Brecht, The workaround didnt fix it, but a fresh git clone did. I was away for the xmas break so I was lacking reliable internet there. All good now - home, sweet, home Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2013/12/25 Brecht Van Lommel : > I'm not sure what is going on here, I just tried the commands and they > worked find to get a checkout with submodules. > > git clone git://git.blender.org/blender.git > cd blender > git submodule update --init --recursive > git submodule foreach git checkout master > git submodule foreach git pull --rebase origin master > > Googling for your error message, it appears this problem can sometimes > be solved by removing the submodule directory and updating, though > it's not clear why. So you could try: > > rm -rf scons > git submodule update > > > On Tue, Dec 24, 2013 at 12:57 PM, Dalai Felinto wrote: >> Hi, >> >> I'm setting up a new computer and after getting the git repository I'm >> failing to update the submodules: >> >> $ git submodule update --init --recursive >> >> Submodule 'release/datafiles/locale' () registered for path >> 'release/datafiles/locale' >> Submodule 'release/scripts/addons' () registered for path >> 'release/scripts/addons' >> Submodule 'release/scripts/addons_contrib' () registered for path >> 'release/scripts/addons_contrib' >> Submodule 'scons' () registered for path 'scons' >> fatal: Needed a single revision >> Unable to find current revision in submodule path 'release/datafiles/locale' >> >> I left the repository cloning happening over night, so I suspect >> something may have gone wrong in the end. git fetch upstream (which is >> BF) works fine too. >> >> I even tried to re-setup the submodules but it didn't make any difference: >> >> $ git config submodule.scons.url git://git.blender.org/scons.git >> $ git config submodule.release/scripts/addons_contrib.url >> git://git.blender.org/blender-addons-contrib.git >> $ git config submodule.release/scripts/addons.url >> git://git.blender.org/blender-addons.git >> $ git config submodule.release/datafiles/locale.url >> git://git.blender.org/blender-translations.git >> $ git submodule update --init --recursive >> >> (same error as above, after the update command) >> >> I'm on a Ubuntu 12.04 LTS, git 1.7.9.5 >> >> Any help is appreciated. Thanks, >> Dalai >> -- >> blendernetwork.org/dalai-felinto >> www.dalaifelinto.com >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Commit overload
You can do git merge --squash next time, that will make one commit out of all the individual ones. Or git rebase -i HEAD~3 (or 10, ...) to group commits together) It's really a matter of deciding how relevant the individual logs are for our git history. -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2014/1/3 Jonathan Williamson : > Sorry about the commit overload just now. Will apply patches directly to > master instead of merging in the branch next time :) > > Jonathan Williamson > http://cgcookie.com > ___ > 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] help with tessface, CustomData and MTFace
Hi there,
Anyone familiar with CustomData and tessface here?
I'm trying to figure out why this function is only working for the first face:
https://github.com/dfelinto/blender-git/blob/bake-cycles/source/blender/render/intern/source/bake_new.c#L104
I'm getting bad data when trying to read the MTFace for any face that
is not the first one:
((MTFace *)&cdl[0])->uv
{0.50238, 1}, {0, 0}, {1, 0}, {0, 0}}
((MTFace *)&cdl[1])->uv
{{0, 0}, {0.50238, 1}, {0, 0}, {0, 0}}
((MTFace *)&cdl[2])->uv
{{7.87199301e+31, 1.17082983e-19}, {2.17010503e-18,
2.61866902e+20}, {2.61048549e+20, 2.95921708e+21}, {
6.9779858e+22, 4.66808809e+24}}
As you can see the 2nd face is bad (2 verts are at 0, 0) and the 3rd
one is totally bogus. The mesh itself is very simple, if you want to
check out (it's the one in 3-Tris):
http://www.pasteall.org/blend/26092
While at there another question:
Is there any way to get the number of verts of a MTFace?
Thanks,
Dalai
--
blendernetwork.org/dalai-felinto
www.dalaifelinto.com
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] help with tessface, CustomData and MTFace
Hi, > This should fix it: > &(cdl[1]) Sorry, but where would that be? Because If I do: (1) MTFace *mtface = (MTFace *)&cdl[i]; As it is now, or if I do: (2) MTFace *mtface = (MTFace *)&(cdl[i]); They all produce the same result I just committed (bc3d601 in the branch) a temporary printf code to illustrate better how I'm getting the values: https://github.com/dfelinto/blender-git/blob/bake-cycles/source/blender/render/intern/source/bake_new.c#L142 It produces this output: face: 0 vec[0]: 0.50, 1.00 vec[1]: 0.00, 0.00 vec[2]: 1.00, 0.00 vec[3]: 0.00, 0.00 face: 1 vec[0]: 0.00, 0.00 vec[1]: 0.50, 1.00 vec[2]: 0.00, 0.00 vec[3]: 0.00, 0.00 face: 2 vec[0]: 78719930099698347488497473945600.00, 0.00 vec[1]: 0.00, 261866902067410370560.00 vec[2]: 261048548756996227072.00, 2959217080378280902656.00 vec[3]: 69779857993988661313536.00, 4668088091354259464912896.00 Thanks, Dalai ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] help with tessface, CustomData and MTFace
> However you shouldn't be storing this pointer in CustomDataLayer*, you should > do something like this instead: (...) Ah, now I I understand the CustomData_get_* functions better. Way more clear thanks a lot Brecht. @Tom, many thanks, my system was crashing some times, but I haven't stop to pinpoint the MEM_callocN issue ;), and thanks for the other fix too. Apparently the function is fully working now :) The only missing bit is to get the number of verts of the MTFace to know when it's a quad and when it is a triangle. Kudos, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] [c24a23f] master: Fix for particle emission bug, reported on IRC by Thomas Beck (@plasmasolutions): When the particle emitter is parented to a fast moving object,
Hey Lukas, (and others) you may want to skip a line next time between
the git log "subject" and the rest of the message. Otherwise git
considers it all part of the 'headline'.
cheers,
Dalai
--
blendernetwork.org/dalai-felinto
www.dalaifelinto.com
2014/1/22 Lukas Tönne :
> Commit: c24a23f264d2c7001c61ca6e11c66b8c372e1d2a
> Author: Lukas Tönne
> Date: Wed Jan 22 16:26:09 2014 +0100
> https://developer.blender.org/rBc24a23f264d2c7001c61ca6e11c66b8c372e1d2a
>
> Fix for particle emission bug, reported on IRC by Thomas Beck
> (@plasmasolutions): When the particle emitter is parented to a fast
> moving object, the emission locations will not be interpolated over
> subframes. This works if the particle emitter is animated itself.
> Particle system evaluates the emitter location for each subframe, but
> has to do this for the parent objects as well to get reliable results.
>
> ===
>
> M source/blender/blenkernel/intern/particle_system.c
>
> ===
>
> diff --git a/source/blender/blenkernel/intern/particle_system.c
> b/source/blender/blenkernel/intern/particle_system.c
> index 37ca502..6c2a42d 100644
> --- a/source/blender/blenkernel/intern/particle_system.c
> +++ b/source/blender/blenkernel/intern/particle_system.c
> @@ -1974,10 +1974,10 @@ void reset_particle(ParticleSimulationData *sim,
> ParticleData *pa, float dtime,
> /* we have to force RECALC_ANIM here since
> where_is_objec_time only does drivers */
> while (ob) {
> BKE_animsys_evaluate_animdata(sim->scene, &ob->id,
> ob->adt, pa->time, ADT_RECALC_ANIM);
> + BKE_object_where_is_calc_time(sim->scene, ob,
> pa->time);
> ob = ob->parent;
> }
> ob = sim->ob;
> - BKE_object_where_is_calc_time(sim->scene, ob, pa->time);
>
> psys->flag |= PSYS_OB_ANIM_RESTORE;
> }
> @@ -5076,10 +5076,10 @@ void particle_system_update(Scene *scene, Object *ob,
> ParticleSystem *psys)
> if (psys->flag & PSYS_OB_ANIM_RESTORE) {
> while (ob) {
> BKE_animsys_evaluate_animdata(scene, &ob->id,
> ob->adt, cfra, ADT_RECALC_ANIM);
> + BKE_object_where_is_calc_time(scene, ob, cfra);
> ob = ob->parent;
> }
> ob = sim.ob;
> - BKE_object_where_is_calc_time(scene, ob, cfra);
>
> psys->flag &= ~PSYS_OB_ANIM_RESTORE;
> }
>
> ___
> Bf-blender-cvs mailing list
> bf-blender-...@blender.org
> http://lists.blender.org/mailman/listinfo/bf-blender-cvs
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] State of MultiView patch?
Hi Torsten, Multiview is not in the target list for 2.70. I'll resume working on it not later than mid-March. At that time I'll be able to dedicate 2.5 months of half-time development entirely to multiview. That is hopefully enough time to get it stable and get it into review and then 'master'. If I run into any surprises during development (I didn't touch the sequence code, so I don't know what to expect from it) I will aim at at least get a working bulk of the code in master so it can be used in production while the remaining development is done. Gabriel Caraballo forked the code to use for Kiribati feature-length. He may have some update on any changes he may have made. Cheers, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2014-01-21 Torsten Mohr : > Hello, > > I wonder what the status of the MultiView patch (rendering sterographic > videos) is, there hasn't been much talk about it lately and it doesn't seem to > be on the list of targets for 2.70. Or did i miss something? > > > Best regards > Torsten > > ___ > 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] ED_area_headerprint guideline?
Hi all, I was working in the headerprint for the walk and fly navigation and I was wondering if we have a standard/guideline for the operators messages. A few examples showing some inconsistency: Knife Tool operator: "LMB: define cut lines, Return/Spacebar: confirm, Esc or RMB: cancel, E: new cut, Ctrl: midpoint snap (OFF), ..." Vert Slide operator: "Vert Slide: 0.001, (E)ven: OFF, Alt or (C)lamp: ON" Grease Pencil Erase Session: "Grease Pencil Erase Session: Hold and draw LMB or RMB to erase | ESC/Enter to end" That made me wonder about a few points: * When to use "/", when to use "or"? * When to use "," when to use "|" * Should we have the shortcut mixed with the action (e.g., (C)lamp) whenever we can? * Should we have the value (ON/OFF) outside parenthesis? * Why to omit the cancel/confirm actions in some cases (vert slide, bisect, ...) but not in others (knife)? * Why to use shortcut:action (e.g., "LMB: cut") instead of action:shortcut(e.g., "Cut: LMB"). 2.49, Fly Navigation at least, was using the latter. * Should we always show the value (ON/OFF) for the actions that are enabled/disabled with press/release (e.g., Ctrl in Knife Cut, or Shift in the walk navigation)? * ... probably other questions to be pinpointed, I didn't look to all cases I'm not volunteering to tackle this, but I think this is something the UI team could/should take a look. It would be nice to have a guideline for this somewhere. Cheers, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Camera options proposal (Cycles)
Hi Robin, For your first option you may be interested on the following patch: https://developer.blender.org/T35428 It adds the ability of adding a deformation map to your lens. It's not as neat as a drag & drop control, but it should be able to get to the effect you are looking for. Cheers, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2014-02-13 20:36 GMT-02:00 ertuqueque : > Hi, I'm not sure if this is the right place for this proposal/discussion or > if the Cycles mail list would've been better, but I'd like to propose a > couple of feature/parameters for the cameras in Cycles. I'm posting a link > (Google Drive) to a short PDF I prepared with the proposal and interface > mockups. > > https://drive.google.com/file/d/0B9-4MQo-2HDqUVJvWmg2bEJTd1k/edit?usp=sharing > > Thank you in advance. > ___ > 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] GHOST EGL Support
I remember the BGE part of the branch introducing a few regressions. I would like to be in the loop during the merges to make sure things to smooth for the game engine as well. That said, it's an important branch and should be merged for sure. (not sure about the status of the code though, never got to look at it). ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] GSoC - new idea posted (in need of a student) - Multi-Layer Image Handling - (e.g. OpenRaster support)
Hi all, I added a new idea to the list: http://wiki.blender.org/index.php/Dev:Ref/GoogleSummerOfCode/2014/Ideas#Multi-Layer_Image_Handling This came up while we were implementing PSD (Photoshop) files support and I think it could be a nice Summer project if some student is interested. The ideal goal in my opinion would extrapolate Blender coding. The project would work great if the student can implement OpenRaster into OpenImageIO. I think we had similar cases in the past where a project touches more than one Foundation. So I believe it should be fine. Optionally, Krita or Gimp could point a student into this direction. In the ideal world I would love to see a student working for better ORA integration in Gimp, a Krita student implementing ORA in OpenImageIO and another student implementing multi-layer support in Blender. I don't have contacts in the other organizations though, so won't bother trying to pull that off this time. But as far as time-budget goes, I think multi-layer in Blender + extending OIIO makes for a nice Summer. I would be willing to mentor (or co-mentor) such a project, so I thought it was worth thinking out loud in case it picks someone's interest in those last 20 hours. * PS: for someone from Krita reading this: Even if now we don't get Multi-Layer support in Blender, it would be really easy/quick to implement ORA support for Blender once ORA is supported in OpenImageIO. Even if as a flatten down image, as we do for PSD. All the best, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] GSoC - new idea posted (in need of a student) - Multi-Layer Image Handling - (e.g. OpenRaster support)
For the records, there seems to be some lack of consensus on whether or not we should keep pursuing OIIO integration within Blender. I removed this proposal from the GSoC list, but it still lives here if someone wants to recycles it: http://wiki.blender.org/index.php/User:Dfelinto/Ideas#Multi-Layer_Image_Handling If a student does want to pursuit this idea, this can be further discussed (or dismissed) in the proposal page. Without any further, hurry up, there are 2 hours left ;) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Cycles-Baking - 1st round of code review
Dear all, I just submitted the bake-cycles branch for review: https://developer.blender.org/D421 For simple changes/fixes feel free to push (or send a pull request) directly to my github repository: https://github.com/dfelinto/blender-git/tree/bake-cycles For general review and discussions is probably better if we centralize it in developer.blender.org. For bugs/issues I would like to use my github too, at least until the code is 'master'-ready: https://github.com/dfelinto/blender-git/issues?labels=bake-cycles&state=open Thanks, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Clang errors when compiling the Cycles CUDA kernel in Blender
Hi, I'm also running into issues to build with CUDA in a OSX environment. 10.8.5 - clang (Apple LLVM version 5.0 (clang-500.2.75). The -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2014-02-10 21:38 GMT-02:00 Sen Haerens : > On Mon, Feb 10, 2014 at 11:47 PM, Sen Haerens wrote: >> >> Compiling the kernel in Blender GUI is still broken because the nvcc >> arguments are hardcoded in /intern/cycles/device/device_cuda.cpp:324. It >> would be nice if it could apply the flags also. >> > > Attached patch adds setting of extra nvcc flags via an environment > variable and fixed all my issues. > > ___ > 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] Clang errors when compiling the Cycles CUDA kernel in Blender
sorry, I pressed "send" by mistake/too early. Anyways, the error I get is: clang: error: unsupported option '-dumpspecs' That happens with or without the patch sent by Sens. I don't have a NVidia, but that shouldn't be a problem, so I heard. Computer settings: OSX 10.8.5 - clang (Apple LLVM version 5.0 (clang-500.2.75). Any clues? ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Clang errors when compiling the Cycles CUDA kernel in Blender
For the records, I tried: CUDA 5.0, 5.5_20, 5.5_28 (even though it was a 10.9 pkg), 6.0RC They all fail with the same error: clang: error: unsupported option '-dumpspecs' I'm leaving this as it is for now. I happen to be setting up a Linux box that has a NVidia card. It's a remote computer, so not ideal for my day-to-day code, but it may do to get bake-cycles building with CUDA. Thanks for the help though, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2014-04-02 12:26 GMT-03:00 Brecht Van Lommel : > You can try installing the latest CUDA toolkit version: > https://developer.nvidia.com/cuda-downloads > > There was a change in the new Xcode and/or OS X 10.9 that broke the > CUDA toolkit, NVidia released a new version with a fix for this. > > > > On Wed, Apr 2, 2014 at 2:58 AM, Dalai Felinto wrote: >> sorry, I pressed "send" by mistake/too early. >> >> Anyways, the error I get is: >> clang: error: unsupported option '-dumpspecs' >> >> That happens with or without the patch sent by Sens. I don't have a >> NVidia, but that shouldn't be a problem, so I heard. >> >> Computer settings: >> OSX 10.8.5 - clang (Apple LLVM version 5.0 (clang-500.2.75). >> >> Any clues? >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Question about external Blender interface
Hi Pablo, This can be implemented via Python, but you will need to handle all the socket connectivity part. It would be nice to have this built-in in Blender (maybe as new bpy.app.handlers). But I don't think anyone is working on this it at the moment. Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2014-04-04 13:05 GMT-03:00 : > Hi, > > * My background: > > I started using Blender a couple of months ago, I´ve been always a fan of > 3D and Blender in general since I think it´s an excellent product. > I work as a Web and Android developer > > * The object of the email: > > Ultimately when using Blender, I thought about using all 5 mouse buttons > then it came to me that I have a Joystick with 3d movement and lots of > buttons would be interesting using it with blender. > Finally I came to the idea of developing an Android application to replace > the main use of the keyboard. > > What I don´t know is if Blender allows any kind of connectivity out of the > app. > For example, it could use a port or something to which apps could connect > and send in commands, or something else you guys might think of. > The possibilities are really big since virtually anything could be used to > control blender. > > I would like to know if this is possible and if there are already efforts > towards it, I couldn´t find any info on the Web. > > If this is not the right place to post please let me know. > > Thanks! > Pablo > ___ > 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] Git rebase/merge question
Hi all, I have a public branch (bake-cycles in git.blender.org) that started from a local branch, where I was using rebase from master all the time, but moved to upstream, where I've been doing merges from master often. Now that the time to merge back to master is coming close, I want to squash most of my old commits in logical blocks. The problem is, although when I was working locally my commits were all nicely stacked together (due to rebase), they are now scattered all over the git log (due to merge). Is there an automatic way to convert a "merge branch" into a "rebase branch"? Once I had a "rebase branch" it would be much easier for me to do some rebase -i for squashing and re-order commits for the final merge. Otherwise I will have to resort to splitting the commits based on the files, which is not ideal in my case. Many thanks, Dalai ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Git rebase/merge question
> I would think running "git rebase master" in the branch works? And you are correct :) Thanks Brecht ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] bake-cycles merged in master
Dear all, Just a note to say that the bake-cycles branch is fully merged in master. I split the commits in 3 categories: 1. Blender core new utility functions, independent of baking, separate commits (BLI_, IMB_, ...). 2. Bake API - generic API structure to be implemented by interested external render engines 3. Cycles Baking - Cycles implementation of baking, independent of Blender Since I did a lot of squashing and I forgot to reset the date of the commits,the emails in bf-cvs show them in a strange order. git log shows them as intended, regardless of the commit timestamp, so we should be fine. I still need to include Cycles baking in the release logs for 2.72, but the documentation is online: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Bake If someone needs help to integrate an external engine (LuxRender, ...) with the Baking API let me know. The Cycles Baking commit [eec3eab] should have all you need though. For the records: 56d8aff 198f5e5 97641a0 3312b20 eec3eab : * https://developer.blender.org/rB56d8aff * https://developer.blender.org/rB198f5e5 * https://developer.blender.org/rB97641a0 * https://developer.blender.org/rB3312b20 * https://developer.blender.org/rBeec3eab Thanks everyone for all the help, and thanks for the contributors of Blender Development Fund. And let the tests begin. [cross posted on bf-gamedev (tests/workflow/usability related replies) and bf-committers (other Blender dev related replies)] Best regards, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender developers meeting, May 11, 2014
> Last minute suggestion: make a splash with cool game character + provide the blend to export it. And make all its shaders with Cycles, baked as Combined :) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Baking Docs
done. by the way, the fire and smoke setup example file should be stored elsewhere. pasteall is really not a place for permanent storage ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender Wiki Maintenance
The wiki seems to be down at the moment: http://www.downforeveryoneorjustme.com/http://wiki.blender.org (19:55, 22/5, BRT) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender Wiki Maintenance
And it's down again ... (1:33 AM BRT, 28/5) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] [da7bdf1] master: CMake: quiet warnigns with 3.0
Hi Campbell, This break compilation here (and in some LInux stations too as reported by Daniel Salazar). Error: Policy "CMP0043" is not known to this version of CMake I'm tempted to revert that ... I was about to commit the bake-cage patch, doing the final test build when this came up :/ Cheers, Dalai ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Weekly Blender developer meeting minutes - June 29, 2014
Hi Thomas, If we want to play safe, maybe multiview can be moved to 2.73 target list instead of 2.72. That said I believe part of its functionalities may be master-ready in time, even if not all of it. As for the current status of multiview not much changed since my last BF report: http://wiki.blender.org/index.php/User:Dfelinto/Foundation I'm keeping it (locally) up to date with upstream/master, and have the 'Fullscreen Area' (the next task) almost finished. I need uninterrupted time to get things patched up and that will be resumed next week - I decided to take some time off during the World Cup to wrap up other projects and to enjoy the games. I did read the previous dev-meeting logs and I do plan to contact the Foundation to see a good way to wrap this up. Best regards and \o/ go Brazil ;) Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2014-07-07 18:15 GMT-03:00 Thomas Dinges : > Hi Dalai, > Multiview status is still unknown, maybe you can get back to us? ;) > > Otherwise it can be removed as 272 target from this list > http://wiki.blender.org/index.php/Dev:Doc/Projects > > Thomas > > Am 29.06.2014 16:30, schrieb Thomas Dinges: >> Hi all, >> Here are the notes for today's meeting in irc.freenode.net #blendercoders. >> >> * Status of Multiview (Dalai) and Compositor Memory Management (Atmind) >> is unknown. Are these still valid targets for 2.72? >> > > ___ > 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] Any git suggestion to force the commit date to be correctly ordered when pushing?
Hi, >From time to time I forget to re-set the time of some individual commits (git commit --amend --reset-author) and I end up with commits showing up in the wrong order in bf-cvs list. (most recent example: 1aabbf8 and 92c8dd1). It tends to happen when I'm working in a branch, and squash commits. Can anyone suggest an automatic way of git to check if the date of the commits to be pushed is in the correct order? I never used hooks in git but I suspect this would be the way to go. Or perhaps this is something to be handled server-side? If the only issue is the order that bf-cvs uses to show the commits than it may not be an issue. But I suspect it may lead to misinformation in the future and could be avoided. Thanks, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Mulltiview Status and Roadmap [proposal]
Hi, [now that the Cup is over *cough*] I'm done drafting the roadmap for multiview in Blender. I'm still waiting for the feedback from two core collaborators, but those plans are already based on previous design discussions and decisions made with Brecht Van Lommel and Francesco Siddi in the past. I'm not a believer of design-by-comittee but I think openness is essential during open source project and new core collaborators are always welcome. So if you have any comments you can add them in the google doc below: https://docs.google.com/document/d/1bX_69zbZ9KJCozmiQMD-FSwvMXyJEqChSlSRLiUU0As/edit#heading=h.pvbmks2phm2h (if there are actually long discussions I will move the proposed topics to the Blender Tracker to be discussed there, though I believe it won't be necessary) Regards, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Duplicated commits in soc-2013-paint?
Hi, >From the look of bf-cvs and the tracker it seems something went wrong in recent commit from soc-2013-paint. Basically some master commits showed up as commits (with new hashes) in the branch (triggering new emails in bf-cvs and adding new related commits to already closed bug reports). Is that normal? It's the first time I see this. It seems that either rebase was used or the merge went wrong. Cheers, Dalai ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] can we update ffmpeg to have RTSP support?
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 -- blendernetwork.org/dalai-felinto www.dalaifelinto.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] can we update ffmpeg to have RTSP support?
@Fasekas: we are wrapping some of the functionality directly from the FFmpeg library so unless ffmpeg can do it I believe we can't. That's besides the point though, why to reinvent the wheel if we are already using a library that provides streaming. @Sergey > And maintain means communicate with the users in the tracker, making sure > this stuff works in upcoming blender releases, invest time on fixing stuff > when it becomes broken (and stuff tends to become broken in FFmpeg). As I said in IRC I can commit to the Blender side of this (in this particular subset of FFmpeg features). Meaning replying to tracker entries and orienting clueless users. This will be used by BGE anyways, so it won't affect Blender users in general. That said, even with the backend RTSP support in the ffmpeg the feature is not fully working. But I believe it's an issue in BGE code (more details in the tracker). > But seems we need to update FFmpeg anyway (because of > https://developer.blender.org/T41065) so technically tweaking configuration > flags is not that much an issue. Anyways we support so many bizarre things (webcam!), I can't see this going over whatever line we drawn. I think in cases like this we should have reasons to not include things, not to include them (when it comes to 'readers [decoders]'). Either way the reason/use case was explained in the original email. I'm just not sure about the h264, if this violates any GPL/patent thing. Cheers, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2014-07-15 12:49 GMT-03:00 Fazekas László : > 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? > > 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 >> -- >> blendernetwork.org/dalai-felinto >> www.dalaifelinto.com >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers >> >> > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Any git suggestion to force the commit date to be correctly ordered when pushing?
The correct order was 92c8dd1 and then 1aabbf8. So you are right the problem is probably in my email client (gmail). It's not the first time that this happen after I push a series of commits, some of them with the wrong data. Thanks, if it happens again I will just ignore :) -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2014-07-11 18:55 GMT-03:00 GSR : > Hi, > dfeli...@gmail.com (2014-07-11 at 1222.38 -0300): >> >From time to time I forget to re-set the time of some individual >> commits (git commit --amend --reset-author) and I end up with commits >> showing up in the wrong order in bf-cvs list. (most recent example: >> 1aabbf8 and 92c8dd1). It tends to happen when I'm working in a branch, >> and squash commits. > > 92c8dd1 has > Date: Mon Jul 7 12:30:43 2014 -0300 > index 1c3e223..0b80a57 > > 1aabbf8 has > Date: Mon Jul 7 12:46:25 2014 -0300 > index 0b80a57..a9516e6 > > Notice 0b80a57 and 12:30 < 12:46. > > https://developer.blender.org/rB92c8dd16dfa9c1ffe7f4d2912bf1bf78b82c3894 > has Committed dfelinto Fri, Jul 11, 4:43 PM > > https://developer.blender.org/rB1aabbf8476a253b49437691c041bede34d8f4227 > has Committed dfelinto Fri, Jul 11, 4:44 PM > > Now 4:43 < 4:44 (no time zones/offsets... *sigh*). And pages even > point 92c8dd1 is the parent of 1aabbf8. > > All looks correct, doesn't it? Or do you mean it should be "1aabbf8 > parent of 92c8dd1"? > >> If the only issue is the order that bf-cvs uses to show the commits >> than it may not be an issue. But I suspect it may lead to >> misinformation in the future and could be avoided. > > The proper way is to use git log or similar tools that look at the > repository data. Mail systems don't have to always process the emails > in the same order, so they are not trustable sources for this. > > http://lists.blender.org/pipermail/bf-blender-cvs/2014-July/date.html > currently shows 92c8dd1 then 1aabbf8, but could have picked other > order if one of the emails was delayed. Your own mail app could be > showing them in any order. Mails apps don't have to know about git > specifics. > > GSR > > ___ > 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] can we update ffmpeg to have RTSP support?
The Blender (BGE) - side of rtsp support is committed [6f846da], now to the ffmpeg backend: > Seems like a special case - couldn't the BlenderCAVE/remote-camera users who want RTSP do their own builds? That's a possible compromise, but then I would ask to at least have wiki pages on how to build our OSs libraries. I think Linux and OSX are clear enough-ish, but Windows is definitively not. I remember a script to build the libraries for windows in a similar way we have for Linux. Was this abandoned? I get that devs are supposed to know those things, but I think to ask someone to know how to build libraries to all OSs on its own is a bit too much. (thinking on people that relying on custom libraries to get the most out of Blender). That said I still don't see the harm in enabling everything in the ffmpeg backed that doesn't bloat the library size ... Cheers, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2014-07-15 23:55 GMT-03:00 Campbell Barton : > On Wed, Jul 16, 2014 at 5:31 AM, Dalai Felinto wrote: >> @Fasekas: we are wrapping some of the functionality directly from the >> FFmpeg library so unless ffmpeg can do it I believe we can't. That's >> besides the point though, why to reinvent the wheel if we are already >> using a library that provides streaming. >> >> @Sergey >>> And maintain means communicate with the users in the tracker, making sure >>> this stuff works in upcoming blender releases, invest time on fixing stuff >>> when it becomes broken (and stuff tends to become broken in FFmpeg). >> >> As I said in IRC I can commit to the Blender side of this (in this >> particular subset of FFmpeg features). Meaning replying to tracker >> entries and orienting clueless users. This will be used by BGE >> anyways, so it won't affect Blender users in general. That said, even >> with the backend RTSP support in the ffmpeg the feature is not fully >> working. But I believe it's an issue in BGE code (more details in the >> tracker). >> >>> But seems we need to update FFmpeg anyway (because of >>> https://developer.blender.org/T41065) so technically tweaking configuration >>> flags is not that much an issue. >> >> Anyways we support so many bizarre things (webcam!), I can't see this >> going over whatever line we drawn. I think in cases like this we >> should have reasons to not include things, not to include them (when >> it comes to 'readers [decoders]'). Either way the reason/use case was >> explained in the original email. I'm just not sure about the h264, if >> this violates any GPL/patent thing. > > On the other hand we end up loosing time to support various > configurations, its hard to know beforehand if enabling options incurs > maintenance overhead. > > Seems like a special case - couldn't the BlenderCAVE/remote-camera > users who want RTSP do their own builds? > ___ > 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] Patch for review: Fullscreen Editor (new fullscreen mode for clean UI)
https://developer.blender.org/D678 ### Organize Maximize/Fullscreen mess and add a new fullscreen mode with no UI Maximize Editor: (old Ctrl+Up) Full Screen Window: (old Alt + F11) Full Screen Editor: new operator (Alt + F10) It should fullscreen the window and make it clean (no UI, no buttons). After exiting it, it should return to the previous window state (windowed/fullscreen). This was originally intended for the multiview branch, but this functionality also benefits non-stereo workflows, thus it can be reviewed and committed independently. ### Thanks, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Making test builds for WIP projects.
Hi, This is great, really useful. It would be really handy if at least the testbuild branch in the server could use non-fast-forward. In other words, if it could use it as follow: $ git checkout testbuild $ git reset --hard origin/master $ git merge --squash mywippatch $ git commit $ git push --force Would that be possible? Or git handles those permissions globally and not per branch? Cheers, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2014-07-25 9:28 GMT-03:00 Bastien Montagne : > Hi fellow devs, > > This week we set up a way to make test builds on the buildbots (meaning > you get release-like archives, easy to distribute! :) ). > > Here are the steps to follow: > * Checkout the 'testbuild' branch, apply your code to it (probably by > reseting it to master and then squash-merging in your own work); > * Push your changes on remote repo; > * Go to one of the buildbot's builders' page (e.g. > https://builder.blender.org/builders/linux_glibc211_x86_64_scons) - note > you'll need to do that for all platforms you want to build on. > * Select 'testbuild' instead of 'master' in the branch dropdown, and > force the build. > * Note you can also force a given revision, can be handy as it means you > can still build your work even if someone has overriden it in testbuild > branch. > * Download your testbuild as soon as it is finished! It will be replaced > by the next test build (for a given builder). > > Quite obviously, let's try not to abuse the feature! :) > > ___ > 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] Making test builds for WIP projects.
Alright, after talking with Bastien my suggestion is: $ git checkout testbuild $ git merge origin/master $ git merge --squash mywippatch $ git commit $ git revert HEAD $ git push origin Notice that this maintains the branch always 1:1 with origin/master. So no one has to clean after your commits. You will need to specify the hash of the HEAD^1 to the Builder Slave. Regards, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2014-07-28 16:32 GMT-03:00 Dalai Felinto : > Hi, > This is great, really useful. It would be really handy if at least the > testbuild branch in the server could use non-fast-forward. In other > words, if it could use it as follow: > > $ git checkout testbuild > $ git reset --hard origin/master > $ git merge --squash mywippatch > $ git commit > $ git push --force > > Would that be possible? Or git handles those permissions globally and > not per branch? > > Cheers, > Dalai > -- > blendernetwork.org/dalai-felinto > www.dalaifelinto.com > > > 2014-07-25 9:28 GMT-03:00 Bastien Montagne : >> Hi fellow devs, >> >> This week we set up a way to make test builds on the buildbots (meaning >> you get release-like archives, easy to distribute! :) ). >> >> Here are the steps to follow: >> * Checkout the 'testbuild' branch, apply your code to it (probably by >> reseting it to master and then squash-merging in your own work); >> * Push your changes on remote repo; >> * Go to one of the buildbot's builders' page (e.g. >> https://builder.blender.org/builders/linux_glibc211_x86_64_scons) - note >> you'll need to do that for all platforms you want to build on. >> * Select 'testbuild' instead of 'master' in the branch dropdown, and >> force the build. >> * Note you can also force a given revision, can be handy as it means you >> can still build your work even if someone has overriden it in testbuild >> branch. >> * Download your testbuild as soon as it is finished! It will be replaced >> by the next test build (for a given builder). >> >> Quite obviously, let's try not to abuse the feature! :) >> >> ___ >> 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] Patch for review: Fullscreen Editor (new fullscreen mode for clean UI)
Hi, The patch is complete now. When you go to Fullscreen Editor there is no UI, but as soon as you move the mouse to near the top right corner an icon shows up, that brings you back to normal window (of course shortcuts work too, but in case someone get lost there now there is a neater way to go back). Review is appreciated, it works in OSX and Linux (so Windows too). Best regards, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2014-07-26 15:51 GMT+02:00 Dalai Felinto : > https://developer.blender.org/D678 > > ### > Organize Maximize/Fullscreen mess and add a new fullscreen mode with no UI > > Maximize Editor: (old Ctrl+Up) > Full Screen Window: (old Alt + F11) > Full Screen Editor: new operator (Alt + F10) > It should fullscreen the window and make it clean (no UI, no buttons). > After exiting it, it should return to the previous window state > (windowed/fullscreen). > > This was originally intended for the multiview branch, but this > functionality also benefits non-stereo workflows, thus it can be > reviewed and committed independently. > ### > > Thanks, > Dalai > -- > blendernetwork.org/dalai-felinto > www.dalaifelinto.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Patch for review: Fullscreen Editor (new fullscreen mode for clean UI)
Fullscreen in OSX is top right (the tilted <-> icon). ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender input method editor support for windows
Hi, > * extern library, e.g. imm32.lib & imm32.dll, is needed for IME support for > windows, but I don't know how to handle this What you don't know how to handle? The linking? How to add them in the patch (you can't actually, they would need to be in the svn repository with the rest of the libraries)? Make sure they are GPL-compatible, otherwise it's a no-go from the very begin. Cheers, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2014-08-27 3:33 GMT+02:00 Tamito KAJIYAMA : > Hi, > > Windows input method support in Blender has been long waited and will > be very much appreciated. > > You can submit the patch to the Differential system: > https://developer.blender.org/differential/ > > I guess I can be a reviewer of the code then. > > Regards, > > -- > KAJIYAMA, Tamito > > > On 26/08/2014 21:04, randonl...@gmail.com wrote: >> Hello everybody, >> >> I'm developing Blender IME support for windows, in East Asia(China, Japan, >> Korea), >> people need to use IME to type complex characters, so it is useful :) >> >> Now it works well in my mingw64 and vc12x64 >> environment, but I still have some problem: >> >> * extern library, e.g. imm32.lib & imm32.dll, is needed for IME support for >> windows, >> but I don't know how to handle this >> * it is my first time developing Blender, I'm not very familiar with Blender >> architecture, but this task requires changing multiple files, I try my best >> to >> conform the architecture, however I think there still being some error >> >> Should I submit a patch? Would anybody give me some suggestion? >> >> I'm a Chinese college student and enjoyed Blender >> >> >> >> Best regards, >> Dun Liang > ___ > 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] Blender 2.72 testbuild1 AHOY
I was wondering if at some point we could/should use the builds straight from build bot for the test builds (and in the future for the final releases). Or is there any difference in the official builds and the current builds from build bot? Nothing against the release ritual of having the maintainers gathering the builds, uploading them, ... But that would be a way to make sure buildbot builds are 1:1 with the official releases. Cheers, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2014-09-11 17:33 GMT+02:00 Sergey Sharybin : > Hi, > > let's compile testbuild1 tonight. > > Information for platform maintainers: > - Build from master branch, SHA d9192184821f0a5a67672a76be4f048969361c30 > - Use latest locales and addons revisions for this build > > Keep usual naming and put builds to usual place :) > > Make sure you're using CUDA toolkit 6.5. > > -- > With best regards, Sergey Sharybin > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Credits Page
> The only way to make `arc patch` to get proper authorship is to force everyone to use arc for submitting the reports. Just for the records, more than once recently I had troubles tracking back the original author of a phabricator patch before committing it. In one of the cases I had to give up and credit it to a nickname. So whatever decision come out of this I really think we should force the patches to either use arc patch or to do as you suggested (Proper name/public email). Cheers, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Multiview frustrum controler reference
Hi Adriano, Those high-level controls are desirable. But I tend to favour first implement the core functionality, let users define the ultimate workflow that attend their productions and then we sort what is the unique need of "Adriano's pipeline" and what is of general interest. The same is true for controlling min-maximum pixel separation in oppose to setting interocular distance and convergence plane. Internally the result is the same so for the initial Multi-View feature-set we provide the low level settings (e.g., interocular and convergence plane) and leave to the users to build customizable solutions for their pipelines. We had addons to provide those even before a robust Multi-View was in place. I'm confident that solutions built on top of the Multi-View/Stereo 3D functionality will be in place in no time. That said, if you have the time to build a proper proposal on how those controllers would fit in the UI and the pipeline I'm all ears. Regards, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2014-10-09 11:15 GMT-03:00 Adriano Oliveira : > Thank you Dalai for the exceptional work in Multiview branch. > > Stereo images are easy to create in CG, but it is very hard do control how > they can be correctly "decoded" by our brains. > > The main problem is the relation among human interoccular distance, image > resolution, screen size and viewer distance from screen. In short, a 3d > film produced for theater release is not good for TV without propper > adjustment. > > So it is very important that Multiview offers in near future a stereo > camera rig with a frustrum indicating a "safe stereo zone" for placing > objetcs. This zone would change whenever any os above parameters is changed. > > We can see the mathematics for this in http://www.noeol.de/s3d/ > > > But I think we could go further and dream with an ideal dinamic stereo > frustrum similar to this: > > https://vimeo.com/57398627 > > Even if this is not possible right now, it would be very nice if the code > allow it to be implemented in near future. > > ;) > > Adriano A. Oliveira > ___ > 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] Weekly Blender developer meeting notes - October 19, 2014
> - Meeting agrees on just updating the current 'a' build and name it 'b' on > blender.org. Will happen tuesday, who knows something else pops up tomorrow! Can we have this commit in 2.72.b as well? [4b42c4b] It fixes blenderplayer building for cmake. It's not critical but helps who patch custom branches on top of stable tarballs. (I'll be in transit during most of Tuesday, but meanwhile Jens can explain the patch better if needs be) Thanks, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2014-10-19 19:23 GMT-02:00 Jacob Merrill : > Any word on the full viewport FX integration? - Android compatibility? > > On Sun, Oct 19, 2014 at 8:21 AM, Ton Roosendaal wrote: > >> Hi all, >> >> Here are the notes from today's meeting in irc.freenode.net >> #blendercoders. >> >> 1) Release update, 2.72 b ? >> >> - Unfortunately... there's an issue in 2.72a that causes Blender to crash, >> when you attempt to texture paint on an subsurfed mesh without UVs. Easy to >> bypass when you know, but annoying if you don't. >> >> - Meeting agrees on just updating the current 'a' build and name it 'b' on >> blender.org. Will happen tuesday, who knows something else pops up >> tomorrow! >> >> - Reminder: when doing an update release, we have to add a tag for package >> maintainers. >> >> - The BCon2 deadline (define final targets) will be postponed two weeks. >> >> 2) Targets for the next release >> >> - Fracture modifier has been reviewed >> https://developer.blender.org/D817#12710 >> Campbell Barton proposes to not accept the patch - for implementation >> reasons. Martin Felke will reply. Please join the discussion in the patch >> tracker. >> >> - Thomas Dinges reminds us the todos for making Blender to use Cycles as >> default render engine. >> http://wiki.blender.org/index.php/User:DingTo/Cycles_Default_Engine >> One of the issues is better presets or bundling with preset node groups. >> This is also related to the asset project people are working on for the >> Gooseberry project. >> >> 3) Other projects >> >> Note for everyone: next week there's no IRC meeting, because of Blender >> Conference in Amsterdam! >> >> Laters, >> >> -Ton- >> >> >> Ton Roosendaal - t...@blender.org - www.blender.org >> Chairman Blender Foundation - Producer Blender Institute >> Entrepotdok 57A - 1018AD Amsterdam - The Netherlands >> >> >> >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers >> > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Normal Map issue.
Hi, > more normal map support in cycles for the future would be great though. Such as? > all you need to do is separate the RGB, invert the Green, combine RGB and the > normals sort themselves out properly. You can use the 'normal swizzle' option in Cycles Baking: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Bake#Normals Regards, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2014-11-05 19:26 GMT-02:00 R VR : > > Hello, so I came across a thread in the net and tried a few suggestions out, > and it turns out that when you have a mirrored model which is exhibiting > behavior of flipped normals on either side, all you need to do is separate > the RGB, invert the Green, combine RGB and the normals sort themselves out > properly. > Seeing as I have seen this talked about quite a bit and it's a tricky fix, > hopefully this information can make it's way out to the broader blender > community. > > Cheers, and thanks for the help, more normal map support in cycles for the > future would be great though. > >> Date: Mon, 3 Nov 2014 14:42:41 + >> From: metalliandy...@googlemail.com >> To: bf-committers@blender.org >> Subject: Re: [Bf-committers] Normal Map issue. >> >> Hi Rob, >> >> AFAIK, mirrored baking should work perfectly with a mirror modifier. I >> just did a quick test and everything looked as I would expect, but maybe >> I am misunderstanding what you mean. >> Could you post a picture and a .blend so that I can reproduce the error >> please? >> >> Also, what kind of normal map are you baking (Tangent Space/Object >> Space) & which render are you using to bake the normal maps with? >> >> Cheers, >> >> -Andy >> >> On 03/11/2014 08:34, R VR wrote: >> > Hello, I have a suggestion for what I feel would be a minor feature >> > addition with large large upside. It has been raised by others, but has >> > never been implemented for whatever reason. >> > When working with a mirrored symmetrical object with a uv map, the normals >> > on the mirrored side are flipped in the red color I believe, which has a >> > very undesirable result. One side is as expected and the other side is >> > completely the opposite. When attempting to make photo-realistic skin >> > pores on an animated character, in which as much uv space as possible >> > needs to be allocated to the face, having a mirrored normal only enhances >> > the level of detail that can be achieved, while having to map the entire >> > surface to have the normals right is a real obstacle for that goal. >> > This issue is imposing a fairly reasonable obstacle in my workflow (as I'm >> > sure is the case with others), I cannot work in progression with any >> > symmetrical model in which normal maps are a large feature, which is >> > often, seeing as how any texture I make while the object is mirrored and >> > being tested will need to be completely and utterly redone down to the >> > last pixel when it comes time to finalize the model. Not only this but I >> > would also be losing detail in having to share space with the other half >> > of the model. >> > If the mirror modifier had an implementation that automatically switched >> > the normal map in the right direction for the mirrored side, this would >> > take care of the issue, and seeing as how there are uv options already I >> > don't feel like this would be a big step to take. >> > You guys are awesome! >> > Cheers, Rob. >> > ___ >> > Bf-committers mailing list >> > Bf-committers@blender.org >> > http://lists.blender.org/mailman/listinfo/bf-committers >> > >> >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Propose to reduce default feature set (*nix dev builds)
+1 to the proposed idea on top of that it would be nice to have a 'make release' or similar option to mimic the settings used in the release build. It's worthy noting that the current CMake default settings are already different than the release options (e.g., BlenderPlayer is not built by default). The idea presented here only brings this a step further. Regards, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2014-11-13 13:14 GMT-02:00 AIBlender : > On 13/11/14 14:32, Sergey Sharybin wrote: >> Addressing this: >> I understand the reasoning behind it Sergey, but if new >> people want to build Blender they should get something which is approaching >> a feature complete build, otherwise what is the point of using a Dev build. >> >> Why would motion tracker developer want to deal with LLVM? Why new modifier >> guy would want to deal with Boost? Why compositor or dependency graph guys >> need to worry about any of external dependencies? This could be continued.. >> >> For sure at some point developer would need to be able to compile >> feature-complete blender, but forcing him to solve all the dependencies >> from the very beginning is really scary for new developers. >> > > If for every new dev you started turning off features because they get > confused you end up with a very limited version of Blender. > > Any dev working on advanced features should be able to compile full > versions of Blender, and that Ideally should be because a seasoned Dev > has made Blender work with all feature enabled out of the box. > > Errors when features are turned back on are going to get reported and > need fixing anyways, so may as well keep it working from the very > beginning with all features on. > > Anyways my point is clear on this, sorry if it come across as aggressive > but, turning off features is just hiding problems, and for people like > me it will just mean I turn the features back on a complain a lot more > forcefully if I get errors that run out of control because some feature > was disabled because of some "scared" dev. > > Terry Wallwork > > > > ___ > 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] Revising the testbuild branch
How to make a build now? After I click on 'Force Build' I land in a page saying: "Authorization Failed. You are not allowed to perform this action." And for the records, in the future it would help to have the outcome of such an important discussion re-sent to the list as an email on its own (instead of a reply in a 11-email long thread) ... I just pushed 'testbuild' back to the servers :( [and deleted it after, but still, the notification commits will be all over everyone's email boxes]. Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2014-10-16 8:16 GMT-03:00 Bastien Montagne : > Hi devs, > > So, we resurrected testbuild as 'experimental-build', getting rid of the > issues that caused last week's shutdown of this tool (i.e. builds > publicly available from builder.b.o., and confusing name with testbuilds > done during release process). > > Note this tool implies commit access to our main git repository. > > Here are the steps to follow to make an experimental build: > * Checkout the 'experimental-build' branch, merge master in, > squash-apply your code to it, revert last commit, and push to origin > (see below[1] for an concrete example); > * Go to one of the buildbot's builders' page (e.g. > https://builder.blender.org/builders/linux_glibc211_x86_64_scons) - note > you'll need to do that for all platforms you want to build on. > * Select 'experimental-build' instead of 'master' in the branch > dropdown, copy-paste the exact hash of your squashed-commit of your > patch into 'revision' field, and force the build. > * Go to the experimental 'hidden' sub-folder of > https://builder.blender.org/download/ and download your builds from > there asap. > * DO NOT SHARE ABOVE LINK PUBLICLY! It's your responsibility to > distribute your builds (e.g. through graphicall, dropbox, whatever), > 'official' blender site should not be involved in this. Note that the > next experimental build on the same builder will replace current one, so > builder.b.o is not a reliable storage for such builds anyway! > > Quite obviously, let's try not to abuse the feature! :) > > Happy Blending, > Bastien > > [1] Typical git commands to make an experimental build: > $ git checkout experimental-build > $ git merge origin/master > $ git merge --squash mywippatch > $ git commit > $ git revert HEAD > $ git push origin > $ git checkout master > > > Le 12/10/2014 10:39, Sergey Sharybin a écrit : >> Think we should agree on some better name then and deploy? >> >> On Sun, Oct 12, 2014 at 9:19 AM, Bastien Montagne >> wrote: >> >>> Good catch, this seems to work fine! :) >>> >>> Le 12/10/2014 08:26, Sergey Sharybin a écrit : >>>> Did you try using public_html/testbuilds instead? There's also a code in >>>> the template which lusts the dirs, could comment that out. >>>> On Oct 11, 2014 11:27 PM, "Bastien Montagne" >>> wrote: >>>>> Following Sergey's suggestion (put testbuilds in a separate dir) I >>>>> fought a bit with my local version of buildbot to get it running again. >>>>> >>>>> In the end, looks like a very simple change is enough, in >>>>> master_unpack.py, something like: >>>>> >>>>> diff --git a/build_files/buildbot/master_unpack.py >>>>> b/build_files/buildbot/master_unpack.py >>>>> index ecacf3b..f5c8493 100644 >>>>> --- a/build_files/buildbot/master_unpack.py >>>>> +++ b/build_files/buildbot/master_unpack.py >>>>> @@ -116,7 +116,7 @@ if platform == '': >>>>> sys.exit(1) >>>>> >>>>> # extract >>>>> -directory = 'public_html/download' >>>>> +directory = 'public_html/download' if branch == 'master' else >>>>> 'public_html/download/testbuilds' >>>>> >>>>> try: >>>>> zf = z.open(package) >>>>> >>>>> public_html/download/testbuilds must be created beforehand of course. >>>>> >>>>> On my local web buildbot UI, that dir is automatically listed under the >>>>> download page… Not sure whether we consider that as safe enough for >>>>> users not to mess with it? Guess we can find a way to hide it, >>> otherwise. >>>>> As a side note, do not think listing those builds publically is needed >>>>>
[Bf-committers] Multiview branch, updated status
Hi, This email is to address the point raised in the previous dev meeting. Since I won't be online tomorrow here are my thoughts. (from dev meeting) "Note, officially Multiview has to migrate to master this week, has that been planned?" I think multiview can be merged to master if blender as it is (with 'Views" disabled) works as before (absolutely no regression and no crashes). So the user that doesn't touch the "Views" panel shouldn't experience any differences. That also means that, if due to instability or plain simple bugs, we think it's not ready for 2.73 we can hide the UI panels and no harm is done. At the moment there is only one known issue for that milestone, which is proxies in the Sequencer. I started looking at it today, but I will have to resume working on it on Monday only. That means that, as soon as proxy is working (again, in non-multiview mode), I can send the code for review and we merge as soon as another core developer approves it. After that, for multiview itself the missing bits are: proxies in sequencer, some usability todos and other small bugs (e.g., to filter out _L or _R when adding image strips). Meanwhile if anyone wants to help testing it, (specially the 'non-multiview' mode), there are builds for the 3 major platforms in 64 bits: Win 64: http://goo.gl/eucBWf Linux: http://goo.gl/zOeGD0 OSX: http://goo.gl/1b6XmD (if you want to build it yourself the branch is 'multiview' in the official git.blender.org server) I've been using my own github repository to collect bugs, but I guess you can send me an email directly to report an issue in case you don't have a github account. https://github.com/dfelinto/blender/issues (or we could use the blender tracker, but I'm not sure what is our policy on reporting bugs in branches). Thanks! Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Multiview branch, updated status
Hi Campbell, I just tried to 'arc diff' a squashed version of the branch, but I think it's too big for Phabricator. The error I get is: """ No unit test engine is configured for this project. Exception [HTTP/500] Internal Server Error As received by the server, this request had a nonzero content length but no POST data. Normally, this indicates that it exceeds the 'post_max_size' setting in the PHP configuration on the server. Increase the 'post_max_size' setting or reduce the size of the request. Request size according to 'Content-Length' was '9781018', 'post_max_size' is set to '8M'. """ Any suggestions? Thanks, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2014-11-22 15:40 GMT-02:00 Campbell Barton : > Hi Dalai, even with the small todo's left, its probably worth doing a > first pass review. > I'll go over the branch Monday, Sergey can take a look this week too. > > IIRC the policy is not to use tracker for branches, but we could > re-visit that and associate reports with a branch so its not clogging > up the tracker and mixing bugs from master. > > On Sat, Nov 22, 2014 at 5:26 PM, Dalai Felinto wrote: >> Hi, >> This email is to address the point raised in the previous dev meeting. >> Since I won't be online tomorrow here are my thoughts. >> >> (from dev meeting) >> "Note, officially Multiview has to migrate to master this week, has >> that been planned?" >> >> I think multiview can be merged to master if blender as it is (with >> 'Views" disabled) works as before (absolutely no regression and no >> crashes). So the user that doesn't touch the "Views" panel shouldn't >> experience any differences. That also means that, if due to >> instability or plain simple bugs, we think it's not ready for 2.73 we >> can hide the UI panels and no harm is done. >> >> At the moment there is only one known issue for that milestone, which >> is proxies in the Sequencer. I started looking at it today, but I will >> have to resume working on it on Monday only. >> >> That means that, as soon as proxy is working (again, in non-multiview >> mode), I can send the code for review and we merge as soon as another >> core developer approves it. >> >> After that, for multiview itself the missing bits are: proxies in >> sequencer, some usability todos and other small bugs (e.g., to filter >> out _L or _R when adding image strips). >> >> Meanwhile if anyone wants to help testing it, (specially the >> 'non-multiview' mode), there are builds for the 3 major platforms in >> 64 bits: >> >> Win 64: http://goo.gl/eucBWf >> Linux: http://goo.gl/zOeGD0 >> OSX: http://goo.gl/1b6XmD >> >> (if you want to build it yourself the branch is 'multiview' in the >> official git.blender.org server) >> >> I've been using my own github repository to collect bugs, but I guess >> you can send me an email directly to report an issue in case you don't >> have a github account. >> >> https://github.com/dfelinto/blender/issues >> >> (or we could use the blender tracker, but I'm not sure what is our >> policy on reporting bugs in branches). >> >> Thanks! >> Dalai >> -- >> blendernetwork.org/dalai-felinto >> www.dalaifelinto.com >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers > > > > -- > - Campbell > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Multiview branch, updated status
It worked like a charm, many thanks Dan. The patch is here: https://developer.blender.org/D914 -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2014-11-24 0:12 GMT-02:00 Dan McGrath : > Hi Dalai, > > Perhaps Sergey can discuss and pick a higher default, but in the mean time, > I increased the php.ini post_max_size to 10M (up from 8M) for you to land > your patch. Hope this helps (although possible that phab has another limit > of its own that you could hit). > > Let me know if it works. o/ > > Dan > > On Sun, Nov 23, 2014 at 7:47 PM, Dalai Felinto wrote: > >> Hi Campbell, >> >> I just tried to 'arc diff' a squashed version of the branch, but I >> think it's too big for Phabricator. >> >> The error I get is: >> """ >> No unit test engine is configured for this project. >> Exception >> [HTTP/500] Internal Server Error >> As received by the server, this request had a nonzero content length >> but no POST data. >> >> Normally, this indicates that it exceeds the 'post_max_size' setting >> in the PHP configuration on the server. Increase the 'post_max_size' >> setting or reduce the size of the request. >> >> Request size according to 'Content-Length' was '9781018', >> 'post_max_size' is set to '8M'. >> """ >> >> Any suggestions? >> >> Thanks, >> Dalai >> -- >> blendernetwork.org/dalai-felinto >> www.dalaifelinto.com >> >> >> 2014-11-22 15:40 GMT-02:00 Campbell Barton : >> > Hi Dalai, even with the small todo's left, its probably worth doing a >> > first pass review. >> > I'll go over the branch Monday, Sergey can take a look this week too. >> > >> > IIRC the policy is not to use tracker for branches, but we could >> > re-visit that and associate reports with a branch so its not clogging >> > up the tracker and mixing bugs from master. >> > >> > On Sat, Nov 22, 2014 at 5:26 PM, Dalai Felinto >> wrote: >> >> Hi, >> >> This email is to address the point raised in the previous dev meeting. >> >> Since I won't be online tomorrow here are my thoughts. >> >> >> >> (from dev meeting) >> >> "Note, officially Multiview has to migrate to master this week, has >> >> that been planned?" >> >> >> >> I think multiview can be merged to master if blender as it is (with >> >> 'Views" disabled) works as before (absolutely no regression and no >> >> crashes). So the user that doesn't touch the "Views" panel shouldn't >> >> experience any differences. That also means that, if due to >> >> instability or plain simple bugs, we think it's not ready for 2.73 we >> >> can hide the UI panels and no harm is done. >> >> >> >> At the moment there is only one known issue for that milestone, which >> >> is proxies in the Sequencer. I started looking at it today, but I will >> >> have to resume working on it on Monday only. >> >> >> >> That means that, as soon as proxy is working (again, in non-multiview >> >> mode), I can send the code for review and we merge as soon as another >> >> core developer approves it. >> >> >> >> After that, for multiview itself the missing bits are: proxies in >> >> sequencer, some usability todos and other small bugs (e.g., to filter >> >> out _L or _R when adding image strips). >> >> >> >> Meanwhile if anyone wants to help testing it, (specially the >> >> 'non-multiview' mode), there are builds for the 3 major platforms in >> >> 64 bits: >> >> >> >> Win 64: http://goo.gl/eucBWf >> >> Linux: http://goo.gl/zOeGD0 >> >> OSX: http://goo.gl/1b6XmD >> >> >> >> (if you want to build it yourself the branch is 'multiview' in the >> >> official git.blender.org server) >> >> >> >> I've been using my own github repository to collect bugs, but I guess >> >> you can send me an email directly to report an issue in case you don't >> >> have a github account. >> >> >> >> https://github.com/dfelinto/blender/issues >> >> >> >> (or we could use the blender tracker, but I'm not sure what is our >> >> policy on reporting bugs in branches). >> >> >> >> Thanks! >> >> Dalai >> >> -- >> >> blendernetwork.org/dalai-felinto >> >> www.dalaifelinto.com >> >> ___ >> >> Bf-committers mailing list >> >> Bf-committers@blender.org >> >> http://lists.blender.org/mailman/listinfo/bf-committers >> > >> > >> > >> > -- >> > - Campbell >> > ___ >> > Bf-committers mailing list >> > Bf-committers@blender.org >> > http://lists.blender.org/mailman/listinfo/bf-committers >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers >> > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Can't build blender trunk on win32 since 2.73
Hi, According to the builder bot Windows 32 is building fine. Your building error suggests you are having troubles with the JACK audio system. At least for now I would recommend you disabling it. In command-line cmake I use the option WITH_JACK=OFF, in the GUI CMake there is an equivalent option. Regards, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2015-01-17 19:07 GMT-02:00 Jonathan Railsback : > Everyone - > > Last week I started trying to build Blender on win32, and I've been having > several issues with the libraries that I check out of SVN. > > First, I tried to do a debug build, and my build got tripped up because it > couldnt find libjack_d.lib. I was able to work around this by searching for > it in cmake lists file and changing the debug build to use the release > version of the library. > > After fixing the issue with libjack_d.lib, I had problems linking with the > opencollada libraries. It appears that somehow a 64bit debug library got > checked into the 32 bit precompiled windows libraries. I get the following > error from MSVC++ 2013: > > OpenCOLLADAFramework_d.lib(COLLADAFWFileInfo.cpp.obj) : fatal error LNK1112: > module machine type 'x64' conflicts with target machine type 'X86' > > For reference, I checked out my windows precompiled libraries from the > following SVN URL, per the instructions on the Blender website: > > https://svn.blender.org/svnroot/bf-blender/trunk/lib/windows_vc12 > > So I'm fairly confident that I *should* have the 32 bit libs. I ran dumpbin > /headers against the lib referenced above, as well as it's release > counterpart, and what I found is that the collada debug lib above is 64bit > and the release version is 32bit. > > So, next I reconfigured my MSVC++ 2013 IDE to do a release build. That one > quit with the following error: > > 136> Creating library > C:/Users/xxx/Documents/projects/blender-build/bin/Release/blender-app.lib and > object > C:/Users/xxx/Documents/projects/blender-build/bin/Release/blender-app.exp > 136>libjack.lib(JackClient.obj) : error LNK2019: unresolved external symbol > "public: static void __cdecl std::_String_base::_Xran(void)" > (?_Xran@_String_base@std@@SAXXZ) referenced in function "public: class > std::basic_string,class > std::allocator > & __thiscall std::basic_string std::char_traits,class std::allocator >::erase(unsigned > int,unsigned int)" > (?erase@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAEAAV12@II@Z) > 136>libjack.lib(JackTools.obj) : error LNK2001: unresolved external symbol > "public: static void __cdecl std::_String_base::_Xran(void)" > (?_Xran@_String_base@std@@SAXXZ) > 136>libjack.lib(JackClient.obj) : error LNK2019: unresolved external symbol > "public: static void __cdecl std::_String_base::_Xlen(void)" > (?_Xlen@_String_base@std@@SAXXZ) referenced in function "protected: bool > __thiscall std::basic_string,class > std::allocator >::_Grow(unsigned int,bool)" > (?_Grow@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@IAE_NI_N@Z) > 136>libjack.lib(JackTools.obj) : error LNK2001: unresolved external symbol > "public: static void __cdecl std::_String_base::_Xlen(void)" > (?_Xlen@_String_base@std@@SAXXZ) > 136>C:\Users\xxx\Documents\projects\blender-build\bin\Release\blender-app.exe > : fatal error LNK1120: 2 unresolved externals > > I'm embarrassed to admit my C++Fu isn't strong enough to understand what's > wrong here! I could probably try a build without Jack (that's what I'll try > next) but I figured I'd ask folks here in case there's a fix. > > For whatever it's worth, I was playing with some fixes for COLLADA import. I > havent had that many problems on the Linux side, but I moved to Windows since > I'm working on this concurrently with a Unity3D project I'm playing with. > > Thanks! > > jonbitzen > > ___ > 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] Multiview branch, status update
Hi, As of today, Multi-View is mostly working as supposed. It should go to master as soon as it gets the 'go' from other developers. Meanwhile testers are once again welcome. Fresh builds: Linux x86_ 64: http://goo.gl/Tq3uCg OSX x86_64: http://goo.gl/R7DDia Win 64: http://goo.gl/GH6PNj The patch is here: https://developer.blender.org/D914 but the work can be built directly from the 'multiview' branch. I know some artists are already using it for real production work. This is really important, and I'm counting on you to report bugs (you can do it directly to my email or in the patch page). Main missing todos: * internal code changes to address missing review suggestions * usability design for sequencer/compositor to quickly edit one view at a time * best communicate to the user the stereo fullscreen modes * usability design: we may need to add a 'Single View' option for Image/Movie strips Anyways, there are other small ones, but those are to illustrate the current state. Apart from some of the 'internal code changes to address missing review suggestions', the other items can be done after the code land in master as well. Thanks, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Multi-View (Stereo 3D) is in Master \o/
Hi, I thought it was worth mentioning it ;) Release log and (eventual) bug report instructions: https://developer.blender.org/rBd5f1b9c222e03f2e4994171ad9df8c1c4f21 Thanks everything for the support, help, tests, reviews, commits, ... Really, that was a fun ride. Have a great one, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Multi-View (Stereo 3D) is in Master \o/
Hm something I forgot to mention on the release log: Quadbuffer support is pending until a developer with a quadbuffer-friendly graphic board and some understanding of OpenGL steps in to help debugging this. At the moment the page-flip mode is commented in the RNA. (rna_scene.c, look for S3D_DISPLAY_PAGEFLIP) The cards that support QUADBUFFER are the ones listed as "Professional, flicker free, stereo through the on board stereo connector": http://www.nvidia.com/object/quadro_pro_graphics_boards.html Basically we use the same method for the BGE Quadbuffer stereo. So if your card can display active stereo from a BGE file it should be eligible for this. This should just be working, but it's really hard to debug without the hardware at hand. (and thanks Jonathan ;) ) Cheers, Dalai ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Latest release build 2.74 Installer seen as virus by Webroot SecureAnywhere
Out of curiosity, do you have the same issue with a build from builder.blender.org or only when the installer is involved? On Apr 6, 2015 17:58, "Matthew Gayton" wrote: > Greetings, > > My apologies in advance if I am sending this to the wrong area, but as it > isn't really a bug I figure I would try here first. > > I have been using Blender for years and updating with the Windows 64 > release build as they are posted. However, this current one, 2.74 installer > for Win 64 systems is seen as a virus, with SecureAnywhere stating that it > has found *W32.Adware.Somoto* and immediately quarantining the executable. > I am downloading from https://www.blender.org/ > > Just though someone there should know. > > -Matthew > ___ > 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] mingwin libs missing ImfPartHelper.h file
Hi, The following lib folders are missing the file ImfPartHelper.h : mingw32 mingw64 mingw64_gcc49 For now we can just copy the file from any of the windows* lib folders: https://svn.blender.org/svnroot/bf-blender/trunk/lib/win64/openexr/include/OpenEXR/ImfPartHelper.h Thanks, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.75 RC1 release AHOY!
"Also please note Git is considered frozen for until all the builds are up (approx ~24hrs from now on). No commits are allowed to the master branch for until unfreeze message is sent t this ML (expect this tomorrow afternoon-ish)." Apparently I oversaw this email and commited a small error message fix in master. Sorry about that, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2015-06-10 12:55 GMT-03:00 Sergey Sharybin : > Hi, > > We've switched to bcon5 today which means two things: > > 1. Only crucial fixes are allowed in the master branch > 2. We're doing RC1 builds > > Information for platform maintainers: > > - Branch: blender-v2.75-release > - Branch hash: bff8b5ddad29e2ba5b2a6b92e640870e45466d1d > - Locale hash: da05fa08d4e80a634a91a82f211589587f9169bc > - Addons hash: fe47d3d49371b03691774ba3b915c5c047876ab9 > > Suggested name: blender-2.75-rc1- > > Thing to test: there should be now python binary be included into the > archive. In order to test this you can check bpy.app.binary_path_python in > the python console. > > Usual reminder: it is a REAL release candidate. Meaning, if we do a fix, we > backport it to the branch and do another RC. If no fixes are to be > backported (or if they're really tiny small) we do final release. > > Also please note Git is considered frozen for until all the builds are up > (approx ~24hrs from now on). No commits are allowed to the master branch > for until unfreeze message is sent t this ML (expect this tomorrow > afternoon-ish). > > > Thanks everyone for the work! :) > > -- > With best regards, Sergey Sharybin > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender developers meeting notes - July 5, 2015
> Two big bugs were fixed that deserve in the release. (...) and one bug to > browse passes in render buffers. I was under the impression this was not fixed yet - I'm assuming you were referring to https://developer.blender.org/T45290. I was planning to address this on Monday anyways. -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2015-07-05 12:31 GMT-03:00 Ton Roosendaal : > Hi all, > > Here are the notes from today's meeting in irc.freenode.net #blendercoders. > > 1) Release update? > > - Meeting agrees on making an 'a' update this week. > Two big bugs were fixed that deserve in the release. One bug prevented GE > from running, > and one bug to browse passes in render buffers. > > 2) Targets for 2.76 > > - Bastien Montagne suggests to stick to plan (release in a month) and focus > on a stable > release. We'll check with every release target project how well it goes. > > - Open Subddiv: still possible to go in. > > - OpenVDB: Kevin Dietrich will be first working on VDB support for our > existing caches, > and then work on (cycles) rendering. The latter might not make it for 2.76. > > Interesting docs from Kevin: > > http://wiki.blender.org/index.php/User:Kevindietrich/OpenVDBRendering > http://wiki.blender.org/index.php/User:Kevindietrich/OpenVDBSmokeExport > > And a proposal for a volume primitive: > http://wiki.blender.org/index.php/User:Kevindietrich/OpenVDBVolumePrimitive > > 3) Other projects > > - Gooseberry branch migration: still pending docs and design proposals. > > - Campbell Barton will work (aligned with Viewport project) on a Derivedmesh > redesign. > This to stop using old (pre-bmesh) face data for display, and use a more GPU > friendly data > format for tessellation. > > Laters, > > -Ton- > > > Ton Roosendaal - t...@blender.org - www.blender.org > Chairman Blender Foundation - Producer Blender Institute > Entrepotdok 57A - 1018AD Amsterdam - The Netherlands > > > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender developers meeting notes - July 5, 2015
ok T455290 fixed, please include 6a132aa6 and 93608e4f in 2.75a Now if only we could fix the multiview/freestyle pending issues in time ;) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Blender and Oculus - Food for Thought
Hi there, I've been pondering on how to get proper Oculus support in Blender "viewport", and it came down to the ideas presented here: http://www.dalaifelinto.com/?p=1108 Basically, I propose we expand our Blender/Game Engine API with the following: * Allow off-screen rendering straight to a FBO bind id with custom OpenGL matrices * BGL extended to support glBindFramebuffer amount other required GL functions * BGE Video Texture ImageRender to support FBO rendering and custom OpenGL matrices That should allow for not only oculus but any shader-based HMD (Head Mounted Display) to use Blender (or rather, to have an addon written to support it). Any thoughts on that? Can anyone come up with a different design to address that? (in the link above I explain why I think a Python approach is preferable over a deeper C integration between Blender and the Oculus SDK). Thanks, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender and Oculus - Food for Thought
Hi Jacob, > offscreen rendering is esential for fast 2d effects as well? Speed aside, offscreen rendering allows for quality you won't get otherwise. If you are counting relying on warping the acquired data, offscreen allows you to work with an original higher resolution buffer (e.g., similar to what the BGE does in the fulldome mode with warp meshes). So speed is not even the point here. Apart from that, using FBO allows you to hand out the buffer to the SDK, without having to worry about implementing distortion shaders yourself. > also, how do we get screen space AO and screen space reflections? something > similar? Such off-screen rendering routine should support any of the fancy viewport effects Blender now has. In fact as part of the function arguments we should probably be able to set specific viewport settings (render only, ao, ...). Cheers, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2015-09-18 15:09 GMT-03:00 Jacob Merrill : > offscreen rendering is esential for fast 2d effects as well? > > also, how do we get screen space AO and screen space refelctions? > something similar ? > On Sep 18, 2015 10:05 AM, "Dalai Felinto" wrote: > >> Hi there, >> >> I've been pondering on how to get proper Oculus support in Blender >> "viewport", and it came down to the ideas presented here: >> http://www.dalaifelinto.com/?p=1108 >> >> Basically, I propose we expand our Blender/Game Engine API with the >> following: >> >> * Allow off-screen rendering straight to a FBO bind id with custom >> OpenGL matrices >> * BGL extended to support glBindFramebuffer amount other required GL >> functions >> * BGE Video Texture ImageRender to support FBO rendering and custom >> OpenGL matrices >> >> That should allow for not only oculus but any shader-based HMD (Head >> Mounted Display) to use Blender (or rather, to have an addon written >> to support it). >> >> Any thoughts on that? Can anyone come up with a different design to >> address that? >> >> (in the link above I explain why I think a Python approach is >> preferable over a deeper C integration between Blender and the Oculus >> SDK). >> >> Thanks, >> Dalai >> -- >> blendernetwork.org/dalai-felinto >> www.dalaifelinto.com >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers >> > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender and Oculus - Food for Thought
Hi, I finished all the required changes in Blender (not in the BGE) for viewport offscreen rendering: https://developer.blender.org/D1533 I will share a video of this working once I plug it with a HMD, but for a quick preview, this is what is now possible: http://dalaifelinto.com/ftp/tmp/fbo.jpg (via Python I'm rendering two new views, with custom opengl matrices into two FBOs, and visualizing them back on top of the viewport). I hope this can get reviewed and make its way into Blender 2.77. Cheers, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2015-09-18 15:52 GMT-03:00 Dalai Felinto : > Hi Jacob, > >> offscreen rendering is esential for fast 2d effects as well? > > Speed aside, offscreen rendering allows for quality you won't get > otherwise. If you are counting relying on warping the acquired data, > offscreen allows you to work with an original higher resolution buffer > (e.g., similar to what the BGE does in the fulldome mode with warp > meshes). So speed is not even the point here. > > Apart from that, using FBO allows you to hand out the buffer to the > SDK, without having to worry about implementing distortion shaders > yourself. > >> also, how do we get screen space AO and screen space reflections? something >> similar? > > Such off-screen rendering routine should support any of the fancy > viewport effects Blender now has. In fact as part of the function > arguments we should probably be able to set specific viewport settings > (render only, ao, ...). > > Cheers, > Dalai > -- > blendernetwork.org/dalai-felinto > www.dalaifelinto.com > > > 2015-09-18 15:09 GMT-03:00 Jacob Merrill : >> offscreen rendering is esential for fast 2d effects as well? >> >> also, how do we get screen space AO and screen space refelctions? >> something similar ? >> On Sep 18, 2015 10:05 AM, "Dalai Felinto" wrote: >> >>> Hi there, >>> >>> I've been pondering on how to get proper Oculus support in Blender >>> "viewport", and it came down to the ideas presented here: >>> http://www.dalaifelinto.com/?p=1108 >>> >>> Basically, I propose we expand our Blender/Game Engine API with the >>> following: >>> >>> * Allow off-screen rendering straight to a FBO bind id with custom >>> OpenGL matrices >>> * BGL extended to support glBindFramebuffer amount other required GL >>> functions >>> * BGE Video Texture ImageRender to support FBO rendering and custom >>> OpenGL matrices >>> >>> That should allow for not only oculus but any shader-based HMD (Head >>> Mounted Display) to use Blender (or rather, to have an addon written >>> to support it). >>> >>> Any thoughts on that? Can anyone come up with a different design to >>> address that? >>> >>> (in the link above I explain why I think a Python approach is >>> preferable over a deeper C integration between Blender and the Oculus >>> SDK). >>> >>> Thanks, >>> Dalai >>> -- >>> blendernetwork.org/dalai-felinto >>> www.dalaifelinto.com >>> ___ >>> Bf-committers mailing list >>> Bf-committers@blender.org >>> http://lists.blender.org/mailman/listinfo/bf-committers >>> >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] git issue after push (mail sending aborted)
Hi, I just get this error back from Blender's git server: """ Writing objects: 100% (7/7), 707 bytes | 0 bytes/s, done. Total 7 (delta 6), reused 0 (delta 0) remote: sendmail: fatal: config variable inet_interfaces: host not found: git.blender.org remote: *** Error while generating commit email remote: *** - mail sending aborted. remote: Traceback (most recent call last): remote: File "hooks/post-receive", line 22, in remote: blender_multimail.run_as_post_receive_hook(environment, mailer) remote: File "/data/git/mailhook/blender_multimail.py", line 2297, in run_as_post_receive_hook remote: push.send_emails(mailer, body_filter=environment.filter_body) remote: File "/data/git/mailhook/blender_multimail.py", line 2278, in send_emails remote: mailer.send(rev.generate_email(self, body_filter), rev.recipients) remote: File "/data/git/mailhook/blender_multimail.py", line 1379, in send remote: p.stdin.writelines(lines) remote: IOError: [Errno 32] Broken pipe To g...@git.blender.org:blender.git 11c00ca..3bc5399 master -> master """ I'm not sure if it's something to be aware of. But I thought it was worthy mentioning it. Thanks, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Some Ideas for a Blender Plugin System
Hi, I'm missing the main point here which would be, what is the advantage of a C/C++ plugin system over the current Python addon interface? I'm currently developing an addon which relies on an external C++ SDK. I got things working with ctypes and C API. It works pretty fine. Cheers, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2015-11-03 10:59 GMT-02:00 Martin Felke : > Hi, today i wrote down a couple of more thoughts regarding a plugin > system. As said earlier, those serve only as discussion starting points > and are not meant yet as design principles made out of cement. :) > > Fat VS Slim Core > > - currently we have a fat core which contains all functionality > as monolith > - hard to extend and to maintain because it might be everything depends > on everything else > - idea: a slim, "bootloader like" core, which handles modules and > plugins registration and deregistration and serves as API Hub (of > existing modules) > - modules are not standalone, they communicate via a central core API > Hub so they need the core as well > - this way the core can track module APIs and provide a fallback (as > in exception handler) for missing code / functions (if module or > plugin is not present) > > Modules VS Plugins > -- > - need to distinguish between logical code separation (module) and > "physical" separation (plugin, as in shared library or dll) > - group existing core functionality to modules (like, an editor could > be a module, or even a modifier) > - base modules can be provided by "base" plugins, and extension modules > by external plugins > - plugins can provide parts of modules, entire modules or multiple > modules (like nodes maybe, modifiers, new editors, or extensions to > editors) > > Dependencies > > - do we want to have inter-plugin dependencies ? For a slim core > approach this might be necessary, if plugin A provides a module or > part where plugin B 's code depends on > - else base modules should be moved / kept in the core, so everyone has > a minimum set of functionality without needing to use plugins > - but in general, should plugin code only use Core API (the Hub ?) > would be better than "directly" accessing other plugins code, because > the core might provide the error fallback in case a plugin isnt > present > > Plugin properties > - > - should be "hotpluggable", addable, removable during runtime > - core needs to take care of disabling all related functionality when > module is unloaded (closing editor, saving for example) > - each plugin needs an unique identifier of some kind, and versioning > info > - if basis modules are in a plugin, this plugin needs to be flagged as > important or official or so > - plugins could be classified by their purpose, like provides Module X, > extends Module Y, replaces Module Z, removes Module W > > > ___ > 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] Blender developers meeting notes, November 29, 2015
Hi, A small question regarding the OpenGL project: > "Work now progresses on removing 'immediate mode' calls (glBegin, glEnd), and on defining how to use shaders everywhere" How does that affect Python addons? Can immediate mode still be used via bgl? Or it's not recommended (not guaranteed to work in all OSs)? Thanks, Dalai On Nov 29, 2015 14:02, "Ton Roosendaal" wrote: > Hi all, > > Here are the (short) notes of today's meeting in irc.freenode.net > #blendercoders > > 1) Work on 2.77 > > - Project page with planning: > http://wiki.blender.org/index.php/Dev:Doc/Projects > (As agreed on, 2.77 has not been scheduled yet) > > - Bastien Montagne reports good progress on library referencing > improvements: > > http://code.blender.org/2015/11/test-build-live-reloading-relocating-of-libraries/ > (Might go to 2.77 if testing goes well) > > 2) Other projects and 2.8 preparations > > - Migrating to OpenGL 2.1 has started. > > - We're now officially on 2.1 minimal! Meaning that the old 'extension' > (compatibility) API calls > are gone. Work now progresses on removing 'immediate mode' calls (glBegin, > glEnd), and on defining > how to use shaders everywhere. > > - Mike Erwin will write (today!) a wiki page - to log and report on OpenGL > work, also as dashboard to > give people insight what they can do to help. Code upgrading is fun work > for which a lot of people > can contribute. Check the wiki project page later today for the correct > page link. > > - If you want to get involved: join the coders IRC channel, or the > viewport list: > http://lists.blender.org/mailman/listinfo/bf-viewport > > - After the meeting, a group discussed key aspects of the work ahead... > viewport team members so-far: > Mike Erwin, Antony Ryakiotakis, Brecht van Lommel, Inez Almeida, Martijn > Berger. Thomas Dinges is > available to help. Jason Wilkins is inactive currently but welcome to join! > > Laters, > > -Ton- > > > Ton Roosendaal - t...@blender.org - www.blender.org > Chairman Blender Foundation - Producer Blender Institute > Entrepotdok 57A - 1018AD Amsterdam - The Netherlands > > > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Cycles-Bake: passes type revamp
Hi, I've been working in some changes on the way Cycles Baking handle the combined and the light passes. You can find the current design and discussions in the patch thread [1]. Besides what is there presented, Brecht proposed to unify diffuse and subsurface baking. This way, it would be easier to bake the view-independent passes at once. Does anyone have something to say on this? I wonder if the patch as it is would help for PBR materials, and if it makes sense for the users to keep diffuse and subsurface separated. [1] - https://developer.blender.org/D1674 Thanks, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Cycles-Bake: passes type revamp
Hi, I've been giving it more thought, and I would rather hold on the subsurface proposed change, and focus on getting the main revamp into master. Even if we assume the performance would stay the same for diffuse baking when no subsurface. How to merge the diffuse and subsurface colors? What is the point of baking Diffuse + Subsurface passes together as weight only, if we won't be able to get the color to multiply them to? Considering that you can bake the colored diffuse and subsurface passes with the combine pass, I think it's fine. @Yury: I don't think fixing antialiasing in baking is a 'small thing'. That's why it has never been tackled. But if I have a chance I will discuss this with Brecht and see how would he propose addressing this. Maybe it's simpler than I thought. Cheers, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2015-12-23 13:14 GMT-02:00 Yury Baranov : > Hi. First of all, thank you for all things you did for Blender. > I don't know if my suggestion is related to your task, but currently Cycles > baking is missing antialiasing in everything: OSL shaders, normals baking > and Combined baking, of course. I have switched my texture development > pipeline from AD software to Blender completely, and this issue is > harrasing me a lot ATM. It would be great if improving this small thing > will be in your todo list. Thanks again! > > 2015-12-23 7:11 GMT+03:00 Dalai Felinto : > >> Hi, >> >> I've been working in some changes on the way Cycles Baking handle the >> combined and the light passes. You can find the current design and >> discussions in the patch thread [1]. >> >> Besides what is there presented, Brecht proposed to unify diffuse and >> subsurface baking. This way, it would be easier to bake the >> view-independent passes at once. >> >> Does anyone have something to say on this? I wonder if the patch as it >> is would help for PBR materials, and if it makes sense for the users >> to keep diffuse and subsurface separated. >> >> [1] - https://developer.blender.org/D1674 >> >> Thanks, >> Dalai >> -- >> blendernetwork.org/dalai-felinto >> www.dalaifelinto.com >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers >> > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] New glLineWidth Policy
> Just thinking there might be a way to guarantee initial width of 1.0 for addons only. We could (easily even) set the opengl states back to their "reset" values prior to calling the pre/post drawing callbacks. In fact I think we *should* do this, if we can't guarantee line width 1.0. -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2016-02-18 22:37 GMT-02:00 Mike Erwin : > Brecht Van Lommel wrote: > >> Mike Erwin wrote: >> > For 2.77 what is left to fix? If it's a small set I say fix those and >> keep >> > the change. (but of course I would say that) It gets us closer to clean >> GL >> > usage. >> >> But it also breaks addon backwards compatibility, which I don't think >> is intentional for 2.77? >> > > Of course not :) At this point this is the big unknown, since it's > impossible to review all addon code. Addons must go through the Python > interface right? Just thinking there might be a way to guarantee initial > width of 1.0 for addons only. > > Up to now there have been multiple fixes based on bug reports from >> users. If we rely on just bug reports then there's likely more corner >> cases that are still broken. If we keep these commits then I think >> someone should go over all GL_LINE drawing and verify that it's >> properly setting the line widths. > > > Sign me up for that. A second or third pair of eyes would help too. > > -- Mike > ___ > 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] pushed wrong branch to git.blender.org
but removed it already, sorry about the noise. -- blendernetwork.org/dalai-felinto www.dalaifelinto.com ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] New committer -- Germano Cavalcante!
That's nice, snapping can indeed use a lot of love in Blender ... welcome Germano (and #GoTeamBrazil ;) -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2016-07-14 4:47 GMT-03:00 Sybren A. Stüvel : > Cool, welcome mano-wii :) > > On Thu, Jul 14, 2016 at 01:55:44PM +1000, Campbell Barton wrote: >> Hi, >> >> Those who read commit logs will be aware of Germano Cavalcante's (aka >> mano-wii) >> work on improving snapping code, with quite a few patches already in master. >> He's been added as a committer to continue development. >> >> He's work has revolved around optimizing ray casts, >> using BVH spatial search to optimize screen-space snapping and general >> BVH improvements. >> >> Welcome aboard! >> >> -- >> - Campbell >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> https://lists.blender.org/mailman/listinfo/bf-committers > > -- > Sybren A. Stüvel > > https://cloud.blender.org/ > https://stuvelfoto.nl/ > https://stuvel.eu/ > > ___ > 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] Patch : OpenGL urls updated in doc
Hi Julien, Patch tested and committed ;) thanks for the work Campbell updates the pydocs online regularly. The changes will automatically be online. Cheers, Dalai 2012/5/1 Julien Duroure > Hi all, > > I submit a patch [1] updating opengl urls ( see simple todo [2] ). > > Regards, > > Julien > > [1] > > http://projects.blender.org/tracker/index.php?func=detail&aid=31216&group_id=9&atid=127 > [2] > > http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo/Simple_Todos > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [46256] trunk/blender/source/tools/GL: GL Tools
> it's fine to finish it up before consolidating the files, for future cases
The other alternative is to hold it a bit and commit to the gsoc branch.
Cheers,
Dalai
2012/5/4 Campbell Barton
> fine to finish it up before consolidating the files, for future cases
> like this though - I prefer not to have 100's of files added to svn
> only to be removed later on (clogs up SVN logs/history).
>
> Of course refactoring our opengl usage is important - don't mean to
> diminish your work here.
>
> On Fri, May 4, 2012 at 10:29 PM, Jason Wilkins
> wrote:
> > Yes, that is a good idea. I just do not want to break it before I get
> > it working.
> >
> > Also, right now it is much easier for me to just dump some C header
> > file or spec that I copy pasted than to worry about making everything
> > into pretty JSON style code. I'll see what I can do this weekend to
> > consolidate the data.
> >
> > I actually did not realize there are 550 extensions in the extensions
> directory.
> >
> > On Fri, May 4, 2012 at 6:44 AM, Campbell Barton
> wrote:
> >> Really don't think this should be added with each function as a file
> (over 600!)
> >>
> >> This data could be a dictionary ('func -> data' as 'key: value')
> >> pickled into one file.
> >>
> >> On Fri, May 4, 2012 at 12:42 PM, Jason Wilkins
> >> wrote:
> >>> Revision: 46256
> >>>
> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=46256
> >>> Author: jwilkins
> >>> Date: 2012-05-04 02:42:45 + (Fri, 04 May 2012)
> >>> Log Message:
> >>> ---
> >>> GL Tools
> >>>
> >>> glreport.py now lists several more categories
> >>>Toolkits like GLUT and GLU
> >>>System librarys GLX, AGL, and WGL
> >>>ES 1.1 (Common and Common-Light)
> >>>ES 2.0
> >>>Deprecated 1.x functions
> >>>
> >>> Several other bug fixes.
> >>>
> >>> OpenGL 1.0 and 1.1 enumerations have not been added to VERSION_1_0 and
> VERSION_1_1 files yet.
> >>>
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Socket storage and backwards compatibility
Hi, > What are the ideas about backwards compatibility of the image node/file output node? The 'File Output' seems to be pretty backward compatible. The one in trunk seems like a subset of the one in Tiles. What is wrong with creating an output node set with the scene parameters (image type, compression, ...)? Cheers, Dalai 2012/5/6 Jeroen Bakker > Hi All, > > We have some issues with the new image node. Users are creating files > with trunk and read them using tiles. And it crashes :) > > for example: > * > > http://projects.blender.org/tracker/index.php?func=detail&aid=31329&group_id=9&atid=524 > * > > http://projects.blender.org/tracker/index.php?func=detail&aid=31300&group_id=9&atid=524 > * > > http://projects.blender.org/tracker/index.php?func=detail&aid=31301&group_id=9&atid=524 > > These 3 bugs are related to the fact that the new image node, using > socket storage in stead of the index of the socket. This issue can be > solved after merging. Just as the new file output node. > > Question remains; > What are the ideas about backwards compatibility of the image node/file > output node? > > Greetings, > Jeroen & Monique > > ___ > 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] NodeTree.nodes.new() vanished?
Hi there,
Did any of the recent changes (tile/node frame/node tweaks) change the way
we can add new nodes?
I used (until 2ish weeks ago) to do:
bpy.context.scene.use_nodes = True # this still works
bpy.context.scene.node_tree.nodes.new('IMAGE')
but now I get:
AttributeError: 'bpy_prop_collection' object has no attribute 'new'
*edit: I updated tile here and it seems the problem comes from there.*
Thanks,
Dalai
www.dalaifelinto.com
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Invalid ArtifactID: tracker: [bf-blender-Game Engine][31787]
Hi, The link to this tracker entry gives an 'Artifact: Invalid ArtifactID'. Did the entry get removed? http://projects.blender.org/tracker/?func=detail&atid=306&aid=31787&group_id=9 (also I can't see how this is a BGE bug, but maybe the tracker file shows why) Thanks, - Dalai -- Forwarded message -- From: Date: 2012/6/11 Subject: [bf-blender-Game Engine][31787] OSX cursor shape wrong when passing outside Blender workspace window. To: nore...@projects.blender.org Game Engine item #31787, was changed at 2012-06-11 07:00 by Ton Roosendaal You can respond by visiting: http://projects.blender.org/tracker/?func=detail&atid=306&aid=31787&group_id=9 Or by replying to this e-mail entering your response between the following markers: #+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+ (enter your response here, only in plain text format) #+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+ Status: Open Priority: 3 Submitted By: Steve Turnbull (zavigny) Assigned to: Nobody (None) Summary: OSX cursor shape wrong when passing outside Blender workspace window. Category: None Status: New Duplicates: Initial Comment: A very minor bug. The cursor in OSX shows the change from the Arrow to the SplitVCursor correctly when crossing window boundaries, but incorrectly remains the SplitVCursor rather then the Arrow when passing outside of Blenders workspace window. See Attachment. -- Comment By: Ton Roosendaal (ton) Date: 2012-06-11 11:49 Message: Moved from Blender 2.6 Bug Tracker to Game Engine -- You can respond by visiting: http://projects.blender.org/tracker/?func=detail&atid=306&aid=31787&group_id=9 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Improvement of BGE rendering for CAVE systems
Hi Damien, I remember the patch, but I also remember that you were gathering more feedback before pushing the final version of the patch. (from the tracker) "for the moment, I will wait for feebacks from users from our lab and other Virtual Environment [...] before modifying the patch and resubmit it to this blender patch page." Is everyone happy with the current status of it? Regards, Dalai 2012/6/11 Damien Touraine > Hi, > > I remind you a patch we would like to integrate inside blender : > > http://projects.blender.org/tracker/?func=detail&atid=127&aid=29161&group_id=9 > > I would like to know if somebody can review our patch. > > Regards > Damien Touraine > > -- > > Damien TOURAINE - Ingénieur de Recherche CNRS, LIMSI-CNRS > Groupe de RV&A "VENISE", (http://www.limsi.fr/venise/) > Bat. 508, Universite Paris-Sud 91403 Orsay cedex - +33 1 69 85 81 64 > > > ___ > 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
