[Bf-committers] Multiple compiling errors with libraries (-lpng, lfreetype, -ltiff)
Hi I am trying to build the latest Blender svn on Windows using Mingw-32bit, Cmake, Eclipse(Indigo) and also with QtCreator. For some reason I am unable to past this stage. Qtcreator gives me the exact same message. I was not able to compile with Scons either. I have compiled the Boost1.49 libraries with Bjam for Mingw, and additional zlib and png libs(tried different version) and they are all residing in standard MingGW folders but those steps did not help me either. I have all the Blender external libs from svn repos (mingw, mingw64 and windows). And I know that there are png libs there. I am really puzzled that it cannot find the png. I have directed Eclipse to add the -l directive with png libs (tried multiple versions). but that did not do much either. The compiler compiles %100 then after linking stage I believe I am stuck. I am wondering if anyone else on the list had similar compiler issues. Maybe it is a configuration problem. I am not able to distinguish the issue at this point. I am not sure if this is directly to do with the png or tiff libraries. Here is the Cmake skips Blender Skipping: (bf_collada;bf_intern_ctr;bf_intern_elbeem;bf_intern_smoke;cycles_bvh;cycles_device;cycles_kernel;cycles_render;cycles_subd; cycles_util;extern_bullet;extern_recastnavigation;extern_redcode;ge_blen_routines;ge_converter;ge_logic;ge_logic_expressions;ge_logic_ketsji; ge_logic_loopbacknetwork;ge_logic_network;ge_logic_ngnetwork;ge_oglrasterizer;ge_phys_bullet;ge_phys_common;ge_phys_dummy;ge_rasterizer;ge_scenegraph;ge_videotex) Compiler error " \..\lib\libbf_intern_itasc.a ..\..\lib\libextern_carve.a -lopengl32 -lglu32 -lpng -lz -lfreetype C:\DEV_SOURCES\blender-svn\blender\..\lib\mingw32\python\lib\python33mw.lib -lwrap_oal -lSDL -ltiff -lOpenImageIO -lboost_date_time-mgw46-mt-s-1_49 -lboost_filesystem-mgw46-mt-s-1_49 -lboost_regex-mgw46-mt-s-1_49 -lboost_system-mgw46-mt-s-1_49 -lboost_thread-mgw46-mt-s-1_49 -lboost_filesystem-mgw46-mt-sd-1_49 -lboost_regex-mgw46-mt-sd-1_49 -lboost_system-mgw46-mt-sd-1_49 -lboost_thread-mgw46-mt-sd-1_49 -llibjpeg -lHalf -lIlmImf -lImath -lIlmThread -lIex -lpthreadGC2 -lshell32 -lshfolder -lgdi32 -lmsvcrt -lwinmm -lmingw32 -lm -lws2_32 -lz -lstdc++ -lole32 -luuid -lwsock32 -lpsapi c:/devtools/mingw/bin/../lib/gcc/mingw32/4.6.2/../../../../mingw32/bin/ld.exe: cannot find -lpng c:/devtools/mingw/bin/../lib/gcc/mingw32/4.6.2/../../../../mingw32/bin/ld.exe: cannot find -lfreetype c:/devtools/mingw/bin/../lib/gcc/mingw32/4.6.2/../../../../mingw32/bin/ld.exe: cannot find -ltiff C:\DEV_SOURCES\blender-svn\blender\..\lib\mingw32\openimageio\lib/OpenImageIO.lib(CMakeFiles/OpenImageIO.dir/imagebufalgo_yee.cpp.obj):(.text[_powf]+0x0): multiple definition of `powf' mingw32-make[2]: Leaving directory `C:/DEV_SOURCES/blender-svn/Cmake_Eclipse_MinGW32' mingw32-make[1]: Leaving directory `C:/DEV_SOURCES/blender-svn/Cmake_Eclipse_MinGW32' ..\..\lib\libcycles_kernel.a(kernel.cpp.obj):kernel.cpp:(.text$powf[_powf]+0x0): first defined here collect2: ld returned 1 exit status mingw32-make[2]: *** [bin/blender.exe] Error 1 mingw32-make[1]: *** [source/creator/CMakeFiles/blender.dir/all] Error 2 mingw32-make: *** [all] Error 2 " thanks k ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Writing a Compositor node plugin?
Hi I am trying to create a Compositor node. It seems like there is the new Compositor engine requires a bit of different wiring. So I looked around and used the GammaNode as an example. I believe I covered as much ground as possible however I am getting an error " Linking CXX executable ..\..\bin\blender.exe Creating library file: ..\..\bin\libblender.dll.a ..\..\lib\libbf_compositor.a(COM_Converter.cpp.obj):COM_Converter.cpp:(.text+0x1fd): undefined reference to `LinearNode::LinearNode(bNode*)' collect2: ld returned 1 exit status" I am wondering about the prerequisites for successful creation of a compositor node. Here are the files that I have created and edited BKE_node.h #define CMP_NODE_LINEAR274 COM_Converter.cpp case CMP_NODE_LINEAR: node = new LinearNode(b_node); break; Nodes (based on GammaNode) COM_LinearNode.cpp COM_LinearNode.h Operations (based on GammaOperation) COM_LinearOperation.cpp COM_LinearOperation.h If that is all to it then it must be something my new files. However at this point I am not sure where the issue could be. thanks k ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] import_obj.py - Reimplementation
Hi I think that it will be great if the obj importer has been taken for a new ride. Recently I needed to import an .obj that was around 3.5Gb into Blender. Naturally, as you might expect Blender(Win 64bit) was not able import it. Rather it just froze up for a long time. I am not sure if that is a limitation with the mesh memory or a limitation of the Python version in use. I am sure most Blender users will never need to import meshes that are that big (at least for now), but in big and serious projects big data is always a possibility. thanks k On 01/02/2013 08:16 PM, Isaac Lenton wrote: > Hi > > A few days ago I was using Blender's import_obj.py script to import a few > rather bulky OBJ files into blender (200MB and above). On my little system > it takes about 2 minutes for every file. I have been looking into improving > this script with simple optimisation, splitting the work amongst multiple > workers and changing the amount of memory the script uses. Some of these > methods are successful, but the results are only minor. I did manage to > reduce the loading time of the 200MB file to 1 minute 40 seconds. > > Although a quicker method for importing my data into Blender would be to > use another format, I quite like the OBJ format and I am "in the mood" for > optimising. > > In order to significantly improve the speed of Blender's OBJ importer I can > see a couple of options: > > - Implement the importer straight in C/C++ and build into Blender. > I think this option is probably undesirable considering it takes > away one of the really nice things about Blender's add-ons (the > add-on part!). > > - Keep the implementation in pure python. > Also, in my opinion, undesirable. The Python is great, but it can > slither only so fast. (Also, what are your opinions on using > Python's > multiprocessing module in import scripts?) > > - Keep the python script but implement the most expensive methods in > a C dynamic library. This option will keep the interface to the > exporter exactly the same, the module will still be able to be > imported using pythons `import` and Blender will not even notice > the difference. The library would be placed in the same directory > as the script (scripts/addons/io_scene_obj) and the script would > simply add the line `from . import TheNewLibrary` at the start. > Downside: using plain C and python can be painful (but fun). > > - Keep the python script but implement the most expensive methods in > a boost::python C++ dynamic library. Same as above. > Downside: Boost::Python libraries have a big overhead. > > I find for my own code, when size is not important, I prefer the last option. > > I am interested to hear any opinions on the above ideas, and any ideas anyone > may have on generally improving the speed of Blender's importers. Are any > of these options Blender compatible (as in, could they be included in the > official release)? > > Thanks, > Isaac Lenton > (ilent2) > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- Kursad Karatas http://portfolio.plecxus.com/ ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] import_obj.py - Reimplementation
The mesh is around 3.5gb single mesh obj. Blender puffed up all the way
to 26.8gb in ram and stopped loading after sometime. I have 32gb here
so that should be ok. In any case 26.8 gb for this mesh sounds a bit
excessive to me.
Keeping the vert order definitely helped. Blender finally showed some
signs of life after sometime. But I was not able to interact with
Blender after that point (massive slowdown due to mesh size I guess) .
Maybe that is the best it can do at the moment. Just load it. Once it
loaded the mesh the memory use went down to 11.08 gb although Blender is
not in usable interaction state once that mesh was in the viewport.
thanks
k
On 01/03/2013 10:58 AM, CoDEmanX wrote:
> OBJ import can take quite some time and use a lot memory, but only if
> you use splitting ("keep vert order" imports way faster). Is there
> something else causing the bad performance?
>
> Multiprocessing would be great, for splitting it might work. But
> probably not for any code that calls bpy api functions...
>
> C/C++ importer: This year's GSoC project "FBX importer" wasn't actually
> about FBX, but assimp integration (= C/C++ importers for FBX, OBJ etc.).
> There are builds available at graphicall.org. However, I'd keep the
> python addons in trunk.
>
> Python + Lib: Why improve performance of a python script if a C/C++
> importer is available (assimp) and faster than the script will ever be?
> In addition, I/O scripts should be kept simple IMO, so that scripters
> can learn from them for their own addons.
>
> If there are any simple python hacks to improve performance, they should
> be applied of course.
>
>
> Am 03.01.2013 03:16, schrieb Isaac Lenton:
>> Hi
>>
>> A few days ago I was using Blender's import_obj.py script to import a few
>> rather bulky OBJ files into blender (200MB and above). On my little system
>> it takes about 2 minutes for every file. I have been looking into improving
>> this script with simple optimisation, splitting the work amongst multiple
>> workers and changing the amount of memory the script uses. Some of these
>> methods are successful, but the results are only minor. I did manage to
>> reduce the loading time of the 200MB file to 1 minute 40 seconds.
>>
>> Although a quicker method for importing my data into Blender would be to
>> use another format, I quite like the OBJ format and I am "in the mood" for
>> optimising.
>>
>> In order to significantly improve the speed of Blender's OBJ importer I can
>> see a couple of options:
>>
>> - Implement the importer straight in C/C++ and build into Blender.
>> I think this option is probably undesirable considering it takes
>> away one of the really nice things about Blender's add-ons (the
>> add-on part!).
>>
>> - Keep the implementation in pure python.
>> Also, in my opinion, undesirable. The Python is great, but it can
>> slither only so fast. (Also, what are your opinions on using
>> Python's
>> multiprocessing module in import scripts?)
>>
>> - Keep the python script but implement the most expensive methods in
>> a C dynamic library. This option will keep the interface to the
>> exporter exactly the same, the module will still be able to be
>> imported using pythons `import` and Blender will not even notice
>> the difference. The library would be placed in the same directory
>> as the script (scripts/addons/io_scene_obj) and the script would
>> simply add the line `from . import TheNewLibrary` at the start.
>> Downside: using plain C and python can be painful (but fun).
>>
>> - Keep the python script but implement the most expensive methods in
>> a boost::python C++ dynamic library. Same as above.
>> Downside: Boost::Python libraries have a big overhead.
>>
>> I find for my own code, when size is not important, I prefer the last option.
>>
>> I am interested to hear any opinions on the above ideas, and any ideas anyone
>> may have on generally improving the speed of Blender's importers. Are any
>> of these options Blender compatible (as in, could they be included in the
>> official release)?
>>
>> Thanks,
>> Isaac Lenton
>> (ilent2)
>> ___
>> 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
>
--
Kursad Karatas
http://portfolio.plecxus.com/
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] "make install" with only the relevant files?
@Brecht, @Campell Thank you for the tips, I appreciate your speedy and informative replies. This is going to be much better than my default build setup. k ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Looking for insight into a problem with setting up a modifier
Hi I am trying to set up a modifier. For some reason it is giving me an compilation error, something that I am not able to figure out. At one point I was able to compile and made it work, but got a corrupt git branch so lost it. I am hoping that someone on the list will probably have some idea about it. I based it on the shapekey modifier and follow up on Campbell`s meshcache commit. Here is the diff against the master branch http://www.pasteall.org/39985/c And here is the error from mingw32-make [ 88%] Built target bf_modifiers Linking C static library ..\..\..\lib\libbf_blenkernel.a [ 95%] Built target bf_blenkernel Scanning dependencies of target bf_rna [ 95%] Generating rna_ID_gen.c, rna_action_gen.c, rna_actuator_gen.c, rna_animation_gen.c, rna_animviz_gen.c, rna_armature_gen.c, rna_boid_gen.c, rna_brush_gen.c, rna_c amera_gen.c, rna_cloth_gen.c, rna_color_gen.c, rna_constraint_gen.c, rna_context_gen.c, rna_controller_gen.c, rna_curve_gen.c, rna_dynamicpaint_gen.c, rna_fcurve_gen.c, rna_fluidsim_gen.c, rna_gpencil_gen.c, rna_group_gen.c, rna_image_gen.c, rna_key_gen.c, rna_lamp_gen.c, rna_lattice_gen.c, rna_main_gen.c, rna_mask_gen.c, rna_material _gen.c, rna_mesh_gen.c, rna_meta_gen.c, rna_modifier_gen.c, rna_movieclip_gen.c, rna_nla_gen.c, rna_nodetree_gen.c, rna_object_gen.c, rna_object_force_gen.c, rna_packed file_gen.c, rna_particle_gen.c, rna_pose_gen.c, rna_property_gen.c, rna_render_gen.c, rna_rigidbody_gen.c, rna_rna_gen.c, rna_scene_gen.c, rna_screen_gen.c, rna_sculpt_ paint_gen.c, rna_sensor_gen.c, rna_sequencer_gen.c, rna_smoke_gen.c, rna_sound_gen.c, rna_space_gen.c, rna_speaker_gen.c, rna_test_gen.c, rna_text_gen.c, rna_texture_ge n.c, rna_timeline_gen.c, rna_tracking_gen.c, rna_ui_gen.c, rna_userdef_gen.c, rna_vfont_gen.c, rna_wm_gen.c, rna_world_gen.c Running makesrna [ 95%] [ 95%] [ 95%] [ 95%] [ 95%] [ 95%] [ 95%] [ 95%] [ 95%] [ 95%] Building C object source/blender/makesrna/intern/CMakeFiles/bf_rna.dir/rna_cloth_gen.c.obj Building C object source/blender/makesrna/intern/CMakeFiles/bf_rna.dir/rna_constraint_gen.c.obj Building C object source/blender/makesrna/intern/CMakeFiles/bf_rna.dir/rna_dynamicpaint_gen.c.obj Building C object source/blender/makesrna/intern/CMakeFiles/bf_rna.dir/rna_fluidsim_gen.c.obj Building C object source/blender/makesrna/intern/CMakeFiles/bf_rna.dir/rna_modifier_gen.c.obj Building C object source/blender/makesrna/intern/CMakeFiles/bf_rna.dir/rna_object_gen.c.obj Building C object source/blender/makesrna/intern/CMakeFiles/bf_rna.dir/rna_object_force_gen.c.obj Building C object source/blender/makesrna/intern/CMakeFiles/bf_rna.dir/rna_particle_gen.c.obj Building C object source/blender/makesrna/intern/CMakeFiles/bf_rna.dir/rna_scene_gen.c.obj Building C object source/blender/makesrna/intern/CMakeFiles/bf_rna.dir/rna_smoke_gen.c.obj Linking C static library ..\..\..\..\lib\libbf_rna.a [ 99%] Built target bf_rna Linking CXX executable ..\..\bin\blender.exe Creating library file: ..\..\bin\libblender.dll.a ..\..\lib\libbf_modifiers.a(MOD_util.c.obj):MOD_util.c:(.text+0x5ed): undefined reference to `modifierType_kkShapeKeyModifier' collect2: ld returned 1 exit status mingw32-make[2]: *** [bin/blender.exe] Error 1 mingw32-make[1]: *** [source/creator/CMakeFiles/blender.dir/all] Error 2 mingw32-make: *** [all] Error 2 cheers k ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Looking for insight into a problem with setting up a modifier
On 02/24/2013 12:54 AM, Dan Eicher wrote: > Looks like you didn't add MOD_kkshapekeymodifier.c to the build system > so it doesn't get compiled. > > > Dan Dan thanks for your reply. It is already added to Cmakelists.txt under blender/modifiers. You can see it in the diff around #180. Is there any other place that the builder looks for that needs to be added to? thanks k ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Linking error with libge on Windows
Hi I am getting a compiling problem with the latest svn #54983, something todo with the GE code. For example \source\gameengine\Ketsji\KX_KetsjiEngine.cpp:389:52: warning: 'scene' may be used uninitialized in this function [-Wuninitialized] Linking CXX static library ..\..\..\lib\libge_logic_ketsji.a [ 50%] Built target ge_logic_ketsji mingw32-make: *** [all] Error 2 http://www.pasteall.org/40166 thanks k ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
