Ah, OK then, sorry for misunderstanding. I got around the name clashes
by a lot of manual tweaking of the cmakefiles (yep, doing cmake here,
should be easy to combine the two once finished).
Finally managed to get a binary yesterday (with a lot of stuff turned
off, just to see if it worked) at las
I am extremely proud to announce I have the first working build of
blender built with MinGW64 :)
The problem is with pyextensions, look at http://bugs.python.org/issue4709
The solution is to define MS_WIN64 when building with MinGW64.
Caleb, can you please verify?
Also, I still get the issues w
> It would be convenient if you can provide your
> configuration scripts as well.
Also library versions and any diffs needed could help (though for most
libraries I know there are no modifications needed)
___
Bf-committers mailing list
Bf-committers@blen
OK, I am trying OpenEXR with this
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/ray_linn/GCC-4.7.0-with-ada/
build and seeing some progress. There are differences between the
configuration of the two compilers but I hope to get it working.
___
On 22/04/2012 8:40 PM, Antony Riakiotakis wrote:
> I am extremely proud to announce I have the first working build of
> blender built with MinGW64:)
>
> The problem is with pyextensions, look athttp://bugs.python.org/issue4709
>
> The solution is to define MS_WIN64 when building with MinGW64.
Awes
Hi, using the def generated and adding a definition through the
CMakefile did it for me. I am sure if you add a define through the
mingw64 configuration file it will work
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/ma
On 22/04/2012 9:37 PM, Antony Riakiotakis wrote:
> Hi, using the def generated and adding a definition through the
> CMakefile did it for me. I am sure if you add a define through the
> mingw64 configuration file it will work
Cool, didn't realise it was that simple. Compiling now, I'll let you
kn
On 22/04/2012 9:37 PM, Antony Riakiotakis wrote:
> Hi, using the def generated and adding a definition through the
> CMakefile did it for me. I am sure if you add a define through the
> mingw64 configuration file it will work
Hooray! I can confirm adding -DMS_WIN64 to the preprocessor flags lets
Yes, I will ask on this meeting :).
Thanks for confirming!
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
On 22/04/2012 10:25 PM, Caleb Joseph wrote:
> The speed differences are amazing. On the same scene with Cycles, the
> Visual Studio build takes 1min 33.15sec to render, while the MinGW-w64
> build (built with -O3 and -march=nocona) only takes 48.62sec. This is
> 95% faster, almost double the spe
On 22/04/2012 10:27 PM, Antony Riakiotakis wrote:
> Yes, I will ask on this meeting:).
>
> Thanks for confirming!
Currently the only libraries that need to be sorted out on my system are
FFmpeg and SDL which give linking errors, gettext and iconv which need
compiling, and Collada which also need
SDL, iconv and gettext are a go here. FFMpeg also produced errors so I
disabled (which is painful on cmake because you also have to disable
openexr/tiff/cycles...If it cycles/openexr/tiff work on scons with
ffmpeg off then it is definitely a link order issue on cmake that I
should figure out). For
>If it cycles/openexr/tiff work on scons with
>ffmpeg off then it is definitely a link order issue on cmake that I
>should figure out
Gah! I meant:
If cycles/openexr/tiff work on scons with
ffmpeg on then it is definitely a link order issue on cmake that I
should figure out)
sorry for the poll
Hi all,
1) Blender 2.63 Release Candidate
- Testing is in progress still, a bit more testing is always good. Campbell
Barton reports that the showstoppers in BMesh were handled now.
- Release log in progress:
http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.63
- Todo for everyone: d
Hi, to reduce the size of the windows lib folder we will separate the
gcc libraries from the windows folder. The new path will be
lib/mingw32. I will try to make the transition smoothly so that trunk
builds always for people who have both folders available. I will also
update the wiki soon to refle
It would be good to separate visual studio versions too. BOOST and OpenCollada
added a lot of bloat to the Windows folder. 2 Gigabyte of support libs?
Sent from my iPhone
On Apr 22, 2012, at 8:27 AM, Antony Riakiotakis wrote:
> Hi, to reduce the size of the windows lib folder we will separate
Perfectly agree.
Btw, I think it is better to use "set_lib_path" function which vc2010 uses.
It checks whether compiler is vc2010, and assigns special path if it exist.
This can be easily extended to mingw.
On Sun, Apr 22, 2012 at 1:26 PM, Erwin Coumans wrote:
> It would be good to separate visua
I can only agree here as well. MSVC 2008 (used to do releases) should be
the "main" repo and all other compiler libs should be an extra archive. :)
Am 22.04.2012 19:46, schrieb Alexandr Kuznetsov:
> Perfectly agree.
> Btw, I think it is better to use "set_lib_path" function which vc2010 uses.
> I
How about a lib/MSVC2008_64bit folder, replacing the lib/Windows folder
(and perhaps similar for lib/MSVC2010, 32bit and 64 bit separately so that
it is easy to just download the support lbs you need, without the other
compiler/bit versions?
On Sunday, 22 April 2012, Thomas Dinges wrote:
> I can
Many vc2008 compiled libraries works on mingw and vc2010 without a problem.
If we have complete separate directories for each folder, it will take more
space on server and we would have to update lib for each compiler.
On the other hand, I think we can make pointers from lib/MSVC2010 to
lib/Window
Hi, the way I am making this work is by copying the gcc libraries to
lib/mingw32 and setting up links (with svn:externals properties) to
the common libraries inside the main repository lib/windows. Then
during build I (will) simply set the LIB dir appropriately.
This has the disadvantage that it m
I made some experiments with Cycles today and I noticed that AO sees all
faces as opaque, like the internal Renderer did. That means that a face
with glass material (entirely or nearly entirely transparent) will be
dark (itself) at parts close to other geometry. Should AO not have much
less imp
I am pretty sure it does work with transparent BSDF, and not with caustics
i.e. using glass bsdf , so if you are using glass bsdf, use light path node
to switch to transparent bsdf at least for shadow/diffuse rays or whatever
ray you need.
Cheers
2012/4/22 Tobias Oelgarte
> I made some experime
hifor more consistency renaming in the lib folder
i propose also to rename the current windows lib folders to:
lib\windows > lib\win32-MSVC_2008
lib\windows\vc2010 > lib\win32-MSVC_2010
lib\win64 > lib\win64-MSVC_2008
lib\win64\vc2010 > lib\win64-MSVC_2010
can anybody do that?
thanks
Regards
Y
@lukas : at some point Joeren were working on dot to brake compositor lines
create angle and organize pipe. Are you aware of this ?
cheers,
F.
2012/4/22 Ton Roosendaal
> Hi all,
>
> 1) Blender 2.63 Release Candidate
>
> - Testing is in progress still, a bit more testing is always good.
> Cam
As AO is geometry based, as far as I know, it is not supposed to make
difference on its transparency, as at least the basic algorithm only check
for mesh data, but not the material.
2012/4/22 Agustin Benavidez
> I am pretty sure it does work with transparent BSDF, and not with caustics
> i.e. u
Augustin is right, it works, but only for the Transparent BSDF. In
Cycles, Transparent is defined to work as, "render as if there was no
geometry there", which also affects AO and shadow rays.
The case could be made that the Glass BSDF should also work this way
for AO rays, but it gets fuzzy then,
Hi, I would -really- like some guidance with compiling openEXR such
as: openexr/ilmbase version used, configuration options, MinGW64 build
used (MSYS is latest and patches are applied). I have used up to 6
different compiler builds here without result. Ilmbase gets compiled
with some compilers (onl
Hi, just finished moving the gcc libs to a separate lib folder. I
don't think that the main windows folder got a lot smaller (about 200
MB smaller I think) but the mingw32 folder is just 600MB, so there's a
win there.
MinGW builders will need to check out the lib/mingw32 folder from now
on. The b
Hi,
I'm also working on the new modifier to render lines similar to Howard
Trickey's.
http://mimosa-pudica.net/tmp/lineart.png
The main purpose of my modifier is to render cartoon-like
(edge|border|silhouette) lines.
Does Howard Trickey's modifier have the same goals?
On Mon, Apr 23, 2012 at 12:
I believe your modifier is more similar to the Freestyle render engine
project: http://freestyleintegration.wordpress.com/
I believe Howard's modifier is meant as a way to generate geometry along
existing edges and vertices as though it were wire frame.
On Mon, Apr 23, 2012 at 1:48 AM, Yasuhiro F
@francois: Yes, i updated the patch to trunk a few weeks ago and made
a couple of minor modifications. Needs general green light from core
devs, then i guess it could go into 2.64 as well.
On Sun, Apr 22, 2012 at 11:28 PM, François T. wrote:
> @lukas : at some point Joeren were working on dot to
32 matches
Mail list logo
