Re: [Bf-committers] Adding Separate Wireframe Color for Edit Mode
It would be great if we could control the wireframe thickness as well. k On 06/07/2013 04:52 PM, Jonathan Williamson wrote: Hi everyone, and specifically Ton :) I spoke with Campbell on IRC about this, and he just said I need to convince you, Ton. I would like to push for adding a new theme option for mesh wireframes in Edit Mode. The reason for this is during retopology, when working on dense meshes (such as a dynamic topology sculpt) distinguishing between the original form and the retopo form becomes quite difficult. For example, take a look at this screenshot: http://cl.ly/PWyr It's easy to the see the vertices, the edges are quite difficult to see, particularly while rotating around the model. Ideally, it'd be great to have full control over wireframe colors, on a per object basis. However, Campbell mentioned that is a much larger undertaking, and so for now having the theme option would be a good compromise. Thoughts? Jonathan Williamson http://cgcookie.com ___ 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] Edit mode tools.
Do you mean Cad tools? http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Modeling/Edge_Slice kursad On 05/12/2013 12:22 PM, Knapp wrote: intersected a plane etc. I can't find info about this anywhere. Does ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Simple proposal for selecting linked vertices in Edit Mode defaults
Hi
I have been using this simple change below in my setup and it seems to
work well for me. I think that double clicking to select connected
vertices can improve general modeling workflow. Similar setups are also
available many other 3d apps like Modo when editing meshes.
These are nortmally assigned to L and shift L
kmi = km.keymap_items.new('mesh.select_linked', 'LEFTMOUSE',
'DOUBLE_CLICK', shift=True)
kmi = km.keymap_items.new('mesh.select_linked_pick', 'LEFTMOUSE',
'DOUBLE_CLICK')
thanks
kursad
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] making blender with eclipseMingW ...
Hi I have it working in Eclipse. It works fine except that Eclipse likes to use a lot of memory. Make sure that - You choose the right Eclipse version when building the Eclipse project wtih Cmake - Use the Make Target pane for building not the Project Build all kursad On 03/20/2013 04:59 AM, Gaia wrote: Hello; After talking about alternatives for the Visual express 2008 build environment for making blender, i browsed a bit and after some digging i found a tutorial for setting up eclipse and MingW. So i decided to give that a try and actually it was very easy to get this working with a simple hello world example. So, now i want to add Blender into that system. But that is no longer easy going ;-( However maybe i just need a few bitsto get it to work. Here is what i did so far: I used CMake to create the build directories using Eclipse CDT4 - MingW makefiles Then i imported that generated folder to eclipse as existing code as makefile project ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Looking for a bachelor thesis
Hi Here are 2 thing areas to consider. - One area that can be improved is a better remesher. - We also need a point cloud meshing modifier. - Multi range uv support and baking. Currently most uv things happen in standard uv space in Blender. We need uv support for textures/baking/painting beyond 0-1. So one should be able to use uv islands that sit outside of 0-1 range in Blender. k On 03/11/2013 05:25 AM, Michele Fenu wrote: Hi blender developers, I'm looking for a bachelor thesis for my Computer Science degree at University of Turin. This may be my first time with open source development and I don't know how I can contribute to this community, but I have about 200 hours to spend on the project and I'd really like to receive any suggestions on which field i can contribute to. At the beginning I was thinking to develop a plug-in, but almost all ideas I've had were already developed by someone else (e.g. sapling, or camera calibration), so I decided to write this email. Any help will be appreciated ;) Thank you in advance, Michele ___ 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] Suggestion: Drop zip archives (Windows releases)
On 03/09/2013 09:05 AM, Thomas Dinges wrote: Hi everybody, I'd like to drop .zip archives for our windows releases. At the moment we provide .exe (Installer version) and .zip and .7z (Extract Run version). Pros: * .7z archive is much smaller than .zip, saving traffic and also faster for people to download. * .7z format is open and supported by different programs: 7-Zip, WinZip, WinRar. Cons: * Windows does not support .7z out of the box, needs third party app like 7-zip. I understand that the one con is a problem in theory, but in practise most people have a third party app installed, whether it's 7-Zip, WinZip etc. Windows only supports .zip archives, so without a third party app, people can not uncompress/compress .rar, 7-zip, .tar etc... Asking people to install 7-Zip shouldn't be a problem, 7-Zip is free software (LGPL) and only 1 megabyte large. http://7-zip.org/ Anyway, I don't think we should keep 3x different types of binaries (*2 for the architecture) for Windows, as for Mac and Linux we also only provide one for each bitness. Best regards, Thomas Hi I am one of those Win users who prefer an archive over installer. In that respect I think that a self containted .exe is perfectly one(indicated clearly). One can also use 7zip itself to open the self contained exe as a compressed file. The only thing that can get in way is the permissions/virus app issues with .exe files. So providing a .7z along with the exe is a viable solution in my view. k ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] broken win32 build, sculpt_paint related [SOLVED]
Just to follow up on this issue. It seems like there was file corruptions that led to this problem. After Antony advised me to delete the files locally and redownload the relevant files form the svn I am able to build properly. k On 03/08/2013 05:34 PM, Antony Riakiotakis wrote: Strange, it works here...what compiler are you using? We support 4.6.3 from MinGW.org ___ 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] broken win32 build, sculpt_paint related
Win64 / Mingw32 [ 4%] Built target bf_editor_metaball [ 4%] Built target bf_editor_object [ 5%] Built target bf_editor_physics [ 5%] Built target bf_editor_render [ 5%] Built target bf_editor_screen [ 5%] Building C object source/blender/editors/sculpt_paint/CMakeFiles/bf_editor_sculpt_paint.dir/paint_image_proj.c.obj D:\_BLENDER_BUILDS\SVN\blender\source\blender\editors\sculpt_paint\paint_image_proj.c:4289:14: error: nested redefinition of 'enum PaintMode' D:\_BLENDER_BUILDS\SVN\blender\source\blender\editors\sculpt_paint\paint_image_proj.c:4289:14: error: redeclaration of 'enum PaintMode' D:/_BLENDER_BUILDS/SVN/blender/source/blender/blenkernel/BKE_paint.h:57:14: note: originally defined here mingw32-make[2]: *** [source/blender/editors/sculpt_paint/CMakeFiles/bf_editor_sculpt_paint.dir/paint_image_proj.c.obj] Error 1 mingw32-make[1]: *** [source/blender/editors/sculpt_paint/CMakeFiles/bf_editor_sculpt_paint.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
Re: [Bf-committers] broken win32 build, sculpt_paint related
On Mar 8, 2013 5:12:59 PM, Antony Riakiotakis wrote: I can't reproduce here. There is also no such redefinition on these files. Are you sure you are using the correct svn revision? ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers It is the latest trunk as far as I can tell. I am at 55121 -- Sent with love from the new tine 2.0 email client ... Please visit http://tine20.org ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] broken win32 build, sculpt_paint related
On Mar 8, 2013 5:34:04 PM, Antony Riakiotakis wrote: Strange, it works here...what compiler are you using? We support 4.6.3 from MinGW.org ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers yeah I have 4.6.2 here. Is there anything else I could try? Could it be a Cmake issue? I updated the cache before build -- Sent with love from the new tine 2.0 email client ... Please visit http://tine20.org ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] build error on Windows with Mingw32 ( bf_blenlib.dir/intern/winstuff.c.obj] Error 1 )
Hi I am getting a build error on Windows7 with Mingw32. I used Cmake to create the build for using with Mingw32 on Windows7 64bit. here is the tail D:/_BLENDER_BUILDS/SVN/blender/source/blender/blenlib/BLI_path_util.h:110:1: error: unknown type name 'bool' D:/_BLENDER_BUILDS/SVN/blender/source/blender/blenlib/BLI_path_util.h:111:1: error: unknown type name 'bool' D:/_BLENDER_BUILDS/SVN/blender/source/blender/blenlib/BLI_path_util.h:115:1: error: unknown type name 'bool' D:/_BLENDER_BUILDS/SVN/blender/source/blender/blenlib/BLI_path_util.h:115:24: error: unknown type name 'bool' D:/_BLENDER_BUILDS/SVN/blender/source/blender/blenlib/BLI_path_util.h:140:1: error: unknown type name 'bool' D:/_BLENDER_BUILDS/SVN/blender/source/blender/blenlib/BLI_path_util.h:143:1: error: unknown type name 'bool' D:/_BLENDER_BUILDS/SVN/blender/source/blender/blenlib/BLI_path_util.h:157:1: error: unknown type name 'bool' D:/_BLENDER_BUILDS/SVN/blender/source/blender/blenlib/BLI_path_util.h:163:1: error: unknown type name 'bool' D:\_BLENDER_BUILDS\SVN\blender\source\blender\blenlib\intern\winstuff.c:208:1: warning: 'UNUSED_BLI_alloc_utf16_from_8' defined bu t not used [-Wunused-function] mingw32-make[2]: *** [source/blender/blenlib/CMakeFiles/bf_blenlib.dir/intern/winstuff.c.obj] Error 1 mingw32-make[1]: *** [source/blender/blenlib/CMakeFiles/bf_blenlib.dir/all] Error 2 mingw32-make: *** [all] Error 2 and here is the rest http://www.pasteall.org/40204 k ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Linking error with libge on Windows
On 03/02/2013 11:14 PM, Mitchell Stokes wrote: Strange, I'm not seeing an actual error in that log output. Warnings usually don't stop a compile, and that particular warning (unused scene in dome code) has been around for a long time. --Mitchell Mitchell, thanks for the reply. I will see if this is a local issue. This is a regular vanilla build that normally builds fine, that is why in thought I would report it first. thanks k ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Conversion to a dynamic/plugable modifier system
On Dec 5, 2012 2:38:33 AM, Chad Fraleigh wrote: On Tue, Dec 4, 2012 at 11:26 PM, Brecht Van Lommel brechtvanlom...@pandora.be wrote: As you have found from reading the code, Blender wasn't really designed with plugins in mind. Code for things like modifiers tends to be scattered over many files. I fear that making a C/C++ plugin system work is a far bigger project than you might think. Getting all the components like DNA/RNA/blenloader/UI/.. ready for this would be great but I don't think it's a feasible task for one developer. I knew (as a whole) it wouldn't be a trivial thing. But the general plan was to add some [API backward compatible] modifier framework/interface changes over time, and then convert an existing modifier or two to be in a self-contained module as a proof of concept and to work the kinks out. At some point after this making them actual run-time loadable plugins would be a next step. Just being modular could allow them to be compiled as a shard library and linked during standard blender compile time.. the plugin stuff would just be some linking glue added on (albeit not trivial in itself). And while in the long term it would certainly be cleaner and better to do the same for all the other legacy modifier code, technically they should still work as-is (if the new code checks what it needs first and falls through to old code on NULL hook functions and such). Of course once a couple are done and a basic example is laid down, then other developers could jump in and each try to convert other modifiers.. and if new issues are encounter in the more complex modifiers, at worse the change could reverted for those specific modifier(s) until more framework updates can be made to support it. The worse case scenario is that even if the end goal ends up a failure, in the effort the code would be made much more modular and code-coupling for them reduced and hopefully make later attempts easier. Making Blender more modular is one of those things that should be tackled as a bigger project, like the 2.5 UI refactor or the planned dependency graph upgrade. For python we have some mechanisms to make extensions work, and I can imagine python modifier support being feasible to add using the bmesh python api. -Chad ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers I am not sure if this would be a new idea to Blender, but Houdini has couple neat tricks. For example it provides inline coding nodes both for cpp and for high performance VEX lang. The codes in the nodes are compiled at runtime when the nodes are cooked. Maybe there could be a dedicated modifier that can compile the code in real time (even possible?) . While this sure is neither a replacement for a plugin nor for dedicated modifier, it might be able to help with protoyping and or even with distribution if the modifier data could be loaded. k ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Writing a Compositor node plugin?
On Dec 5, 2012 6:56:54 PM, Troy Sobotka wrote: Is there any chance that the registering the new nodes goes through some old system of nodes? I can now compile without any errors however(maybe naturally) my node does not show up in the nodes in Blender. So I am suspecting that I am not able to register this new node in the system properly. I wrote a wiki page on a minimal node tutorial here: http://wiki.blender.org/index.php/User:Sobotka/Misc/Minimal_Node_Tutorial There is a minimal node-skeleton branch here: https://github.com/sobotka/blender/tree/node-skeleton Hope that helps someone a little... TJS Hi Troy Thanks for the reply. This is better than what I could have hoped for. I wish I saw it couple days ago but in any case this is great. The old node coding page is obsolete so was little help to me. k ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
