Re: [Bf-committers] Frame Rate: Time Remapping
On Mar 23, 2011 11:39 AM, "Tobias Oelgarte" wrote: >The > feature works partially, but some strange things are happening: Are you certain it still works in SVN? It seems potentially broken. > I would like to have this feature back or reimplemented, since it is the > only simple way to adjust the timing. As someone with a smidge of experience in film work, I could not agree at all that the implementation works or is, from the vantage of a motion picture tool, "simple". I wonder if there are things we could do that would serve motion picture artists better here? 1) Should time remapping be given the central piece of UI real estate where it is currently located given frequency of use? 2) Within other contextual application workflows, does the current implementation resemble or appear understandable to a motion picture artist? 3) Aside from (2) above, given understanding of the two adjustable variables, does it work as expected? I worry that in all of the above questions time remapping may be sub optimal in its current implementation and execution. Would this be more well suited as a technique to leverage out of the VSE? At the very least it would seem logical to migrate the current implementation to an alternate panel of lesser prominence. Sincerely, TJS ___ 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 [35755] trunk/blender/source/blender/ editors/physics/physics_fluid.c: Further fix for parented fluidsim objects
Oh, thanks for the tip! I always thought it didn't correct for +-360
degrees, but looks like it does, great!
On Thu, 24 Mar 2011 23:51:29 +0200, Campbell Barton
wrote:
> mat4_to_compatible_eulO should be able to do this (rather then own
> function continuous_rotation).
>
> On Thu, Mar 24, 2011 at 5:15 PM, Janne Karhu wrote:
>> Revision: 35755
>>
>>
>> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=35755
>> Author: jhk
>> Date: 2011-03-24 17:15:43 + (Thu, 24 Mar 2011)
>> Log Message:
>> ---
>> Further fix for parented fluidsim objects
>> * The rotation values determined from ob->obmat have to be continuous
>> as fluidsim interpolates between these values internally.
>>
>> Modified Paths:
>> --
>>trunk/blender/source/blender/editors/physics/physics_fluid.c
>>
>> Modified: trunk/blender/source/blender/editors/physics/physics_fluid.c
>> ===
>> --- trunk/blender/source/blender/editors/physics/physics_fluid.c
>> 2011-03-24 14:31:58 UTC (rev 35754)
>> +++ trunk/blender/source/blender/editors/physics/physics_fluid.c
>> 2011-03-24 17:15:43 UTC (rev 35755)
>> @@ -349,6 +349,16 @@
>>}
>> }
>>
>> +static void continuous_rotation(float *rot, const float *old_rot)
>> +{
>> + *rot += (int)(*old_rot/360.f)*360.f;
>> +
>> + if(*old_rot - *rot > 180.f)
>> + *rot += 360.f;
>> + else if(*old_rot - *rot < -180.f)
>> + *rot -= 360.f;
>> +}
>> +
>> static void fluid_init_all_channels(bContext *C, Object
>> *UNUSED(fsDomain), FluidsimSettings *domainSettings, FluidAnimChannels
>> *channels, ListBase *fobjects)
>> {
>>Scene *scene = CTX_data_scene(C);
>> @@ -451,8 +461,14 @@
>>/* init euler rotation values and convert to
>> elbeem format */
>>/* get the rotation from ob->obmat rather than
>> ob->rot to account for parent animations */
>>mat4_to_eul(rot_d, ob->obmat);
>> - mul_v3_fl(rot_d, 180.f/M_PI);
>> - sub_v3_v3v3(rot_d, rot_360, rot_d);
>> + mul_v3_fl(rot_d, -180.f/M_PI);
>> + if(i) {
>> + /* the rotation values have to be
>> continuous, so compare with previous rotation and adjust accordingly */
>> + /* note: the unfortunate side effect of
>> this is that it filters out rotations of over 180 degrees/frame */
>> + continuous_rotation(rot_d,
>> fobj->Rotation + 4*(i-1));
>> + continuous_rotation(rot_d+1,
>> fobj->Rotation + 4*(i-1)+1);
>> + continuous_rotation(rot_d+2,
>> fobj->Rotation + 4*(i-1)+2);
>> + }
>>
>>set_channel(fobj->Translation, timeAtFrame,
>> ob->loc, i, CHANNEL_VEC);
>>set_channel(fobj->Rotation, timeAtFrame, rot_d,
>> i, CHANNEL_VEC);
>>
>> ___
>> 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] Frame Rate: Time Remapping
I used this feature for the first time about a week ago... I'm using an svn build a week or so old and it works for particles if you bake... I've heard it's not working for cloth and smoke has its own "time" value for simulations Part of the issue is that this feature doesn't seem to work for everything... and until it does then what would be "most intuitive" doesn't matter! That said, It's quite easy to use as is, (if you find it in the first place) but: If the renderer could have non integer frames then it could all be much simpler and "intuitive" The first place I looked to slow down time was the render step size: If you could set the render step size to a float value step = 0.5 would render twice as many frames and so be half speed... Done! When that didn't work the second place i tried was the sequencer: I set a scene strip to have a "speed" effect strip that doubles its duration hoping it'd render the interpolated frames... Instead it renders as in source and just holds them as if they were any other image sequence... Once I found the feature it was pretty easy to use, but with the quirks already mentioned by some (having to drag further on the timeline... non baked things going beserk... On 25/03/11 08:42, Troy Sobotka wrote: > On Mar 23, 2011 11:39 AM, "Tobias Oelgarte" > wrote: >> The >> feature works partially, but some strange things are happening: > Are you certain it still works in SVN? It seems potentially broken. > >> I would like to have this feature back or reimplemented, since it is the >> only simple way to adjust the timing. > As someone with a smidge of experience in film work, I could not agree at > all that the implementation works or is, from the vantage of a motion > picture tool, "simple". > > I wonder if there are things we could do that would serve motion picture > artists better here? > > 1) Should time remapping be given the central piece of UI real estate where > it is currently located given frequency of use? > > 2) Within other contextual application workflows, does the current > implementation resemble or appear understandable to a motion picture artist? > > 3) Aside from (2) above, given understanding of the two adjustable > variables, does it work as expected? > > I worry that in all of the above questions time remapping may be sub optimal > in its current implementation and execution. > > Would this be more well suited as a technique to leverage out of the VSE? At > the very least it would seem logical to migrate the current implementation > to an alternate panel of lesser prominence. > > Sincerely, > 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] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [35646] trunk/blender/source/blender: Fix/ change in normal computation, now the viewport uses the same angle
There's also a bug about this in the tracker, will be fixed.
Thanks.
On Fri, Mar 25, 2011 at 3:36 AM, Campbell Barton wrote:
> This also causes a problem with modifiers that use the vertex normal,
> https://projects.blender.org/tracker/index.php?func=detail&aid=26582&group_id=9&atid=498
>
> new code
> >>> bpy.context.object.data.vertices[0].normal
> Vector((0.0, 0.0, -1.0))
>
> 2.56
> >>> bpy.context.object.data.vertices[0].normal
> Vector((0.5773491859436035, 0.5773491859436035, -0.5773491859436035))
>
> On Fri, Mar 25, 2011 at 1:35 AM, Nicholas Bishop
> wrote:
>> Just FYI, this commit seems to make Subdivide Smooth significantly
>> less smooth. For example, doing Subdivide Smooth on a cube multiple
>> times keeps the same cube shape.
>>
>> -Nicholas
>>
>> On Sun, Mar 20, 2011 at 9:35 AM, Brecht Van Lommel
>> wrote:
>>> Revision: 35646
>>>
>>> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=35646
>>> Author: blendix
>>> Date: 2011-03-20 13:35:35 + (Sun, 20 Mar 2011)
>>> Log Message:
>>> ---
>>> Fix/change in normal computation, now the viewport uses the same angle
>>> weighted normals as the render engine, and the render engine will copy
>>> normals from the mesh rather than always recalculating them.
>>>
>>> Subsurf/multires still use regular vertex normals, but they are expected
>>> to be sufficiently high resolution to not need this.
>>>
>>> This means that normal maps displayed in the viewport actually match the
>>> render engine exactly and don't have artifacts due to this discrepancy.
>>> It of course also avoids unexpected surprises where your render normals
>>> look different than your viewport normals.
>>>
>>> Subversion bumped to 4 for version patch to recalculate normals.
>>>
>>> Patch by Morten Mikkelsen, with some small changes.
>>>
>>> Modified Paths:
>>> --
>>> trunk/blender/source/blender/blenkernel/BKE_DerivedMesh.h
>>> trunk/blender/source/blender/blenkernel/BKE_blender.h
>>> trunk/blender/source/blender/blenkernel/intern/cdderivedmesh.c
>>> trunk/blender/source/blender/blenkernel/intern/mesh.c
>>> trunk/blender/source/blender/blenlib/BLI_math_geom.h
>>> trunk/blender/source/blender/blenlib/intern/math_geom.c
>>> trunk/blender/source/blender/blenloader/intern/readfile.c
>>> trunk/blender/source/blender/editors/mesh/editmesh_lib.c
>>> trunk/blender/source/blender/render/intern/source/convertblender.c
>>>
>>> Modified: trunk/blender/source/blender/blenkernel/BKE_DerivedMesh.h
>>> ===
>>> --- trunk/blender/source/blender/blenkernel/BKE_DerivedMesh.h 2011-03-20
>>> 12:19:21 UTC (rev 35645)
>>> +++ trunk/blender/source/blender/blenkernel/BKE_DerivedMesh.h 2011-03-20
>>> 13:35:35 UTC (rev 35646)
>>> @@ -206,7 +206,7 @@
>>> /* Fill the array (of length .getNumVerts()) with all vertex
>>> locations */
>>> void (*getVertCos)(DerivedMesh *dm, float (*cos_r)[3]);
>>>
>>> - /* Get vertex normal, undefined if index is not valid */
>>> + /* Get smooth vertex normal, undefined if index is not valid */
>>> void (*getVertNo)(DerivedMesh *dm, int index, float no_r[3]);
>>>
>>> /* Get a map of vertices to faces
>>>
>>> Modified: trunk/blender/source/blender/blenkernel/BKE_blender.h
>>> ===
>>> --- trunk/blender/source/blender/blenkernel/BKE_blender.h 2011-03-20
>>> 12:19:21 UTC (rev 35645)
>>> +++ trunk/blender/source/blender/blenkernel/BKE_blender.h 2011-03-20
>>> 13:35:35 UTC (rev 35646)
>>> @@ -44,7 +44,7 @@
>>> * and keep comment above the defines.
>>> * Use STRINGIFY() rather then defining with quotes */
>>> #define BLENDER_VERSION 256
>>> -#define BLENDER_SUBVERSION 3
>>> +#define BLENDER_SUBVERSION 4
>>>
>>> #define BLENDER_MINVERSION 250
>>> #define BLENDER_MINSUBVERSION 0
>>>
>>> Modified: trunk/blender/source/blender/blenkernel/intern/cdderivedmesh.c
>>> ===
>>> --- trunk/blender/source/blender/blenkernel/intern/cdderivedmesh.c
>>> 2011-03-20 12:19:21 UTC (rev 35645)
>>> +++ trunk/blender/source/blender/blenkernel/intern/cdderivedmesh.c
>>> 2011-03-20 13:35:35 UTC (rev 35646)
>>> @@ -1798,7 +1798,7 @@
>>> int i;
>>> int numVerts = dm->numVertData;
>>> int numFaces = dm->numFaceData;
>>> - MFace *mf;
>>> + MFace *mfaces;
>>> MVert *mv;
>>>
>>> if(numVerts == 0) return;
>>> @@ -1817,27 +1817,43 @@
>>>
>>> NULL, dm->numFaceData);
>>>
>>> /* calculate face normals and add to vertex normals */
>>> - mf = CDDM_get_faces(dm);
>>> - for(i = 0; i < numFaces; i++, mf++) {
>>> + mfaces = CDDM_get_faces(dm);
>>> + for(i = 0;
Re: [Bf-committers] Frame Rate: Time Remapping
Troy I'd like to know what are you trying to do before saying anything. You are trying to use an almost deprecated feature and there are other options around. Are you handling live footage? Daniel Salazar 2011/3/25 michael williamson : > I used this feature for the first time about a week ago... > I'm using an svn build a week or so old and it works for particles if > you bake... > > I've heard it's not working for cloth and smoke has its own "time" value > for simulations > > Part of the issue is that this feature doesn't seem to work for > everything... and until it does then what would be "most intuitive" > doesn't matter! > > That said, It's quite easy to use as is, (if you find it in the first > place) but: > > If the renderer could have non integer frames then it could all be much > simpler and "intuitive" > > > The first place I looked to slow down time was the render step size: > If you could set the render step size to a float value > > step = 0.5 would render twice as many frames and so be half speed... > > Done! > > > When that didn't work the second place i tried was the sequencer: > I set a scene strip to have a "speed" effect strip that doubles its > duration hoping it'd render the interpolated frames... > > Instead it renders as in source and just holds them as if they were any > other image sequence... > > Once I found the feature it was pretty easy to use, but with the quirks > already mentioned by some (having to drag further on the timeline... > non baked things going beserk... > > > > > > > > On 25/03/11 08:42, Troy Sobotka wrote: >> On Mar 23, 2011 11:39 AM, "Tobias Oelgarte" >> wrote: >>> The >>> feature works partially, but some strange things are happening: >> Are you certain it still works in SVN? It seems potentially broken. >> >>> I would like to have this feature back or reimplemented, since it is the >>> only simple way to adjust the timing. >> As someone with a smidge of experience in film work, I could not agree at >> all that the implementation works or is, from the vantage of a motion >> picture tool, "simple". >> >> I wonder if there are things we could do that would serve motion picture >> artists better here? >> >> 1) Should time remapping be given the central piece of UI real estate where >> it is currently located given frequency of use? >> >> 2) Within other contextual application workflows, does the current >> implementation resemble or appear understandable to a motion picture artist? >> >> 3) Aside from (2) above, given understanding of the two adjustable >> variables, does it work as expected? >> >> I worry that in all of the above questions time remapping may be sub optimal >> in its current implementation and execution. >> >> Would this be more well suited as a technique to leverage out of the VSE? At >> the very least it would seem logical to migrate the current implementation >> to an alternate panel of lesser prominence. >> >> Sincerely, >> 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 > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] bpy.dll
In which version of Windows did you compile? May the problem be this one? http://www.mingw.org/wiki/linking_hangs_under_windows_7 By the way, I got a 33 mb .pyd file. Cheers 2011/3/25 Campbell Barton > >From the error message, python fails to load the DLL, it doesn't even > get to look for a function inside it. > > Some misc suggestions if you want to look into this further. > > - My DLL was about 120mb (RelWithDebugInfo). When setting up cmake > linking with add_library(...SHARED) function I managed to get a DLL > that was ~600kb. > If your bpy.pyd is under 6mb something is wrong linking it and its > - try build with CMAKE_BUILD_TYPE set to RelWithDebugInfo > - Find some tool to inspect the dll to get a hint as to why it fails, > whats wrong with it. > - could be a python ABI version conflict, I used the 32bit Python3.2 > MSI, built with blenders default python that comes in lib. > > Would be interesting to know if other systems have the same trouble. > > On Fri, Mar 25, 2011 at 12:16 AM, Paolo Basso wrote: > > no I was running Python 3.2, I just mentioned that I also hav Python 2.6 > > installed just in case it could be of some help in understanding my > > problem. > > > > I tried to build also the blender.exe from source but, again in this > case, > > everything seems to work fine except that at the end I get an error > message > > when I try to launch blender. > > > > I guess the problem could be something related to my minGW, can be? > > > > > > > > 2011/3/25 Daniel Tavares > > > >> Which of the Python runtimes were you running when you got the > ImportError? > >> It seems to me that you're trying to import bpy from Python 2.6. That > will > >> not work. > >> > >> Make sure to import bpy from your Python 3.2 runtime. As Campbell said: > >> > >> Execute... > >> C:\Python32\python.exe > >> > >> >>> import bpy > >> >>> print(bpy.data) > >> > >> > >> Cheers, > >> > >> Daniel > >> > >> > >> On Thu, Mar 24, 2011 at 8:20 AM, Paolo Basso > wrote: > >> > >> > My environment: > >> > > >> > Windows7 32 bit > >> > python 2.6 and python 3.2 installed (C.\Pythonx.x\...) > >> > > >> > by the way, when I write the command "python" at the command prompt, > >> > then python26 starts (not python32) > >> > > >> > > >> > What I did: > >> > > >> > download latest build and windows dependencies with SVN and placed in > >> > C.\BlenderSVN > >> > (then I have two folders in C.\BlenderSVN: "blender" and "lib") > >> > > >> > I run Cmake 2.8.2 gui and set: > >> > > >> > - source code location: "C:/BlenderSVN/blender" > >> > - where to build the binaries: "C:/BlenderSVN/build" > >> > > >> > then > >> > 1) click configure once > >> > 2) specify the generator for the project as "MinGW Makefiles" (Use > >> default > >> > native compilers) > >> > > >> > I get the following configure info: > >> > > >> > The C compiler identification is GNU > >> > > >> > The CXX compiler identification is GNU > >> > > >> > Check for working C compiler: C:/Program > Files/pythonxy/mingw/bin/gcc.exe > >> > > >> > Check for working C compiler: C:/Program > Files/pythonxy/mingw/bin/gcc.exe > >> > -- > >> > works > >> > > >> > Detecting C compiler ABI info > >> > > >> > Detecting C compiler ABI info - done > >> > > >> > Check for working CXX compiler: C:/Program > >> Files/pythonxy/mingw/bin/g++.exe > >> > > >> > Check for working CXX compiler: C:/Program > >> Files/pythonxy/mingw/bin/g++.exe > >> > -- works > >> > > >> > Detecting CXX compiler ABI info > >> > > >> > Detecting CXX compiler ABI info - done > >> > > >> > Performing Test SUPPORT_SSE_BUILD > >> > > >> > Performing Test SUPPORT_SSE_BUILD - Success > >> > > >> > SSE Support: detected. > >> > > >> > Performing Test SUPPORT_SSE2_BUILD > >> > > >> > Performing Test SUPPORT_SSE2_BUILD - Success > >> > > >> > SSE2 Support: detected. > >> > > >> > Performing Test C_WARN_ALL > >> > > >> > Performing Test C_WARN_ALL - Success > >> > > >> > Performing Test C_WARN_CAST_ALIGN > >> > > >> > Performing Test C_WARN_CAST_ALIGN - Success > >> > > >> > Performing Test C_WARN_ERROR_DECLARATION_AFTER_STATEMENT > >> > > >> > Performing Test C_WARN_ERROR_DECLARATION_AFTER_STATEMENT - Success > >> > > >> > Performing Test C_WARN_ERROR_IMPLICIT_FUNCTION_DECLARATION > >> > > >> > Performing Test C_WARN_ERROR_IMPLICIT_FUNCTION_DECLARATION - Success > >> > > >> > Performing Test C_WARN_ERROR_RETURN_TYPE > >> > > >> > Performing Test C_WARN_ERROR_RETURN_TYPE - Success > >> > > >> > Performing Test C_WARN_ERROR_STRICT_PROTOTYPES > >> > > >> > Performing Test C_WARN_ERROR_STRICT_PROTOTYPES - Success > >> > > >> > Performing Test C_WARN_NO_CHAR_SUBSCRIPTS > >> > > >> > Performing Test C_WARN_NO_CHAR_SUBSCRIPTS - Success > >> > > >> > Performing Test C_WARN_NO_UNKNOWN_PRAGMAS > >> > > >> > Performing Test C_WARN_NO_UNKNOWN_PRAGMAS - Success > >> > > >> > Performing Test C_WARN_POINTER_ARITH > >> > > >> > Performing Test C_WARN_POINTER_ARITH - Success > >> > > >> > Performing Test C_WARN_UNUSED_PARAMETER > >> > > >> >
Re: [Bf-committers] bpy.dll
Finally I fixed the problem: 1) Built with CMake and Visual C++ Express 2008 (MINGW seems not to work appropriately for Windows 7 and generates a bpy.pyd file which is not valid, see previous mail) 2) Copied bpy.pyd AND all the other generated dll (except for python32.dll) in the same folder (bin) to C.:\Python32\DLLs (or alternatively in C:\Python32\Lib\site-packages) Just copying bpy.pyd is not enough in my case but I neither tried to copy just some of the dlls... any suggestions concerning this point is appreciated. Cheers, P 2011/3/25 Paolo Basso > In which version of Windows did you compile? > > May the problem be this one? > http://www.mingw.org/wiki/linking_hangs_under_windows_7 > By the way, I got a 33 mb .pyd file. > > Cheers > 2011/3/25 Campbell Barton > >> >From the error message, python fails to load the DLL, it doesn't even >> get to look for a function inside it. >> >> Some misc suggestions if you want to look into this further. >> >> - My DLL was about 120mb (RelWithDebugInfo). When setting up cmake >> linking with add_library(...SHARED) function I managed to get a DLL >> that was ~600kb. >> If your bpy.pyd is under 6mb something is wrong linking it and its >> - try build with CMAKE_BUILD_TYPE set to RelWithDebugInfo >> - Find some tool to inspect the dll to get a hint as to why it fails, >> whats wrong with it. >> - could be a python ABI version conflict, I used the 32bit Python3.2 >> MSI, built with blenders default python that comes in lib. >> >> Would be interesting to know if other systems have the same trouble. >> >> On Fri, Mar 25, 2011 at 12:16 AM, Paolo Basso wrote: >> > no I was running Python 3.2, I just mentioned that I also hav Python 2.6 >> > installed just in case it could be of some help in understanding my >> > problem. >> > >> > I tried to build also the blender.exe from source but, again in this >> case, >> > everything seems to work fine except that at the end I get an error >> message >> > when I try to launch blender. >> > >> > I guess the problem could be something related to my minGW, can be? >> > >> > >> > >> > 2011/3/25 Daniel Tavares >> > >> >> Which of the Python runtimes were you running when you got the >> ImportError? >> >> It seems to me that you're trying to import bpy from Python 2.6. That >> will >> >> not work. >> >> >> >> Make sure to import bpy from your Python 3.2 runtime. As Campbell said: >> >> >> >> Execute... >> >> C:\Python32\python.exe >> >> >> >> >>> import bpy >> >> >>> print(bpy.data) >> >> >> >> >> >> Cheers, >> >> >> >> Daniel >> >> >> >> >> >> On Thu, Mar 24, 2011 at 8:20 AM, Paolo Basso >> wrote: >> >> >> >> > My environment: >> >> > >> >> > Windows7 32 bit >> >> > python 2.6 and python 3.2 installed (C.\Pythonx.x\...) >> >> > >> >> > by the way, when I write the command "python" at the command prompt, >> >> > then python26 starts (not python32) >> >> > >> >> > >> >> > What I did: >> >> > >> >> > download latest build and windows dependencies with SVN and placed in >> >> > C.\BlenderSVN >> >> > (then I have two folders in C.\BlenderSVN: "blender" and "lib") >> >> > >> >> > I run Cmake 2.8.2 gui and set: >> >> > >> >> > - source code location: "C:/BlenderSVN/blender" >> >> > - where to build the binaries: "C:/BlenderSVN/build" >> >> > >> >> > then >> >> > 1) click configure once >> >> > 2) specify the generator for the project as "MinGW Makefiles" (Use >> >> default >> >> > native compilers) >> >> > >> >> > I get the following configure info: >> >> > >> >> > The C compiler identification is GNU >> >> > >> >> > The CXX compiler identification is GNU >> >> > >> >> > Check for working C compiler: C:/Program >> Files/pythonxy/mingw/bin/gcc.exe >> >> > >> >> > Check for working C compiler: C:/Program >> Files/pythonxy/mingw/bin/gcc.exe >> >> > -- >> >> > works >> >> > >> >> > Detecting C compiler ABI info >> >> > >> >> > Detecting C compiler ABI info - done >> >> > >> >> > Check for working CXX compiler: C:/Program >> >> Files/pythonxy/mingw/bin/g++.exe >> >> > >> >> > Check for working CXX compiler: C:/Program >> >> Files/pythonxy/mingw/bin/g++.exe >> >> > -- works >> >> > >> >> > Detecting CXX compiler ABI info >> >> > >> >> > Detecting CXX compiler ABI info - done >> >> > >> >> > Performing Test SUPPORT_SSE_BUILD >> >> > >> >> > Performing Test SUPPORT_SSE_BUILD - Success >> >> > >> >> > SSE Support: detected. >> >> > >> >> > Performing Test SUPPORT_SSE2_BUILD >> >> > >> >> > Performing Test SUPPORT_SSE2_BUILD - Success >> >> > >> >> > SSE2 Support: detected. >> >> > >> >> > Performing Test C_WARN_ALL >> >> > >> >> > Performing Test C_WARN_ALL - Success >> >> > >> >> > Performing Test C_WARN_CAST_ALIGN >> >> > >> >> > Performing Test C_WARN_CAST_ALIGN - Success >> >> > >> >> > Performing Test C_WARN_ERROR_DECLARATION_AFTER_STATEMENT >> >> > >> >> > Performing Test C_WARN_ERROR_DECLARATION_AFTER_STATEMENT - Success >> >> > >> >> > Performing Test C_WARN_ERROR_IMPLICIT_FUNCTION_DECLARATION >> >> > >> >> > Performing Test C_
Re: [Bf-committers] bpy.dll
needed .dlls: - gnu_gettext - OpenAL32 - pthreadVC2 - SDL - wrap_oal apparently not needed to (I just tried to import bpy, nothing else): - iconv - libpng - zlib 2011/3/25 Paolo Basso > Finally I fixed the problem: > > 1) Built with CMake and Visual C++ Express 2008 (MINGW seems not to work > appropriately for Windows 7 and generates a bpy.pyd file which is not valid, > see previous mail) > > 2) Copied bpy.pyd AND all the other generated dll (except for python32.dll) > in the same folder (bin) to C.:\Python32\DLLs (or alternatively in > C:\Python32\Lib\site-packages) > > Just copying bpy.pyd is not enough in my case but I neither tried to copy > just some of the dlls... any suggestions concerning this point is > appreciated. > > Cheers, > > P > > > > > > > 2011/3/25 Paolo Basso > >> In which version of Windows did you compile? >> >> May the problem be this one? >> http://www.mingw.org/wiki/linking_hangs_under_windows_7 >> By the way, I got a 33 mb .pyd file. >> >> Cheers >> 2011/3/25 Campbell Barton >> >>> >From the error message, python fails to load the DLL, it doesn't even >>> get to look for a function inside it. >>> >>> Some misc suggestions if you want to look into this further. >>> >>> - My DLL was about 120mb (RelWithDebugInfo). When setting up cmake >>> linking with add_library(...SHARED) function I managed to get a DLL >>> that was ~600kb. >>> If your bpy.pyd is under 6mb something is wrong linking it and its >>> - try build with CMAKE_BUILD_TYPE set to RelWithDebugInfo >>> - Find some tool to inspect the dll to get a hint as to why it fails, >>> whats wrong with it. >>> - could be a python ABI version conflict, I used the 32bit Python3.2 >>> MSI, built with blenders default python that comes in lib. >>> >>> Would be interesting to know if other systems have the same trouble. >>> >>> On Fri, Mar 25, 2011 at 12:16 AM, Paolo Basso >>> wrote: >>> > no I was running Python 3.2, I just mentioned that I also hav Python >>> 2.6 >>> > installed just in case it could be of some help in understanding my >>> > problem. >>> > >>> > I tried to build also the blender.exe from source but, again in this >>> case, >>> > everything seems to work fine except that at the end I get an error >>> message >>> > when I try to launch blender. >>> > >>> > I guess the problem could be something related to my minGW, can be? >>> > >>> > >>> > >>> > 2011/3/25 Daniel Tavares >>> > >>> >> Which of the Python runtimes were you running when you got the >>> ImportError? >>> >> It seems to me that you're trying to import bpy from Python 2.6. That >>> will >>> >> not work. >>> >> >>> >> Make sure to import bpy from your Python 3.2 runtime. As Campbell >>> said: >>> >> >>> >> Execute... >>> >> C:\Python32\python.exe >>> >> >>> >> >>> import bpy >>> >> >>> print(bpy.data) >>> >> >>> >> >>> >> Cheers, >>> >> >>> >> Daniel >>> >> >>> >> >>> >> On Thu, Mar 24, 2011 at 8:20 AM, Paolo Basso >>> wrote: >>> >> >>> >> > My environment: >>> >> > >>> >> > Windows7 32 bit >>> >> > python 2.6 and python 3.2 installed (C.\Pythonx.x\...) >>> >> > >>> >> > by the way, when I write the command "python" at the command prompt, >>> >> > then python26 starts (not python32) >>> >> > >>> >> > >>> >> > What I did: >>> >> > >>> >> > download latest build and windows dependencies with SVN and placed >>> in >>> >> > C.\BlenderSVN >>> >> > (then I have two folders in C.\BlenderSVN: "blender" and "lib") >>> >> > >>> >> > I run Cmake 2.8.2 gui and set: >>> >> > >>> >> > - source code location: "C:/BlenderSVN/blender" >>> >> > - where to build the binaries: "C:/BlenderSVN/build" >>> >> > >>> >> > then >>> >> > 1) click configure once >>> >> > 2) specify the generator for the project as "MinGW Makefiles" (Use >>> >> default >>> >> > native compilers) >>> >> > >>> >> > I get the following configure info: >>> >> > >>> >> > The C compiler identification is GNU >>> >> > >>> >> > The CXX compiler identification is GNU >>> >> > >>> >> > Check for working C compiler: C:/Program >>> Files/pythonxy/mingw/bin/gcc.exe >>> >> > >>> >> > Check for working C compiler: C:/Program >>> Files/pythonxy/mingw/bin/gcc.exe >>> >> > -- >>> >> > works >>> >> > >>> >> > Detecting C compiler ABI info >>> >> > >>> >> > Detecting C compiler ABI info - done >>> >> > >>> >> > Check for working CXX compiler: C:/Program >>> >> Files/pythonxy/mingw/bin/g++.exe >>> >> > >>> >> > Check for working CXX compiler: C:/Program >>> >> Files/pythonxy/mingw/bin/g++.exe >>> >> > -- works >>> >> > >>> >> > Detecting CXX compiler ABI info >>> >> > >>> >> > Detecting CXX compiler ABI info - done >>> >> > >>> >> > Performing Test SUPPORT_SSE_BUILD >>> >> > >>> >> > Performing Test SUPPORT_SSE_BUILD - Success >>> >> > >>> >> > SSE Support: detected. >>> >> > >>> >> > Performing Test SUPPORT_SSE2_BUILD >>> >> > >>> >> > Performing Test SUPPORT_SSE2_BUILD - Success >>> >> > >>> >> > SSE2 Support: detected. >>> >> > >>> >> > Performing Test C_WARN_ALL >>> >> > >>> >> > Performing Test C_WARN_ALL
Re: [Bf-committers] bpy.dll
Is there a way/bpy function which allows to open Blender interface and get its reference? I'm happy now I can call bpy methods but I'd like to see what happens, is it possible? 2011/3/25 Paolo Basso > needed .dlls: > > - gnu_gettext > - OpenAL32 > - pthreadVC2 > - SDL > - wrap_oal > > apparently not needed to (I just tried to import bpy, nothing else): > - iconv > - libpng > - zlib > > > > 2011/3/25 Paolo Basso > >> Finally I fixed the problem: >> >> 1) Built with CMake and Visual C++ Express 2008 (MINGW seems not to work >> appropriately for Windows 7 and generates a bpy.pyd file which is not valid, >> see previous mail) >> >> 2) Copied bpy.pyd AND all the other generated dll (except for >> python32.dll) in the same folder (bin) to C.:\Python32\DLLs (or >> alternatively in C:\Python32\Lib\site-packages) >> >> Just copying bpy.pyd is not enough in my case but I neither tried to copy >> just some of the dlls... any suggestions concerning this point is >> appreciated. >> >> Cheers, >> >> P >> >> >> >> >> >> >> 2011/3/25 Paolo Basso >> >>> In which version of Windows did you compile? >>> >>> May the problem be this one? >>> http://www.mingw.org/wiki/linking_hangs_under_windows_7 >>> By the way, I got a 33 mb .pyd file. >>> >>> Cheers >>> 2011/3/25 Campbell Barton >>> >From the error message, python fails to load the DLL, it doesn't even get to look for a function inside it. Some misc suggestions if you want to look into this further. - My DLL was about 120mb (RelWithDebugInfo). When setting up cmake linking with add_library(...SHARED) function I managed to get a DLL that was ~600kb. If your bpy.pyd is under 6mb something is wrong linking it and its - try build with CMAKE_BUILD_TYPE set to RelWithDebugInfo - Find some tool to inspect the dll to get a hint as to why it fails, whats wrong with it. - could be a python ABI version conflict, I used the 32bit Python3.2 MSI, built with blenders default python that comes in lib. Would be interesting to know if other systems have the same trouble. On Fri, Mar 25, 2011 at 12:16 AM, Paolo Basso wrote: > no I was running Python 3.2, I just mentioned that I also hav Python 2.6 > installed just in case it could be of some help in understanding my > problem. > > I tried to build also the blender.exe from source but, again in this case, > everything seems to work fine except that at the end I get an error message > when I try to launch blender. > > I guess the problem could be something related to my minGW, can be? > > > > 2011/3/25 Daniel Tavares > >> Which of the Python runtimes were you running when you got the ImportError? >> It seems to me that you're trying to import bpy from Python 2.6. That will >> not work. >> >> Make sure to import bpy from your Python 3.2 runtime. As Campbell said: >> >> Execute... >> C:\Python32\python.exe >> >> >>> import bpy >> >>> print(bpy.data) >> >> >> Cheers, >> >> Daniel >> >> >> On Thu, Mar 24, 2011 at 8:20 AM, Paolo Basso wrote: >> >> > My environment: >> > >> > Windows7 32 bit >> > python 2.6 and python 3.2 installed (C.\Pythonx.x\...) >> > >> > by the way, when I write the command "python" at the command prompt, >> > then python26 starts (not python32) >> > >> > >> > What I did: >> > >> > download latest build and windows dependencies with SVN and placed in >> > C.\BlenderSVN >> > (then I have two folders in C.\BlenderSVN: "blender" and "lib") >> > >> > I run Cmake 2.8.2 gui and set: >> > >> > - source code location: "C:/BlenderSVN/blender" >> > - where to build the binaries: "C:/BlenderSVN/build" >> > >> > then >> > 1) click configure once >> > 2) specify the generator for the project as "MinGW Makefiles" (Use >> default >> > native compilers) >> > >> > I get the following configure info: >> > >> > The C compiler identification is GNU >> > >> > The CXX compiler identification is GNU >> > >> > Check for working C compiler: C:/Program Files/pythonxy/mingw/bin/gcc.exe >> > >> > Check for working C compiler: C:/Program Files/pythonxy/mingw/bin/gcc.exe >> > -- >> > works >> > >> > Detecting C compiler ABI info >> > >> > Detecting C compiler ABI info - done >> > >> > Check for working CXX compiler: C:/Program >> Files/pythonxy/mingw/bin/g++.exe >> > >> > Check for working CXX compiler: C:/Program >> Files/pythonxy/mingw/bin/g++.exe >> > -- works >> > >> > Detecting CXX compiler ABI info >> > >> > Detecting CXX compiler ABI info - done >> > >>
[Bf-committers] Blenderplayer memory issue.
Hi devs.
Blenderplayer reports memory corruption while exiting here:
GHOST_EventManager::~GHOST_EventManager()
{
disposeEvents();
TConsumerVector::iterator iter= m_consumers.begin();
while (iter != m_consumers.end())
{
GHOST_IEventConsumer* consumer = *iter;
delete consumer;
m_consumers.erase(iter);
iter = m_consumers.begin();
}
}
on delete consumer;
line
I think, that running Valgrind on linux could reveal the source of the problem,
I'm on windows and not equipped with memory profilers.
I did not try to track the reason.
But seems with Valgrind this should be easy.
So if someone has a minute to look at this minor issue, that will be great.
Regards
Sergey
___
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 [35500] trunk/blender: update Bullet physics sdk to latest trunk/version 2.78
Hi Erwin, there is a new bug that seems related to the bullet upgrade as well. [#26614] Can't restore dynamics after suspending them [1] http://projects.blender.org/tracker/?func=detail&atid=498&aid=26614&group_id=9 Do you think you could take a look at it? Thanks, Dalai 2011/3/12 Erwin Coumans : > Please revert the file extern/bullet2/src/Bullet-C-Api.h to the previous > version. > > Thanks! > > Sent from my iPhone > > On Mar 12, 2011, at 2:49 PM, "Sergey I. Sharybin" wrote: > >> extern/bullet2/src/Bullet-C-Api.h > ___ > 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
