Re: [Bf-committers] FFMPEG Problem on Linux (Yes, I think it is a Blender problem).
Am 29.06.2011 19:17, schrieb Juan Pablo Bouza: > > Carsten, I didn't find compiling ffmpeg difficult, and I'm not a linux guru, Yep, seems it is not quite easy. > For compiling with x264, you have to install the latest version of libx264. > It compiles easily just with : Ok, this is for ENCODING, I was confused because I can read/play/use vids from my camera in Blender without special options. Thanks for your help, Carsten -- Carsten Wartmann: Autor - Dozent - 3D - Grafik Homepage: http://blenderbuch.de/ Das Blender-Buch: http://blenderbuch.de/redirect.html ___ 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 [37961] branches/cycles/intern/cycles/ cmake/external_libs.cmake: Cycles: cmake changes to make win32 use lib/ windows for boost a
Thank you xavier, got it to work with that corrected path. It was
simpler in the past :(
Daniel Salazar
3Developer.com
On Wed, Jun 29, 2011 at 7:33 PM, Xavier Thomas
wrote:
> I had the same error. I fixed it by using:
> cmake ../blender -DCYCLES_OIIO=../oiio/dist/linux64
>
> 2011/6/29 Daniel Salazar - 3Developer.com
>
>> I'm getting this error now when launching cmake on a clean build dir
>> with "cmake ../blender -DCYCLES_OIIO=../oiio"
>>
>> http://www.pasteall.org/22821
>>
>> dunno if its related to this commit?
>>
>> Daniel Salazar
>> 3Developer.com
>>
>>
>>
>> On Wed, Jun 29, 2011 at 1:18 PM, Brecht Van Lommel
>> wrote:
>> > Revision: 37961
>> >
>> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=37961
>> > Author: blendix
>> > Date: 2011-06-29 19:18:08 + (Wed, 29 Jun 2011)
>> > Log Message:
>> > ---
>> > Cycles: cmake changes to make win32 use lib/windows for boost and
>> openimageio.
>> >
>> > Modified Paths:
>> > --
>> > branches/cycles/intern/cycles/cmake/external_libs.cmake
>> >
>> > Modified: branches/cycles/intern/cycles/cmake/external_libs.cmake
>> > ===
>> > --- branches/cycles/intern/cycles/cmake/external_libs.cmake
>> 2011-06-29 19:16:32 UTC (rev 37960)
>> > +++ branches/cycles/intern/cycles/cmake/external_libs.cmake
>> 2011-06-29 19:18:08 UTC (rev 37961)
>> > @@ -1,4 +1,19 @@
>> >
>> ###
>> > +# Windows lib directory libraries
>> > +
>> > +IF(WIN32)
>> > + if(CMAKE_CL_64)
>> > + set(LIBDIR ${CMAKE_SOURCE_DIR}/../lib/win64)
>> > + else()
>> > + set(LIBDIR ${CMAKE_SOURCE_DIR}/../lib/windows)
>> > + endif()
>> > +
>> > + SET(CYCLES_OIIO ${LIBDIR}/openimageio)
>> > + SET(CYCLES_BOOST ${LIBDIR}/boost)
>> > + SET(Boost_USE_STATIC_LIBS ON)
>> > +ENDIF()
>> > +
>> >
>> +###
>> > # Boost setup
>> >
>> > SET(BOOST_ROOT ${CYCLES_BOOST})
>> > @@ -11,7 +26,7 @@
>> >
>> > SET(Boost_USE_MULTITHREADED ON)
>> >
>> > -FIND_PACKAGE(Boost 1.34 REQUIRED COMPONENTS filesystem regex system
>> serialization thread)
>> > +FIND_PACKAGE(Boost 1.34 REQUIRED COMPONENTS filesystem regex system
>> thread)
>> >
>> > MESSAGE(STATUS "Boost found ${Boost_FOUND}")
>> > MESSAGE(STATUS "Boost version ${Boost_VERSION}")
>> >
>> > ___
>> > Bf-blender-cvs mailing list
>> > bf-blender-...@blender.org
>> > http://lists.blender.org/mailman/listinfo/bf-blender-cvs
>> >
>> ___
>> 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 [37885] trunk/blender: cleanup for cmake msvc build options, reference some libs directly, fix conflicting flags /Ob1 and /Zi for
Strange, msvc 2008 and 2010 work ok here, does replacing this line fix it?
717:
set(PLATFORM_LINKFLAGS "/SUBSYSTEM:CONSOLE /STACK:2097152
/INCREMENTAL:NO
/NODEFAULTLIB:msvcrt.lib\;msvcmrt.lib\;msvcurt.lib\;msvcrtd.lib ")
With
set(PLATFORM_LINKFLAGS "/SUBSYSTEM:CONSOLE /STACK:2097152
/INCREMENTAL:NO /NODEFAULTLIB:\"msvcrt.lib\"
/NODEFAULTLIB:\"msvcmrt.lib\" /NODEFAULTLIB:\"msvcurt.lib\"
/NODEFAULTLIB:\"msvcrtd.lib\" ")
(both 1 line)
Both work ok for me with msvc2010.
On Thu, Jun 30, 2011 at 5:27 AM, Alex K wrote:
> Hi.
> This patch causes build error with cmake + vs2010:
> error MSB6001: Invalid command line switch for "CL.exe". The value
> [BUILD_LINKFLAGS="/MACHINE:X64 /OPT:NOREF /SUBSYSTEM:CONSOLE /STACK:2097152
> /INCREMENTAL:NO /NODEFAULTLIB:msvcrt.lib] contains an odd number of
> double-quote characters. Only even numbers of literal double-quote
> characters are acceptable to command line tools. C:\Program Files
> (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\x64\Microsoft.Cpp.x64.Targets
> When CMakeLists.txt and macros.cmake reversed to 37884, Blender builds fine.
>
> Alex
>
>
> On Mon, Jun 27, 2011 at 10:49 PM, Campbell Barton wrote:
>
>> Revision: 37885
>>
>> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=37885
>> Author: campbellbarton
>> Date: 2011-06-28 02:49:49 + (Tue, 28 Jun 2011)
>> Log Message:
>> ---
>> cleanup for cmake msvc build options, reference some libs directly, fix
>> conflicting flags /Ob1 and /Zi for debug
>>
>> Modified Paths:
>> --
>> trunk/blender/CMakeLists.txt
>> trunk/blender/build_files/cmake/macros.cmake
>> trunk/blender/build_files/scons/config/win32-vc-config.py
>> trunk/blender/build_files/scons/config/win64-vc-config.py
>>
>> Modified: trunk/blender/CMakeLists.txt
>> ===
>> --- trunk/blender/CMakeLists.txt 2011-06-28 02:12:31 UTC (rev 37884)
>> +++ trunk/blender/CMakeLists.txt 2011-06-28 02:49:49 UTC (rev 37885)
>> @@ -243,13 +243,26 @@
>> set(WITH_BINRELOC OFF)
>>
>> # MAXOSX only, set to avoid uninitialized
>> -set(EXETYPE "")
>> +set(EXETYPE)
>>
>> +# C/C++ flags
>> +set(PLATFORM_CFLAGS)
>> +
>> # these are added to later on.
>> -set(C_WARNINGS "")
>> -set(CXX_WARNINGS "")
>> +set(C_WARNINGS)
>> +set(CXX_WARNINGS)
>>
>> +# libraries to link the binary with passed to target_link_libraries()
>> +# known as LLIBS to scons
>> +set(PLATFORM_LINKLIBS)
>>
>> +# Added to linker flags in setup_liblinks
>> +# - CMAKE_EXE_LINKER_FLAGS
>> +# - CMAKE_EXE_LINKER_FLAGS_DEBUG
>> +set(PLATFORM_LINKFLAGS)
>> +set(PLATFORM_LINKFLAGS_DEBUG)
>> +
>> +
>> # disabled for now, not supported
>> # option(WITH_WEBPLUGIN "Enable Web Plugin (Unix only)" OFF)
>>
>> @@ -419,24 +432,24 @@
>> endif()
>>
>> # OpenSuse needs lutil, ArchLinux not, for now keep, can avoid by
>> using --as-needed
>> - set(LLIBS "-lutil -lc -lm -lpthread -lstdc++")
>> + set(PLATFORM_LINKLIBS "-lutil -lc -lm -lpthread -lstdc++")
>>
>> if(NOT WITH_HEADLESS)
>> find_package(X11 REQUIRED)
>> find_path(X11_XF86keysym_INCLUDE_PATH X11/XF86keysym.h
>> ${X11_INC_SEARCH_PATH})
>> mark_as_advanced(X11_XF86keysym_INCLUDE_PATH)
>>
>> - list(APPEND LLIBS ${X11_X11_LIB})
>> + list(APPEND PLATFORM_LINKLIBS ${X11_X11_LIB})
>>
>> if(WITH_X11_XINPUT)
>> - list(APPEND LLIBS ${X11_Xinput_LIB})
>> + list(APPEND PLATFORM_LINKLIBS ${X11_Xinput_LIB})
>> endif()
>> endif()
>>
>> if(CMAKE_SYSTEM_NAME MATCHES "Linux")
>> if(NOT WITH_PYTHON_MODULE)
>> # BSD's dont use libdl.so
>> - list(APPEND LLIBS -ldl)
>> + list(APPEND PLATFORM_LINKLIBS -ldl)
>> # binreloc is linux only
>> set(BINRELOC_INCLUDE_DIRS
>> ${CMAKE_SOURCE_DIR}/extern/binreloc/include)
>> set(WITH_BINRELOC ON)
>> @@ -547,14 +560,16 @@
>>
>> if(MSVC)
>> if(CMAKE_CL_64)
>> - set(LLIBS ws2_32 vfw32 winmm kernel32 user32 gdi32
>> comdlg32 advapi32 shfolder shell32 ole32 oleaut32 uuid)
>> + set(PLATFORM_LINKLIBS ws2_32 vfw32 winmm kernel32
>> user32 gdi32 comdlg32 advapi32 shfolder shell32 ole32 oleaut32 uuid)
>> else()
>> - set(LLIBS ws2_32 vfw32 winmm kernel32 user32 gdi32
>> comdlg32 advapi32 shfolder shell32 ole32 oleaut32 uuid)
>> + set(PLATFORM_LINKLIBS ws2_32 vfw32 winmm kernel32
>> user32 gdi32 comdlg32 advapi32 shfolder shell32 ole32 oleaut32 uuid)
>> endif()
>> -
>> - set(CMAKE_CXX_FLAGS "/D_CRT_NONSTDC_NO_DEPRECATE
>> /D_CRT_SECURE_NO_DEPRECATE /D_SCL_SECURE_NO_DEPRECATE /D_CONSOLE /D_LIB
>> /nologo /Ob1 /J /W0 /Gd /wd4018 /
Re: [Bf-committers] 2.58a bugfix release?
Hi all, It's always OK to have a stable 2.58a build online, we need to prepare a couple of commits and do final test first though. If everyone's OK, let's not commit changes now that might need user tests, check regressions, report back here or in IRC, and within 24h I'll call for the build! Laters, -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 30 Jun, 2011, at 6:50, Campbell Barton wrote: > 2 more crash fixes: > - OpenGL crash fix for some cards r37881 > - [#27807] bake /w Deep Shadow && strand && children, r37970 > > Of course we will keep getting fixings until 2.59 but think this > reason enough for a 2.58a. > > Ton, did you get your modem working right yet? :) > > On Wed, Jun 29, 2011 at 9:50 AM, Campbell Barton > wrote: >> I've been keeping up with changes in the tracker, and don't thinks >> there are show stoppers for 2.58a. >> >> On Tue, Jun 28, 2011 at 8:20 PM, Sergey I. Sharybin > > wrote: >>> Hi, >>> >>> Have somebody checked bug tracker? Maybe there are additional >>> reported >>> issues which we'd better fix before 2.58a? >>> >>> Campbell Barton wrote: We thought it was all ok, but infact a nasty regression slipped into 2.58 which breaks image texture tiling in r37342. now fixed. There are 2 reports about this, it effects projection painting and and the displace modifier when an image textures used. https://projects.blender.org/tracker/index.php? func=detail&aid=27782 http://projects.blender.org/tracker/index.php?func=detail&aid=27755 A handful of other fixes have been made since the release too. - thumbnail save crashing blender in editmode with linked meshes - in some cases, smart-uv-project failed, projections were also wrong. - multi-res from 2.4x wasn't loading - loading cached sounds leaked ram - Wkey toggle bone flags failed in some cases. - bug clicking in a non-active Blender window - OSX player now works apparently IMHO this is worth a 2.58a. >>> >>> >>> -- >>> With best regards, Sergey I. Sharybin >>> >>> ___ >>> Bf-committers mailing list >>> Bf-committers@blender.org >>> http://lists.blender.org/mailman/listinfo/bf-committers >>> >> >> >> >> -- >> - Campbell >> > > > > -- > - Campbell > ___ > 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] petition to remove 'protected' layers from armature
+1 Obviously (as the report in tracker is mine) this has struck me too. I just don't get this.. This behavior only makes me do a whole lot of monkey work that wasn't necessary before. Every time I update a rig it means dozens of pointless save and reloads. And working on SVN makes it more complicated. Terrible for production Daniel Salazar 3Developer.com On Wed, Jun 29, 2011 at 7:13 PM, Bassam Kurdali wrote: > Hello > > Behavior of protected armature layers has changed a couple of times at > least, to the point where the original design intent is unclear at best. > I propose the option be removed entirely, and revert armature behavior > to that of *protected* layers, as it was in blender 2.49b. > > Link to bug: > http://projects.blender.org/tracker/?group_id=9&atid=498&func=detail&aid=27501 > > Rationale: > In 2.49 we had a good option and a bad option: good was protect, bad was > 'don't protect'. As a result, riggers had to click on 'protect' for > every layer in the (proxy) armature. Protect as an option is effectively > useless, since there is only one real choice. Note that the behavior of > protection has changed during it's existence even prior to 2.5. I'm > currently unaware of a design document that adequatly specifies what > it's for. > > In 2.5 we have two (in my opinion, and others) bad choices. > > Don't protect: rig changes don't propogate to animators (things like > constraints, drivers, transform locks, bone groups, etc.. the rig just > breaks) on this layer. > > protect: you can't pose the rig on this layer. > > So what happens if the rig changes? well, you can either: > -delete and remake the proxy > -protect the layer(/s) save the rig, load the anim file, save it, open > the rig, unprotect... > > BUT: in either case you will lose custom constraints, parenting in the > anim file... so you are left chosing between not getting rig changes, > losing animation data, or fighting to get both working... given that > production rigs change quite a bit, this is a workflow killer, > especially for a small team. > > I believe the change happened during Sintel, so I'm CCing Nathan to see > if he has insight into the change. I'm hoping for a small, calm > discussion between those who understand the issues (coders, and riggers/ > TDs in medium to largish projects) to either come up with a good > design/workflow, or just remove the feature. > > PS I was initially going to email Nathan individually, but then thought > this might just contribute to how opaque this feature has gotten ;) > > > ___ > 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 [37885] trunk/blender: cleanup for cmake msvc build options, reference some libs directly, fix conflicting flags /Ob1 and /Zi for
I did
set(PLATFORM_LINKFLAGS "/SUBSYSTEM:CONSOLE /STACK:2097152
/INCREMENTAL:NO
/NODEFAULTLIB:msvcrt.lib,msvcmrt.lib,msvcurt.lib,msvcrtd.lib")
# MSVC only, Mingw doesnt need
if(CMAKE_CL_64)
set(PLATFORM_LINKFLAGS "/MACHINE:X64 /OPT:NOREF
${PLATFORM_LINKFLAGS}")
else()
set(PLATFORM_LINKFLAGS "/MACHINE:IX86 /LARGEADDRESSAWARE
${PLATFORM_LINKFLAGS}")
endif()
set(PLATFORM_LINKFLAGS_DEBUG "/NODEFAULTLIB:LIBCMT.lib,
libc.lib /FORCE:MULTIPLE")
Dunno, visual studio tried to link LIBCMT.lib in debug mode also, causing a
conflict. /FORCE:MULTIPLE resolved it.
Btw, I used cmake 2.8.4
Thanks,
Alex
___
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 [37986] trunk/blender/source/blender/ editors: Todo item:
On Fri, Jul 1, 2011 at 1:02 AM, Ton Roosendaal wrote: > My preference is something that aligns visually to the seperators between > regions; for testing and hacking pleasure I've added two quick versions, > a small tabbish thing and a triangle. Enable these with debug menu, > ALT+CTRL+D, values 1 or 2. > As far as these go, I think the tabs are pretty good. Another thing that might help too is for them to have a tooltip when the mouse is over them, telling you what they will do (eg. reveal properties region) Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] petition to remove 'protected' layers from armature
IIRC the reason for the protected/unprotected distinction is because of the way Blender updates bones in a linked+proxy armature: it completely overwrites the bone, including all pose information. This doesn't matter for properties/transforms that are animated, since actions are stored separately from the pose bones. But if a pose bone is moved without being keyed, those transforms are completely lost upon saving and loading the file. Same with other properties on pose bones. This was extremely annoying on Sintel, for example, when an animator would change an IK/FK slider, or tweak a bone that wasn't animated, and that would be completely lost if they forgot to key it. So to keep people from shooting themselves in the foot, we made it so that bones on protected layers (e.g. bones that get updated with the linked armature) couldn't be transformed in the first place. I agree that this situation completely sucks and needs to be changed at some point. Updating of bones in proxy armatures should be more intelligent, instead of just overwriting, or Blender should be more intelligent about preserving changes made to proxy poses/properties, so that we can lose the whole protected/unprotected distinction altogether and have everything Just Work(tm). But just sayin' that it's not a totally trivial change. --Nathan On Wed, Jun 29, 2011 at 6:13 PM, Bassam Kurdali wrote: > Hello > > Behavior of protected armature layers has changed a couple of times at > least, to the point where the original design intent is unclear at best. > I propose the option be removed entirely, and revert armature behavior > to that of *protected* layers, as it was in blender 2.49b. > > Link to bug: > http://projects.blender.org/tracker/?group_id=9&atid=498&func=detail&aid=27501 > > Rationale: > In 2.49 we had a good option and a bad option: good was protect, bad was > 'don't protect'. As a result, riggers had to click on 'protect' for > every layer in the (proxy) armature. Protect as an option is effectively > useless, since there is only one real choice. Note that the behavior of > protection has changed during it's existence even prior to 2.5. I'm > currently unaware of a design document that adequatly specifies what > it's for. > > In 2.5 we have two (in my opinion, and others) bad choices. > > Don't protect: rig changes don't propogate to animators (things like > constraints, drivers, transform locks, bone groups, etc.. the rig just > breaks) on this layer. > > protect: you can't pose the rig on this layer. > > So what happens if the rig changes? well, you can either: > -delete and remake the proxy > -protect the layer(/s) save the rig, load the anim file, save it, open > the rig, unprotect... > > BUT: in either case you will lose custom constraints, parenting in the > anim file... so you are left chosing between not getting rig changes, > losing animation data, or fighting to get both working... given that > production rigs change quite a bit, this is a workflow killer, > especially for a small team. > > I believe the change happened during Sintel, so I'm CCing Nathan to see > if he has insight into the change. I'm hoping for a small, calm > discussion between those who understand the issues (coders, and riggers/ > TDs in medium to largish projects) to either come up with a good > design/workflow, or just remove the feature. > > PS I was initially going to email Nathan individually, but then thought > this might just contribute to how opaque this feature has gotten ;) > > > ___ > 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] petition to remove 'protected' layers from armature
Maybe the solution is to have easy access to property flags, hopefully in the same UI where properties are created. We already have some *useful* flags like ['HIDDEN', 'SKIP_SAVE', 'ANIMATABLE'] but they can only be set on creation time from py. It makes more sense to to set them on the fly, here an 'SKIP_PROXY_REFRESH' (working tittle!) seems like the obvious way to go? cheers Daniel Salazar 3Developer.com On Thu, Jun 30, 2011 at 4:38 PM, Nathan Vegdahl wrote: > IIRC the reason for the protected/unprotected distinction is because > of the way Blender updates bones in a linked+proxy armature: it > completely overwrites the bone, including all pose information. This > doesn't matter for properties/transforms that are animated, since > actions are stored separately from the pose bones. But if a pose bone > is moved without being keyed, those transforms are completely lost > upon saving and loading the file. Same with other properties on pose > bones. > > This was extremely annoying on Sintel, for example, when an animator > would change an IK/FK slider, or tweak a bone that wasn't animated, > and that would be completely lost if they forgot to key it. So to > keep people from shooting themselves in the foot, we made it so that > bones on protected layers (e.g. bones that get updated with the linked > armature) couldn't be transformed in the first place. > > I agree that this situation completely sucks and needs to be changed > at some point. Updating of bones in proxy armatures should be more > intelligent, instead of just overwriting, or Blender should be more > intelligent about preserving changes made to proxy poses/properties, > so that we can lose the whole protected/unprotected distinction > altogether and have everything Just Work(tm). > > But just sayin' that it's not a totally trivial change. > > --Nathan > > > On Wed, Jun 29, 2011 at 6:13 PM, Bassam Kurdali > wrote: >> Hello >> >> Behavior of protected armature layers has changed a couple of times at >> least, to the point where the original design intent is unclear at best. >> I propose the option be removed entirely, and revert armature behavior >> to that of *protected* layers, as it was in blender 2.49b. >> >> Link to bug: >> http://projects.blender.org/tracker/?group_id=9&atid=498&func=detail&aid=27501 >> >> Rationale: >> In 2.49 we had a good option and a bad option: good was protect, bad was >> 'don't protect'. As a result, riggers had to click on 'protect' for >> every layer in the (proxy) armature. Protect as an option is effectively >> useless, since there is only one real choice. Note that the behavior of >> protection has changed during it's existence even prior to 2.5. I'm >> currently unaware of a design document that adequatly specifies what >> it's for. >> >> In 2.5 we have two (in my opinion, and others) bad choices. >> >> Don't protect: rig changes don't propogate to animators (things like >> constraints, drivers, transform locks, bone groups, etc.. the rig just >> breaks) on this layer. >> >> protect: you can't pose the rig on this layer. >> >> So what happens if the rig changes? well, you can either: >> -delete and remake the proxy >> -protect the layer(/s) save the rig, load the anim file, save it, open >> the rig, unprotect... >> >> BUT: in either case you will lose custom constraints, parenting in the >> anim file... so you are left chosing between not getting rig changes, >> losing animation data, or fighting to get both working... given that >> production rigs change quite a bit, this is a workflow killer, >> especially for a small team. >> >> I believe the change happened during Sintel, so I'm CCing Nathan to see >> if he has insight into the change. I'm hoping for a small, calm >> discussion between those who understand the issues (coders, and riggers/ >> TDs in medium to largish projects) to either come up with a good >> design/workflow, or just remove the feature. >> >> PS I was initially going to email Nathan individually, but then thought >> this might just contribute to how opaque this feature has gotten ;) >> >> >> ___ >> 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] Collada import support
Hello Peter, One of the first things to check if you're files are not loading in blender, is to check if the files load anywhere (and not just back into 3DS MAX). Find another program which has support for collada, or a collada model viewer. It would also be good to check if the models load in any non-autodesk products. If they do, then try make a very simple test case which fails to load in blender, think cube, empty, 1-3-object scenes and report it to our bug tracker. After that you can iterate, increasing complexity each time, this way bugs can be solved 1 by 1 rather then being handed a complex scene which is too hard to debug and `doesn't work`. On Wed, Jun 29, 2011 at 1:14 PM, Peter Amstutz wrote: > Hello all, > > My development team wants to transition from 3DS Max 2011 to Blender > for character modeling. In order to do so, we need two pieces: the > ability to get our data out of 3DS Max and into Blender, and the > ability to export from Blender to Cal3D. I've already found a Blender > addon that exports to Cal3D. It needs work, but that is something I > can handle and doesn't involve Blender C++ code. > > I have been trying to use Collada to transfer our characters from 3DS > Max to Blender, using the Autodesk-provided Collada exporter on the > Max side. The data consists of meshes, materials, bones, bone weights > and animations. From a cursory examination of the Collada XML file it > appears that all the necessary data is present in the DAE file. > > Unfortunately, the Blender import of Collada doesn't work. The errors > range from "Image not found" (caused by missing paths to textures, > surely not a fatal import error but nevertheless stops import in its > tracks) to corrupted geometry. > > I am in a position that I can devote some time to testing / debugging > / development on the Blender Collada importer to handle our import > needs. I also noticed there is a Google Summer of Code project to > improve Collada animation import. I would like to get in touch with > Blender developers who can tell me about the state of Collada support > in Blender to find our where I should focus my attention and avoid > duplicate effort. I've already checked out Blender trunk and > successfully compiled and run a debug build, so I am ready to go, I > just need some pointers on where to start. > > - Pete > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Collada import support
Hi Peter et al, Meshlab :: http://meshlab.sourceforge.net/ has a reasonable collada import/export facility. Mostly for the model and not for animations/textures etc. GLC Player can read collada (based on http://www.glc-lib.net/) :: http://glc-player.net/index.php Apple OSX Quicklook can also view unrigged Collada models as well. It actually has support for the Transparency Tag and passes the Collada Transparency Tag Test. Mike. On 11/07/01 11:28, Campbell Barton wrote: > Hello Peter, > One of the first things to check if you're files are not loading in > blender, is to check if the files load anywhere (and not just back > into 3DS MAX). > Find another program which has support for collada, or a collada model viewer. > > It would also be good to check if the models load in any non-autodesk > products. > > If they do, then try make a very simple test case which fails to load > in blender, think cube, empty, 1-3-object scenes and report it to our > bug tracker. > > After that you can iterate, increasing complexity each time, this way > bugs can be solved 1 by 1 rather then being handed a complex scene > which is too hard to debug and `doesn't work`. > > On Wed, Jun 29, 2011 at 1:14 PM, Peter Amstutz > wrote: >> Hello all, >> >> My development team wants to transition from 3DS Max 2011 to Blender >> for character modeling. In order to do so, we need two pieces: the >> ability to get our data out of 3DS Max and into Blender, and the >> ability to export from Blender to Cal3D. I've already found a Blender >> addon that exports to Cal3D. It needs work, but that is something I >> can handle and doesn't involve Blender C++ code. >> >> I have been trying to use Collada to transfer our characters from 3DS >> Max to Blender, using the Autodesk-provided Collada exporter on the >> Max side. The data consists of meshes, materials, bones, bone weights >> and animations. From a cursory examination of the Collada XML file it >> appears that all the necessary data is present in the DAE file. >> >> Unfortunately, the Blender import of Collada doesn't work. The errors >> range from "Image not found" (caused by missing paths to textures, >> surely not a fatal import error but nevertheless stops import in its >> tracks) to corrupted geometry. >> >> I am in a position that I can devote some time to testing / debugging >> / development on the Blender Collada importer to handle our import >> needs. I also noticed there is a Google Summer of Code project to >> improve Collada animation import. I would like to get in touch with >> Blender developers who can tell me about the state of Collada support >> in Blender to find our where I should focus my attention and avoid >> duplicate effort. I've already checked out Blender trunk and >> successfully compiled and run a debug build, so I am ready to go, I >> just need some pointers on where to start. >> >> - Pete >> >> ___ >> 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] Cycles and Boost 1.44 (Fedora 14 and above)
hi all, has anyone been able to compile on Fedora 14 (with boost 1.44)? Thanks. ___ 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 [37885] trunk/blender: cleanup for cmake msvc build options, reference some libs directly, fix conflicting flags /Ob1 and /Zi for
Ah 'Debug' broke but not Release which is why it worked for me,
committed fix 37996
On Thu, Jun 30, 2011 at 6:04 PM, Alex K wrote:
> I did
>
>
> set(PLATFORM_LINKFLAGS "/SUBSYSTEM:CONSOLE /STACK:2097152
> /INCREMENTAL:NO
> /NODEFAULTLIB:msvcrt.lib,msvcmrt.lib,msvcurt.lib,msvcrtd.lib")
>
> # MSVC only, Mingw doesnt need
> if(CMAKE_CL_64)
> set(PLATFORM_LINKFLAGS "/MACHINE:X64 /OPT:NOREF
> ${PLATFORM_LINKFLAGS}")
> else()
> set(PLATFORM_LINKFLAGS "/MACHINE:IX86 /LARGEADDRESSAWARE
> ${PLATFORM_LINKFLAGS}")
> endif()
>
> set(PLATFORM_LINKFLAGS_DEBUG "/NODEFAULTLIB:LIBCMT.lib,
> libc.lib /FORCE:MULTIPLE")
>
> Dunno, visual studio tried to link LIBCMT.lib in debug mode also, causing a
> conflict. /FORCE:MULTIPLE resolved it.
> Btw, I used cmake 2.8.4
>
> Thanks,
> Alex
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
--
- Campbell
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
