Re: [Bf-committers] cloth
for the first patch do take a look at openmp for threading instead as it would become more portable and is already used in blender in several places.it also would handle different amounts of cores better. // Fredrik On Tuesday, September 30, 2014 7:32 PM, Jim Gaston jim.gas...@gerbertechnology.com wrote: Hi All, I've made a couple of changes to the cloth modifier. Since I'm new to blender (and open source generally) any advice is welcome. **The first patch changes collision.c The patch make the cloth collision detection multithreaded. http://www.pasteall.org/54287/c I've gotten good results on my system. Unfortunately It's not portable, so I need some help to make it portable. I tested it, but I always worry reentrancy. **The second patch changes implicit.c The patch forces the seams together after frame 15. http://www.pasteall.org/54288/c Probably this change should be optional (I've hardcoded at the moment) and instead of using a fixed frame number probably it should use the pre-roll value instead. Thank you and Regards Jim -Original Message- From: bf-committers-boun...@blender.org [mailto:bf-committers-boun...@blender.org] On Behalf Of Dan McGrath Sent: Tuesday, September 30, 2014 1:05 PM To: bf-blender developers Subject: Re: [Bf-committers] cloth Hi Jim, You could probably try submit a patch to our phabricator ( developer.blender.org), or if you don't want the hassle of creating an account, you could just use pasteall.org and put a link to the code for others here to look over and critique. Hope this helps? Dan On Mon, Sep 29, 2014 at 11:50 AM, Jim Gaston jim.gas...@gerbertechnology.com wrote: Hi Dan, Thank you for the reply. I have a couple of patches I have made locally to the cloth modifier, But the patches need work. The first patch is a multithreaded version of cloth_bvh_objcollisions_nearcheck(). It improves the speed of the cloth simulation. unfortunately, I don't know how to code it *portably*. The second patch causes sew lines to close after frame 15. (Jez's sew springs). It works well for my application, but it needs to UI to make it optional and set the start frame. And it could be unacceptable because it is applied after the collision checks. both patches are small. Less than 100 lines. Regards Jim -Original Message- From: bf-committers-boun...@blender.org [mailto:bf-committers-boun...@blender.org] On Behalf Of Dan McGrath Sent: Monday, September 29, 2014 11:31 AM To: bf-blender developers Subject: Re: [Bf-committers] cloth Well, it depends on specifically what you are looking for. This list is for coders/coding, not for something looking for tutorials/help on how to use cloth simulation. Dan On Mon, Sep 29, 2014 at 11:06 AM, Jim Gaston jim.gas...@gerbertechnology.com wrote: Hello. I am interested in the blender cloth simulation. Is this the correct mailing list? Thank you and regards Jim ___ 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 ___ 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] Auto switch between ortho/persp
just incase you missed it.the autoperspective option already switches to ortho when you use the set views with the numpad keys. as for the view snapping with alt+mmb sure yeah that could make sense. didn't actually know you could snap the view while rotating normally. // Fredrik On Tuesday, May 6, 2014 9:52 PM, Hadrien Brissaud hadris...@gmail.com wrote: Hello all, I have a small usability suggestion, but first of all I'd like to know where the best place for suggestions would be. It's not the first time I write to BF-committers and each time I feel like I'm a bit out of place. BF-funboard doesn't seem to get a lot of attention (understandably, not complaining here) and I heard developer.blender.org had a place for suggestions, which I couldn't find. While I'm here though, I might as well write it ? It's pretty straightforward anyway : I'd like to suggest a auto ortho option in addition to the auto perspective one. What it would do is basically the opposite of auto perspective, id est switch to ortho view when snapping to an axis with alt+MMB. I know everyone is busy and this mailing list is for discussing commits so please redirect me to a more appropriate place for suggestions if there is one. Good night, Hadrien ___ 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] Import, research on speed improvements
you can always do as i did and grab some of the stanford models they don't have uvs/normals but works anyway, the xyzrgb_dragon one is 574mb or so and takes 27seconds to load for me or 7seconds if the file is in the file cache. can't say how long blender takes to do the same as it runs out of memory and crashes after a few minutes(32bit build) it did manage to do the parsing step however 82seconds. note that these numbere would be smaller if i was at home haven't got a ssd here at work. as to Dan's question what i do here is not to thread every line but instead load say 1mb of the file at a time split that up into sections of1-numcores of lines, that i then parse and stitch together in the original order since i know what order the chunks are. the main speedup i found however is to just load the entire file or parts of the file into memory and then parse. loading the entire thing is if im not mistaken the fastest but uses way to much memory while if i load 1mb at a time, i actually use less memory than the file size in the end (338mb for the xyzrgb dragon) // Fredrik On Monday, March 10, 2014 5:50 AM, metalliandy metalliandy...@googlemail.com wrote: I'm sure I can get something to you, mate. Be aware that the files are often 900mb+ though I will upload something tomorrow. Cheers, -Andy On 10/03/2014 03:12, Sebastian A. Brachi wrote: Andy, could you provide a link to an example to do some benchmarks? I'd prefer to work with real user cases than a super-subdivided suzzane. On Sun, Mar 9, 2014 at 8:42 PM, metalliandy metalliandy...@googlemail.comwrote: I have been praying for a faster obj loader for years! I use massive objs on a regular basis (up to 900mb) so this would be amazing. IMHO all I/O plugins should be done in C/C++ as python just doesn't have the speed. FWIW, Blender takes about 30mins to export a 31.5m poly mesh while ZBrush takes around 2 mins for the same mesh. Cheers, -Andy On 09/03/2014 19:21, Fredrik hansson wrote: hi, i have recently written a obj loader myself just for fun. now i did try to optimize it quite a bit by making it multithreaded and a few other things. i have put it up on https://github.com/FredrikHson/fast_obj_loader now granted this is a much simpler example than doing everything that blender does with pushing it into blenders internal structure and all that. anyway tried it + blenders current importer. some stats blender total 17.8 sec. 8.6sec. parse time mine: sigle threaded 0.6seonds multi threaded 0.26sec this is on a 36mb obj file on a ssd drive with 8threads. so yes it could probably benefit from being done in c/c++ the question is still if its worth the trouble i personally never import anything much heavier than that 36mb file myself due to slow viewport/manipulation speeds after actually getting the file into blender and 18seconds is a bit annoying but i don't do it that often that its really much of an issue. what is much worse imo is export speeds ( i often forget export selected only) when dealing with dense subsurfed meshes. // Fredrik On Saturday, March 8, 2014 3:30 AM, Sebastian A. Brachi sebastianbra...@gmail.com wrote: Hi Paul, I'm pretty satisfied with the performance of my importers right now, and specially compared to max-script. Turned out the major bottleneck was from UV data, since I wasn't using foreach_set which is a much efficient method than adding uv data in a loop. check http://blenderartists.org/forum/showthread.php?321210-Importing-UV-coordinates This is for video game data that usually isn't very heavy though (although I'm also importing whole levels with hundreds of assets, all in ~40 seconds), and also not using an efficient method for unpacking half-floats (used a lot in video games for uvs). As I said before, I heard users complaining .obj importer performance vs zbrush's for example in 500 mb data (sculpts mainly). There might be room for improvement there, but consider the topics discussed (would be good to rewrite it? is C an better option? can small tweaks improve performance considerably?) Regards On Thu, Mar 6, 2014 at 12:26 PM, Paul Melis paul.me...@surfsara.nl wrote: Hi Sebastian, I read your interesting thread on blender import improvements. Did you make any progress on this topic? Would this be something that a summer-of-code student can work on as well? Regards, Paul On 01/05/14 23:00, Sebastian A. Brachi wrote: Hi all, this is the first time writing to the list, I'd like to start learning a lot and hopefully help to improve blender in some areas. My main interest right now is Blender's import/export pipeline. Currently I'm making an addon to import a lot of different formats from different game engines and also rewriting/improving some existing ones like PSK/PSA and MD5. I'd like to research the best possible ways to import to blender; my first concern besides code style
Re: [Bf-committers] Import, research on speed improvements
hi, i have recently written a obj loader myself just for fun. now i did try to optimize it quite a bit by making it multithreaded and a few other things. i have put it up on https://github.com/FredrikHson/fast_obj_loader now granted this is a much simpler example than doing everything that blender does with pushing it into blenders internal structure and all that. anyway tried it + blenders current importer. some stats blender total 17.8 sec. 8.6sec. parse time mine: sigle threaded 0.6seonds multi threaded 0.26sec this is on a 36mb obj file on a ssd drive with 8threads. so yes it could probably benefit from being done in c/c++ the question is still if its worth the trouble i personally never import anything much heavier than that 36mb file myself due to slow viewport/manipulation speeds after actually getting the file into blender and 18seconds is a bit annoying but i don't do it that often that its really much of an issue. what is much worse imo is export speeds ( i often forget export selected only) when dealing with dense subsurfed meshes. // Fredrik On Saturday, March 8, 2014 3:30 AM, Sebastian A. Brachi sebastianbra...@gmail.com wrote: Hi Paul, I'm pretty satisfied with the performance of my importers right now, and specially compared to max-script. Turned out the major bottleneck was from UV data, since I wasn't using foreach_set which is a much efficient method than adding uv data in a loop. check http://blenderartists.org/forum/showthread.php?321210-Importing-UV-coordinates This is for video game data that usually isn't very heavy though (although I'm also importing whole levels with hundreds of assets, all in ~40 seconds), and also not using an efficient method for unpacking half-floats (used a lot in video games for uvs). As I said before, I heard users complaining .obj importer performance vs zbrush's for example in 500 mb data (sculpts mainly). There might be room for improvement there, but consider the topics discussed (would be good to rewrite it? is C an better option? can small tweaks improve performance considerably?) Regards On Thu, Mar 6, 2014 at 12:26 PM, Paul Melis paul.me...@surfsara.nl wrote: Hi Sebastian, I read your interesting thread on blender import improvements. Did you make any progress on this topic? Would this be something that a summer-of-code student can work on as well? Regards, Paul On 01/05/14 23:00, Sebastian A. Brachi wrote: Hi all, this is the first time writing to the list, I'd like to start learning a lot and hopefully help to improve blender in some areas. My main interest right now is Blender's import/export pipeline. Currently I'm making an addon to import a lot of different formats from different game engines and also rewriting/improving some existing ones like PSK/PSA and MD5. I'd like to research the best possible ways to import to blender; my first concern besides code style is speed in large or medium files, and I have a couple questions. I've been reading http://wiki.blender.org/index.php/User:Ideasman42/ImportExport_TODO , and the idea of using C/C++ modules is very interesting. Here are some observations and questions for importing, (expect some misconceptions): 1) Python file reading/parsing. *Seems fast enough to me in binary data, even with processing many GB's. I haven't tested XML/text data though (seems many users complain of the obj importer, but where are the main bottlenecks is unknown to me) Also best practices for reading seems to improve the speed (see 2)) Q: C + Ctypes doesn't seem very good since we don't want to rewrite the reading part in C if it's done in python, and compile dlls or OS with the addons, right? But if someone like me would do it, does it seem like the best option because we can still keep the mesh building or other data handling in more readable python? Q: Is it worth to investigate Cython/pypy for speed improvements here and was it used in past addons pre 2.5? I haven't done any tests so far and I'd like to know opinions first, haven't found more than a couple threads in the list that mention it, and a few in BA: e.g., http://blenderartists.org/forum/showthread.php?278213- TEST-Cython-performances-test 2) Python binary data unpack (struct module). * This seems to add a lot of overhead, specially in big files. Also best practices allow for some speedups (like the use of struct.Struct or list.extend). Besides the main document in the API for best practices with a few tips in string handling when importing, I couldn't fine much info. Q: Is it worth to start/modify a document for best practices, and also add benchmarks? Who could I ask to review it? * What if Blender could accept/interpret python bytes objects to build geometry, avoiding the unpacking in python? E.g., reading a face index buffer all at once, and just passing the count, type (short in most cases) and bytes object
Re: [Bf-committers] python tangents export missing
+1 from me. this is something that i have wanted to have for quite a long time now. its also something that would be really useful when dealing with fbx files and udk, so we can have synced tangents between blender/xnormal and udk. maybe even unity but not sure about if it can import the tangents or just generate them. anyway would be great if it was finally added to the python api. From: Morten Mikkelsen mikkels...@gmail.com To: bf-blender developers bf-committers@blender.org Sent: Sunday, August 18, 2013 1:11 PM Subject: [Bf-committers] python tangents export missing I see rumblings now and then here and there about Blender's python API missing the ability to export Blender's internal tangent space. http://www.blender.org/forum/viewtopic.php?p=105835sid=68eaa02463462a62bbdcbe427761ca49 There's also been a proposed patch around for a while: https://projects.blender.org/tracker/index.php?func=detailaid=29335group_id=9atid=127 I just thought I'd bring it up in case anyone has the knowledge and bandwidth to perhaps pick it up. Cheers, Morten. ___ 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] Object space normal map axis proposed change.
a better option imo would be to give 3 small dropdown boxes under the object space selection or somewhere similar to the user where you can pick what goes where so you set it to match your target application From: metalliandy...@googlemail.com metalliandy...@googlemail.com To: bf-committers@blender.org bf-committers@blender.org Sent: Friday, June 14, 2013 10:50 AM Subject: [Bf-committers] Object space normal map axis proposed change. Hy everyone, I would like to propose a change the the axis configuration that is currently used when baking to object space normal maps. What does everyone think about changing it so that the axis matches the one for the tangent space normal maps (X+ Y+ Z+)? Currently the OS maps use a very odd configuration so if anyone wants to use them in other applications, or as something like a selection/direction mask while texturing, they have to do some very complicated channel flipping and swapping within Photoshop which is confusing even to experienced users. Cheers, -Andy ___ 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] Adding Separate Wireframe Color for Edit Mode
on the same topic made a patch like 5 months ago for well not the edit mode colors but per object (for all object types). as for your screenshot example here is one with my patch applied and the highpoly object having its color changed https://www.dropbox.com/s/kfle9d6s1xzw85d/retopocolors.PNG i think the problem before was the convincing ton part but can't really remember. http://projects.blender.org/tracker/?func=detailatid=127aid=33817group_id=9 From: Jonathan Williamson jonat...@cgcookie.com To: bf-blender developers bf-committers@blender.org Sent: Friday, June 7, 2013 11:52 PM Subject: [Bf-committers] Adding Separate Wireframe Color for Edit Mode 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] select loop behavior
this is something that also has annoyed me to no end when doing some strip modeling or retopology work. since i usually never leave vertex select mode it was the fastest way of selecting just the end of the poly strip. workaround... never work on a polygon strip that is just a single quad thick .. well or just select both verts manually its not that much extra work after all. From: Yousef Hurfoush ba...@msn.com To: blender foundation committers bf-committers@blender.org Sent: Saturday, May 11, 2013 9:21 PM Subject: [Bf-committers] select loop behavior hi recently if you select a loop at the end of mesh that doesn't have perpendicular edges it select the whole face, see the attached image: http://www.pasteall.org/pic/show.php?id=51119 is this a bug or change of behavior? thanks Regards Yousef Harfoush ba...@msn.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] Ideas for Blender 2.7
this mailing list isn't really for feature suggestions but i could always give you a few tips on a few things that should help you along 3. we already have this by pressing ctrl+e and mark/clear sharp then adding an edge split modifier at the end 4. cycles already lets you do this and its probably better/faster to fake it in BI anyway using area lights, and you can make it so the emmitting mesh does not cast shadows by placing it in another layer + enabling the this layer only button on the light 8. take a look at the looptools addon for the bridge function From: Halina Kumorek - Alexandrou halina1...@gmail.com To: bf-committers@blender.org Sent: Friday, March 22, 2013 8:56 PM Subject: [Bf-committers] Ideas for Blender 2.7 Developers, I have lots of ideas for developping Blender. I am making a project, which is an animation series. Please, include those ideas below and I will be unstopable. 1. Continue Internal Render Engine. 2. 1024 threads rendering support. 3. Setting smooth / flat shading not only for faces, but also for edges and vertices. This is useful, for example, for smoothing the perimeter of a cylinder without the shading of a sphere! 4. Materials which can cast light from faces, edges or vertices with all the lamps' settings (energy, distance, samples...). 5. Rendering code simplification in order to cut render times. 6. An option which allows anti-aliased shadows, atmosphere effect and others. 7. Inserting from table, copying and pasting characters to fields (for example material) and text objects. 8. Mesh editing fill gaps function. 9. Correct vertical sliders. At the half of each one value is 0.25 / 1.00 instead of 0.50 / 1.00! 10. Improve the rigging system! 11. With very low start clip distance faces that are too near themselves, not exactly overplaced, seem to be like that! Fix this, please! 12. In VERY LARGE meshes, edges (I don't undestand) are visible in rendered image. I would like this to be also fixed! 13. Graph editor actuator. In 2.4 there was something similar, IPO actuator. 14. Fix bugs! I would like the 2.7 release with *all* reported bugs fixed! 15. Rename function add cone to add cone / pyrapid. 16. Add option which disables collision in 3d view. Both 2 objects must have this option enabled to disable collision. Alexandros Alexandrou 22/3/2013 ___ 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] Matcap collection for release
ugh damn you yahoo mail client never press ctrl + enter :P anyway link to the stripeless version https://www.dropbox.com/s/qlt8vi2vmgvqk06/stripebase.PNG From: Fredrik hansson fredrikhansson_12...@yahoo.com To: bf-blender developers bf-committers@blender.org Sent: Thursday, February 7, 2013 5:14 PM Subject: Re: [Bf-committers] Matcap collection for release here is one i made for finding small bumps in smooth surfaceswithout having to rely on specular where you might only see them in a certain angle. https://www.dropbox.com/s/zahsnde22mdxu6j/stripes.PNG some examples using this https://www.dropbox.com/s/0ycap17itanb9e7/smoothsurface.jpg https://www.dropbox.com/s/ibaakrwzjv4dggy/matcaphead.jpg also got the same light setup without the stripes. From: Ton Roosendaal t...@blender.org To: bf-blender developers bf-committers@blender.org Sent: Sunday, February 3, 2013 3:58 PM Subject: [Bf-committers] Matcap collection for release Hi, For 2.66 we will have a default set of matcaps compiled into Blender. Adding own images (or pointing to custom directory) is a nice project for 2.67. We have to release soon anyway! Here's a selection of the 24 images I've received sofar: http://www.blender.org/bf/mc24.jpg The last image seems to be not so useful, but I've been ensured by power-sculpters it is! :) -Ton- Ton Roosendaal Blender Foundation t...@blender.org www.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands ___ 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
[Bf-committers] colored wireframe patch
http://projects.blender.org/tracker/index.php?func=detailaid=33817group_id=9atid=127 was getting a bit frustrated when retopologizing a mesh when both the mesh i was editing and the highpoly had black wireframes where i could not actually see what i was selecting so i made this little patch. and yes there has been 2 other patches that does this before none that actually seem to work as they were over 1-2 years old. anyway this takes the object color property and applies that color to the wireframe if the new colored wireframe checkbox is ticked so pretty straightforward to use. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] texture painting blend mode patch
seems like whatever i had crashing it before isn't an issue anymore so i rewrote those functions that used the hsv to rgb code to use the ones in math_color. From: Xavier Thomas xavier.thomas.1...@gmail.com To: Fredrik hansson fredrikhansson_12...@yahoo.com; bf-blender developers bf-committers@blender.org Sent: Thursday, November 1, 2012 9:09 PM Subject: Re: [Bf-committers] texture painting blend mode patch My optimization comment was not specific to your patch and apply to existing blending modes as well. The module maintainer will ultimately decide but it is (almost) always better to write code that works and optimize later using that code as reference and using profiling information with real life data than optimizing blindly. So my advise is to stick with a first non optimized patch first. The rgb-hsv funtions are still duplicated, resolving this seems clearly higher priority to me. 2012/11/1 Fredrik hansson fredrikhansson_12...@yahoo.com converted the code from 8bit - float didn't do any of that optimizing should perhaps do that but i preferred to just get it working quickly and without getting any additional errors. i did notice a few things however while testing out the code. mainly that it felt like it always were in air brush mode making some of the brushes way to strong unless you had a huge spacing (not overlapping). as for if the hsv_to_rgb crashes well it did when i originally wrote the patch but just looked at the code and i see no reason at all for it to actually crash as you said its just 2 simple static functions. From: Xavier Thomas xavier.thomas.1...@gmail.com To: Fredrik hansson fredrikhansson_12...@yahoo.com; bf-blender developers bf-committers@blender.org Sent: Wednesday, October 31, 2012 8:25 PM Subject: Re: [Bf-committers] texture painting blend mode patch I a looked at the patch and effectively the code for float images is missing. Another thing that might need investigating is the rgb_to_hsv and hsv_to_rgb method, basically duplicated code because the origiginal version crash with threading! I think it might be better to fix the original, it should be basic static methods, I do no see any reason to crash. Not related to this patch specifically but it seems there is quite a room for optimisation. If I understood well, for each pixel that is painted on, IMB_blend_color() is called, and this function is only a big switch(blend_mode) that then call the method that blend the 2 colors. One possibly better way to do this is to cache a pointer to the apropriate method each time the blend mode is changed so the huge switch statement is not done for every pixel. Another way maybe to inline the blend funtions so we do a function call less for each pixel. For the float version of the blend funtion SSE2 will certainly provide a 20 to 40% gain, and (depending on the compilator and the images used) you might want to avoid code like this: if(test) temp=big float calculation; else temp=other big float calc; which is not pipeline friendly, and prefer: temp1 = big float calculation; temp2 = other big float calc; temp = test ? temp1 : temp2; but this is not always the case so don't optimise blindly. Xavier 2012/10/31 Fredrik hansson fredrikhansson_12...@yahoo.com oh right i think that might have been why it wasn't added before or something i guess i could take a look at writing the float versions quickly should be the same pretty much. From: Antony Riakiotakis kal...@gmail.com To: Fredrik hansson fredrikhansson_12...@yahoo.com; bf-blender developers bf-committers@blender.org Sent: Wednesday, October 31, 2012 4:39 PM Subject: Re: [Bf-committers] texture painting blend mode patch This looks cool! A little remark though, we would also need float versions for the functions to support float images properly. ___ 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] texture painting blend mode patch
oh right i think that might have been why it wasn't added before or something i guess i could take a look at writing the float versions quickly should be the same pretty much. From: Antony Riakiotakis kal...@gmail.com To: Fredrik hansson fredrikhansson_12...@yahoo.com; bf-blender developers bf-committers@blender.org Sent: Wednesday, October 31, 2012 4:39 PM Subject: Re: [Bf-committers] texture painting blend mode patch This looks cool! A little remark though, we would also need float versions for the functions to support float images properly. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] texture painting blend mode patch
i think i did submit this forever ago but it kinda got ignored or something... anyway cleaned it up for revision 51772 and submitted it again. this patch adds a bunch of more blend modes for the texture painting brushes. all of these are added: Overlay Hard light Color burn Linear burn Color dodge Screen Soft light Pin light Vivid light Linear light Difference Exclusion Hue Saturation Luminosity Color http://projects.blender.org/tracker/index.php?func=detailaid=33021group_id=9atid=127 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Uniform displace modifier patch
just a little note on something that was removed for the svn commit the mid value. mainly the reason why i didn't have that affecting the strength value without the texture was really that it would mean 2 sliders doing the same thing really. but on the other hand having it default to 0.5 and with a strength of 1.0 would mean that applying a texture would give the same outwards push. not that its a big deal to slide the mid value down to 0 when your there to tweak the strength anyway. what might have been better imo that i didn't do originally is to grey out the mid value slider thus showing that its not used until you apply a texture to it. either way thanks for taking a look at this so quickly and great to see it being added to the trunk :D From: Fredrik hansson fredrikhansson_12...@yahoo.com To: bf-committers@blender.org bf-committers@blender.org Sent: Tuesday, August 14, 2012 6:27 PM Subject: [Bf-committers] Uniform displace modifier patch last one of the changes i had done for myself (well i do have one fixing some small things for glsl but i am sure i did submit that ages ago). another copy paste: this isn't really a new modifier or anything but just a modification to the regular displace modifier. now the thing this does is that when you don't have any texture loaded in the modifier it just applies the strength value directly to the mesh. works in normal x y z modes but not rgb-xyz (just didn't make any sense to add it to that). now the reason why i made this was really that every time i was going to do some retopology work i would see almost the entire face being inside the highpoly mesh making it really hard to work with it since 90% of what you did was lying under the surface of what was visible. i used to add an empty texture image to the modifier and set the mid value to 1 and the strength to something negative. but it really felt like it was a few to many steps for something so simple as to push the entire mesh outwards a little bit. included an example image of how its useful when retopologizing but i am sure its useful for other things as well. http://projects.blender.org/tracker/index.php?func=detailaid=32327group_id=9atid=127 ___ 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] Textured solid backface culling patch
hi just made a simple little patch for something that have been bugging me for a while now. what this does is basically remove the automatic backface culling that comes from turning on textures solid and moves it to the backface culling button making it more uniform with the other view modes. not really much else to say about it. http://projects.blender.org/tracker/index.php?func=detailaid=32325group_id=9atid=127 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] ndof patch
copy pasted from the patch notes: i wasn't really happy with how the ndof integration was done so i made some changes. the new behavior of it is that you can rotate and pan the view at the same time. i also added a new option to the ndof menu letting you pick turntable/trackball independently of the mouse viewport navigation style. and another option to change the rotation sensitivity separate from the panning since the scale of the scene might need you to change the translation speed much higher but the rotation should always work the same. holding shift + moving the ndof does just as before locking it to panning holding ctrl + moving will lock it to only rotation and holding no keys while moving will do both at the same time. http://projects.blender.org/tracker/index.php?func=detailaid=32326group_id=9atid=127 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Uniform displace modifier patch
last one of the changes i had done for myself (well i do have one fixing some small things for glsl but i am sure i did submit that ages ago). another copy paste: this isn't really a new modifier or anything but just a modification to the regular displace modifier. now the thing this does is that when you don't have any texture loaded in the modifier it just applies the strength value directly to the mesh. works in normal x y z modes but not rgb-xyz (just didn't make any sense to add it to that). now the reason why i made this was really that every time i was going to do some retopology work i would see almost the entire face being inside the highpoly mesh making it really hard to work with it since 90% of what you did was lying under the surface of what was visible. i used to add an empty texture image to the modifier and set the mid value to 1 and the strength to something negative. but it really felt like it was a few to many steps for something so simple as to push the entire mesh outwards a little bit. included an example image of how its useful when retopologizing but i am sure its useful for other things as well. http://projects.blender.org/tracker/index.php?func=detailaid=32327group_id=9atid=127 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Realtime PCF soft shadows support
its generated by the datatoc.py utility as such python datatoc.py c:#92;blendersourcedir#92;blender#92;source#92;blender#92;gpu#92;intern#92;gpu_shader_material.glsl - Original Message - From: Yousef Hurfoush lt;ba...@msn.comgt; To: blender foundation committers lt;bf-committers@blender.orggt; Cc: Sent: Sunday, June 26, 2011 2:21 AM Subject: [Bf-committers] Realtime PCF soft shadows support hi all this patch is very outdated, i tried to update but i can#39;t hack the gpu_shader_material.glsl.c (will i don#39;t know how it was generated) and currently there are no turn-around to get shadows from a texture with alpha transparency, if there are, fell free to guide me !! thanks in advance ___ 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] new patch:uniform displace modifier when no texture is present
https://projects.blender.org/tracker/index.php?func=detailaid=24177group_id=9atid=127 copy pasted from the patch description: this removes the need for adding a texture if all you want is a uniform push over the entire mesh using the displace modifier. now my usual workflow is to use the displace modifier + one single colored texture when i am retopologizing a mesh so the new mesh will be sightly above the surface instead of partially hidden this patch removes the need for that texture step. now this works in x y z and normal mode disabled the xyz-rgb one since it would just result in the entire mesh being pushed in the all axises at once. and it works just as before with a texture present. compiled against rev:32357 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Patch for Bump map painting preview. Please, review
first off i love the ability to paint bumpmaps directly without having to render :D but i did notice a small bug in the way you generate the normals as shown here http://img834.imageshack.us/img834/6781/bump.jpg its quite simple to fix it i have actually gone ahead and done that myself. http://www.pasteall.org/14583/cpp lines 15 and 17 are the ones i changed. http://img530.imageshack.us/img530/2142/bump2.jpg this is how it looks after those changes. now i do have one request with this a simple value controlling the strength of the bump as it can feel a bit weak at times. --- On Mon, 7/26/10, Konrad Wilhelm Kleine kon...@konradwilhelm.de wrote: From: Konrad Wilhelm Kleine kon...@konradwilhelm.de Subject: [Bf-committers] Patch for Bump map painting preview. Please, review To: bf-blender developers bf-committers@blender.org Date: Monday, July 26, 2010, 5:23 AM Hi, I've managed to get bump map painting working using the technique we talked about during yesterdays developer meeting: Generating normal values from a height map using a Height2Normal GLSL shader. I would really appreciate every feedback, or bug report, or feature request I can get for this patch! You can find more information here: Design document: http://wiki.blender.org/index.php/User:Kwk/Gsoc2010/BumpMapPainting Video: http://vimeo.com/13639081 Patch: http://www.pasteall.org/14573/diff Cheers, -Konrad ___ 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] seams from UV isles script
just finished rewriting this old script from 2.4x so it would work in 2.5 works on the entire mesh and is imo great for when you need to import+export a lot. works as far as i know exactly like it did in 2.4x http://www.pasteall.org/14458/python ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] seams from UV isles script
i really had no idea where to place it before that's why i posted it like i did but i have now added it to the extension tracker so thanks for pointing me in the right direction. https://projects.blender.org/tracker/index.php?func=detailaid=22929group_id=153atid=467 --- On Tue, 7/20/10, mindrones mindro...@gmail.com wrote: From: mindrones mindro...@gmail.com Subject: Re: [Bf-committers] seams from UV isles script To: bf-blender developers bf-committers@blender.org Date: Tuesday, July 20, 2010, 9:42 AM Hi Fredrik, On 07/20/2010 03:40 PM, Fredrik hansson wrote: just finished rewriting this old script from 2.4x so it would work in 2.5 works on the entire mesh and is imo great for when you need to import+export a lot. works as far as i know exactly like it did in 2.4x http://www.pasteall.org/14458/python cool, please read this http://wiki.blender.org/index.php/Dev:Py/Sharing and when you have time come in #blenderpython, we can discuss about where to put it :) Thanks! Luca _ http://www.mindrones.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
[Bf-committers] [patch] [#22451] fix for subtractive clay brush
made a small patch to the clay sculpting brush fixing some noise issues http://projects.blender.org/tracker/index.php?func=detailaid=22451group_id=9atid=127 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Texture baking proposals
i definitely would like to see some super sampling and more options to bake to like the specular color map and all that goodness. got 2 more ideas to improve texture baking that wasn't on your list. first some form of cage for baking one mesh onto another this would let you control the length of the rays and direction so you can avoid things like http://www.hula.ca/cylinder_normal.jpg or as shown in the last image on http://www.poopinmymouth.com/tutorial/normal_workflow_2.htm with the cage. the cage would basically be the same mesh duplicated and moved outwards in the normal direction + the ability to move verts manually. now the second thing is in the same spirit but much simpler. this would be to avoid areas where its easy to get rays that hit the wrong surface like between fingers by placing a blocker mesh that is just a single face between each finger that if the baking rays hit those they won't try to go any further and use the last valid hit instead. heres some examples on a mesh of mine baked using xnormal that has support for all of this http://img405.imageshack.us/img405/3082/rayproblems.jpg first one with the cage has only had the bottom of the cage edited to be flat with the sole of the shoe so notice how much cleaner the bottom edge of the sole is. second one has had a plane between the legs only so that effectivly did the same as setting a small distance value however the distance value might be ok with say 0.1 for the legs but the fingers or that cloth thats sticking up on the shoe might need much less and lowering the value might cause the foot to show up trough the side of the shoe as if that needed a larger value. the third one is without any of those features and the max distance set way to high. the cage might handle both of these issues but is much slower to setup as you need to go over the entire mesh instead of just adding planes where you see fit. --- On Tue, 3/23/10, Wahooney wahoo...@wahooney.net wrote: From: Wahooney wahoo...@wahooney.net Subject: [Bf-committers] Texture baking proposals To: bf-blender developers bf-committers@blender.org Date: Tuesday, March 23, 2010, 12:07 PM I've written out some proposed ideas for texture baking in 2.5: http://wiki.blender.org/index.php/User:Wahooney_re/Baking_Ideas If anyone wants some GSOC ideas these might be handy, although some more ideas should probably be added to make it more substantial, as this might not take a developer that long to implement. Keith ___ 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] new patch#18645 adding more texture paint blending modes
http://projects.blender.org/tracker/?func=detailaid=18645group_id=9atid=125 this adds the following blending modes: overlay hard light color burn linear burn color dodge screen soft light pin light vivid light linear light difference exclusion hue saturation luminosity color did only write these for unsigned char textures so they won't work with floating point textures and i had some issues with rgb_to_hsv + hsv_to_rgb causing crashes due to what im guessing is the threading so i made new versions of those functions to not use any pointers. compiled against rev:26834 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
