Re: [Bf-committers] can we update ffmpeg to have RTSP support?
On Wednesday, July 16, 2014 12:55:49 PM Campbell Barton wrote: On the other hand we end up loosing time to support various configurations, its hard to know beforehand if enabling options incurs maintenance overhead. Seems like a special case - couldn't the BlenderCAVE/remote-camera users who want RTSP do their own builds? May I suggest enabling v4l2? In conjunction with the v4l2loopback kernel module (https://github.com/umlaeute/v4l2loopback) you could use it as a shim to interface with any source available to ffmpeg / gstreamer / mlt / whatever support v4l2. That way all you need to deal with is uncompressed video. No codecs to worry about since it's would be decompressed by whatever is feeding the v4l2loopback input. Also a big bonus is that it's non-blocking, unlike a FIFO interface. For windows, I'm sure there is something similar that could be done with directshow. For Mac you might consider something like Syphon. (http://syphon.v002.info/) -Reuben ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] can we update ffmpeg to have RTSP support?
I have a deck link card. And I've redirected the captured video from it to the v4l2loopback device. It can be done using bmdcapture + ffmpeg or gstreamer. Both work quite well. You can do it with melt too, but technically it uses ffmpeg to interface with v4l2. On Jul 16, 2014 12:23 AM, Fazekas László mn...@freemail.hu wrote: I agree. For win32, besides of DirectShow, there is the simple old VfW input. I think it's still working and it has a wrapper for DirectShow. For OSX, the video capture is in the commercial version of Quicktime. But there are incompatible hardwares with their own interface (for example, BMD DeckLink). So perhaps a raw input through a fifo (named pipe) is still a good option. 2014-07-16 05:34 keltezéssel, Reuben Martin írta: On Wednesday, July 16, 2014 12:55:49 PM Campbell Barton wrote: On the other hand we end up loosing time to support various configurations, its hard to know beforehand if enabling options incurs maintenance overhead. Seems like a special case - couldn't the BlenderCAVE/remote-camera users who want RTSP do their own builds? May I suggest enabling v4l2? In conjunction with the v4l2loopback kernel module (https://github.com/umlaeute/v4l2loopback) you could use it as a shim to interface with any source available to ffmpeg / gstreamer / mlt / whatever support v4l2. That way all you need to deal with is uncompressed video. No codecs to worry about since it's would be decompressed by whatever is feeding the v4l2loopback input. Also a big bonus is that it's non-blocking, unlike a FIFO interface. For windows, I'm sure there is something similar that could be done with directshow. For Mac you might consider something like Syphon. (http://syphon.v002.info/) -Reuben ___ 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] HiDPI notes for other OS'es
On Saturday, June 29, 2013 04:47:09 PM Brecht Van Lommel wrote: It's not a reliable value to use, because it's not correctly reported by many monitors, and does not actually correspond to the DPI assumed by any other UI toolkit. I've looked for the right value for quite a while, but only conclusion I can find is that none of Gnome/KDE/Xfce/GTK/Qt/.. have proper high DPI support on Linux/X11, it's just not implemented. If one of them did we could copy the same mechanism to detect DPI. Blog post from yesterday may provide insight into how others are tackling the issue. http://blogs.gnome.org/alexl/2013/06/28/hidpi-support-in-gnome/ -Reuben ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Remove Frameserver
I tried using it when it did work, and even then it didn't provide the functionality that it was intended for. Furthermore, the intended functionality does not fit into the monolithic work flow that blender is designed to facilitate. On Friday, August 03, 2012 12:19:35 AM Thomas Dinges wrote: Hey everyone, Today Campbell, Sergey and I discussed to drop frameserver. The reasoning is, that it's not really used (at all?). Also we got one bug report a few weeks ago, where someone said that its not working at all! (And that over a couple of versions, so it was not used at all, otherwise people would have reported earlier) http://projects.blender.org/tracker/index.php?func=detailaid=32078group_id =9atid=498 Any objections to that? Patch for the removal: http://www.pasteall.org/34253/diff Regards, Thomas ___ 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] Floating buttons proposal
meh, we all do it now and then. I pissed a guy off a few years ago on this list by by being a smart ass when calling him out for posting a long winded email that provided nothing of technical significance, but was little more than a copy and paste of a press release sprinkled with buzzwords. It started my own personal little flame war. People will usually put up with you going off the deep end if you can back your position up. (And be willing to eat your hat when you're wrong.) People passionate about blender ofter have very strong opinions about this stuff. For what it's worth, there might be a good argument for using floating buttons for context specific things that would just be a waste of space in a panel 99% of the time. A good example is the panel that lets you modify the parameters of your previous action. It varies quite drastically in size depending on context, and as a result I'm constantly changing it's size and position in the tool shelf. -Reuben On Saturday, June 16, 2012 09:21:10 AM Michael Fox wrote: sorry for my outburst, i hope no one really takes offence to me, my opinions are my own and i tend to be a little protective of blender, i owe my life to it. some serious things have happened in my life recently and its made me irritable, im usually not like this, so for any offence i have caused im sorry and please excuse me ___ 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] Build error
I've been having this build error the last couple days. SVN is up-to-date. -Reuben Log: [ 17%] Building C object source/blender/blenkernel/CMakeFiles/bf_blenkernel.dir/intern/collision.c.o source/blender/blenkernel/intern/collision.c: In function ‘edgepair_cmp’: source/blender/blenkernel/intern/collision.c:636:19: warning: initialization discards qualifiers from pointer target type source/blender/blenkernel/intern/collision.c:636:28: warning: initialization discards qualifiers from pointer target type source/blender/blenkernel/intern/collision.c:638:6: warning: unused variable ‘keysb’ source/blender/blenkernel/intern/collision.c: In function ‘cloth_edge_collision’: source/blender/blenkernel/intern/collision.c:681:2: warning: initialization from incompatible pointer type source/blender/blenkernel/intern/collision.c:681:2: warning: initialization from incompatible pointer type source/blender/blenkernel/intern/collision.c:681:2: warning: initialization from incompatible pointer type source/blender/blenkernel/intern/collision.c:681:2: warning: initialization from incompatible pointer type source/blender/blenkernel/intern/collision.c:681:2: warning: initialization from incompatible pointer type source/blender/blenkernel/intern/collision.c:681:2: warning: initialization from incompatible pointer type source/blender/blenkernel/intern/collision.c:794:5: warning: passing argument 2 of ‘sub_v3_v3v3’ from incompatible pointer type source/blender/blenlib/intern/math_vector_inline.c:294:14: note: expected ‘const float *’ but argument is of type ‘void **’ source/blender/blenkernel/intern/collision.c:794:5: warning: passing argument 3 of ‘sub_v3_v3v3’ from incompatible pointer type source/blender/blenlib/intern/math_vector_inline.c:294:14: note: expected ‘const float *’ but argument is of type ‘void **’ source/blender/blenkernel/intern/collision.c:795:5: warning: passing argument 2 of ‘sub_v3_v3v3’ from incompatible pointer type source/blender/blenlib/intern/math_vector_inline.c:294:14: note: expected ‘const float *’ but argument is of type ‘void **’ source/blender/blenkernel/intern/collision.c:795:5: warning: passing argument 3 of ‘sub_v3_v3v3’ from incompatible pointer type source/blender/blenlib/intern/math_vector_inline.c:294:14: note: expected ‘const float *’ but argument is of type ‘void **’ source/blender/blenkernel/intern/collision.c:804:5: warning: passing argument 2 of ‘copy_v3_v3’ from incompatible pointer type source/blender/blenlib/intern/math_vector_inline.c:65:14: note: expected ‘const float *’ but argument is of type ‘void **’ source/blender/blenkernel/intern/collision.c:805:5: warning: passing argument 2 of ‘copy_v3_v3’ from incompatible pointer type source/blender/blenlib/intern/math_vector_inline.c:65:14: note: expected ‘const float *’ but argument is of type ‘void **’ source/blender/blenkernel/intern/collision.c:809:5: error: implicit declaration of function ‘eltopo_line_line_moving_isect_v3v3_f’ source/blender/blenkernel/intern/collision.c:778:16: warning: unused variable ‘collp2’ source/blender/blenkernel/intern/collision.c:778:8: warning: unused variable ‘collp1’ source/blender/blenkernel/intern/collision.c:680:8: warning: unused variable ‘n1’ source/blender/blenkernel/intern/collision.c:673:9: warning: unused variable ‘distance’ source/blender/blenkernel/intern/collision.c:672:15: warning: unused variable ‘verts1’ source/blender/blenkernel/intern/collision.c: In function ‘cloth_collision_response_moving’: source/blender/blenkernel/intern/collision.c:948:8: warning: unused variable ‘epsilon2’ source/blender/blenkernel/intern/collision.c:946:15: warning: unused variable ‘v2’ source/blender/blenkernel/intern/collision.c:945:28: warning: unused variable ‘u3’ source/blender/blenkernel/intern/collision.c:945:24: warning: unused variable ‘u2’ source/blender/blenkernel/intern/collision.c:945:20: warning: unused variable ‘u1’ source/blender/blenkernel/intern/collision.c: In function ‘tripair_cmp’: source/blender/blenkernel/intern/collision.c:1131:18: warning: initialization discards qualifiers from pointer target type source/blender/blenkernel/intern/collision.c:1131:27: warning: initialization discards qualifiers from pointer target type source/blender/blenkernel/intern/collision.c:1133:6: warning: unused variable ‘keysb’ source/blender/blenkernel/intern/collision.c: In function ‘cloth_point_tri_moving_v3v3_f’: source/blender/blenkernel/intern/collision.c:1182:2: error: implicit declaration of function ‘eltopo_point_tri_moving_v3v3_f’ source/blender/blenkernel/intern/collision.c: In function ‘cloth_collision’: source/blender/blenkernel/intern/collision.c:1198:21: warning: unused variable ‘p’ source/blender/blenkernel/intern/collision.c:1198:8: warning: unused variable ‘n1’ source/blender/blenkernel/intern/collision.c:1192:9: warning: unused variable ‘distance’ source/blender/blenkernel/intern/collision.c:1191:15: warning: unused variable ‘verts1’
[Bf-committers] Wayland to soon release stable 1.0
http://fosdem.org/2012/interview/kristian-hogsberg Has anybody even looked into porting Blender's toolkit to Wayland? Qt and Gtk toolkits are chomping at the bit to move to Wayland, so I imagine that the Linux distros will begin a hard push to move everything to Wayland in the not- too-distant fiuture. -Reuben ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] CUDA compiler open-sourced
With all the headaches of trying to make Cycles work properly with OpenCL, I thought it was interesting that Nvidia has now open sourced with CUDA compiler as well as the documentation of the intermediate representation. http://pressroom.nvidia.com/easyir/customrel.do?easyirid=A0D622CE9F579F09version=livereleasejsp=release_157xhtml=trueprid=831864 In theory, this could mean that CUDA could eventually be ported to non-nvidia architectures. -Reuben ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] CUDA compiler open-sourced
The devil is in the details. Nobody really knows yet, as they have only made the announcement. I don't think you can actually get ahold of anything yet. And they haven't indicated what licenese it is to be released under. -Reuben On Thursday, December 15, 2011 12:47:32 AM Davis Sorenson wrote: To quote from the linked article: NVIDIA today announced that *it will provide the source code* for the new NVIDIA® CUDA® LLVM-based compiler *to academic researchers and software-tool vendors*, enabling them to more easily add GPU support for more programming languages and support CUDA applications on alternative processor architectures. While It does mention opening (In the title) and source code, the wording is a bit strange. Do they mean that it will be Shared-source like some Microsoft products, or do they mean that it will be under an open-source license? Just thought I would point this out. Either way this is good news, but if it's real open-source it's much better news. Davis On Thu, Dec 15, 2011 at 12:42 AM, Reuben Martin reube...@gmail.com wrote: With all the headaches of trying to make Cycles work properly with OpenCL, I thought it was interesting that Nvidia has now open sourced with CUDA compiler as well as the documentation of the intermediate representation. http://pressroom.nvidia.com/easyir/customrel.do?easyirid=A0D622CE9F579F0 9version=livereleasejsp=release_157xhtml=trueprid=831864 In theory, this could mean that CUDA could eventually be ported to non-nvidia architectures. -Reuben ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Help! Error building blender
On Thursday, December 01, 2011 04:11:08 PM iozk...@gmail.com wrote: I have error building blender latest source LINK: fatal error LNK1104: cannot open file 'libboost_thread-vc100-mt-s-1_47.lib' I'm bulding with python 27 scons The error is rather self explanatory. Make sure the missing file exists, and that is in in the library paths used when linking. -Reuben ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Is alpha within Blender totally broken?
On Saturday, July 16, 2011 02:37:57 PM Troy Sobotka wrote: So far, I've been experimenting with several files and uptake tools using Blender in conjunction with Nuke. I have yet to be able to find a pattern that delivers proper alpha channels.Perhaps someone here can shed some light on the matter. I can't speak for Nuke, but if blender has a bug concerning alpha channels when rendering, then it also has the same bug in the compositer, because I've never had issues keying anything. The first two images look like what happens when trying to key a pre-multiplied image with a white background that isn't properly removing the matte. The second two look like trying to key with the matte being removed, but not useing linear color space blending in the compositing. But I don't know what your actual settings are. Straight-keyed Alpha, CM on, rendered to Half-Exr, Composited with CM on. (in blender) http://img692.imageshack.us/img692/779/compositescreencap.png -Reuben ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Confusing Render, File Format and Encoding presets
On Friday, January 14, 2011, Damir Prebeg wrote: I find organization and interaction of render, file format and encoding presets under render options quite inconsistent and illogical. So here are my proposals: A) First smaller annoyances: Default render preset that we get when Blender is first started is not even listed under Render presets dropdown. Also, there's no option for aspect ratio locking while changing image dimensions. Is there any special reason why actual frame rate is calculated from framerate and framerate base and not simply one float value for framerate (eg. FPS: 23.976 instead of FPS:24 and Base:1.001)? Living in the US I can not stress how much of a PITA it is when dealing with video set as a decimal rather than a frame-rate / frame-base ratio. Causes all sorts of annoying little sync problems. Being able to specify both is invaluable. And there's a bug: Select any Render preset, and then reload startup file (Ctrl+N). All values except selected Render preset name in that dropdown box will be reloaded. What's actually needed is a means to store your own custom presets. (i.e. the settings are not stored in the file, which preset was selected is what is stored) I propose that there should be Default entry by default, implementation of aspect ratio lock and one simple floating point framerate. layout needs to be something logical. Right now different parameters are scattered all over the place and it is a mess. I would propose a render panels to be stacked somthing like this: Render Action Pannel - Select from user-created presets - Render Type (Render Animation, Preview Render, Bake - Enable / Disable Compositor Sequencer Render Settings specific to rendering engine - Aliasing - Sample filter - Dithering - Render Layers - Render feature enable / disable Non-Format or Render Engine Specific Options - Frame Rate, Frame Base - Resolution - Display Aspect Ratio -or- Sample Aspect Ratio (Being able to switch between the two as an option would be super nice) - Field / Frame - Color Range (having the option to clamp YCbCr values to match 601 or 709 spec would be nice) - Stamp Format Type === - Video Format -or- Image Format -or- Frame Server - Format specific options - Codec(s) used (from what is availble for selected format) Codec Options -or- Image Type Options - Codec or Image format specific options == Beyond that I would even recommend dropping support for many of the formats and codecs. Anything with P and B frames in an AVI file is a mess. For that matter I don't understand why blender supports non-intraframe codecs anyway. There are plenty of tools outside of blender to deal with transcoding into distribution formats. Limiting supported video formats (likewise with audio formats) to things like MJPEG, DNxHD, AVC-Intra, FFV1, and other similar intra-frame or lossless codecs would make for a lot less headaches in the sequencer. To be honest I think it's kinda pointless to try to support things like x264 where the amount of options availble (if all exposed) would take up quite a bit of space. But they again, the one option you don't make availale to reduce size is of course the one option I want to get access to. This is why even now, I do all my encoding outside of blender. -Reuben ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Fwd: Copyright violation distributing faac binaries together with GPL software
On Thursday, January 06, 2011, Leo Sutic wrote: The solution is to compile FFmpeg / libavcodec without libfaac. (Throwing out x264 is not an option, as libfaac has more problems than just being GPL-incompatible) It should be a build config change and that's it - but someone has to build a new distribution. Then we should be OK. SVN is down fot the moment, so I haven't been able to look at the 2.49 source to figure out where the change needs to be made. We lose the ability to encode sound using AAC, but nothing more. FFMPEG has their own AAC decoder which should work for the decode side. They have been developing their own AAC encoder as well, but it's still a work in progress. I've always built against my system's ffmpeg (0.6.1+) without any issues. (at least for building) -Reuben ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Fwd: Copyright violation distributing faac binaries together with GPL software
On Thursday, January 06, 2011, Ton Roosendaal wrote: Hi devs, Please advise. I recall libavcodec is quite old already, and probably obsolete mostly because of FFmpg? -Ton- From: Carl Eugen Hoyos Date: 6 January, 2011 17:15:37 GMT+01:00 To: foundat...@blender.org Subject: Copyright violation distributing faac binaries together with GPL software I downloaded blender-2.49b-windows, it contains libavcodec.dll, a binary distribution of libavcodec. The dll contains code from x264, making it GPL (and not LGPL). It also contains code from the libfaac project. Originally, libfaac claimed to be free software (under the LGPL), but unfortunately, this was never true: libfaac is (and always has been) proprietary software. I'm not sure where he is getting this from. There is no libfaac dll shipped in the zip archive, and the dll deos not appear to be statically linked with libfaac. reu...@subterfuge ~ $ strings avcodec-52.dll | grep aac aac_main aac_low aac_ssr aac_ltp Read beyond end of ff_aac_codebook_vectors[%d][]. index %d = %d jaac faacDecInit2 failed r:%d sr:%ld ch:%ld s:%d faac: codec init failed. faac: frame decoding failed: %s aac_adtstoasc aac_adtstoasc_bsf aac_decoder aac_encoder aac_parser ff_aac_ac3_parse ff_aac_codebook_vectors ff_aac_coders ff_aac_kbd_long_1024 ff_aac_kbd_short_128 ff_aac_num_swb_1024 ff_aac_num_swb_128 ff_aac_parse_header ff_aac_pow2sf_tab ff_aac_pred_sfb_max ff_aac_psy_model ff_aac_scalefactor_bits ff_aac_scalefactor_code ff_aac_spectral_bits ff_aac_spectral_codes ff_aac_spectral_sizes I believe all of those strings are comming from the ffmpeg codebase. On _MY_ system where I compiled ffmpeg with libfaac: reu...@subterfuge ~ $ less /usr/lib64/libavcodec.so.52 Dynamic section at offset 0x69e848 contains 47 entries: TagType Name/Value [ ... ] 0x0001 (NEEDED) Shared library: [libfaac.so.0] -Reuben ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Does blender svn cmake build with openCOLLADA
Not sure an about player, but I've been building with collada and cmake for several months. On Oct 25, 2010 8:42 AM, Dave Plater dpla...@webafrica.org.za wrote: Hi, I've created shared openCOLLADA libs to use for blender (They've even got SONAMEs) and I'm also trying to change to cmake, does blender build with cmake with collada and player? You can see the openCOLLADA package at : https://build.opensuse.org/package/show?package=openCOLLADAproject=home%3Aplater%3Ablender the 2.5x blender package is in the same project. I can also build them for fedora, ubuntu, debian, mandriva and centos at a later stage, though I'm not familiar with debian style packages yet. Thanks Dave P ___ 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] Blender Foundation Development Team report week 40
Yo, back on Saturday, October 09, 2010 (Ry)akiotakis (An)tonis was all like: Collada fails to compile for me (Scons- MinGW with gcc 4.5.1) In file included from e:/mingw/lib/gcc/../../include/c++/4.5.1/ext/hash_map:60:0, from E:\blender_svn\lib\windows\gcc\opencollada\include\COLLADABaseUtils\include/COLLADABUPrerequisites.h:41, from E:\blender_svn\lib\windows\gcc\opencollada\include\COLLADABaseUtils\include/Math/COLLADABUMathUtils.h:14, from E:\blender_svn\lib\windows\gcc\opencollada\include\COLLADABaseUtils\include/Math/COLLADABUMathMatrix4.h:16, from E:\blender_svn\lib\windows\gcc\opencollada\include\COLLADAFramework\include/COLLADAFWTypes.h:16, from E:\blender_svn\lib\windows\gcc\opencollada\include\COLLADAFramework\include/COLLADAFWUniqueId.h:15, from source\blender\collada\/SkinInfo.h:31, from source\blender\collada\SkinInfo.cpp:40: e:/mingw/lib/gcc/../../include/c++/4.5.1/backward/backward_warning.h:28:2: warning: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated. In file included from e:/mingw/lib/gcc/../../include/c++/4.5.1/ext/hash_map:60:0, from E:\blender_svn\lib\windows\gcc\opencollada\include\COLLADABaseUtils\include/COLLADABUPrerequisites.h:41, from E:\blender_svn\lib\windows\gcc\opencollada\include\COLLADABaseUtils\include/Math/COLLADABUMathUtils.h:14, from E:\blender_svn\lib\windows\gcc\opencollada\include\COLLADABaseUtils\include/Math/COLLADABUMathMatrix4.h:16, from E:\blender_svn\lib\windows\gcc\opencollada\include\COLLADAFramework\include/COLLADAFWTypes.h:16, from E:\blender_svn\lib\windows\gcc\opencollada\include\COLLADAFramework\include/COLLADAFWUniqueId.h:15, from E:\blender_svn\lib\windows\gcc\opencollada\include\COLLADAFramework\include/COLLADAFWObject.h:15, from E:\blender_svn\lib\windows\gcc\opencollada\include\COLLADAFramework\include/COLLADAFWMeshPrimitive.h:15, from source\blender\collada\MeshImporter.cpp:31: e:/mingw/lib/gcc/../../include/c++/4.5.1/backward/backward_warning.h:28:2: warning: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated. In file included from source\blender\collada\SkinInfo.cpp:34:0: source\blender\editors\include/ED_mesh.h:84:1: error: 'intptr_t' does not name a type In file included from E:\blender_svn\lib\windows\gcc\opencollada\include\COLLADAFramework\include/COLLADAFWPolygons.h:15:0, from source\blender\collada\MeshImporter.cpp:33: E:\blender_svn\lib\windows\gcc\opencollada\include\COLLADAFramework\include/COLLADAFWMeshPrimitiveWithFaceVertexCount.h: In member function 'const int COLLADAFW::MeshPrimitiveWithFaceVertexCountVertexCountType::getGroupedVerticesVertexCount(size_t) const': E:\blender_svn\lib\windows\gcc\opencollada\include\COLLADAFramework\include/COLLADAFWMeshPrimitiveWithFaceVertexCount.h:90:17: error: 'cerr' is not a member of 'std' scons: *** [E:\blender_svn\build\source\blender\collada\SkinInfo.o] Error 1 source\blender\collada\MeshImporter.cpp: In member function 'MTex* MeshImporter::assign_textures_to_uvlayer(COLLADAFW::TextureCoordinateBinding, Mesh*, TexIndexTextureArrayMap, MTex*)': source\blender\collada\MeshImporter.cpp:707:32: error: 'class COLLADAFW::TextureCoordinateBinding' has no member named 'getSemantic' scons: *** [E:\blender_svn\build\source\blender\collada\MeshImporter.o] Error 1 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers Update your Collada codebase to svn 771. -Reuben ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] cmake parses compiler options incorrectly
Since sometime within the past day or two, cmake has generated make files that are not correctly parsing the compiler options info a functional shell script. [ 0%] Building CXX object intern/audaspace/CMakeFiles/bf_intern_audaspace.dir/intern/AUD_Mixer.cpp.o c++: no input files /bin/sh: -fopenmp: command not found make[2]: *** [intern/audaspace/CMakeFiles/bf_intern_audaspace.dir/intern/AUD_Mixer.cpp.o] Error 127 make[1]: *** [intern/audaspace/CMakeFiles/bf_intern_audaspace.dir/all] Error 2 make: *** [all] Error 2 -Reuben ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] building blender with opencollada using scons on ubuntu
Yo, back on Saturday, September 04, 2010 Wael EL ORAIBY was all like: Hi, I have been trying to build blender on ubuntu amd64, i followed the steps in http://wiki.blender.org/index.php/User:Kazanbas/Building_Collada_Branch but did not succeed, I still have problems with the include directories for opencollada! so is there any way to remedy this ? One question though, why opencollada is not with the rest of extern shipped with blender, won't that make building blender easier and less complicated ? Regards, The includes are not all dumped in one directory, but rather is assumed that the path layout from the directory set as the collada include directory will retain the path layout as pulled from the collada repo. You should just be able to point it to the root directory of your local copy of the repo. i.e. if your opencollada include directory is set to /usr/include/collada/ then the layout within that directory needs to be: . |-- COLLADABaseUtils | `-- include | `-- Math |-- COLLADAFramework | `-- include |-- COLLADASaxFrameworkLoader | `-- include | |-- generated14 | `-- generated15 |-- COLLADAStreamWriter | `-- include |-- COLLADAValidator | `-- include |-- Externals | |-- MathMLSolver | | `-- include | | `-- AST | `-- UTF | `-- include |-- GeneratedSaxParser | `-- include `-- common |-- libBuffer | `-- include | |-- performanceTest | `-- unitTest `-- libftoa `-- include |-- performanceTest `-- unitTest -Reuben ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Scons and install paths layout
With the recent removal of the WITH_BF_FHS variable I'm having trouble figuring out how to setup a standard linux system install. Right now the install paths relative to the install root are: ./ |blender |-- 2.53 | `-- scripts | |-- [ ... ] |-- icons | |-- [ ... ] `-- plugins |-- [ ... ] And I want to set it to do something more in line with LSB layout that will allow multiple versions installed on the system in parallel: ./ |-- bin | `-- blender-2.53 |-- lib | `-- blender | `-- 2.53 | `-- plugins `-- share `-- blender `-- 2.53 |-- icons `-- scripts Is there a way to do this now without WITH_BF_FHS ? -Reuben ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] blender opencollada svn circle
Yo, back on Tuesday, August 24, 2010 luxInteg was all like: Greetings, I am attempting to compile blender with opencollada on a machine with these:- --CPU- amd64 --o/s linux 64-bit only --compiler gcc-4.4.2 opencollada SVN rv735 compiles NOT/w-scons ~ required libs. opencollada SVN rv767 compiles/w-scons ~ required libs. blenderSVN 31533 compiles fine aginst opencollada-svn revision 735 blenderSVN 31533 compiles NOT aginst opencollada-svn revisions 767/768 You have to build SVN-r735. Furthermore, to build with gcc 4.4 you have to apply a patch first. Read here: http://code.google.com/p/opencollada/issues/detail?id=44 Also when you build blender you need to be sure the library and include paths are set correctly according to however you install opencollada. -Reuben ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Declarative UI Experiment
If you're defining a custom XML name-space for blender, would it be possible to
embed python script within the markup as event handlers or registering
callbacks? (Similar to how ECMA script is embedded within (X)HTML.) You could
have the best of both worlds that way. Especially if you extend it to other
areas (or create new name-spaces) where markup alone would be somewhat limiting.
-Reuben
Yo, back on Sunday, August 08, 2010 Campbell Barton was all like:
There are some concerns I have with the current UI code so yesterday I
looked into declarative UI's (Mozilla's XUL and some others) and wrote
a working, experimental XML method for defining panels/menus/headers.
Comparisons with render dimension and stamp panel (XML misses poll functions)
http://www.pasteall.org/14880/python
http://www.pasteall.org/14879/xml
Before I go any further I should say that this is something I did in
my spare time yesterday because I wanted to look into an alternative,
its not a BF supported project :)
Also, I'm not especially interested in XML, This could be JSON, a
Python dictionary or our own markup.
The XML to RNA translator will currently run if you start blender in
debug mode (--debug argument). just to show this is working.
the script that does this is scripts/modules/bpy_xml_ui.py
notice it has no hard coded rna functions, the XML names are passed
directly to RNA so its just a thin wrapper.
Problems I see with the current python based UI
- heavy weight solution to a simple(?) problem - in many cases you
only define rows/columns containing static rna references.
we are writing code for what is really a data definition.
(note: in some cases its useful to write code for a UI rather then
just doing simple data deceleration, but perhaps this is an exception
which can be supported).
- no way to validate rna variables are correct.
- no way to edit the UI graphically.
- ties us too closely to python, requires we run python code to do a UI.
So after doing this test here are some pro's for this style of UI integration
- having declarative XML/JSON/YAML UI co-exist with what we have now
is quite easy (either for migration or to support both systems long
term)
(having 2 methods of doing UI's is annoying and in general I'd like
to avoid this)
- declarative UI supports having a graphical tool to create and edit
the UI where code cant be edited in a graphical tool, think how nice
it could be for someone with no coding experience to make a UI for
their rig, or to add options they use frequently into blenders.
note, UI can generate code easy enough, just not edit once
generated - http://members.optusnet.com.au/cjbarton/obui/ObUI.png :).
- declarative UI means we can scan the UI and detect bad RNA paths for
example, at the moment you only get the error when the button is
drawn.
- interestingly I found the XML version of the UI nicer in some ways
* The columns and rows are anonymous, no need for variable names, I
quite like this.
* The nested structure of the UI is better displayed in XML then by
python functions.
Some Implementation details/options
- However this works it should at least not be slower then the current
UI api stuff (easy enough to make it faster)
- XML/JSON translation into RNA could be cached and could be faster
then current Py UI
- since XML cant define expressions we could inline python in XML or
XML in python, but think this could get annoying. having external xml
files would be cumbersome IMHO.
Just saying its not hard to mix this any way that suits us.
- Even though most of the time I find code logic in UI scripts to be
bad practice, it IS useful at times, can't ignore this. a declarative
UI is less functional.
- We could *optionally* replace python draw functions with a draw
dictionary, this lets us have the benefits of a declarative UI with
minimal disruption.
eg:
def MyPanel(bpy.types.Panel):
bl_label = My Panel
bl_draw_data = [
(row: ({align: True},
column: ( ... )
)
]
basically a list/dictionary which represents the XML linked
above, though I find the py version would use a lot of quotes and
braces.
Would be good to discuss this on the list and see if its worth
investigating further.
- Campbell
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] The final step that Blender needs to take in order to become fundamentally perfect
Yo, back on Saturday, May 08, 2010 nautilus was all like: Yo, internet tough guy, I'm not sure if I'm misunderstanding your post, but when you post a reply to a person who is trying to be helpful you should 1) be respectful and considerate like Joe that replied before you. 2) be intelligent. That's all fine and well, but your original post is neither respectful nor intelligent. (And not the least bit helpful) I'm not saying your topic of discussion is out of context for this mailing list, but your means of approaching it is very pretentious. - Nothing you mentioned is anything that the developers are probably not already aware of to some degree. - It is an obnoxiously long post full of long quotes that amount to little more than hot air. - Houdini, Maya, etc, are all excellent programs, but this is Blender. Assuming that you can take what works well in one environment and directly graft it into another environment without taking into consideration the differences in needs, goals, and culture will fail at worst, and be nothing more than a half-assed clone of something else at best. - You would not believe how fantastically ineffective it is to walk in to a group of developers who work on a project out of personal passion and tell them how they should do their work or what their goals should be without first earning their respect. - If you want to be effective then you can express interest in contributing code to achieve the goals you mentioned. Or you can express interest in funding somebody else to work on those goals. Or you can start an actual discussion by requesting the developers point of view on if those goals would fit well with blender and if so to what extent. Big long quotes and references to other projects do not achieve that. They are merely solutions in search of a problem to fix. -Reuben ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] patch #21750: Vectorscope and luma/color waveform for image view
Yo, back on Wednesday 24 March 2010 Xavier Thomas was all like: Test and feedback much appreciated :) Screenshot: http://www.pasteall.org/pic/show.php?id=2102 Wow, that looks beautiful. :) For the WaveForm, would it also be possible to have an option to scope the YCrCb levels? That would be very beneficial for final output when trying to keep the levels clamped to CCIR 610 / 709 levels. (The levels allowed for Luminance are slightly different for levels allowed for chrominence according to spec, which can be hard to visualize in RGB mode.) Also, would you consider and option to switch histogram between log and linear? -Reuben ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Color Management and gamma correct scaling
I had know that working in linear color space helping color mixing look correct, but I hadn't known till now that it also plays a significant role in scaling images correctly as well. There is an interesting article getting linked to from slashdot that might interest some people here involved with the color management: http://www.4p8.com/eric.brasseur/gamma.html -Reuben ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Is collada work in progress?
Yo, back on Thursday 11 February 2010 Dave Plater was all like:
The scripts/unixbuild.sh build works for me but I'm still getting
missing include file problems, I've tried lndir in the
source/blender/collada directory to link all the collada includes from
their directories in the openCOLLADA sources but before I went to sleep
last night I was still getting errors, openCOLLADA takes a long time to
build. In my spec file, I unpack collada in the root directory of the
blender sources and change to the collada directory, which is named
openCOLLADA in my case, and then build it. The directory which the
static libs are placed in by the build is installed-opencollada/lib and
the libs built are :-
libCOLLADABaseUtils.a, libCOLLADASaxFrameworkLoader.a,
libGeneratedSaxParser.a, libpcre.a, libxml2.la, testdso.a,
libCOLLADAFramework.a, libConvertUTF.a, libMathMLSolver.a, libxml2.a
and libxml2.lai
Trial and error takes a long time, what should I specify for
BF_OPENCOLLADA_LIBPATH=, BF_OPENCOLLADA= and the one I find the most
difficult because the include files are scattered between different sub
directories in the openCOLLADA root BF_OPENCOLLADA_INC=. I've
currently specified :-
BF_OPENCOLLADA=openCOLLADA
BF_OPENCOLLADA_LIBPATH=openCOLLADA/installed-opencollada/lib and
BF_OPENCOLLADA_INC=openCOLLADA/, openCOLLADA being the directory
containing the collada sources unpacked in the blender source root. I
will go through Sconstruct and compare it with yours.
I've also found that the scons build of collada get's further with the
latest version of scons, openSUSE is still on scons-1.2.0.d20090113, but
will be on the latest when I submit the new build. The changelog of
scons indicates that it had problems with different versions of python
and I have both 2.6 and 3.1 on my system. Blender-2.50 is currently the
only package that requires python3 in openSUSE.
Thanks
Dave P
For Blender, I have the following set:
WITH_BF_COLLADA = True
BF_COLLADA = '#source/blender/collada'
BF_COLLADA_INC = '${BF_COLLADA}'
BF_COLLADA_LIB = 'bf_collada'
BF_OPENCOLLADA = '/usr'
BF_OPENCOLLADA_LIB = 'OpenCOLLADAStreamWriter OpenCOLLADASaxFrameworkLoader
OpenCOLLADAFramework OpenCOLLADABaseUtils GeneratedSaxParser UTF MathMLSolver
pcre buffer ftoa'
BF_OPENCOLLADA_LIBPATH = '${BF_OPENCOLLADA}/lib'
BF_OPENCOLLADA_INC = '${BF_OPENCOLLADA}/include
${BF_OPENCOLLADA}/include/collada'
BF_PCRE = ''
BF_PCRE_LIB = 'pcre'
BF_PCRE_LIBPATH = '/usr/lib'
BF_EXPAT = '/usr'
BF_EXPAT_LIB = 'expat'
BF_EXPAT_LIBPATH = '/usr/lib'
Be aware that I installed the openCollada library files into the system's
/usr/lib (since I'm building everything using shared libs)
I also created a /usr/include/collada directory where I dumped the file
structure with nothing but the include files. So for instance if looking for
the include files for the COLLADABaseUtils they would be found in
/usr/include/collada/COLLADABaseUtils/include/
-Reuben
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Is collada work in progress?
Yo, back on Wednesday 10 February 2010 Dave Plater was all like:
I tried the build exactly as laid out in the web page and then tried
PCRENATIVE=no, I've also tried XMLPARSER with expat native and supplied,
also libxmlnative, I haven't tried the supplied libxml yet but it will
most probably give the same result, possibly caused by openSUSE's pcre
installation or lack of an environment variable. I've discovered that
the opencollada Makefile points to a bash script called unixbuild.sh
which autoconfigures and then uses cmake, it's succeeded with the build
and maybe I can get a clue there about what's missing with the scons build.
Thanks
Dave P
I think getting the blender portion of the code to compile and link correctly
is dependent on which XML parser you build against. Also it's best to use the
native system libs, because that will be the same libs the blender portion of
the code builds against.
I'm on Gentoo, so it's a bit less of a mess: all the development portions of
the packages are installed by default as a matter of necessity.
Here's the complete scons options I set pasted from the Sconstruct file:
[code]
vars = Variables('custom.py')
vars.Add(BoolVariable('RELEASE', 'Set to build for release', 1))
vars.Add(BoolVariable('PG', 'Set to build with -pg set for gcc for profiling',
0))
vars.Add(BoolVariable('SHAREDLIB', 'Set to build shared libraries instead of
static ones (untested).', 1))
vars.Add(BoolVariable('PCRENATIVE',
Set to build using the systems native pcre lib instead of the delivered lib.
Uses same configuration dir for both configurations.
, 1))
vars.Add(EnumVariable('XMLPARSER',
Selects the xml parser to be used
libxml: Use libXML contained in OpenCOLLADA external sources
expat: Use expat contained in OpenCOLLADA external sources
libxmlNative: Use libXML deliverd with your OS. libXML and the
corresponding development files need to be installed
expatNative: Use expat deliverd with your OS. expat and the corresponding
development files need to be installed
, 'expatnative', allowed_values=('libxml', 'expat', 'libxmlnative',
'expatnative'), ignorecase=2))
vars.Add(BoolVariable('NOVALIDATION', 'Set to disable shema validation in sax
frame work loader', 0))
[/code]
I also commented out the line to build the dae2ogre. Not needed and I don't
think it builds anyway.
I also have a recent version of gcc, so I had to add a #include cstdio to
common/libBuffer/src/CommonFWriteBufferFlusher.cpp
I've had blender building with Collada option turned on for several weeks. But
it doesn't work. Of the few meshes I've tested (export from blender and import
back in), all the mesh data is folded into itself so that all verticies with
negative values in the local coordinates are mapped to the positive values. I
haven't done much more with it besides just a casual test or two. I suspect
that the problems are probably the result of all the warnings thrown about
comparing signed and unsigned values. But that's just an assumption. I haven't
had the motivation to really dig into it. There are occasional commits to the
Collada branch, so I assume it's still a work in progress.
-Reuben
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] faster usage of panels via pie menu
Yo, back on Tuesday 09 February 2010 Charles Wardlaw was all like: I really like the idea of it popping up a panel like the F6 key, although the same pie menu in the Properties area could scroll to the requested panel instead. I would *kill* for the ability to customize pie menus by creating custom classes for them. Would be nice to have one pie menu that is a generic tools menu that a user can customize with custom tool-sets, and a separate pie menu that is context specific and expandable via python. -Reuben ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Audio stuff!
I forgot to mention, (in case you're not familiar with the codec) that FFV1 is part of FFMPEG. -Reuben ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Shading System Proposals
On Tue, Dec 1, 2009 at 10:06 AM, Brecht Van Lommel bre...@blender.org wrote: Hi, After discussion with Matt and Nathan, I've revised the proposal, I think it's much clearer now, and also more ambitious. There's still various things to be worked out in more detail and mockups for UI to be made. But I think we now have a design that solves the BXDF/node interaction and the texture stack questions. http://wiki.blender.org/index.php/BlenderDev/ShadingSystem Brecht. I'm not sure this is the proper place to bring this up since it is not about BXDF but rather about API / design: Has anybody considered the possibility of allowing 3rd party rendering engines selected via the Render API, to add their own set of nodes for things like shaders or procedural textures that are not supported by blender internal? Furthermore, you write about some of the things that are Non-Targets for this project. Will any of those limitations cause issues with some external shaders? (Especially with some of the exotic things that can be programed into a renderman shader) I know 3rd party rendering engines are not the primary focus, but have you determined the extents (if at all) to which the shading system will accommodate them? -Reuben ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
