Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [53534] trunk/blender/build_files: Patch from Ejner Fergo: enhancements to install_deps.sh.
Hi again, I got RPM to compile with scons, by adding 'rt' in this scons config option: LLIBS = ['util', 'c', 'm', 'dl', 'pthread', 'stdc++', 'rt' ] I also forgot to mention yesterday another caveat compiling with scons: No OSL or OpenCOLLADA... couldn't get them to work :-/ Compiling with cmake works with all options on all tested distros. Was thinking of making a check for sudo on Arch as it is not default like on the other distros (unless you use something like ArchBang), but maybe not necessary since it is mentioned on the wiki that sudo is needed? On Thu, Jan 10, 2013 at 12:18 PM, Bastien Montagne montagn...@wanadoo.frwrote: Hee… I’m nearly a complete noob with those advanced linking topics :/ Regarding python under Ubuntu/debian, I already added another fields to CMake one or two months ago, as (future) py3.3 package under Debian also has split dirs, so now CMake has two different include dirs for python, old PYTHON_INCLUDE_DIR and new PYTHON_INCLUDE_CONFIG_DIR... As for Schro, fine with me to remove it, but don't bother making a patch for this, I’ll do it while applying your patch ;) On 10/01/2013 12:06, Sergey Sharybin wrote: Well, depends. If ffmpeg fails to compile and -rt doesn't help, then i'm currently don't have ideas. If ffmpeg compiles fine but blender fails, -lrt shall be added to blender's linker flags. On Thu, Jan 10, 2013 at 5:02 PM, Ejner Fergoejner...@gmail.com wrote: Hi Sergey, About -lrt option, I tried that (on ffmpeg configure line) but still couldn't get it to work. Maybe you or Bastien understand the issue better? I can remove schroedinger (don't know who used dirac anyway :P), can have a patch ready tomorrow maybe. Thanks! /Ejner On Thu, Jan 10, 2013 at 11:55 AM, Sergey Sharybinsergey@gmail.com wrote: From quick glance part related to NUMPY seems to be fine. Din't have Arch here to test tho. As per ubuntu, not sure that seemd to be working before? But why would they even split includes for multiarch, seems to be not smartest decision. Anyway, shouldn't be difficult to add multiarch includes detection i guess. For --all-static issue adding -lrt could help. But currently working from laptop where don't have virtual machines, so couldn't verify. Just side note: would say let's kick schro out. It's a bit of headache for this script.. Bastien, look fine for me. If you could do quick tests guess patch could be commited. On Thu, Jan 10, 2013 at 4:23 PM, Ejner Fergoejner...@gmail.com wrote: Hi again Sergey and Bastien! Well I kept hacking and testing the script, even if it will be replaced eventually. Hopefully it will help as a reference. Diff is here: http://www.pasteall.org/38680/diff There is now support for Arch Linux. NumPy is now an option. Able to compile without ffmpeg as well as cycles (seems some are interested in this). I also made the scons info useable for some systems (didn't really work before). Small fixes. What works: Arch build with cmake/scons and all options DEB build with scons What doesn't work: Ubuntu 12.10 with scons can't find the split python headers, needs: BF_PYTHON_INC = '/usr/include/python3.3m /usr/include/i386-linux-gnu/python3.3m' DEB with scons fails with --all-static (can't find libs that are directly referenced?) RPM with scons with/without --all-static, fails with: /usr/bin/ld: /opt/lib/ffmpeg/lib/libavdevice.a(v4l2.o): undefined reference to symbol 'clock_gettime@@GLIBC_2.2' /usr/bin/ld: note: 'clock_gettime@@GLIBC_2.2' is defined in DSO /lib/librt.so.1 so try adding it to the linker command line /lib/librt.so.1: could not read symbols: Invalid operation Hope you find it usefull. Best regards, Ejner On Fri, Jan 4, 2013 at 11:21 AM, Ejner Fergoejner...@gmail.com wrote: Ok, so you are saying numpy build and opencollada option should be removed again? Numpy is RC because that is the only thing that can build using python 3.3 In any case, it seems Bastien will port the script to python, so if you feel like reverting be my guest... On Fri, Jan 4, 2013 at 8:02 AM, Sergey Sharybin sergey@gmail.com wrote: Seems numpy would be enabled by default. I'm not sure it's indeed what shall be done: there're not so much people who really need numpy compiled by ibstall_deps.sh. Also, libraries compiling by this script should be considered stable and numpy used in the script is release candidate. As per script size i would prefer to keep only stuff needed for initial build of blender, don't try to support all possible configurations. Would make it much easier to maintain the script and check f it's working on all platforms easier. All the extra dependencies better be described in Building Blender section in our wiki. On Thu, Jan 3, 2013 at 9:35 PM, Bastien Montagne montagn...@wanadoo.fr
[Bf-committers] Color Correction Node - Lift
I'd like to point out that in Color Correction node we have some naming issues. Lift in all of the color correction tools do as follows: C - input value L - lift value R - resulting value R = (1-C) * L + C in Color Correction node Lift simply adds lift value to input color. I think we need to make a decision which color correction model to use. What Lift does right now is in fact called Offset. In my opinion we should either: 1. leave the current behavior of Lift, but rename it to Offset, or 2. change it to represent the real lift. I'd opt for second solution. Bartek Skorupa www.bartekskorupa.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Color Correction Node - Lift
Sorry for double message on the same topic: When analyzing behavior of Color Correction node I noticed that in fact all of the terms are messed up here. It seems that this node uses Offset/Gamma/Slope model. Therefore Gain also doesn't do what it says. What it does is SLOPE, not GAIN. Bartek Skorupa www.bartekskorupa.com On 11 sty 2013, at 16:27, Bartek Skorupa (priv) bartekskor...@bartekskorupa.com wrote: I'd like to point out that in Color Correction node we have some naming issues. Lift in all of the color correction tools do as follows: C - input value L - lift value R - resulting value R = (1-C) * L + C in Color Correction node Lift simply adds lift value to input color. I think we need to make a decision which color correction model to use. What Lift does right now is in fact called Offset. In my opinion we should either: 1. leave the current behavior of Lift, but rename it to Offset, or 2. change it to represent the real lift. I'd opt for second solution. Bartek Skorupa www.bartekskorupa.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
Re: [Bf-committers] Color Correction Node - Lift
On Jan 11, 2013 7:27 AM, Bartek Skorupa (priv) bartekskor...@bartekskorupa.com wrote: R = (1-C) * L + C I don't believe this would work well at all with scene referred models / spaces, of which Blender is. Perhaps it is wiser to shift the default operation to ASC CDL format? With respect, TJS ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Color Correction Node - Lift
I'd prefer it working like LIFT/GAMMA/GAIN does, but this is my personal taste. In my opinion ASC CDL is rather not practical for working with colors. It's great to exchange grades between apps, but I simply don't feel it when grading. The way Color Correction node works now is neither LIFT/GAMMA/GAIN nor ASC CDL. It is kind of ASC CDL, but according to specs power should be used instead of Gamma. In fact Gamma in this case is nothing more than 1/power so maybe it could be left this way, especially that when increasing the value the artist expects colors to be brighter. This is how Gamma behaves in LIFT/GAMMA/GAIN. If we all decide to leave the behavior as is - no problem for me, even though I'd opt for changing it. The point of my thread here is to point out inconsistency between how the things work and what the names of operations are. I did my tests just because I was surprised with the results when trying to use this node. I simply know what happens when I change Lift or Gain and when I changed the parameters that are called Lift or Gain in this particular node - the behavior was different. If we decide to change the behavior - we lose backwards compatibility, so to make things easier - maybe just changing names of operations would be enough? I would be more than happy if the behavior changes to proper LIFT/GAMMA/GAIN, but if it's left as is - fine, as long as the names say what they should. Best Regards Bartek Skorupa www.bartekskorupa.com On 11 sty 2013, at 18:41, Troy Sobotka troy.sobo...@gmail.com wrote: On Jan 11, 2013 7:27 AM, Bartek Skorupa (priv) bartekskor...@bartekskorupa.com wrote: R = (1-C) * L + C I don't believe this would work well at all with scene referred models / spaces, of which Blender is. Perhaps it is wiser to shift the default operation to ASC CDL format? With respect, TJS ___ 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] Color Correction Node - Lift
On Jan 11, 2013 10:31 AM, Bartek Skorupa (priv) bartekskor...@bartekskorupa.com wrote: I'd prefer it working like LIFT/GAMMA/GAIN does, but this is my personal taste. You missed my point. The formula does not work on scene referred data. With respect, TJS ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Compile Failure since 53730?
Hello,
Getting errors compiling (scons VS9) since 53730 with errors
in editmesh_knife.c. Compiles fine if I revert that one change.
Harley
source\blender\editors\mesh\editmesh_knife.c(228) :
error C2054: expected '(' to follow 'inline'
source\blender\editors\mesh\editmesh_knife.c(229) :
error C2085: 'round_ftoi' :not in formal parameter list
source\blender\editors\mesh\editmesh_knife.c(229) :
error C2143: syntax error : missing ';' before '{'
source\blender\editors\mesh\editmesh_knife.c(1777) :
error C4013: 'round_ftoi' undefined; assuming extern returning int
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Compile Failure since 53730?
Hello Harley,
the problem is that in the c standart library of msvc inline is defined as
__inline. If you add these two underscores it works.
This is specific to msvc, it works on the gnu c compiler without the
underscores (also on MinGW).
Also for the msvc c++ compiler inline without underscores works.
Best regards
Dominik
2013/1/11 Harley Acheson harley.ache...@gmail.com
Hello,
Getting errors compiling (scons VS9) since 53730 with errors
in editmesh_knife.c. Compiles fine if I revert that one change.
Harley
source\blender\editors\mesh\editmesh_knife.c(228) :
error C2054: expected '(' to follow 'inline'
source\blender\editors\mesh\editmesh_knife.c(229) :
error C2085: 'round_ftoi' :not in formal parameter list
source\blender\editors\mesh\editmesh_knife.c(229) :
error C2143: syntax error : missing ';' before '{'
source\blender\editors\mesh\editmesh_knife.c(1777) :
error C4013: 'round_ftoi' undefined; assuming extern returning int
___
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
