[Bf-committers] Unlimited Clay status
Hi guys! The last step on getting good topology (aside from a good smoothing that luckily we already have) seems to be some sort of dynamic brush size, I mean, mesh detail under the brush should be fine enough to avoid stretching polygons, and also detail transition among adjacent faces should be smooth and the only way of getting that is with an adaptive brush radius. if the underlying faces on the brush are too big , then the radius will scale accordingly and subdivide, then scale again to the smaller faces and subdivide , till reach the user desired radius and perform the full detail subdivission plus the sculpt action this seems to be the behaviour of sculptris. I need to thinker with the sculpt/brush structures to see how could I implement this. I will preciate any help/hint on that from experienced sculpt devs in order to speed up the implementation. the goal is to alwyas have enough detail under the brush to perform the sculpt action and avoid sharp size transitions among adjacent faces. Thanks in advance Farsthary ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender developer meeting, sunday 12 dec, 2010
Ubuntu has a new font this year which I consider to be very aesthetically pleasing and versitile. It is easy to read at just about every size. It's a sans serif font. Sans serif fonts can be easier to read on a computer monitor than serif fonts, especially with small text where the serifs disappear or are distorted in some other way. http://font.ubuntu.com/ Cheers! Loop On 12/12/2010 08:52 AM, Ton Roosendaal wrote: - Dalai proposes to replace the ancient built-in vector font with a more modern (and official free) one. We can even include a couple? Waiting for proposal... ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Fonts
Hi, hache...@shawnigan.ca (2010-12-13 at 0957.04 -0800): There are actually quite a few very good fonts that have very good multi-language support and have good licenses. My current favorite is the Droid family of fonts, commissioned by Google and released under the Apache license. Droid - http://www.droidfonts.com/ I have been testing this one for interface, it is highly readable in really tiny sizes with AA off (sharp). [...] Bitstream Vera - http://www.gnome.org/fonts/ Current Blender interface fonts are derived from Vera, and we already know what goes with some combinations of hinting, kerning and AA settings. Maybe not a problem for big size vector usage, but still. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Fonts
Hi, On Mon, Dec 13, 2010 at 5:46 PM, Dalai Felinto dfeli...@gmail.com wrote: Hello everyone. It's nice to see so much enthusiasm on that topic. Please keep in mind that it's important to pick a font that has an extense support/fallback for unicode. Ton mentioned the idea of bundle Blender with a few fonts. I'm afraid the size of those fonts is too big. Unless we add them as a separate package I compiled Blender here with the Droid http://www.pasteall.org/pic/show.php?id=7479 http://www.pasteall.org/pic/show.php?id=7479patch available here: http://www.filedropper.com/showdownload.php/droidfont Quoting my blender-design-font-specialist friend [1]: It may need some adjustments (default size + hinting [2] ). I have no idea how Blender handles fallbacks (when a char is available in another ttf file). But I'm assuming it will be supported eventually (and Droid does have the asian set in another ttf file). I can take a look at that :) Regards, Dalai [1] - http://www.blog.ohweb.com.ar/ [2] - http://en.wikipedia.org/wiki/Font_hinting [3] - Droid Fonts downloaded from: http://damieng.com/blog/2007/11/14/droid-font-family-courtesy-of-google-ascender www.dalaifelinto.com 2010/12/13 jonathan d p ferguson jdpf.p...@gmail.com hi. On Dec 13, 2010, at 12:57 PM, Harley Acheson wrote: There are actually quite a few very good fonts that have very good multi-language support and have good licenses. My current favorite is the Droid family of fonts, commissioned by Google and released under the Apache license. Droid - http://www.droidfonts.com/ Ubuntu Font Family - http://font.ubuntu.com/ Linux Libertine - http://www.linuxlibertine.org Bitstream Vera - http://www.gnome.org/fonts/ Indeed. The Free World now has many wonderful fonts to choose from: See [1,2,3,4,5,6,7,8,9,10] for places to find FOSS fonts. [1] http://en.wikipedia.org/wiki/Free_software_Unicode_typefaces [2] http://en.wikipedia.org/wiki/Liberation_fonts [3] http://www.tug.dk/FontCatalogue/ [4] http://scripts.sil.org/cms/scripts/page.php?site_id=nrsiid=OFL_fonts [5] http://www.alvit.de/blog/article/20-best-license-free-official-fonts [6] http://www.unifont.org/fontguide/ [7] http://www.stixfonts.org/ [8] http://www.scholarsfonts.net/cardofnt.html [9] http://www.gust.org.pl/projects/e-foundry/tex-gyre/ [10] http://www.scholarsfonts.net/cardofnt.html have a day.yad jdpf ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [33578] trunk/blender/source/blender/ editors/curve: Related to previous commit:
On Sun, Dec 12, 2010 at 8:05 PM, GSR gsr@infernal-iceberg.com wrote: Hi, ideasma...@gmail.com (2010-12-10 at 1205.52 +): I'm mostly concerned that the usablity of Blender downgraded just for the sake of an enforced consistancy. The clunkiness of the handle menu should have not been accepted in the first place. [...] Menu's are not that clunky. Compare changing curve handle types with say - Switching between Vertex/Edge/Face mode when mesh editing. Other modelers may comment on this, but by the time I become proficient at using blender I had Ctrl+Tab+1/2/3 in muscle memory and used all the time. So you just use the keyboard, not the mouse? Yeah, I can see why you have no problems with that one... menus became visual output for you, and the input goes via keys. Other users never learn about that and just say popups get on the way with not speed wins (so they prefer the even slower method of moving the mouse away from the real workzone, and back). Of course, 1(-2) key(s) is always faster than 3, no discussion possible there. And with this you just reminded me two problems: 1. Non obvious number association. Someone talked about displaying them for all menus where it applies, so people first get a clue about the existence of the feature, and second can learn the numbers by seeing instead of by slowly counting. It would even make less painful the relearning every time the items get shuffled (the old snap menu wars). 2. Menus do not allow modifiers for toggle or multiselect. For edit multimode people instead has to use the mouse to aim and hit some buttons (small targets in the edge of the work area... here clunky adjetive fits). Move to layer is fixed already, for example, you get all the 20 entries under your cursor, fast, with number keys and modifiers working. GSR Hi GSR, agree that number selection isn't obvious, committed automatic key assignments r33648 which are displayed in the menu... http://www.graphicall.org/ftp/ideasman42/menu_letter3.png This means Handle keys can be accessed by V+A, V+V, V+L, V+F So, NOW can we use a menu for handle types? :) Note about method used... Ton liked automatic assignment idea best though it does mean renaming or adding menu items will change keys used, before that I tried manual assignment of keys in the menu. http://www.graphicall.org/ftp/ideasman42/menu_letter.png Its clunky but it would give some more control to keeping keys from changing or not assigning keys to some menu items. About mesh vertex/edge/face menu enabling more then one type at a time, This is possible but would need to be done with an operator which checked for Shift held on invoke for eg. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [33650] trunk/blender/source/blender/ makesrna/intern/rna_define.c: disallow RNA color values to be set to negative values.
On Tue, Dec 14, 2010 at 3:44 PM, Campbell Barton ideasma...@gmail.com wrote: Log Message: --- disallow RNA color values to be set to negative values. Material colors could be set to -100.0 if typed in manually, this is sure to cause bad/unpredictable behavior. If this is a problem for materials, then it should be set in the material colour's range functions. Forcing all colour properties to have these limits is too heavy handed - It's not sure to cause bad behaviour, there are plenty of cases where you might want negative values in a colour property - doing things in the compositor for example. Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [33650] trunk/blender/source/blender/ makesrna/intern/rna_define.c: disallow RNA color values to be set to negative values.
On Tue, Dec 14, 2010 at 5:10 AM, Matt Ebb m...@mke3.net wrote: On Tue, Dec 14, 2010 at 3:44 PM, Campbell Barton ideasma...@gmail.com wrote: Log Message: --- disallow RNA color values to be set to negative values. Material colors could be set to -100.0 if typed in manually, this is sure to cause bad/unpredictable behavior. If this is a problem for materials, then it should be set in the material colour's range functions. Forcing all colour properties to have these limits is too heavy handed - It's not sure to cause bad behaviour, there are plenty of cases where you might want negative values in a colour property - doing things in the compositor for example. Matt Hi Matt, Yep, materials could have their colors clamped instead (setting value ranges is enough, without having range functions). However this is the sort of thing that is often overlooked when adding properties - color properties like sequencer, bone, object, theme, lamp shadow, render stamp, fcurve, brush, world etc. So I think its better to have negative colors opt-in. This way nodes which are known to work with negative colors can have negative values explicitly set. If you think most compo/shader nodes work with negative colors I can add in calls to all of them to allow negative color's so at least they work the same as before. Later if its found some compo nodes dont work right negative color func can be removed ofcourse. Would this be ok? ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [33650] trunk/blender/source/blender/ makesrna/intern/rna_define.c: disallow RNA color values to be set to negative values.
On Tue, Dec 14, 2010 at 4:35 PM, Campbell Barton ideasma...@gmail.com wrote: On Tue, Dec 14, 2010 at 5:10 AM, Matt Ebb m...@mke3.net wrote: On Tue, Dec 14, 2010 at 3:44 PM, Campbell Barton ideasma...@gmail.com wrote: Log Message: --- disallow RNA color values to be set to negative values. Material colors could be set to -100.0 if typed in manually, this is sure to cause bad/unpredictable behavior. If this is a problem for materials, then it should be set in the material colour's range functions. Forcing all colour properties to have these limits is too heavy handed - It's not sure to cause bad behaviour, there are plenty of cases where you might want negative values in a colour property - doing things in the compositor for example. Matt Hi Matt, Yep, materials could have their colors clamped instead (setting value ranges is enough, without having range functions). However this is the sort of thing that is often overlooked when adding properties - color properties like sequencer, bone, object, theme, lamp shadow, render stamp, fcurve, brush, world etc. So I think its better to have negative colors opt-in. I'm really not sure why. Colours are used for all kinds of things, not just pixels in an image. They can be used to represent other things like displacements, or used as relative offsets (eg. some comp nodes), or all kinds of stuff. Blender uses full linear floating point colours internally, and there's nothing inherent in that that means they should only be positive. I think defining this as something that 'all colours should be always positive' is too great a limitation to apply as a blanket case across blender - to me it's a similar sort of thing as the idiotic 'can't make concave faces' error in mesh edit mode, making an arbitrary yet wide ranging limitation in order to prevent a few corner cases. On a practical level I also disagree since: * people have to willingly type negative colours into those fields to start with - if that's what you explicitly type in then you get what you get * the idea that things can be added back in as needed I think is expecting a lot, I don't think it's the sort of thing that people will be bothered with reporting as bugs * if it's to prevent bugs, better to fix it at the source, since it could be a deeper problem. eg. if it's a problem in materials, what happens when a texture with negative colours is used, or anim sys is used to get negative values in there, or if a node setup generates negative colours? Clamping RNA inputs may not be enough there. My 2c anyway. Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
