Re: [Bf-committers] Blender 2.64a source package not available in the source download section
Thanks. :) 2012/11/10 Thomas Dinges : > Hi John, > I updated the page now. http://www.blender.org/download/source-code/ > > Regards, > Thomas > > Am 10.11.2012 22:13, schrieb John Zoidberg: >> Hi, >> >> I can't find the source tarball for Blender 2.64a on the usual source >> download page: http://www.blender.org/download/source-code/ >> >> It seems I can get it here: http://download.blender.org/source/ >> but I think the link on the webpage should be updated as well. >> >> Cheers, >> John >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers > > > -- > Thomas Dinges > Blender Developer, Artist and Musician > > www.dingto.org > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers -- Unlock your computing: http://www.getgnulinux.org/ If the above link is down: http://www.linux.com/learn/new-user-guides ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.64a source package not available in the source download section
Also "blender-2.64a.tar.gz.md5sum" appears to be incorrectly formatted. (and sha1sum would be better from what I've heard) 2012/11/10 John Zoidberg : > Hi, > > I can't find the source tarball for Blender 2.64a on the usual source > download page: http://www.blender.org/download/source-code/ > > It seems I can get it here: http://download.blender.org/source/ > but I think the link on the webpage should be updated as well. > > Cheers, > John ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.64a source package not available in the source download section
Hi John, I updated the page now. http://www.blender.org/download/source-code/ Regards, Thomas Am 10.11.2012 22:13, schrieb John Zoidberg: > Hi, > > I can't find the source tarball for Blender 2.64a on the usual source > download page: http://www.blender.org/download/source-code/ > > It seems I can get it here: http://download.blender.org/source/ > but I think the link on the webpage should be updated as well. > > Cheers, > John > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers -- Thomas Dinges Blender Developer, Artist and Musician www.dingto.org ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Blender 2.64a source package not available in the source download section
Hi, I can't find the source tarball for Blender 2.64a on the usual source download page: http://www.blender.org/download/source-code/ It seems I can get it here: http://download.blender.org/source/ but I think the link on the webpage should be updated as well. Cheers, John ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] There is no way to use LLVM as shared library in CMake build
Currently, Blender can use only static libLLVM, while shared OSL
library always uses shared libLLVM if it exists. So, if using shared
OSL library, Blender has to link libLLVM twice as both static one and
shared one.
I think such strange linking should be avoided.
IRIE Shinsuke
12/11/09, IRIE Shinsuke wrote:
> Thanks, Brecht.
>
> However, the additional changes for dynamic linking are not working
> because libLLVMAnalysis.so does not exist. Most of all LLVM libraries
> are contained in libLLVM-3.x.so, so LLVM_LIBRARY must be set such as
> LLVM-3.1, instead.
>
> Now I'm testing the following patch on Uubntu 12.10:
>
> Index: CMakeLists.txt
> ===
> --- CMakeLists.txt(revision 52037)
> +++ CMakeLists.txt(working copy)
> @@ -718,7 +718,7 @@
> if(WITH_LLVM)
> set(LLVM_DIRECTORY ${LIBDIR}/llvm CACHE PATH"Path to the LLVM
> installation")
> set(LLVM_VERSION "3.0" CACHE STRING"Version of LLVM to use")
> -set(LLVM_STATIC YES)
> +set(LLVM_STATIC YES CACHE BOOL"Link LLVM libraries statically")
> if(EXISTS "${LLVM_DIRECTORY}/bin/llvm-config")
> set(LLVM_CONFIG "${LLVM_DIRECTORY}/bin/llvm-config")
> else()
> @@ -733,9 +733,15 @@
> execute_process(COMMAND ${LLVM_CONFIG} --libdir
> OUTPUT_VARIABLE LLVM_LIB_DIR
> OUTPUT_STRIP_TRAILING_WHITESPACE)
> -find_library(LLVM_LIBRARY
> - NAMES LLVMAnalysis # first of a whole bunch of libs to
> get
> - PATHS ${LLVM_LIB_DIR})
> +if(LLVM_STATIC)
> +find_library(LLVM_LIBRARY
> + NAMES LLVMAnalysis # first of a whole bunch of libs
> to get
> + PATHS ${LLVM_LIB_DIR})
> +else()
> +find_library(LLVM_LIBRARY
> + NAMES LLVM-${LLVM_VERSION}
> + PATHS ${LLVM_LIB_DIR})
> +endif()
> message(STATUS "LLVM version = ${LLVM_VERSION}")
> message(STATUS "LLVM dir = ${LLVM_DIRECTORY}")
> message(STATUS "LLVM lib dir = ${LLVM_LIB_DIR}")
>
>
> So far it works fine for me. I'm not sure if this patch works on the
> other distros.
>
> --
> IRIE Shinsuke
>
> 12/11/09, Brecht Van Lommel wrote:
>> Hi,
>>
>> I've committed the llvm-config patch now. Also changed it so it
>> doesn't only look for static libLLVMAnalysis.a, but also dynamic libs.
>> That might not be enough to make it work though.
>>
>> Brecht.
>>
>> On Thu, Nov 8, 2012 at 12:45 PM, IRIE Shinsuke
>> wrote:
>>> Please fix this bug! It's annoying that I have to set
>>> LLVM_DIRECTORY=/usr every time I use cmake...
>>>
>>> It should be easy to fix.
>>>
>>> --
>>> IRIE Shinsuke
>>>
>>> 12/11/05, IRIE Shinsuke wrote:
Hi,
I'm using system-wide LLVM installed in /usr on Ubuntu 12.10, but
CMakeLists.txt cannot find it so I have to specify the directory
explicitly by a command line option -DLLVM_DIRECTORY=/usr.
The following patch should fix this bug:
Index: blender/CMakeLists.txt
===
--- blender/CMakeLists.txt (revision 51867)
+++ blender/CMakeLists.txt (working copy)
@@ -715,7 +715,7 @@
set(LLVM_DIRECTORY ${LIBDIR}/llvm CACHE PATH"Path to
the LLVM installation")
set(LLVM_VERSION "3.0" CACHE STRING "Version of LLVM
to use")
set(LLVM_STATIC YES)
- if(LLVM_DIRECTORY)
+ if(EXISTS "${LLVM_DIRECTORY}/bin/llvm-config")
set(LLVM_CONFIG
"${LLVM_DIRECTORY}/bin/llvm-config")
else()
set(LLVM_CONFIG llvm-config)
>>> ___
>>> 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] Triangulate modifier
Exactly, the point is not display, but data availability for baking. A
{0,1,2} {2,1,3} scheme is also being considered for the modifier.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Triangulate modifier
I'm not sure I get what you are suggesting here, but the point of the modifier (and why it was requested) is to give consistent triangulation between the baker and the final mesh before baking normal maps. These can then be exported into a game engine, while still maintaining a non-destructive work flow and retaining the original topology of the initial mesh. Normal maps require that the geometry/topology of the low poly mesh is 100% identical to the mesh used for baking in order to work correctly, otherwise the normal map will likely be compensating for edges/faces that are flipped another way and thus provide an incorrect result and therefore shading errors in the final result. The triangulation modifier is the most reliable way that I am aware of to do this in a non destructive way while guaranteeing identical topology between the mesh used for baking and the final exported asset. :) On 10/11/2012 16:57, CoDEmanX wrote: > We already have tesselation (tris+quad), and you can turn the quads into > triangles by taking vert 0,1,2 and 2,3,0. That will give you a > triangulation like seen in Blender viewport. So why not use tessfaces? > I'd like to have a viewport option to show triangulation edges, but I > can't see the reason for triangulation modifier. > > btw. I wrote a little script to make tessellation visible why creating a > new mesh from tessfaces: > http://blenderartists.org/forum/showthread.php?255806-Release-Tessfaces-to-new-mesh-(makes-tessellation-visible) > > Am 10.11.2012 15:10, schrieb Morten Mikkelsen: When baking with an all quad mesh, the triangulation that is done internally in Morten's TS might not match the manual triangulation that the user applies on export, which potentially could cause issues because >> This is not exactly the issue. Let me clarify. >> The mikktspace part is done at quad level if there are quads and will >> always give the same >> tangent spaces at vertex level no matter what the order of vertices or >> faces is. >> This is its very strong advantage which other tangent space calculators >> can't do. >> >> After mikktspace has already run the problem occurs at a later stage >> because before rendering/baking triangulation has to have been performed. >> So the issue is eventhough the tangent spaces at the vertices aren't >> impacted by how quads are triangulated (since triangulation happens later) >> the interpolated tangent space is heavily impacted by which diagonal is >> picked. Similar to how Gouraud shading is heavily impacted by which >> diagonal is picked. So eventhough tangent space is consistent at the >> vertices you get problems if baker and render don't pick the same >> triangulation >> due to differences in the interpolated tangent space. >> >> I should mention I am using "render triangulation" loosely here since it >> can happen in a lot of places though for a game it would typically happen >> somewhere in the engine's tools pipeline. Anyway the advantage to this >> modifier is it enforces a consistent triangulation which will be received >> by both baker and renderer (incl. Blender's renderer). Further, this is >> achieved without causing permanent triangulation. >> It's a sensible practice which is already used by artists in other modeling >> products. >> >> Morten M. >> ___ >> 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] Triangulate modifier
Thanks for the clarification, Morten! You are of course 100% correct. :) -Andy On 10/11/2012 14:10, Morten Mikkelsen wrote: >>> When baking with an all quad mesh, the triangulation that is done >>> internally in Morten's TS might not match the manual triangulation that >>> the user applies on export, which potentially could cause issues because > This is not exactly the issue. Let me clarify. > The mikktspace part is done at quad level if there are quads and will > always give the same > tangent spaces at vertex level no matter what the order of vertices or > faces is. > This is its very strong advantage which other tangent space calculators > can't do. > > After mikktspace has already run the problem occurs at a later stage > because before rendering/baking triangulation has to have been performed. > So the issue is eventhough the tangent spaces at the vertices aren't > impacted by how quads are triangulated (since triangulation happens later) > the interpolated tangent space is heavily impacted by which diagonal is > picked. Similar to how Gouraud shading is heavily impacted by which > diagonal is picked. So eventhough tangent space is consistent at the > vertices you get problems if baker and render don't pick the same > triangulation > due to differences in the interpolated tangent space. > > I should mention I am using "render triangulation" loosely here since it > can happen in a lot of places though for a game it would typically happen > somewhere in the engine's tools pipeline. Anyway the advantage to this > modifier is it enforces a consistent triangulation which will be received > by both baker and renderer (incl. Blender's renderer). Further, this is > achieved without causing permanent triangulation. > It's a sensible practice which is already used by artists in other modeling > products. > > Morten M. > ___ > 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] Triangulate modifier
We already have tesselation (tris+quad), and you can turn the quads into triangles by taking vert 0,1,2 and 2,3,0. That will give you a triangulation like seen in Blender viewport. So why not use tessfaces? I'd like to have a viewport option to show triangulation edges, but I can't see the reason for triangulation modifier. btw. I wrote a little script to make tessellation visible why creating a new mesh from tessfaces: http://blenderartists.org/forum/showthread.php?255806-Release-Tessfaces-to-new-mesh-(makes-tessellation-visible) Am 10.11.2012 15:10, schrieb Morten Mikkelsen: >> >>> When baking with an all quad mesh, the triangulation that is done >>> internally in Morten's TS might not match the manual triangulation that >>> the user applies on export, which potentially could cause issues because >> > > This is not exactly the issue. Let me clarify. > The mikktspace part is done at quad level if there are quads and will > always give the same > tangent spaces at vertex level no matter what the order of vertices or > faces is. > This is its very strong advantage which other tangent space calculators > can't do. > > After mikktspace has already run the problem occurs at a later stage > because before rendering/baking triangulation has to have been performed. > So the issue is eventhough the tangent spaces at the vertices aren't > impacted by how quads are triangulated (since triangulation happens later) > the interpolated tangent space is heavily impacted by which diagonal is > picked. Similar to how Gouraud shading is heavily impacted by which > diagonal is picked. So eventhough tangent space is consistent at the > vertices you get problems if baker and render don't pick the same > triangulation > due to differences in the interpolated tangent space. > > I should mention I am using "render triangulation" loosely here since it > can happen in a lot of places though for a game it would typically happen > somewhere in the engine's tools pipeline. Anyway the advantage to this > modifier is it enforces a consistent triangulation which will be received > by both baker and renderer (incl. Blender's renderer). Further, this is > achieved without causing permanent triangulation. > It's a sensible practice which is already used by artists in other modeling > products. > > Morten M. > ___ > 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] Triangulate modifier
> > >When baking with an all quad mesh, the triangulation that is done > >internally in Morten's TS might not match the manual triangulation that > >the user applies on export, which potentially could cause issues because > This is not exactly the issue. Let me clarify. The mikktspace part is done at quad level if there are quads and will always give the same tangent spaces at vertex level no matter what the order of vertices or faces is. This is its very strong advantage which other tangent space calculators can't do. After mikktspace has already run the problem occurs at a later stage because before rendering/baking triangulation has to have been performed. So the issue is eventhough the tangent spaces at the vertices aren't impacted by how quads are triangulated (since triangulation happens later) the interpolated tangent space is heavily impacted by which diagonal is picked. Similar to how Gouraud shading is heavily impacted by which diagonal is picked. So eventhough tangent space is consistent at the vertices you get problems if baker and render don't pick the same triangulation due to differences in the interpolated tangent space. I should mention I am using "render triangulation" loosely here since it can happen in a lot of places though for a game it would typically happen somewhere in the engine's tools pipeline. Anyway the advantage to this modifier is it enforces a consistent triangulation which will be received by both baker and renderer (incl. Blender's renderer). Further, this is achieved without causing permanent triangulation. It's a sensible practice which is already used by artists in other modeling products. Morten M. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
