[Bf-committers] Synapse : an open source Node Based compositor

[François T .]

http://code.google.com/p/vexx/

I like this kind of idea : Synapse - Custom Node Tour
(GLSL)

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

Re: [Bf-committers] MinGW debug builds do not run

[Nathan Letwory]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 21.2.2011 1:15, Peter Kümmel wrote:
> It compiles now out of the box but still crashes.
> Seems I have to go the 'hard' way you described.

Python 3.1 debug dll is built dynamically linking against msvc9 debug
runtime, so if you want to run debug with other than vs2008, you'll have
to acquire the appropriate debug runtime dlls. These are not
redistributable, so you'll need to get vs2008 (I assume the express
version will do, but can't tell for sure).

You could also rebuild python 3.1 debug dll with mingw, if that's
possible, I suppose. And when using vs2010, you could rebuild the python
3.1 debug dll with that.

Anyway, have the correct debug runtime dlls in the same dir as
blender.exe, and you should be running fine.

/Nathan

>
> On 20.02.2011 14:46, Campbell Barton wrote:
>> IIRC MSVC2008 full version is used for releases,
>> I have a free MSVC2010 which has a similar problem to MinGW, debug
>> builds fail to run with strange popup dialog error.
>>
>> Re Crash on startup:
>>   If its a crash (not a linking/error message), best not assume blender
>> is without fault, debug info&  call-stack can help a lot in tracking
>> down these problems.
>>
>> The IOError define is already in lib/windows, committed shortly after
>> changing the exception.
>> I use an update alias which does both repo's before building to
>> prevent these kinds of errors.
>>
>> Do you still get the crash on startup?
>>
>> On Sun, Feb 20, 2011 at 11:54 AM, Peter Kümmel  wrote:
>>> On 20.02.2011 04:24, Campbell Barton wrote:
>>>
 Whats supported isn't set in stone, its more a case of which
 configurations are tested&known to work.
>>>
>>> OK, thanks. And what is mostly used for the Windows releases?
>>>

 this works for me.
 - windows xp
 - mingw-gcc4.5.2, (from mingw's main site)
 - cmake 2.8 (build type set to Release or RelWithDebInfo)
 - blender (tested r34959)
>>>
>>> I had a little bit outdated checkout with 4.4, W7-64Bit, and
>>> problems with release and debug.
>>>

 A crash on startup may be a real bug rather then lack of support, you
 could run with gdb and see why its crashing.
 If you are unable to figure out how to fix you could file a bug and
 include a backtace.
>>>
>>> I assume not really a error in blender code, it's the mixture of
>>> pre-compiled binaries, compiler used for blender, OS, and runtime
>>> libraries.
>>>
>>> Best is to build everyting with the same compiler.
>>>

 Another way to help find the cause of the crash is to disable all
 WITH_* options in cmake configuration, WITH_OPENAL, WITH_IMAGE_OPENEXR
 ... etc.

 If this works you could try again with usable settings (so you get an
 interface),
 all off except WITH_PYTHON WITH_INSTALL and WITH_PYTHON_INSTALL.
>>>
>>> I already had the idea to try it without python ;)
>>>
 After that its trial and error to see which library causes the crash,
 the offending lib could be disabled by default with mingw until its
 fixed properly.

 One other thing, you were getting the error 'PyModule_Create2'
 interestingly I got this error too on Linux when trying to load a
 library built with a debug python but finding a release library.
>>>
>>> I could link against the lib/windows version with attached patch.
>>>

 On Sat, Feb 19, 2011 at 3:26 PM, Peter Kümmel
 wrote:
>
> Tested it with cmake too. It links after a small fix, but
> crashes immediately after starting. Seems mingw isn't supported.
>
> Peter


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNZNckAAoJEKtfN7KsE0Ttpr8IAI3/xa4WCO373kchO1W7AI16
ZZSzd9oe9PYgyZqJ3AylmdozyNaEg//EuLFtWQnFqov9XE/tuK/8ZNVOD3Ro2hLK
tZ6Z38eQjkXaMOrXR/R+yZnbRutsru3P6xqTHfZY7Au65Z8BQaW1LxXZD0LRrB+p
ITMxB3Tn17wxDEj7AJywVKB4GHhFUMo0vaVdB5LLjnpMXpB+wjGSrvhyZQUStGnb
y05TAxR+Z6fXgvtHrf967PQAeoVVjdigyCY0UNtOg4YMDAeHSVeIQqYHSsPvXmru
B4383jq4q/mnUgOcgYJhSrFr1mSx0f7LmeMdWcq6G2XHK+8NTS7aZ8x9pY0xMdE=
=ifdD
-END PGP SIGNATURE-
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] normal maps, red/green channel inverted

[Ton Roosendaal]

Hi Martin,

This is the "new bump" commit, august 2009:
http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=21771

The patch was provided by Eeshlo, but he didn't want to maintain it  
further. It has been added on artist requests because it visually  
looked much better - at first sight - but the code never got a real  
review or quality check.

On dec 27 last year I mailed to this list a short overview of the  
problems with the "new bump". We also suffered bad noisy normal  
textures in Sintel all over...

The texture code already was an evolved nightmare, and with this  
commit only became less. I rather not even attempt to understand & fix  
it anymore, but keep 2.56 code work and switch to a revamped shade/ 
texture system asap.

-Ton-


Ton Roosendaal  Blender Foundation   t...@blender.orgwww.blender.org
Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands

On 22 Feb, 2011, at 22:58, Martin Poirier wrote:

> Before changing everything again, can we go back to the revision  
> that introduced the change in the first place and maybe understand  
> why it was done? There was probably a reason, even if it wasn't a  
> good one, understanding why might be useful.
>
> Martin
>
> --- On Tue, 2/22/11, Sean Olson  wrote:
>
>> From: Sean Olson 
>> Subject: Re: [Bf-committers] normal maps, red/green channel inverted
>> To: "bf-blender developers" 
>> Received: Tuesday, February 22, 2011, 4:35 PM
>> I also could not agree
>> more.   Some standardization here would get
>> rid of
>> plenty of headaches.  To be clear, the step that I
>> would like to avoid is
>> under:
>> "GIMPing the image" on this page:
>> http://www.foro3d.com/f217/blender-normal-mapping-76567.html
>>
>> (It's basically just instructing to invert the green
>> channel)
>>
>> I
>> believe it
>> worked this way in 2.49 and currently works this way also
>> though I have not
>> tested very recently.
>>
>> If I recall the results of the last mailing list
>> conversation on this
>> subject, the consensus was that there is no 'standard' on
>> ways to do normal
>> mapping so Blender's is as good as anybody else's, and is
>> not technically
>> 'wrong'.  The problem is that most of the other apps
>> have standardized in
>> 'the other method'.  I tried tracking the email thread
>> down, but after about
>> an hour of digging have given up.
>>
>> -Sean
>>
>>
>> On Tue, Feb 22, 2011 at 12:26 PM, Morten Mikkelsen > >wrote:
>>

> Make it standard please, nmaps are something
>> that you usually share
> between softwares. no point in forcing
>> headaches to users

> Daniel Salazar

>>>
>>> May your first born be a son and may your harvest be
>> plentiful!! :)
>>> I could not agree more. That's exactly why this patch
>> needs to go in asap.
>>> Normal maps are indeed typically exported between
>> tools.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>


 2011/2/22 Knapp :
> Just provide an external tool or add-on to
>> fix the files. Perhaps pop
>>> up
 a
> warning: this file has a broken bump-map,
>> run XXX to fix it.
>
> On Tue, Feb 22, 2011 at 7:45 PM, Thomas
>> Dinges 
 wrote:
>
>> I wouldn't do a hackish button either,
>> if it works correct as in 2.49
>> it's fine and all we need.
>>
>> Am 22.02.2011 19:33, schrieb Ton
>> Roosendaal:
>>> Hi all,
>>>
>>> The situation is worse apparently;
>> up to Blender 2.49 the normal
>>> maps
>>> were fine, but the "newbump" patch
>> in 2.51 made red channel become
>>> badly inverted.
>>>
>>> Having it work like in 2.49 is of
>> course correct. Brings up the
>>> question if we should provide a
>> hackish button to support bad normal
>>> maps created in the alpha/beta
>> period.
>>>
>>> Morton's&  Mario's
>> proposal is to not do this. I agree, it only
>>> makes
>>> UI uglier... :)
>>>
>>> -Ton-
>>>
>>>

>> 
>>> Ton Roosendaal  Blender
>> Foundation   t...@blender.org
 www.blender.org
>>> Blender
>> Institute   Entrepotdok 57A  1018AD
>> Amsterdam   The
 Netherlands
>>>
>>> On 20 Feb, 2011, at 14:45, Dalai
>> Felinto wrote:
>>>
 Instead of "old Blender Normal
>> maps" couldn't it be "invert color
 channels [tooltip: old Blender
>> Normal Maps - invert red/green
 channels"? Or Blender was
>> really the only software out there using
 those inverted?

 I remember this being discussed
>> a while ago (1year or +) but don't
 remember what was the outcome
>> of it.

 --
 Dalai

 2011/2/20 Ton Roosendaal:
> Hi,
>
> I think Carsten's proposal
>> is the nicest way, even when a bit
 "ug

Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [35108] trunk/blender: added image-editor operators:

[Brecht Van Lommel]

Hi,

Some comments on the code:

> +static int image_invert_exec(bContext *C, wmOperator *op) {
> +       Image *ima= CTX_data_edit_image(C);
> +       ImBuf *ibuf= BKE_image_get_ibuf(ima, NULL);
> +
> +       // flags indicate if this channel should be inverted
> +       short r,g,b,a;
> +       int i;
> +
> +       r = RNA_boolean_get(op->ptr, "inv_r");
> +       g = RNA_boolean_get(op->ptr, "inv_g");
> +       b = RNA_boolean_get(op->ptr, "inv_b");
> +       a = RNA_boolean_get(op->ptr, "inv_a");
> +
> +       /* TODO: make this into an IMB_invert_channels(ibuf,r,g,b,a) method!? 
> */
> +       if (ibuf->rect_float) {
> +
> +               float *fp = (float *) ibuf->rect_float;
> +               for( i = ibuf->x * ibuf->y; i > 0; i--, fp+=4 ) {
> +                       if( r ) fp[0] = 1.0f - fp[0];
> +                       if( g ) fp[1] = 1.0f - fp[1];
> +                       if( b ) fp[2] = 1.0f - fp[2];
> +                       if( a ) fp[3] = 1.0f - fp[3];
> +               }
> +               IMB_rect_from_float(ibuf);
> +       }
> +       else if(ibuf->rect) {
> +
> +               char *cp = (char *) ibuf->rect;
> +               for( i = ibuf->x * ibuf->y; i > 0; i--, cp+=4 ) {
> +                       if( r ) cp[0] = 255 - cp[0];
> +                       if( g ) cp[1] = 255 - cp[1];
> +                       if( b ) cp[2] = 255 - cp[2];
> +                       if( a ) cp[3] = 255 - cp[3];
> +               }
> +       }
> +       else
> +               return OPERATOR_CANCELLED;
> +
> +       WM_event_add_notifier(C, NC_IMAGE|NA_EDITED, ima);
> +
> +       return OPERATOR_FINISHED;
> +
> +}

The image buffer should be marked as modified: ibuf->userflags |=
IB_BITMAPDIRTY;

> +       RNA_def_boolean(ot->srna, "inv_r", 0, "Red", "Invert Red Channel");
> +       RNA_def_boolean(ot->srna, "inv_g", 0, "Green", "Invert Green 
> Channel");
> +       RNA_def_boolean(ot->srna, "inv_b", 0, "Blue", "Invert Blue Channel");
> +       RNA_def_boolean(ot->srna, "inv_a", 0, "Alpha", "Invert Alpha 
> Channel");

No need to use abbreviations here, change inv_ to invert_.

> @@ -1499,10 +1563,6 @@
>
>        /* flags */
>        ot->flag= OPTYPE_REGISTER|OPTYPE_UNDO;
> -
> -       /* properties */
> -       RNA_def_enum(ot->srna, "method", unpack_method_items, PF_USE_LOCAL, 
> "Method", "How to unpack.");
> -       RNA_def_string(ot->srna, "id", "", 21, "Image Name", "Image datablock 
> name to unpack."); /* XXX, weark!, will fail with library, name collisions */
>  }

Was this intentional, those properties still seem to be used in the
unpack operator?

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

[Bf-committers] Normalization of Vertexgroups?

[Tobias Oelgarte]

As i have noticed, you have now the functionality to normalize vertex 
groups. But it is very unclear which groups will be normalized and which 
are not affected. At least visually you have no feedback which will be 
taken into account and which are not. Is there a part of the UI still 
missing? Or how can you manage that vertex groups are included in 
normalization or not? Can this behavior changed after creation?

I also miss one trivial feature, to fill a vertex group with just enough 
so that the groups are normalized. For example, you have group A and now 
you want to paint on group B that: A.weight + B.weight = 1.0

Many questions. I know. But i could not find any useful documentation on 
this and the UI itself doesn't show it.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Normalization of Vertexgroups?

[Xavier Thomas]

There is also the "auto normalise" vertex group in weight paint mode
(in the Tool side pane-> Brush tab)
My guess and whatt would seems normal is that it only change the
weights value but in such a  way that weights keep the same proportion
compared to the sum of all weight (which would be one after
normalisation).

So if a vertex is part of 2 vertex group and have a weight of 0.5 for
the 1rst group and 1.0 for the second. After normalisation the weights
will be:

0.5/(0.5+1.0) = 0. for the first group

1.0/(0.5+1.0) = 0.666 for the second

After the weight have been normalised, if you paint weight using the
"auto normalize" option, than it is like running "normalize vertex
groups" after each stroke. So if you paint to increase the weight of
the 1rst group than the weight of the second group will diminue.

I hope this was understandable.

Xavier

2011/2/23 Tobias Oelgarte :
> As i have noticed, you have now the functionality to normalize vertex
> groups. But it is very unclear which groups will be normalized and which
> are not affected. At least visually you have no feedback which will be
> taken into account and which are not. Is there a part of the UI still
> missing? Or how can you manage that vertex groups are included in
> normalization or not? Can this behavior changed after creation?
>
> I also miss one trivial feature, to fill a vertex group with just enough
> so that the groups are normalized. For example, you have group A and now
> you want to paint on group B that: A.weight + B.weight = 1.0
>
> Many questions. I know. But i could not find any useful documentation on
> this and the UI itself doesn't show it.
> ___
> 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] Has there been any word on Aligorith?

[Jaevixa McNomera]

Yippie!!!

My whole local Church of about 220 people took time to pray for you
Aligorith!!! I'm SO happy to hear you're ok!

:) :) :) :) :) :) :)

On Tue, Feb 22, 2011 at 5:43 PM, Daniel Salazar - 3Developer.com <
zan...@gmail.com> wrote:

> thanks science!! lots of hugs! talk to you later!
>
> Daniel
>
>
>
> 2011/2/22 Joshua Leung :
> > Hi all,
> >
> > I just want to say that we're fortunately safe and well (apart from
> > being shaken and sleep deprived now).
> >
> > Thanks all for the support and concern :)
> >
> > Joshua/Aligorith
> >
> > On Wed, Feb 23, 2011 at 8:57 AM, Daniel Salazar - 3Developer.com
> >  wrote:
> >> We have tried contacting him but nobody has hes phone number, i have
> >> setup a google page for missing persons and hopefully someone who
> >> knows him can post some info
> >>
> >> As soon as we know something we will post in
> http://twitter.com/#!/graphicall
> >>
> >> Daniel Salazar
> >>
> >>
> >> 2011/2/22 Mike Belanger :
> >>> I was wondering about that today too.  Man the latest earthquakes look
> horrific.  I hope Aligorith is ok.
> >>> Its safe to say if he's ok, he'll reply to this thread.
> >>>
> >>> On 2011-02-22, at 11:11 AM, Jaevixa McNomera wrote:
> >>>
>  Sorry if this is not the place for this email, but can it stated in
> here
>  when someone hears word on Aligorith?
> 
>  The IP's I can get to are somewhat restricted here in the hospital
> (but of
>  course I can get Google) so I can't always see other sites (notably
>  graphicall.org is blocked from in here...)
> 
>  Thanks.
>  ___
>  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
> >
> ___
> 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] Normalization of Vertexgroups?

[Tobias Oelgarte]

Sorry, but i know that already. But some groups seam to be included in 
normalization progress (if created with auto normalize on) and some are 
excluded (if created with auto normalize off). But you can't see it 
later on if a group is excluded from auto normalize or not. Also you 
can't change the "normalization type" for this vertex groups. Meaning 
that auto normalize will not have an effect on them, while other groups 
are included in normalization.

Thinking straight forward, then there should be a button (option) for 
the vertex groups to be included or excluded from normalization.

One more thing i noticed is that auto normalize fails on overlapping 
left/right vertex groups (with x-mirror). The side you are painting on 
is handled fine, but the other side will get different results, as in 
your example calculation. (Guess it ignores that the mirroring will also 
switch the left/right names of the groups)

Am 23.02.2011 15:44, schrieb Xavier Thomas:
> There is also the "auto normalise" vertex group in weight paint mode
> (in the Tool side pane->  Brush tab)
> My guess and whatt would seems normal is that it only change the
> weights value but in such a  way that weights keep the same proportion
> compared to the sum of all weight (which would be one after
> normalisation).
>
> So if a vertex is part of 2 vertex group and have a weight of 0.5 for
> the 1rst group and 1.0 for the second. After normalisation the weights
> will be:
>
> 0.5/(0.5+1.0) = 0. for the first group
>
> 1.0/(0.5+1.0) = 0.666 for the second
>
> After the weight have been normalised, if you paint weight using the
> "auto normalize" option, than it is like running "normalize vertex
> groups" after each stroke. So if you paint to increase the weight of
> the 1rst group than the weight of the second group will diminue.
>
> I hope this was understandable.
>
> Xavier
>
> 2011/2/23 Tobias Oelgarte:
>> As i have noticed, you have now the functionality to normalize vertex
>> groups. But it is very unclear which groups will be normalized and which
>> are not affected. At least visually you have no feedback which will be
>> taken into account and which are not. Is there a part of the UI still
>> missing? Or how can you manage that vertex groups are included in
>> normalization or not? Can this behavior changed after creation?
>>
>> I also miss one trivial feature, to fill a vertex group with just enough
>> so that the groups are normalized. For example, you have group A and now
>> you want to paint on group B that: A.weight + B.weight = 1.0
>>
>> Many questions. I know. But i could not find any useful documentation on
>> this and the UI itself doesn't show it.
>> ___
>> 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] blenderplayer cannot be built with CMake

[IRIE Shinsuke]

Umm... still broken. r35111

jesterking, can you fix the CMake build? Your changes seem to have broken it.


At Tue, 22 Feb 2011 19:38:45 +0200,
Davis Sorenson wrote:
> 
> I can confirm this on Ubuntu 10.10 32 bit r35080, the errors are pretty much
> the same.
> 
> 
> 
> On Tue, Feb 22, 2011 at 7:25 PM, IRIE Shinsuke 
> wrote:
> 
> > Hi,
> >
> > Today I attempted to build Blender with CMake option -DWITH_PLAYER:BOOL=ON,
> > but I got errors as follows:
> >
> > Linking CXX executable ../../bin/blenderplayer
> > ../../lib/libbf_blenkernel.a(pointcache.c.o): In function
> > `ptcache_file_compressed_read':
> > pointcache.c:(.text+0x381d): undefined reference to `LzmaUncompress'
> > ../../lib/libbf_blenkernel.a(pointcache.c.o): In function
> > `ptcache_file_compressed_write':
> > pointcache.c:(.text+0x39a2): undefined reference to `LzmaCompress'
> > ../../lib/libbf_modifiers.a(MOD_decimate.c.o): In function `applyModifier':
> > MOD_decimate.c:(.text+0x463): undefined reference to `LOD_LoadMesh'
> > MOD_decimate.c:(.text+0x47a): undefined reference to `LOD_PreprocessMesh'
> > MOD_decimate.c:(.text+0x493): undefined reference to `LOD_CollapseEdge'
> > MOD_decimate.c:(.text+0x6a5): undefined reference to
> > `LOD_FreeDecimationData'
> > ../../lib/libbf_modifiers.a(MOD_boolean_util.c.o): In function
> > `NewBooleanDerivedMesh_intern':
> > MOD_boolean_util.c:(.text+0x1585): undefined reference to
> > `CSG_NewBooleanFunction'
> > MOD_boolean_util.c:(.text+0x16b3): undefined reference to
> > `CSG_PerformBooleanOperation'
> > MOD_boolean_util.c:(.text+0x16d1): undefined reference to
> > `CSG_OutputFaceDescriptor'
> > MOD_boolean_util.c:(.text+0x16e7): undefined reference to
> > `CSG_OutputVertexDescriptor'
> > MOD_boolean_util.c:(.text+0x175e): undefined reference to
> > `CSG_FreeVertexDescriptor'
> > MOD_boolean_util.c:(.text+0x176d): undefined reference to
> > `CSG_FreeFaceDescriptor'
> > MOD_boolean_util.c:(.text+0x178c): undefined reference to
> > `CSG_FreeBooleanOperation'
> > collect2: ld returned 1 exit status
> > make[2]: *** [bin/blenderplayer] Error 1
> > make[1]: *** [source/blenderplayer/CMakeFiles/blenderplayer.dir/all] Error
> > 2
> > make: *** [all] Error 2
> >
> >
> > I confirmed r34034 is ok, but r34035 or later goes wrong.
> >
> > r35078
> > Ubuntu 10.10 amd64
> >
> > Thanks,
> >
> > IRIE
> > ___
> > 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] Normalization of Vertexgroups?

[Tobias Oelgarte]

Added a bug report for the case that x-mirror is failing together with 
auto normalize and another one for groups excluded from normalization.

Am 23.02.2011 15:57, schrieb Tobias Oelgarte:
> Sorry, but i know that already. But some groups seam to be included in 
> normalization progress (if created with auto normalize on) and some 
> are excluded (if created with auto normalize off). But you can't see 
> it later on if a group is excluded from auto normalize or not. Also 
> you can't change the "normalization type" for this vertex groups. 
> Meaning that auto normalize will not have an effect on them, while 
> other groups are included in normalization.
>
> Thinking straight forward, then there should be a button (option) for 
> the vertex groups to be included or excluded from normalization.
>
> One more thing i noticed is that auto normalize fails on overlapping 
> left/right vertex groups (with x-mirror). The side you are painting on 
> is handled fine, but the other side will get different results, as in 
> your example calculation. (Guess it ignores that the mirroring will 
> also switch the left/right names of the groups)
>
> Am 23.02.2011 15:44, schrieb Xavier Thomas:
>> There is also the "auto normalise" vertex group in weight paint mode
>> (in the Tool side pane->  Brush tab)
>> My guess and whatt would seems normal is that it only change the
>> weights value but in such a  way that weights keep the same proportion
>> compared to the sum of all weight (which would be one after
>> normalisation).
>>
>> So if a vertex is part of 2 vertex group and have a weight of 0.5 for
>> the 1rst group and 1.0 for the second. After normalisation the weights
>> will be:
>>
>> 0.5/(0.5+1.0) = 0. for the first group
>>
>> 1.0/(0.5+1.0) = 0.666 for the second
>>
>> After the weight have been normalised, if you paint weight using the
>> "auto normalize" option, than it is like running "normalize vertex
>> groups" after each stroke. So if you paint to increase the weight of
>> the 1rst group than the weight of the second group will diminue.
>>
>> I hope this was understandable.
>>
>> Xavier
>>
>> 2011/2/23 Tobias Oelgarte:
>>> As i have noticed, you have now the functionality to normalize vertex
>>> groups. But it is very unclear which groups will be normalized and 
>>> which
>>> are not affected. At least visually you have no feedback which will be
>>> taken into account and which are not. Is there a part of the UI still
>>> missing? Or how can you manage that vertex groups are included in
>>> normalization or not? Can this behavior changed after creation?
>>>
>>> I also miss one trivial feature, to fill a vertex group with just 
>>> enough
>>> so that the groups are normalized. For example, you have group A and 
>>> now
>>> you want to paint on group B that: A.weight + B.weight = 1.0
>>>
>>> Many questions. I know. But i could not find any useful 
>>> documentation on
>>> this and the UI itself doesn't show it.
>>> ___
>>> 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] MinGW debug builds do not run

[Peter Kümmel]

On 23.02.2011 10:45, Nathan Letwory wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 21.2.2011 1:15, Peter Kümmel wrote:
>> It compiles now out of the box but still crashes.
>> Seems I have to go the 'hard' way you described.
>
> Python 3.1 debug dll is built dynamically linking against msvc9 debug
> runtime, so if you want to run debug with other than vs2008, you'll have
> to acquire the appropriate debug runtime dlls. These are not
> redistributable, so you'll need to get vs2008 (I assume the express
> version will do, but can't tell for sure).
>
> You could also rebuild python 3.1 debug dll with mingw, if that's
> possible, I suppose. And when using vs2010, you could rebuild the python
> 3.1 debug dll with that.
>

OK. Is it possible that these dlls get added to subversion?
I would update the cmake rules then.

Peter

> Anyway, have the correct debug runtime dlls in the same dir as
> blender.exe, and you should be running fine.
>
> /Nathan
>
>>
>> On 20.02.2011 14:46, Campbell Barton wrote:
>>> IIRC MSVC2008 full version is used for releases,
>>> I have a free MSVC2010 which has a similar problem to MinGW, debug
>>> builds fail to run with strange popup dialog error.
>>>
>>> Re Crash on startup:
>>>If its a crash (not a linking/error message), best not assume blender
>>> is without fault, debug info&   call-stack can help a lot in tracking
>>> down these problems.
>>>
>>> The IOError define is already in lib/windows, committed shortly after
>>> changing the exception.
>>> I use an update alias which does both repo's before building to
>>> prevent these kinds of errors.
>>>
>>> Do you still get the crash on startup?
>>>
>>> On Sun, Feb 20, 2011 at 11:54 AM, Peter Kümmel   wrote:
 On 20.02.2011 04:24, Campbell Barton wrote:

> Whats supported isn't set in stone, its more a case of which
> configurations are tested& known to work.

 OK, thanks. And what is mostly used for the Windows releases?

>
> this works for me.
> - windows xp
> - mingw-gcc4.5.2, (from mingw's main site)
> - cmake 2.8 (build type set to Release or RelWithDebInfo)
> - blender (tested r34959)

 I had a little bit outdated checkout with 4.4, W7-64Bit, and
 problems with release and debug.

>
> A crash on startup may be a real bug rather then lack of support, you
> could run with gdb and see why its crashing.
> If you are unable to figure out how to fix you could file a bug and
> include a backtace.

 I assume not really a error in blender code, it's the mixture of
 pre-compiled binaries, compiler used for blender, OS, and runtime
 libraries.

 Best is to build everyting with the same compiler.

>
> Another way to help find the cause of the crash is to disable all
> WITH_* options in cmake configuration, WITH_OPENAL, WITH_IMAGE_OPENEXR
> ... etc.
>
> If this works you could try again with usable settings (so you get an
> interface),
> all off except WITH_PYTHON WITH_INSTALL and WITH_PYTHON_INSTALL.

 I already had the idea to try it without python ;)

> After that its trial and error to see which library causes the crash,
> the offending lib could be disabled by default with mingw until its
> fixed properly.
>
> One other thing, you were getting the error 'PyModule_Create2'
> interestingly I got this error too on Linux when trying to load a
> library built with a debug python but finding a release library.

 I could link against the lib/windows version with attached patch.

>
> On Sat, Feb 19, 2011 at 3:26 PM, Peter Kümmel 
> wrote:
>>
>> Tested it with cmake too. It links after a small fix, but
>> crashes immediately after starting. Seems mingw isn't supported.
>>
>> Peter
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJNZNckAAoJEKtfN7KsE0Ttpr8IAI3/xa4WCO373kchO1W7AI16
> ZZSzd9oe9PYgyZqJ3AylmdozyNaEg//EuLFtWQnFqov9XE/tuK/8ZNVOD3Ro2hLK
> tZ6Z38eQjkXaMOrXR/R+yZnbRutsru3P6xqTHfZY7Au65Z8BQaW1LxXZD0LRrB+p
> ITMxB3Tn17wxDEj7AJywVKB4GHhFUMo0vaVdB5LLjnpMXpB+wjGSrvhyZQUStGnb
> y05TAxR+Z6fXgvtHrf967PQAeoVVjdigyCY0UNtOg4YMDAeHSVeIQqYHSsPvXmru
> B4383jq4q/mnUgOcgYJhSrFr1mSx0f7LmeMdWcq6G2XHK+8NTS7aZ8x9pY0xMdE=
> =ifdD
> -END PGP SIGNATURE-
> ___
> 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] blenderplayer cannot be built with CMake

[Dalai Felinto]

We actually never had blenderplayer working for all the system at the
same time. That's why we even had commented (#if 0) code there to make
it easy to build for other plataforms.

I thought Nathan's (jesterKing) commit was to finally get it working,
but I confess that I still haven't had the time to test with
CMake+MSVC.

2011/2/23 IRIE Shinsuke :
> Umm... still broken. r35111
>
> jesterking, can you fix the CMake build? Your changes seem to have broken it.
>
>
> At Tue, 22 Feb 2011 19:38:45 +0200,
> Davis Sorenson wrote:
>>
>> I can confirm this on Ubuntu 10.10 32 bit r35080, the errors are pretty much
>> the same.
>>
>>
>>
>> On Tue, Feb 22, 2011 at 7:25 PM, IRIE Shinsuke 
>> wrote:
>>
>> > Hi,
>> >
>> > Today I attempted to build Blender with CMake option -DWITH_PLAYER:BOOL=ON,
>> > but I got errors as follows:
>> >
>> > Linking CXX executable ../../bin/blenderplayer
>> > ../../lib/libbf_blenkernel.a(pointcache.c.o): In function
>> > `ptcache_file_compressed_read':
>> > pointcache.c:(.text+0x381d): undefined reference to `LzmaUncompress'
>> > ../../lib/libbf_blenkernel.a(pointcache.c.o): In function
>> > `ptcache_file_compressed_write':
>> > pointcache.c:(.text+0x39a2): undefined reference to `LzmaCompress'
>> > ../../lib/libbf_modifiers.a(MOD_decimate.c.o): In function `applyModifier':
>> > MOD_decimate.c:(.text+0x463): undefined reference to `LOD_LoadMesh'
>> > MOD_decimate.c:(.text+0x47a): undefined reference to `LOD_PreprocessMesh'
>> > MOD_decimate.c:(.text+0x493): undefined reference to `LOD_CollapseEdge'
>> > MOD_decimate.c:(.text+0x6a5): undefined reference to
>> > `LOD_FreeDecimationData'
>> > ../../lib/libbf_modifiers.a(MOD_boolean_util.c.o): In function
>> > `NewBooleanDerivedMesh_intern':
>> > MOD_boolean_util.c:(.text+0x1585): undefined reference to
>> > `CSG_NewBooleanFunction'
>> > MOD_boolean_util.c:(.text+0x16b3): undefined reference to
>> > `CSG_PerformBooleanOperation'
>> > MOD_boolean_util.c:(.text+0x16d1): undefined reference to
>> > `CSG_OutputFaceDescriptor'
>> > MOD_boolean_util.c:(.text+0x16e7): undefined reference to
>> > `CSG_OutputVertexDescriptor'
>> > MOD_boolean_util.c:(.text+0x175e): undefined reference to
>> > `CSG_FreeVertexDescriptor'
>> > MOD_boolean_util.c:(.text+0x176d): undefined reference to
>> > `CSG_FreeFaceDescriptor'
>> > MOD_boolean_util.c:(.text+0x178c): undefined reference to
>> > `CSG_FreeBooleanOperation'
>> > collect2: ld returned 1 exit status
>> > make[2]: *** [bin/blenderplayer] Error 1
>> > make[1]: *** [source/blenderplayer/CMakeFiles/blenderplayer.dir/all] Error
>> > 2
>> > make: *** [all] Error 2
>> >
>> >
>> > I confirmed r34034 is ok, but r34035 or later goes wrong.
>> >
>> > r35078
>> > Ubuntu 10.10 amd64
>> >
>> > Thanks,
>> >
>> > IRIE
>> > ___
>> > 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] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [35108] trunk/blender: added image-editor operators:

[M.G. Kishalmi]

> Some comments on the code:
>
> The image buffer should be marked as modified: ibuf->userflags |=
> IB_BITMAPDIRTY;

done.


>> +       RNA_def_boolean(ot->srna, "inv_r", 0, "Red", "Invert Red Channel");
>> +       RNA_def_boolean(ot->srna, "inv_g", 0, "Green", "Invert Green 
>> Channel");
>> +       RNA_def_boolean(ot->srna, "inv_b", 0, "Blue", "Invert Blue Channel");
>> +       RNA_def_boolean(ot->srna, "inv_a", 0, "Alpha", "Invert Alpha 
>> Channel");
>
> No need to use abbreviations here, change inv_ to invert_.

done.


>> -       /* properties */
>> -       RNA_def_enum(ot->srna, "method", unpack_method_items, PF_USE_LOCAL, 
>> "Method", "How to unpack.");
>> -       RNA_def_string(ot->srna, "id", "", 21, "Image Name", "Image 
>> datablock name to unpack."); /* XXX, weark!, will fail with library, name 
>> collisions */
>>  }
>
> Was this intentional, those properties still seem to be used in the
> unpack operator?


not at all intentional. thanks for spotting this one!


r35115

cheers,
 lmg

--
all efforts are waste
   without copy and paste.
tho make sure not fsck
   up copy and cut!
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers