Re: [Bf-committers] Change of MinGW64 compiler

2012-07-15 Thread Yousef Hurfoush

i used the this build, i though nathan has another one.
the problem is still there!

Regards
Yousef Harfoush
ba...@msn.com



> Date: Sun, 15 Jul 2012 14:42:40 +1000
> From: comcal...@gmail.com
> To: bf-committers@blender.org
> Subject: Re: [Bf-committers] Change of MinGW64 compiler
> 
> It was posted on the mailing list a few weeks ago, you should be using 
> this MinGW-w64 build:
> http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb/release/x86_64-w64-mingw32-gcc-4.7.1-release-win64_rubenvb.7z/download
> 
> Make sure your libraries are up to date before compiling too, good luck :)
> ___
> 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] Change of MinGW64 compiler

2012-07-15 Thread Caleb Joseph
This build is the new one used by the buildbot. What issue are you 
having exactly?

On 15/07/2012 5:16 PM, Yousef Hurfoush wrote:
> i used the this build, i though nathan has another one.
> the problem is still there!
>
> Regards
> Yousef Harfoush
> ba...@msn.com
>


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


[Bf-committers] Blender developer meeting notes - 15 july 2012

2012-07-15 Thread Ton Roosendaal
Hi all,

Here's the notes from today's meeting, irc.freenode.net #blendercoders

1) Blender 2.64 status

- Bugs bugs bugs... tracker keeps stable around 300 open issues. We still need 
more developers to close & fix!

- Campbell Barton suggests to disable some features before release. He'll come 
with a proposal for which ones later.

- New Compositor and Masking can be finished up this month

- Cycles has a lot of open issues, with Brecht on holidays now we might better 
need docs or some tooltip/widget to warn about experimental features. In 
general Cycles' status is better than in 2.63, worth releasing.

- Ton Roosendaal proposes to postpone 2.64 until mid September, and in the 
meantime keep trunk feature-frozen (BCon3), with as exception approved/stable 
work for Mango - which is mostly color pipeline and grading features.


2) Other projects

- Sergey Sharybin will do sequencer work, grading tools. Docs or proposal will 
be published in 2 weeks max.

- Sergej Reich (and Daniel Genrich) proposes to remove the old "Continuous 
physics option - this now becomes default anyway. Will be done together with 
future merger of the Physics GSoC project.

3) Google Summer of Code

- For review: new subdivision surface modifier:
http://wiki.blender.org/index.php/User:Apinzonf/Doc:2.6/Manual/Modifiers/Deform/Laplacian_Smooth

- Sergej Reich reminds everyone to his video of 2 weeks ago: 
http://vimeo.com/45038904

- Google midterm results: out of the 16 projects, 2 students didn't pass 
midterm due to lack of results. That's the projects for Cycles Subsurface 
Scattering and Polygon tessellation. Fourteen students will now head at a 
successful completion of their work! Congrats :)

Laters,

-Ton-


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

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


[Bf-committers] Closing more old To Do

2012-07-15 Thread Fable Fox
These old To Do's can be closed. Reason added in the comment for each To Do.

11732, 4748, 4729, 4750

-- 
Fable Fox
fable...@fablefox.com
http://www.fablefox.com
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers


Re: [Bf-committers] Closing more old To Do

2012-07-15 Thread Bastien Montagne
On 15/07/2012 20:23, Fable Fox wrote:
> These old To Do's can be closed. Reason added in the comment for each To Do.
>
> 11732, 4748, 4729, 4750
>
Done (and thanks for checking that much-borring stuff ;) ).
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers


[Bf-committers] Inpaint node review

2012-07-15 Thread Peter Schlaile
Hi,

I wrote an inpaint node for the compositor.

Since we are directly before a release, I haven't commited it, but I'd
like people to review it.

In case, you don't know, inpainting does this:
http://en.wikipedia.org/wiki/Inpainting

It's use cases in blender are 

* wire removal
* green screen background reconstruction

the later is important to actually improve keying in blender. (see
below)

The node isn't tile based (for fundamental reasons), but very fast,
since it first builds a manhatten distance map and after that performs
color convolution only on the edges.

That's something, one should probably add also to the dilate node (in
step mode) to make it perform a lot better for dilate iterations greater
than 3.

It will bring it's computing time from O(n^3) down to O(n^2).
Take a look here for the details: 
http://ostermiller.org/dilate_and_erode.html )

My aim is implementing something like the IBK Keyer in Nuke
(http://www.youtube.com/watch?v=-GmMC0AYXJ4 ), since all current
solutions within Blender fail on hair details rather badly.

You can see first steps in this direction here, which already do some
nice improvements:
http://peter.schlaile.de/blender/inpaint/

(compare key_raw.png to inpaint_key.png )

The trick I use is the following:

If you consider the usual compositing equation

Composite = Background * (1-ALPHA) + Foreground * ALPHA

for the case, that Background is our GreenScreen and Foreground is the
Object, we want to seperate, you'll notice, that we more or less
successfully can pull an alpha-matte (using a color channel node), but
currently fail to subtract the GreenScreen Background properly from the
Foreground.

That's no surprise, since until now, the GreenScreen Background wasn't
actually known (we don't have any clean plates shot in Mango).

But: we can inpaint the surrounding greenscreen into the area *behind*
the semi-transparent regions and subtract that instead. 

The only thing missing in blender for that task, is said inpainting
node. And that's why I added it :)

So: please use my git repository at

http://gitorious.org/~schlaile/blenderprojects/blender-vse-schlaile

git checkout image-keyer

and tell me your findings.

If I should commit to trunk, please let me know. If team Mango can make
use of it, feel free to commit to tomato branch.

Cheers and good night,
Peter

P.S.: There are a lot more sophisticated solutions for inpainting, some
are convolution based, like my simple approach (which convolves the
known surrounding pixels with a weighted average into the unknown
region), some are a lot more advanced. For all practical reasons (the
ones noted above), my node should work fairly well. If you want to add
additional inpainting algos, feel free to add a type and activate
custom1 as a type parameter variable.

-- 
--
Peter Schlaile



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


Re: [Bf-committers] Inpaint node review

2012-07-15 Thread Nate Wiebe
Not currently building for me on 64bit Linux: http://www.pasteall.org/33827

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


Re: [Bf-committers] Inpaint node review

2012-07-15 Thread Peter Schlaile
Hi Nate,

forgot a CMake-File entry and to add old compositor node file.

Please git pull and try again!

Cheers,
Peter

> Not currently building for me on 64bit Linux: 
> http://www.pasteall.org/33827


-- 
--
Peter Schlaile



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