Re: [Bf-committers] Towards C++11
Have been doing an initial test (arch linux 64bit, GCC 4.9), and looks like it's working alright with just a few minor tweaks needed. This commit enables C++11 in the depsgraph_refactor branch and could be ported cleanly to master: https://developer.blender.org/rB93e4e1ce3434ea680c6ac69fab68303d09d0d11b Note: some static type tests in BLI_utildefines have been disabled for C++ here, lengthy explanation in the commit comments. Other compilers (clang, xcode, msvc) will need to be tested of course, and some external libs need to be verified for compatibility, but generally it looks quite promising. On Sat, Jun 7, 2014 at 2:16 PM, Jens Verwiebe wrote: > Regarding OSX, it should plain work. > > I use c++11 based projects since a while without any issues recognized. > Anyway apple clang is based on common clang svn, just with some specials > addedas > for example xcode integration etc. .. > > Jens > > > > > Am 07.06.2014 um 12:04 schrieb Lukas Tönne : > > > It's great to see that C++11 has general support. It would be really > > helpful in the depsgraph to deal with closures, among other places. > Without > > this we'd have to either tediously backport boost implementation (but why > > reinvent the wheel?), or use lots of bloated cumbersome type definitions > > and C style void* casting (error prone, hides logic). So i'm really happy > > that there are no big showstoppers so far. > > > > > > On Sat, Jun 7, 2014 at 11:38 AM, Martijn Berger < > martijn.ber...@gmail.com> > > wrote: > > > >> @Campbell I am pretty sure give how hard Apple is pushing out new > releases > >> and given how many people upgrade that we can just assume an llvm/clang > >> 3.0+ feature set for c++11. > >> > >> I think we should also do this analysis for C99 support and C11 support. > >> There are some other projects out there that use C++11 features (clang > is > >> one) and they have made comprehensive analysis of what features they can > >> and do use. > >> > >> There are some things we can use anyway like noexcept provided we use it > >> like the QT people use it so the code does not require a c++11 compiler > but > >> you do get some benefit from compiling with one ( > >> http://qt-project.org/doc/qt-5/qtglobal.html#Q_DECL_NOEXCEPT) > >> > >> I think getting a sort of caniuse.com for c/c++ language features on > the > >> wiki would be good way forward. > >> > >> > >> > >> > >> > >> > >> On Sat, Jun 7, 2014 at 11:11 AM, Campbell Barton > >> wrote: > >> > >>> General +1 to take advantage of C++11 where appropriate, > >>> AFAICS OSX needs some investigation?, otherwise we're close to being > >>> able to support it. > >>> > >>> > >>> @Tom M: I'm not concerned with static checking tools, mainly because > >>> using C++11 in a few places won't suddenly make static checkers fail > >>> on the rest of our code, eventually they will get updated too. > >>> > >>> Coverity has support: > >>> https://communities.coverity.com/docs/DOC-1571 > >>> clang-static-analyser didn't work well for me last I checked with C++, > >>> but it might have improved in last year or so. > >>> > >>> > >>> @Ichthyo: Not being able to build Blender on older Linux isnt such a > >>> big deal since Blender can still run on them, if its important they > >>> can get a new compiler (I did this on a CentOS server, compiling a > >>> newer GCC/Clang isnt that big of a deal). > >>> > >>> > >>> @Jeffrey H: C++11 doesn't raise hardware requirements. > >>> > >>> On Sat, Jun 7, 2014 at 3:18 PM, Jeffrey H > > >>> wrote: > What about older hardware? I don't know much about C++11, but I would > imagine it takes advantage of newer processor instruction sets and I > >> know > new compilers do the same. Would Blender still run on, say, an old > >>> Pentium > 4? The reason I ask is simply because a large number of users use > >> Blender > because it's able to run on the proverbial toaster, where Maya and > >> other > programs cannot. Is this actually an issue or am I just making stuff > >> up? > > > On Fri, Jun 6, 2014 at 11:39 AM, Ichthyostega > >>> wrote: > > > Am 06.06.2014 17:54, schrieb Sergey Sharybin: > >> Why it might be useful? > > > >> C++11 brings some neat syntax and STD library extensions. > > > > ..plus the benefit you can get from using functors / closures wisely. > > > > > > > > Downside is that we have to cut off some platforms / compilers. > > > > Basically we need GCC >= 4.7 and Clang >= 3.0 > > > > And anything below that will not be supported anymore. > > Like RedHat Enterprise Linux. :-P > > > > > > Sounds like something for Blender 2.8.x > > > >--Ichthyo > > > > > > > > > > > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > http://lists.blender.org/mailman/listinfo/bf-committers > > > > > > -- > Je
[Bf-committers] replacement for DXF-importer script
hi, a new DXF-importer based on "dxfgrabber" library is under development by Lukas Treyer: https://bitbucket.org/treyerl/io_import_scene_dxf/overview He has been working on it since December and with minimal support from me he was able to complete it quite well. I am going with him over bugfix iterations and can confirm it very good level of completeness and stability. Lukas is going to continue the development and support bugfixing in the future too. This is great! I can recommend his version as replacement for the official (very limited) importer for the next Blender release (2.71) and I will upload it to main repository if you agree :) DXF importer manual page on blender wiki will be updated shortly. thanks migius ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] replacement for DXF-importer script
Hi, Yes, he posted a patch report about it (https://developer.blender.org/T40487), I yet have to have a look at it. But in any case, I would not replace it before 2.71 - better to get an old, well tested version, even if it has many known issues, than a brand new code put in master one week before a release. We should rather make the switch just after 2.71, this way we have two months of testing at least. :) Cheers, Bastien Le 08/06/2014 13:33, Remigiusz Fiedler a écrit : > hi, > a new DXF-importer based on "dxfgrabber" library is under development > by Lukas Treyer: > https://bitbucket.org/treyerl/io_import_scene_dxf/overview > > He has been working on it since December and with minimal support from > me he was able to complete it quite well. I am going with him over > bugfix iterations and can confirm it very good level of completeness > and stability. > Lukas is going to continue the development and support bugfixing in > the future too. This is great! > I can recommend his version as replacement for the official (very > limited) importer for the next Blender release (2.71) and I will > upload it to main repository if you agree :) > DXF importer manual page on blender wiki will be updated shortly. > > thanks > > migius > ___ > 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] Blender developer meeting minutes, June 8, 2014
Hi all, Here are the notes from today's 1600 CEST meeting in irc.freenode.net #blendercoders. 1) Blender 2.71 release - Planning: we're now going to BCon4, release of a first Release Candidate is imminent, but might take 3-4 days or even longer. - Sergey Sharybin: two regressions were assigned to him, he will look into that. One is related to the switch from MSVC 2008 to 2013 (where OpenMP threading differs). This makes Blender factors slower for Windows users... - Bug tracker: open issues is down to 150. Not too bad. - Dalai Felinto: Cage Baking now has a better implementation: https://developer.blender.org/D547 Meeting agreed this should go to 'master' as soon as possible, but it also would require thorough testing. Any baking fans out there who can help? Connect with Dalai! - Campbell Barton will be working on a visual 'auto test' page on blender.org, which will display a grid of images which each represent a .blend file (renders, opengl views). If files crash it will show, but also a way to inspect stats, and see if it differs from the disired outcome. - Splash Committee - Dalai Felinto, Bastien Montagne, Mitchell Stokes - picked an awesome splash! Nobody will see this until it gets committed, as usual the last commit for a release. 2) Google Summer of Code - Jonathan deWerd made a Nurbs Tesselator overview: http://wiki.blender.org/index.php/User:Jjoonathan/NURBS_Tessellation_Survey We have to make decisions on design a.s.a.p. - help reviewing his work! - Jason Wilkins is getting momentum, and will present his final plan soon. It's a huge project, and he doesn't want to promise what can't be delivered. Everyone agrees it's too important to fail that way. Proposal for Midterm/Final deliverables will be presented soon. - All students were required to be in IRC since last week, at least some hours of every day they they work. This to improve interaction and get more people involved with them. 3) Other projects - Antonis Ryakiotakis is almost done with the C code for pie menus. Patch will be readay for 'master' as soon as the release has been out. - Ongoing iscussion: when will Blender support c++11? http://lists.blender.org/pipermail/bf-committers/2014-June/043691.html - Gooseberry Pilot development plans: a report was posted on the http://gooseberry.blender.org blog. Thanks! -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
Re: [Bf-committers] Track weight animation
Update for sake of completeness: - YES, you can currently *not* edit automation related to the MovieClipEditor in the usual action editors. But you can add and delete keyframes in the usual way in the GUI input fields. - NO, 2d-stabilisation related automation is indeed *properly played back* in VideoSequenceEditor and Compositor. Other issues had led me to wrong conclusions here. --Ichthyo ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Improving the 2D stabilization tool
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Update for sake of completeness - - patch will be reviewed by Sergej - - further discussion on VFX-List -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlOUkQAACgkQZbZrB6HelLLURACdFcFVtMDTfYCE4HJ84LUZLExm w5oAn0eeUJ3iZEu1KlcPl5w0zIu+fekE =LuYS -END PGP SIGNATURE- ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] "Spaceframes"
Ok, I have a new system that animates in the game engine, based on objects. So we have a value (time) assigned to each object, and a order, Then we use distance/time to move the animated object. So no matter where the space frame is, the object moves the distance. This could be usefully in a number of instances, Most of them involve dynamic animation. Example "reloading" 3 frames are in air(pull clip position and angle) and one spaceframe is parented to clip location on belt. Hand will reach clip no matter the rest of the players animated position. How would we go about making this user friendly and practical, as my current example only works in the game engine. I was also thinking you could do rotationDiff/time and scale/time ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Luminance Coefficients
While looking through Blender's code, I noticed that there were legacy hard coded values for luminance. These are hard coded values based on the sRGB and 709 primaries, as opposed to the particular color spaces a given OCIO configuration may have. This would lead to incorrect derivation of luminance if the reference space is not sRGB / 709. I decided to patch Blender to use the reference space coefficients listed in the OCIO configuration file, which is relatively straightforward. The coefficients are summoned per pixel, which would mean having a global structure useful to reference them, but I don't see a relevant place to store them. It would seem logical to store them on configuration loading, reloading, and potentially if a set coefficients call is made. Where and how does it make sense to store these values in Blender's architecture? With respect, TJS ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Luminance Coefficients
Hi, it depends on how you did the job. Perhaps this can be appended to my patch: developer.blender.org/D517 ? I also intended to do something in this area ;) Le 2014-06-09 02:37, Troy Sobotka a écrit : > While looking through Blender's code, I noticed that there were legacy hard > coded values for luminance. > > These are hard coded values based on the sRGB and 709 primaries, as opposed > to the particular color spaces a given OCIO configuration may have. This > would lead to incorrect derivation of luminance if the reference space is > not sRGB / 709. > > I decided to patch Blender to use the reference space coefficients listed > in the OCIO configuration file, which is relatively straightforward. > > The coefficients are summoned per pixel, which would mean having a global > structure useful to reference them, but I don't see a relevant place to > store them. > > It would seem logical to store them on configuration loading, reloading, > and potentially if a set coefficients call is made. > > Where and how does it make sense to store these values in Blender's > architecture? > > With respect, > TJS > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers [1] Links: -- [1] http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
