Re: [Bf-committers] Patch for BGE Keyboard and Mouse Python types

[Mitchell Stokes]

> +1 for Dalai's suggestions, though I'd like to make sure we take care
> when adding another method to access events.
> Assume 'events' includes events since the last logic tick? (as opposed
> to accumulating events and having the developer remove?)

I'm close to have the suggestions implemented and I'll be submitting a
new patch probably tomorrow. As for the events, they being done just
like SCA_KeyboardSensor.events. It returns a list events and statuses
for inputs that are active for that frame.

Here is the example from the GameKeys doc:

   # Do the all keys thing
   import GameLogic
   import GameKeys

   co = GameLogic.getCurrentController()
   # 'Keyboard' is a keyboard sensor
   sensor = co.getSensor('Keyboard')
   keylist = sensor.events
   for key in keylist:
   # key[0] == GameKeys.keycode, key[1] = status
   if key[1] == GameLogic.KX_INPUT_JUST_ACTIVATED:
   if key[0] == GameKeys.WKEY:
   # Activate Forward!
   if key[0] == GameKeys.SKEY:
   # Activate Backward!
   if key[0] == GameKeys.AKEY:
   # Activate Left!
   if key[0] == GameKeys.DKEY:
   # Activate Right!

Cheers,
Mitchell Stokes (Moguri)
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Interaction Presets...

[michael williamson]

Great feature!

I've noted some things with the Maya keymap and have done a new version...
get it here:
http://www.cowtoolsmedia.co.uk/scrip...es-maya.py.zip 



In doing so, a couple of things came up!

1) in edit mode with the Maya preset Alt-lmb doesn't rotate the view... 
It's correct in the keymap so un-clear why this is happening

2)In my edited version of the maya keymap  Alt-lmb works, alt rmb (view 
zoom) is broken in edit mode...
- in my keymap I changed "select with" to RMB so there may be a clue 
there...

3)lmb-drag: border select in maya creates a new selection, 
shift-lmb-drag toggles the select state of what you drag over...

*  "toggle" isn't do-able with box select in blender...
* If i trigger "box select extend" with shift-lmb tweak  the action
  can only be completed by releasing the shift key... feels "wrong"

Notes on my preset version:
Because the standard blender select is very un-maya like I've kept it 
out the way with "select with set to rmb" and set border select to be 
explicity "LMB" rather than select...

This causes a conflict with setting the 3d cursor so I moved that to 
ctrl-shift lmb
I also added clicking on empty space = deselect all...

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] presets.py as_filename bug?

[Domino Marama]

Just spotted this browsing the .py files..

In ./release/scripts/op/presets.py starting at line 35

def _as_filename(self, name): # could reuse for other presets
for char in " !...@#$%^&*(){}:\";'[]<>,./?":
name = name.replace('.', '_')
return name.lower()

shouldn't it be

def _as_filename(self, name): # could reuse for other presets
for char in " !...@#$%^&*(){}:\";'[]<>,./?":
name = name.replace(char, '_')
return name.lower()

so all the funky characters are replaced and not just '.'?

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Interaction Presets...

[michael williamson]

michael williamson wrote:
> In doing so, a couple of things came up!
>
> 1) in edit mode with the Maya preset Alt-lmb doesn't rotate the view... 
> It's correct in the keymap so un-clear why this is happening
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>   



Ok, so it's our old friend "Alt + select mouse" being used for viewnav 
conflicting with "edge loop select"... the cascade-ing effect of these 
changes  Any suggestions for a new home for edgeloop select?  (would 
also allow "emulate 3 button mouse" and "LMB select" in default keymaps 
I guess)
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] presets.py as_filename bug?

[Campbell Barton]

perhaps this couuld be replaced with bpy.utils.clean_name() -
http://www.blender.org/documentation/250PythonDoc/bpy.utils.html?highlight=bpy.utils#bpy.utils.clean_name

On Wed, Apr 14, 2010 at 11:33 AM, Domino Marama
 wrote:
> Just spotted this browsing the .py files..
>
> In ./release/scripts/op/presets.py starting at line 35
>
>    def _as_filename(self, name): # could reuse for other presets
>        for char in " !...@#$%^&*(){}:\";'[]<>,./?":
>            name = name.replace('.', '_')
>        return name.lower()
>
> shouldn't it be
>
>    def _as_filename(self, name): # could reuse for other presets
>        for char in " !...@#$%^&*(){}:\";'[]<>,./?":
>            name = name.replace(char, '_')
>        return name.lower()
>
> so all the funky characters are replaced and not just '.'?
>
> ___
> 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] Error on compilation with cmake for windows

[lguillaume]

Hi,

Since a few days, I can't compile blender 2.5 on vc++ express 9 with cmake.
There is 2 errors about the need of pthreads.h

I correct the cmakefile with the patch :

Index: source/blender/gpu/CMakeLists.txt
===
--- source/blender/gpu/CMakeLists.txt(revision 28190)
+++ source/blender/gpu/CMakeLists.txt(working copy)
@@ -28,8 +28,12 @@

 SET(INC
 . ../blenlib ../blenkernel ../makesdna ../include
-../../../extern/glew/include ../../../intern/guardedalloc
../../../intern/smoke/extern ../imbuf)
+../../../extern/glew/include ../../../intern/guardedalloc
../../../intern/smoke/extern ../imbuf )

+IF(WIN32)
+SET(INC ${INC} ${PTHREADS_INC})
+ENDIF(WIN32)
+
 ADD_DEFINITIONS(-DGLEW_STATIC)

 BLENDERLIB(bf_gpu "${SRC}" "${INC}")
Index: source/creator/CMakeLists.txt
===
--- source/creator/CMakeLists.txt(revision 28190)
+++ source/creator/CMakeLists.txt(working copy)
@@ -49,8 +49,10 @@
 ../../extern/glew/include
 )

+IF(WIN32)
+INCLUDE_DIRECTORIES(${PTHREADS_INC})
+ENDIF(WIN32)

-
 IF(WITH_QUICKTIME)
 ADD_DEFINITIONS(-DWITH_QUICKTIME)
 ENDIF(WITH_QUICKTIME)
___
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 [28156] trunk/blender/source/blender: Todo #21831: Deform modifier is applied to base mesh instead of

[joe]

Thank you!!

Joe

On Tue, Apr 13, 2010 at 8:06 AM, Sergey Sharybin  wrote:
> Revision: 28156
>          
> http://projects.blender.org/plugins/scmsvn/viewcvs.php?view=rev&root=bf-blender&revision=28156
> Author:   nazgul
> Date:     2010-04-13 08:06:49 +0200 (Tue, 13 Apr 2010)
>
> Log Message:
> ---
> Todo #21831: Deform modifier is applied to base mesh instead of
>             multires modifier if both are in the stack (patch #21965)
>
> This patch also removes limitation of multires reshaping when
> destination object has got modifiers after multires modifier.
>
> Modified Paths:
> --
>    trunk/blender/source/blender/blenkernel/BKE_multires.h
>    trunk/blender/source/blender/blenkernel/intern/multires.c
>    trunk/blender/source/blender/editors/object/object_modifier.c
>
> Modified: trunk/blender/source/blender/blenkernel/BKE_multires.h
> ===
> --- trunk/blender/source/blender/blenkernel/BKE_multires.h      2010-04-13 
> 00:55:37 UTC (rev 28155)
> +++ trunk/blender/source/blender/blenkernel/BKE_multires.h      2010-04-13 
> 06:06:49 UTC (rev 28156)
> @@ -35,6 +35,7 @@
>  struct MFace;
>  struct Multires;
>  struct MultiresModifierData;
> +struct ModifierData;
>  struct Object;
>
>  void multires_mark_as_modified(struct Object *ob);
> @@ -46,11 +47,14 @@
>        int local_mmd, struct DerivedMesh*, struct Object *, int, int);
>
>  struct MultiresModifierData *find_multires_modifier(struct Object *ob);
> +struct DerivedMesh *get_multires_dm(struct Object *ob);
>  void multiresModifier_join(struct Object *);
>  void multiresModifier_del_levels(struct MultiresModifierData *, struct 
> Object *, int direction);
>  void multiresModifier_subdivide(struct MultiresModifierData *mmd, struct 
> Object *ob,
>                                int updateblock, int simple);
>  int multiresModifier_reshape(struct MultiresModifierData *mmd, struct Object 
> *dst, struct Object *src);
> +int multiresModifier_reshapeFromDM(struct MultiresModifierData *mmd, struct 
> Object *ob, struct DerivedMesh *srcdm);
> +int multiresModifier_reshapeFromDeformMod(struct MultiresModifierData *mmd, 
> struct Object *ob, struct ModifierData *md);
>
>  void multires_stitch_grids(struct Object *);
>
>
> Modified: trunk/blender/source/blender/blenkernel/intern/multires.c
> ===
> --- trunk/blender/source/blender/blenkernel/intern/multires.c   2010-04-13 
> 00:55:37 UTC (rev 28155)
> +++ trunk/blender/source/blender/blenkernel/intern/multires.c   2010-04-13 
> 06:06:49 UTC (rev 28156)
> @@ -60,6 +60,22 @@
>  static void multires_mvert_to_ss(DerivedMesh *dm, MVert *mvert);
>  static void multiresModifier_disp_run(DerivedMesh *dm, Mesh *me, int invert, 
> int add, DMGridData **oldGridData, int totlvl);
>
> +DerivedMesh *get_multires_dm(Object *ob)
> +{
> +       Mesh *me= ob->data;
> +       ModifierData *md= (ModifierData *)find_multires_modifier(ob);
> +       ModifierTypeInfo *mti = modifierType_getInfo(md->type);
> +       DerivedMesh *tdm = CDDM_from_mesh(me, ob);
> +       DerivedMesh *dm;
> +
> +       CDDM_calc_normals(tdm);
> +       dm = mti->applyModifier(md, ob, tdm, 0, 1);
> +
> +       if(tdm != dm) tdm->release(tdm);
> +
> +       return dm;
> +}
> +
>  MultiresModifierData *find_multires_modifier(Object *ob)
>  {
>        ModifierData *md;
> @@ -191,24 +207,64 @@
>  }
>  #endif
>
> -/* Returns 1 on success, 0 if the src's totvert doesn't match */
> -int multiresModifier_reshape(MultiresModifierData *mmd, Object *dst, Object 
> *src)
> +int multiresModifier_reshapeFromDM(MultiresModifierData *mmd, Object *ob, 
> DerivedMesh *srcdm)
>  {
> -       DerivedMesh *srcdm = src->derivedFinal;
> -       DerivedMesh *mrdm = dst->derivedFinal;
> +       DerivedMesh *mrdm = get_multires_dm (ob);
>
>        if(mrdm && srcdm && mrdm->getNumVerts(mrdm) == 
> srcdm->getNumVerts(srcdm)) {
>                multires_mvert_to_ss(mrdm, srcdm->getVertArray(srcdm));
>
>                multires_dm_mark_as_modified(mrdm);
> -               multires_force_update(dst);
> +               multires_force_update(ob);
>
> +               mrdm->release(mrdm);
> +
>                return 1;
>        }
>
> +       mrdm->release(mrdm);
> +
>        return 0;
>  }
>
> +/* Returns 1 on success, 0 if the src's totvert doesn't match */
> +int multiresModifier_reshape(MultiresModifierData *mmd, Object *dst, Object 
> *src)
> +{
> +       DerivedMesh *srcdm = src->derivedFinal;
> +       return multiresModifier_reshapeFromDM(mmd, dst, srcdm);
> +}
> +
> +int multiresModifier_reshapeFromDeformMod(MultiresModifierData *mmd, Object 
> *ob, ModifierData *md)
> +{
> +       ModifierTypeInfo *mti = modifierType_getInfo(md->type);
> +       DerivedMesh *dm, *ndm;
> +       int numVerts, result;
> +       float (*deformedVerts)[3];
> +
> +       /* Create DerivedMesh for deformation modifier */
> +       dm = get_multires_dm(ob);
> + 

Re: [Bf-committers] jemalloc blender tests.

[joe]

Guardedalloc adds a great deal more overhead to allocations then
system allocators do, which I think explains much of it (and too
fine-grained allocations of course).

Joe

On Wed, Apr 14, 2010 at 2:08 AM, Campbell Barton  wrote:
> Recently I was looking into blender using a lot more memory then it
> should, where blender reported ~75mb, and the OS reported 750mb.
> This made one of the animators run out of ram, so I did a lot of
> checks and made sure it wasn't a leak (calling exit() and have
> valgrind report all unfree'd memory works pretty well).
>
> It turns out that this is *(most likely) because of memory
> fragmentation, so I tried malloc replacements 'hoard' and 'jemalloc',
> which had tried before and found gave minimal/no performance gains.
> But they do help with using less memory from the OS.
> (Keep in mind, using 64bit linux - ubuntu karmic, mileage would vary
> depending on the OS ofcourse).
>
> jemalloc gave better results so did some further tests.
> On loading the same file it used ~500mb rather then ~750mb. This was a
> scene with sintel so I suspect fragmentation could be because of
> vertex groups but not 100% sure.
>
> Then tested the alley scene, jemalloc <-> linux's default malloc,
> interesting results!
> (scene http://durian.blender.org/wp-content/uploads/2010/03/alley.png)
> (maximum memory used, from the OS's memory monitor. unscientifically
> took notes while rendering)
> new file (idle): 53mb <-> 55mb
> loaded alley scene (idle): 671mb <-> 1300mb
> render shadowbuffer: 5.5gig <-> 6.8gig
> raytree: 3.6gig <-> 4.0gig
> sss: 3.1gig <-> 4.1gig
> rendering (/w gi): 6.2gig <-> 7.2gig
> after rendering (idle): 4.0gig <-> 6.7gig
> new file after render (idle): 140mb <-> 3.1gig
>
> >From what I have read, linux malloc implementation is considered to be
> quite good, (not worth replacing), so I'm guessing blender is using
> more fine grained malloc's then it should be.
>
> Im not sure of the details, if libc is keeping the ram for the
> application, but when you want to have more then 1 blender loaded at a
> time, its annoying to have to restart it just to free the memory.
>
> So I'd be interested if someone could test memory usage on windows
> with jemalloc since we get a lot of complaints about memory on windows
> systems,
>
> see: http://www.canonware.com/jemalloc/
> note: needed to compile with "./configure --disable-tcache", it was
> crashing when rendering. (bug reported)
> note: rendertimes were not noticeably different.
>
> According to the site http://www.canonware.com/jemalloc/
> facebook server, firefox and FreeBSD use jemalloc.
>
> Could be worth including with blender, especially if it helps windows
> users from running out of ram so easily.
>
> --
> - 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] jemalloc blender tests.

[Campbell Barton]

In my tests Guardedalloc was still being used, just with jemalloc
rather then the systems.
To test on *nix you dont even need to rebuild :)

LD_PRELOAD=/usr/local/lib/libjemalloc.so ./blender.bin

On Wed, Apr 14, 2010 at 2:14 PM, joe  wrote:
> Guardedalloc adds a great deal more overhead to allocations then
> system allocators do, which I think explains much of it (and too
> fine-grained allocations of course).
>
> Joe
>
> On Wed, Apr 14, 2010 at 2:08 AM, Campbell Barton  wrote:
>> Recently I was looking into blender using a lot more memory then it
>> should, where blender reported ~75mb, and the OS reported 750mb.
>> This made one of the animators run out of ram, so I did a lot of
>> checks and made sure it wasn't a leak (calling exit() and have
>> valgrind report all unfree'd memory works pretty well).
>>
>> It turns out that this is *(most likely) because of memory
>> fragmentation, so I tried malloc replacements 'hoard' and 'jemalloc',
>> which had tried before and found gave minimal/no performance gains.
>> But they do help with using less memory from the OS.
>> (Keep in mind, using 64bit linux - ubuntu karmic, mileage would vary
>> depending on the OS ofcourse).
>>
>> jemalloc gave better results so did some further tests.
>> On loading the same file it used ~500mb rather then ~750mb. This was a
>> scene with sintel so I suspect fragmentation could be because of
>> vertex groups but not 100% sure.
>>
>> Then tested the alley scene, jemalloc <-> linux's default malloc,
>> interesting results!
>> (scene http://durian.blender.org/wp-content/uploads/2010/03/alley.png)
>> (maximum memory used, from the OS's memory monitor. unscientifically
>> took notes while rendering)
>> new file (idle): 53mb <-> 55mb
>> loaded alley scene (idle): 671mb <-> 1300mb
>> render shadowbuffer: 5.5gig <-> 6.8gig
>> raytree: 3.6gig <-> 4.0gig
>> sss: 3.1gig <-> 4.1gig
>> rendering (/w gi): 6.2gig <-> 7.2gig
>> after rendering (idle): 4.0gig <-> 6.7gig
>> new file after render (idle): 140mb <-> 3.1gig
>>
>> >From what I have read, linux malloc implementation is considered to be
>> quite good, (not worth replacing), so I'm guessing blender is using
>> more fine grained malloc's then it should be.
>>
>> Im not sure of the details, if libc is keeping the ram for the
>> application, but when you want to have more then 1 blender loaded at a
>> time, its annoying to have to restart it just to free the memory.
>>
>> So I'd be interested if someone could test memory usage on windows
>> with jemalloc since we get a lot of complaints about memory on windows
>> systems,
>>
>> see: http://www.canonware.com/jemalloc/
>> note: needed to compile with "./configure --disable-tcache", it was
>> crashing when rendering. (bug reported)
>> note: rendertimes were not noticeably different.
>>
>> According to the site http://www.canonware.com/jemalloc/
>> facebook server, firefox and FreeBSD use jemalloc.
>>
>> Could be worth including with blender, especially if it helps windows
>> users from running out of ram so easily.
>>
>> --
>> - 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
>



-- 
- Campbell
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] [Render25 branch] since rev 28087, problem with a simple render

[jmsoler]

Hi,

on the last Win32 MSVC's executables and the Mac OSX ones too, a simple render
closes the application but if I modify the MAX_PIXEL_ROW value in the
rendercore.h file, it works correctly. Curiously, the limit is different from an
OS to other. MAX_PIXEL_ROW has to be smaller (or equal to) than 8818 under Mac
OSX  and 17980 under Win32.

jms.






___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Error on compilation with cmake for windows

[(Ry)akiotakis (An)tonis]

On 14 April 2010 14:36, lguillaume  wrote:
> Hi,
>
> Since a few days, I can't compile blender 2.5 on vc++ express 9 with cmake.
> There is 2 errors about the need of pthreads.h
>
> I correct the cmakefile with the patch :
>
> Index: source/blender/gpu/CMakeLists.txt
> ===
> --- source/blender/gpu/CMakeLists.txt    (revision 28190)
> +++ source/blender/gpu/CMakeLists.txt    (working copy)
> @@ -28,8 +28,12 @@
>
>  SET(INC
>     . ../blenlib ../blenkernel ../makesdna ../include
> -    ../../../extern/glew/include ../../../intern/guardedalloc
> ../../../intern/smoke/extern ../imbuf)
> +    ../../../extern/glew/include ../../../intern/guardedalloc
> ../../../intern/smoke/extern ../imbuf )
>
> +IF(WIN32)
> +    SET(INC ${INC} ${PTHREADS_INC})
> +ENDIF(WIN32)
> +
>  ADD_DEFINITIONS(-DGLEW_STATIC)
>
>  BLENDERLIB(bf_gpu "${SRC}" "${INC}")
> Index: source/creator/CMakeLists.txt
> ===
> --- source/creator/CMakeLists.txt    (revision 28190)
> +++ source/creator/CMakeLists.txt    (working copy)
> @@ -49,8 +49,10 @@
>     ../../extern/glew/include
>  )
>
> +IF(WIN32)
> +    INCLUDE_DIRECTORIES(${PTHREADS_INC})
> +ENDIF(WIN32)
>
> -
>  IF(WITH_QUICKTIME)
>     ADD_DEFINITIONS(-DWITH_QUICKTIME)
>  ENDIF(WITH_QUICKTIME)
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
>

Same here, MinGW/Scons. The fix is, along similar lines:

Index: source/blender/gpu/SConscript
===
--- source/blender/gpu/SConscript   (revision 28190)
+++ source/blender/gpu/SConscript   (working copy)
@@ -9,5 +9,7 @@
 incs += ' #/extern/glew/include #intern/guardedalloc
#intern/smoke/extern ../imbuf .'

 incs += ' ' + env['BF_OPENGL_INC']
+if env['OURPLATFORM'] in ('win32-vc', 'win32-mingw', 'win64-vc', 'linuxcross'):
+   incs += ' ' + env['BF_PTHREADS_INC']

 env.BlenderLib ( 'bf_gpu', sources, Split(incs), defines = defs,
libtype=['core','player'], priority=[160,110] )
Index: source/creator/SConscript
===
--- source/creator/SConscript   (revision 28190)
+++ source/creator/SConscript   (working copy)
@@ -11,6 +11,10 @@
 incs += ' ../kernel/gen_system #/extern/glew/include ../blender/gpu'
 incs += ' ' + env['BF_OPENGL_INC']

+if env['OURPLATFORM'] in ('win32-vc', 'win32-mingw', 'win64-vc', 'linuxcross'):
+   incs += ' ' + env['BF_PTHREADS_INC']
+
+
 defs = []
 if env['WITH_BF_QUICKTIME']:
incs += ' ' + env['BF_QUICKTIME_INC']


Thanks Guillaume!
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Error on compilation with cmake for windows

[loopduplic...@burningtoken.com]

Broken for me too.  Patch did not work either.  MSVStudio + cmake win32
Peace

On 4/14/2010 7:47 AM, (Ry)akiotakis (An)tonis was all like:
> On 14 April 2010 14:36, lguillaume  wrote:
>
>> Hi,
>>
>> Since a few days, I can't compile blender 2.5 on vc++ express 9 with cmake.
>> There is 2 errors about the need of pthreads.h
>>  
>

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Behaviour of "Select every Nth" for curves

[Sergey I. Sharybin]

Hi, Blender community!

There is such bug report in the tracker: 
http://projects.blender.org/tracker/?func=detail&aid=21766&group_id=9&atid=498

I can't start working under it because i don't know how *should* this 
operator work.
There are two ways:
1. Use selection strategy when user selects some base points and then 
every Nth point from selected would be selected. In this approach i've 
got two questions: how should this operator if nothing is selected? and 
if only beizer point's handle is selected should such point become 
selected (it's about curve created from grease pencil where handles have 
got the same coordinates as point and when user tries to select point 
only handle become selected so select every Nth does nothing)?
2. Deselection strategy (as it's done for meshes). In this case i've got 
one question: from which point calculation of every Nth should be 
started? there is no information about the last selected point.

So in which way i should change this operator?

-- 
With best regards, Sergey I. Sharybin

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Behaviour of "Select every Nth" for curves

[Rohith B.V.]

Hi Sergey,

   I made a small fix for this, see if it suits your requirements.

https://projects.blender.org/tracker/?func=detail&aid=21881&group_id=9&atid=127

On Thu, Apr 15, 2010 at 1:31 AM, Sergey I. Sharybin wrote:

> Hi, Blender community!
>
> There is such bug report in the tracker:
>
> http://projects.blender.org/tracker/?func=detail&aid=21766&group_id=9&atid=498
>
> I can't start working under it because i don't know how *should* this
> operator work.
> There are two ways:
> 1. Use selection strategy when user selects some base points and then
> every Nth point from selected would be selected. In this approach i've
> got two questions: how should this operator if nothing is selected? and
> if only beizer point's handle is selected should such point become
> selected (it's about curve created from grease pencil where handles have
> got the same coordinates as point and when user tries to select point
> only handle become selected so select every Nth does nothing)?
> 2. Deselection strategy (as it's done for meshes). In this case i've got
> one question: from which point calculation of every Nth should be
> started? there is no information about the last selected point.
>
> So in which way i should change this operator?
>
> --
> With best regards, Sergey I. 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] Error on compilation with cmake for windows

[loopduplic...@burningtoken.com]

fixed by including lib/windows/pthreads/include in these files:

 trunk/blender/source/blender/gpu/CMakeLists.txt
 trunk/blender/source/creator/CMakeLists.txt

or by copying over the contents of /lib/windows/pthreads/include to 
/source/blender/blenlib


On 4/14/2010 1:01 PM, loopduplic...@burningtoken.com wrote:
> Broken for me too.  Patch did not work either.  MSVStudio + cmake win32
> Peace
>
> On 4/14/2010 7:47 AM, (Ry)akiotakis (An)tonis was all like:
>
>> On 14 April 2010 14:36, lguillaume   wrote:
>>
>>  
>>> Hi,
>>>
>>> Since a few days, I can't compile blender 2.5 on vc++ express 9 with cmake.
>>> There is 2 errors about the need of pthreads.h
>>>
>>>
>>  
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
> Same here, MinGW/Scons. The fix is, along similar lines:
>
> Index: source/blender/gpu/SConscript
> ===
> --- source/blender/gpu/SConscript (revision 28190)
> +++ source/blender/gpu/SConscript (working copy)
> @@ -9,5 +9,7 @@
>   incs += ' #/extern/glew/include #intern/guardedalloc
> #intern/smoke/extern ../imbuf .'
>
>   incs += ' ' + env['BF_OPENGL_INC']
> +if env['OURPLATFORM'] in ('win32-vc', 'win32-mingw', 'win64-vc', 
> 'linuxcross'):
> + incs += ' ' + env['BF_PTHREADS_INC']
>
>   env.BlenderLib ( 'bf_gpu', sources, Split(incs), defines = defs,
> libtype=['core','player'], priority=[160,110] )
> Index: source/creator/SConscript
> ===
> --- source/creator/SConscript (revision 28190)
> +++ source/creator/SConscript (working copy)
> @@ -11,6 +11,10 @@
>   incs += ' ../kernel/gen_system #/extern/glew/include ../blender/gpu'
>   incs += ' ' + env['BF_OPENGL_INC']
>
> +if env['OURPLATFORM'] in ('win32-vc', 'win32-mingw', 'win64-vc', 
> 'linuxcross'):
> + incs += ' ' + env['BF_PTHREADS_INC']
> +
> +
>   defs = []
>   if env['WITH_BF_QUICKTIME']:
>   incs += ' ' + env['BF_QUICKTIME_INC']
>
>
> Thanks Guillaume!
>

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Error on compilation with cmake for windows

[Stephen Swaney]

On Wed, Apr 14, 2010 at 07:13:48PM -0700, loopduplic...@burningtoken.com wrote:
> fixed by including lib/windows/pthreads/include in these files:
> 
>  trunk/blender/source/blender/gpu/CMakeLists.txt
>  trunk/blender/source/creator/CMakeLists.txt
> 
> or by copying over the contents of /lib/windows/pthreads/include to 
> /source/blender/blenlib
> 

A couple points:

The patch you reference is for scons, not cmake.

Copying headers from one directory to another to fix include problems
is both wrong and asking for trouble later.

-- 
Stephen Swaney  
sswa...@centurytel.net

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Error on compilation with cmake for windows

[loopduplic...@burningtoken.com]

I'm not a commiter, though.  Just did it to get the new features.  And I 
posted what I did for those in my situation.  I never studied much 
programming.
Should I have kept to myself?  Is there somewhere else I should have shared?
The patch that lecocqguilla...@gmail.com wrote is for Cmake so I don't 
know what you mean about me referencing a scons patch.
And as soon as a commiter includes the headers in the CMakeLists.txt 
files (or whatever way is best that they decidee,) I'll delete them from 
my local copy of the internal blenlib folder
Anyway.  Back to work for me.  Peace.

On 4/14/2010 8:54 PM, Stephen Swaney wrote:
> On Wed, Apr 14, 2010 at 07:13:48PM -0700, loopduplic...@burningtoken.com 
> wrote:
>
>> fixed by including lib/windows/pthreads/include in these files:
>>
>>   trunk/blender/source/blender/gpu/CMakeLists.txt
>>   trunk/blender/source/creator/CMakeLists.txt
>> 
>> or by copying over the contents of /lib/windows/pthreads/include to 
>> /source/blender/blenlib
>> 
>>  
> A couple points:
>
> The patch you reference is for scons, not cmake.
>
> Copying headers from one directory to another to fix include problems
> is both wrong and asking for trouble later.
>
>

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers