Hi all (and att. Janne),
I have submitted two patches to the tracker:
[#29661] Stability bug fixes for SPH particle physics
http://projects.blender.org/tracker/index.php?func=detail&aid=29661&group_id=9&atid=127
Makes simulations more stable, symmetric and reproducible.
[#29663] Multithreading
Please revert changes in properties_scene.py too, causing same errors...
Am 20.12.2011 07:29, schrieb Thomas Dinges:
> Why do you removed some of the COMPAT_ENGINES (properties_scene.py)?
> The GE is not the only one who can hockup here, it's for any other
> engine as well...
>
> Am 20.12.2011 04
Why do you removed some of the COMPAT_ENGINES (properties_scene.py)?
The GE is not the only one who can hockup here, it's for any other
engine as well...
Am 20.12.2011 04:12, schrieb Dalai Felinto:
> Revision: 42750
>
> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-ble
Im looking for MinGW builds on graphicall but everybody is using
MS-express2008. I need a 32bit Windows MinGW build, are there any out there
for download?
-brett-
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman
Thanks Lukas!
> I actually like the way the sockets remain visible when the node is collapsed.
Agree in *some* nodes is nice to have the sockets shown, but default
behavior should be to hide them, as it is not the same case for all
the nodes, so perhaps let the "Toggle Hidden Node Sockets" option
one of the things I was worried about, looks like it might be happening...
- not content to set basic rules, devs want full style guide.
- devs can't agree
- nothing happens
So if we cant get our act together in under a month or so (or if Ton
is busy, since it seems Ton wants to handle this now)
- Original Message -
> From: "Alex Fraser"
> I actually like the way the nodes remain visible when the node is
> collapsed.
I mean sockets :)
Alex
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinf
Hi Lukas,
- Original Message -
> Ok, i just had a discussion with Daniel and Dalai, who also are not
> amused about the removed "hide unused sockets" button ;)
>
> Instead of just adding back this button though, Dalai proposed to add
> a more intelligent auto-hide feature: unused sockets
On Mon, Dec 19, 2011 at 8:03 PM, François T. wrote:
>
> As usual I'm more for the teaching rather the hiding :)
> As Matt said, only comp expert are going to want to mess with this anyway
> (I'm even sure some expert will bypass it in some cases). But people who
> wants to get serious about it wil
On Tue, Dec 20, 2011 at 12:59 AM, Nicholas Bishop
wrote:
> I'm basically fine with this proposal. Don't know if it's worth
> enforcing completely, but if that's the way we want to go I wouldn't
> object to a commit hook enforcing it.
>
> On breaking long lines, this is probably the only thing I ca
I don;t think we need separation by msvc/mingw, it should be more like
separation by libs.
Some libs can't be compiled by mingw (e.g. python) and some can't be
compiled by msvc (e.g. ffmpeg). And if library doesn't use some special
stuff like C++, OpenMP or so i shouldn't be necessary no separate
c
Hi all,
Here's a proposal for how to split the depsgraph work in parts;
hopefully it helps getting this project running that way. There's also
a link to an excellent analysis from Joshua!
http://wiki.blender.org/index.php/User:Ton/Depsgraph_2012
Thanks,
-Ton-
--
Hi,
this is correct. The issue is that sometimes msvc/mingw also share the
header files, which could cause problems if we have very new msvc libs
but old mingw libs.
My main wish is that the different teams (msvc/mingw/msvc2010) can
update their libs separately without worrying about breaking th
Hi Sergey,
Your proposal has very subjective rules, and renders all old code to
be 'bad'.
The idea to have code over many lines with only few characters (to fit
unix terminals) was already outdated when I started C in 1991 (on SGI,
OK :)...
I learned C with SGI code too, using their code a
I'm very glad this issue is finally getting the attention it deserves!
>> If it does, it makes more sense to go with added complexity and force
>> the artist to learn the ins and outs of alpha for certain operations.
>>
> As usual I'm more for the teaching rather the hiding :)
> As Matt said, only
Hi Thomas, I can't really see what is the problem, since MinGW
libraries usually use the lib.a naming so there are no name
clashes between msvc/mingw. Now, there was also a discussion about
making a separate directory for each of msvc08 msvc10 mingw so that
builders can download only the one needed
Thanks Philippe, I'm having a look at them right now.
Martin
>
> From: Philippe Van Hecke
>To: bf-committers@blender.org
>Sent: Monday, December 19, 2011 2:20:40 AM
>Subject: [Bf-committers] netrender addon patch to correctly send smoke cache
>from cli
>
>Hi
Quick reply on DEM node,
Yes that's ready, Lukas Tonne said he'd review.
The 2D mask editor code is working on the "mask" side, but I had 0% of
the UI code for it done, so that'll be at least 2.63. Discussed some
important things with Sebastian and Daniel. Will send UI proposal in
shortly. Will h
I'm basically fine with this proposal. Don't know if it's worth
enforcing completely, but if that's the way we want to go I wouldn't
object to a commit hook enforcing it.
On breaking long lines, this is probably the only thing I care
strongly about. I find it very helpful to split my editor into
m
Hi,
I think the way this should work is good defaults that work without
the user having to think about it, and then extra controls for those
who want more control.
It's not true that unassociated stores most information, it can't
store a rendered object that is both transparent and emitting light
>
> I prefer no space, don't see why there should be a difference because
> one is a keyword and the other a function call, it's still just an
> arbitrary choice. But I can live with the proposed coding style up to
> now.
>
It's just more matter of readability which is a bit subjective and
unfortu
2011/12/19 François T. :
>>
>>
>>
>> If it does, it makes more sense to go with added complexity and force
>> the artist to learn the ins and outs of alpha for certain operations.
>>
>>
> As usual I'm more for the teaching rather the hiding :)
> As Matt said, only comp expert are going to want to m
Hi,
On Mon, Dec 19, 2011 at 1:00 PM, Bastien Montagne wrote:
>>> 2) Spacing *should* be used between a builtin keyword and an opening
>>> brace. Keywords != function calls.
>>>
>> I wouldn't be so categoric here and say "it might be used". Reading code
>> from BKE/BLI i didn't see way which is mo
Hi all,
Thanks for the feedback.
As i see people prefer ore "space-ish" style. Changed proposal to use "a =
b" and "for (..)" style. Also made each-line-markers referable for
multiline comments.
Will also add more code samples soon and try to cover such situations as
"if (flag & SOMEFLAG)" vs. "
Hi,
Nice proposal! :)
Le 19/12/2011 11:56, Sergey Sharybin a écrit :
> Hi,
>
> On Mon, Dec 19, 2011 at 4:24 PM, Joshua Leung wrote:
>
>> Hi,
>>
>> Over the weekend, I've posted my thoughts on a few of these issues [1].
>>
> Will check that soon (when all curent ssvn merge stuff is over)
>
>> Reg
On Mon, Dec 19, 2011 at 9:56 PM, Sergey Sharybin wrote:
> Hi,
>
> On Mon, Dec 19, 2011 at 4:24 PM, Joshua Leung wrote:
>
>> Hi,
>>
>> Over the weekend, I've posted my thoughts on a few of these issues [1].
>>
> Will check that soon (when all curent ssvn merge stuff is over)
>
>>
>> Regarding your
Hi,
On Mon, Dec 19, 2011 at 4:24 PM, Joshua Leung wrote:
> Hi,
>
> Over the weekend, I've posted my thoughts on a few of these issues [1].
>
Will check that soon (when all curent ssvn merge stuff is over)
>
> Regarding your proposal, I agree with most of the issues brought up.
> HOWEVER,
> 1) I
Hi,
Over the weekend, I've posted my thoughts on a few of these issues [1].
Regarding your proposal, I agree with most of the issues brought up. HOWEVER,
1) I prefer the version of comments with a starting indicator on each
line + closing on a separate line. Apart from having seen it used all
ove
Hi,
I've prepared first draft of code style guideline [1]. Of course it needed
to be finished and probably more adopted for existing code style in
Blender, i'll continue working on this. Want to have feedback from active
debelopers about things from rules needed to be discussed section.
Also feel
+1
That was my 1st idea, but keep in mind that preprocessing does not solve
all cases:
#define STR_SIZE 32
char* s1[STR_SIZE];
char* s2[STR_SIZE*2];
char *s3[STR_SIZE+2];
will preprocess to:
char* s1[32];
char* s2[32*2];
char *s3[32 +2];
which was not handled by makesdna (at least the last tim
Ok, i just had a discussion with Daniel and Dalai, who also are not
amused about the removed "hide unused sockets" button ;)
Instead of just adding back this button though, Dalai proposed to add
a more intelligent auto-hide feature: unused sockets are automatically
hidden in collapsed node mode. T
>
>
>
> If it does, it makes more sense to go with added complexity and force
> the artist to learn the ins and outs of alpha for certain operations.
>
>
As usual I'm more for the teaching rather the hiding :)
As Matt said, only comp expert are going to want to mess with this anyway
(I'm even sure
>
> The advice I got from the comp lead on my previous project was that his
> recommended convention for working in Nuke with premultiplied inputs was
> always to manually un-premult before any colour/filtering operations and
> premult back again at the end of that chain before over-ing with other
Hi,
Think i'm one from guys who's responsible for gcc libs. But i can't see why
we need to use different png libs for mingw and msvc.
Basically, only libraries which are using C++ should be definitely split,
but if C++ isn't used in libs it should be possible to use them in both of
mcvc and gcc.
34 matches
Mail list logo
