Re: [Bf-committers] Arabic support in text editing
Thanks for the link. I looked at fribidi and found it interesting. Their standalone is doing the same as we are with the python scripts (they call it log2vis - to convert from logic to visual strings). Now, if we use this lib, do we still need harfbuzz? It seemed to me that truetype2 can handle most of the layout, no? -- Dalai 2011/10/25 Majid AL-Dharrab ma...@aldharrab.com: I guess you can't go wrong with harfbuzz-ng on freetype2. After all, that is what's used to render text in Firefox. libass, the SSA subtitle renderer used in VLC and MPlayer, has recently started to support complex and bidi scripts using harfbuzz and fribidi on top of freetype2. That resulted in very sophisticated rendering of complex texts. Implementing that turned out to be easier than the developer had thought. http://ssadev.blogspot.com/2011/05/getting-complex-text-layout-into-libass.html I hope his experience helps make the issue a bit easier for our Blender devs. Good luck! ___ 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] note to developers about 32 vs 64 bit long datatypes
I recently came across a similar issue when working on random number generation for particles. I copied part of the code in BLI_rand.h/rand.c, which uses the common linear congruential generator [1]. In order to create random numbers over the full 32-bit integer range, the internal state variable must be a 64-bit integer, and to ensure this the code uses different typedefs depending on OS: #if defined(WIN32) !defined(FREE_WINDOWS) typedef unsigned __int64r_uint64; #else typedef unsigned long long r_uint64; I don't know if this code even takes Win64 into account ... but according to the standard the awkward unsigned long long type should have *at least* 64 bits. Imo it would be nice to have a general, reliable, platform-independent 64 bit typedef for this sort of thing. On Tue, Oct 25, 2011 at 11:42 PM, pete larabell xgl.asyl...@gmail.com wrote: Hey all, was debugging a new node im making and some discussion on IRC lead me to find this: http://en.cppreference.com/w/cpp/language/types Note that unsigned long, and long are truly DIFFERENT sizes on Win64 vs Linux64/FreeBSD64/OSX64 Not sure if anyone else ran into a problem like this, but I thought it was worth bringing up to everyone that may be expecting something a certain size (for filling out a struct or whatever), it's different depending on the platform you compile on. Cheers! ___ 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] note to developers about 32 vs 64 bit long datatypes
Oops, forgot the link: [1] http://en.wikipedia.org/wiki/Linear_congruential_generator On Wed, Oct 26, 2011 at 11:33 AM, Lukas Tönne lukas.toe...@googlemail.com wrote: I recently came across a similar issue when working on random number generation for particles. I copied part of the code in BLI_rand.h/rand.c, which uses the common linear congruential generator [1]. In order to create random numbers over the full 32-bit integer range, the internal state variable must be a 64-bit integer, and to ensure this the code uses different typedefs depending on OS: #if defined(WIN32) !defined(FREE_WINDOWS) typedef unsigned __int64 r_uint64; #else typedef unsigned long long r_uint64; I don't know if this code even takes Win64 into account ... but according to the standard the awkward unsigned long long type should have *at least* 64 bits. Imo it would be nice to have a general, reliable, platform-independent 64 bit typedef for this sort of thing. On Tue, Oct 25, 2011 at 11:42 PM, pete larabell xgl.asyl...@gmail.com wrote: Hey all, was debugging a new node im making and some discussion on IRC lead me to find this: http://en.cppreference.com/w/cpp/language/types Note that unsigned long, and long are truly DIFFERENT sizes on Win64 vs Linux64/FreeBSD64/OSX64 Not sure if anyone else ran into a problem like this, but I thought it was worth bringing up to everyone that may be expecting something a certain size (for filling out a struct or whatever), it's different depending on the platform you compile on. Cheers! ___ 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] Arabic support in text editing
Actually, fribidi's shaper is very primitive and rudimentary and it has lots of fundamental problems. It simply replaces letters with their Unicode presentation forms depending on their position in a word. That is not a good approach because it completely ignores ligatures and other OpenType features, leading to broken support for most modern fonts that use OpenType tables. That's why libass only uses a fribidi function that positions text characters in the correct order, following rules from Unicode's bidi algorithm (http://unicode.org/reports/tr9/#The_Paragraph_Level). Shaping is then handled by HarfBuzz, which a great OpenType shaper. Unfortunately, I'm not a developer, so I'm afraid I can't help any further with this issue. But you can contact libass's developer if you face any problems with either lib. His GSoC project was supporting complex and bidi scripts, so he probably knows a couple of tricks that might help. Good luck. :) On Wed, Oct 26, 2011 at 9:57 AM, Dalai Felinto dfeli...@gmail.com wrote: Thanks for the link. I looked at fribidi and found it interesting. Their standalone is doing the same as we are with the python scripts (they call it log2vis - to convert from logic to visual strings). Now, if we use this lib, do we still need harfbuzz? It seemed to me that truetype2 can handle most of the layout, no? -- Dalai 2011/10/25 Majid AL-Dharrab ma...@aldharrab.com: I guess you can't go wrong with harfbuzz-ng on freetype2. After all, that is what's used to render text in Firefox. libass, the SSA subtitle renderer used in VLC and MPlayer, has recently started to support complex and bidi scripts using harfbuzz and fribidi on top of freetype2. That resulted in very sophisticated rendering of complex texts. Implementing that turned out to be easier than the developer had thought. http://ssadev.blogspot.com/2011/05/getting-complex-text-layout-into-libass.html I hope his experience helps make the issue a bit easier for our Blender devs. Good luck! ___ 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] note to developers about 32 vs 64 bit long datatypes
MEM_sys_types.h can be used for this, it has int64_t and uint64_t. On Wed, Oct 26, 2011 at 11:33 AM, Lukas Tönne lukas.toe...@googlemail.com wrote: I recently came across a similar issue when working on random number generation for particles. I copied part of the code in BLI_rand.h/rand.c, which uses the common linear congruential generator [1]. In order to create random numbers over the full 32-bit integer range, the internal state variable must be a 64-bit integer, and to ensure this the code uses different typedefs depending on OS: #if defined(WIN32) !defined(FREE_WINDOWS) typedef unsigned __int64 r_uint64; #else typedef unsigned long long r_uint64; I don't know if this code even takes Win64 into account ... but according to the standard the awkward unsigned long long type should have *at least* 64 bits. Imo it would be nice to have a general, reliable, platform-independent 64 bit typedef for this sort of thing. On Tue, Oct 25, 2011 at 11:42 PM, pete larabell xgl.asyl...@gmail.com wrote: Hey all, was debugging a new node im making and some discussion on IRC lead me to find this: http://en.cppreference.com/w/cpp/language/types Note that unsigned long, and long are truly DIFFERENT sizes on Win64 vs Linux64/FreeBSD64/OSX64 Not sure if anyone else ran into a problem like this, but I thought it was worth bringing up to everyone that may be expecting something a certain size (for filling out a struct or whatever), it's different depending on the platform you compile on. Cheers! ___ 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] osg exporter
Hi there is OpenSceneGraph exporter https://github.com/cedricpinson/osgexport/ not sure, if it fits into 'export' option into Blender, still OpenSceneGraph is widely used scenegraph and export option to it will be welcomed by graphics developers. Regards Sergey ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Arabic support in text editing
hi @dalai: * Note 2: a python addon exclusively for the text3d could work for you as well. Have you considered it? yes i do, and i'm trying to build one. Let me know what you think. If someone is interested on tackling that we can put branch up and running. i'm happey to help with that, but currently i'm totally occupied with my work, and i'm a .NET dev. i know basic c c++ maybe more, but it's somewhat hard to do the implementation for know, i'll try to dig in if i had more time (if Allah wishes). @Majid AL-Dharrab: thanks for the info. why implement functions from different libs, i think there are other libs that could do it all i'm still searching for a better text stack libs. i'll report as i'm progressing. Yousef Harfoush ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Arabic support in text editing
Hi, I noticed pango being mentioned here is one possible implementation for graphics http://code.google.com/p/osgpango/ ( just for reference ) it requires though quite a lot dlls (cairo, pango, many gtk+ dlls ) to be included, so the size of Blender will keep growing Regards Sergey ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Bicubic filtering for bump maps, patch + discussion
Hi everyone, there has been some work by Morten Mikkelsen for supporting bicubic filtering for bump maps. I have helped adapting the code to glsl and the result can be seen here: old: http://www.pasteall.org/pic/19660 new: http://www.pasteall.org/pic/19659 The patch is here: http://www.pasteall.org/25833/diff Notes: This patch substitutes the Best Quality setting on capable GPUs with bicubic filtering. It may be preferable to make an extra setting altogether for this? The functionality relies on GLSL 1.3 and uses the textureGather function to quickly get samples from nearby texels. Getting the samples normally would require 16 instead of 4 texture samples. However only the red component is taken. This implies that for correct behaviour the rgb scannels need to be identical. Bump maps are usually monochrome anyway but it is possible to use a colour image as a bump map with in trunk functionality. After some discussion with Morten we thought that there are some ways this could be done(with increasing difficulty IMO): 1) Leave it up to the artist to enforce that he uses only black/white images 2) Use 16 samples and make this an extra setting for good systems 3) Make 1-channel images and a luminance upload path for 1-channel images. Best Quality bump maps only work with one-channel images Thoughts? ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Arabic support in text editing
@Sergey Kurdakov AFAICR, harfbuzz doesn't have any dependencies except for freetype2, of course. Fribidi doesn't require any dependencies either. Besides, pango's shaper is a little bit inferior to harfbuzz. @Yousef Hurfoush Harfbuzz can do all of this on its own (with freetype2). I think Greg just found it easier to use fribidi's function instead. Fribidi's part in this is the easiest anyway, so recoding it for blender won't be too much of a hassle. Although, I'm curious to see what other possible solutions you can come up with. Regards, Majid On Wed, Oct 26, 2011 at 6:11 PM, Sergey Kurdakov sergey.fo...@gmail.comwrote: Hi, I noticed pango being mentioned here is one possible implementation for graphics http://code.google.com/p/osgpango/ ( just for reference ) it requires though quite a lot dlls (cairo, pango, many gtk+ dlls ) to be included, so the size of Blender will keep growing Regards Sergey ___ 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] Arabic support in text editing
Harfbuzz can do all of this on its own (with freetype2). then this sums it up i think, implementing harfbuzz over the existence of freetype. i'll try to tackle the idea in the next days. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Bicubic filtering for bump maps, patch + discussion
It should be mentioned that two variants are 3) are possible. One is to simply convert the color image to grayscale during uploads to the gpu. The other is to actually support single channel image painting in blender and then only support the bicubic for such bump maps. Though I would be thrilled to see single channel images supported in blender for painting I actually still like the idea of converting the bump map during upload to grayscale because it makes it more efficient all around whether bicubic is in use or not. It consumes less memory and makes it more feasible for people to use the new (2.61) 16 bits per height in glsl when the bump map is a float image. However, I have no idea if this is possible or not since it requires knowing at that point in the code that the texture to be uploaded is used by a material with bump and it also requires knowledge on whether or not the same texture will be used for anything color related. Another option is of course to define it such that blender always does bump using red channel only but I am guessing I won't win any popularity contests with this suggestion? :) Anyway, the difference in quality is very significant so I'm hoping we can work this in somehow. Several artists were bugged by the lack of quality during close-up when painting bump maps. 2011/10/26 Αντώνης Ρυακιωτάκης kal...@gmail.com Hi everyone, there has been some work by Morten Mikkelsen for supporting bicubic filtering for bump maps. I have helped adapting the code to glsl and the result can be seen here: old: http://www.pasteall.org/pic/19660 new: http://www.pasteall.org/pic/19659 The patch is here: http://www.pasteall.org/25833/diff Notes: This patch substitutes the Best Quality setting on capable GPUs with bicubic filtering. It may be preferable to make an extra setting altogether for this? The functionality relies on GLSL 1.3 and uses the textureGather function to quickly get samples from nearby texels. Getting the samples normally would require 16 instead of 4 texture samples. However only the red component is taken. This implies that for correct behaviour the rgb scannels need to be identical. Bump maps are usually monochrome anyway but it is possible to use a colour image as a bump map with in trunk functionality. After some discussion with Morten we thought that there are some ways this could be done(with increasing difficulty IMO): 1) Leave it up to the artist to enforce that he uses only black/white images 2) Use 16 samples and make this an extra setting for good systems 3) Make 1-channel images and a luminance upload path for 1-channel images. Best Quality bump maps only work with one-channel images Thoughts? ___ 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: baking to vertex colours
Hi all, I have submitted a patch that allows render baking directly to vertex colours. The advantage of this is that it doesn't require a UV map, but the quality of the bake will depend on the resolution of the mesh. http://projects.blender.org/tracker/?func=detailatid=127aid=29035group_id=9 http://www.pasteall.org/pic/19692 It currently works well for all bake modes except full render, shadow and AO. Full render and shadow have the occasional black vertex, and AO has its values shifted randomly. Increasing the number of samples for AO fixes it, so I guess it's just unstable noise. Baking from selected to active works too. Baking a modified mesh (e.g. subdivision surface) does not work; it will segfault due to the different number of vertices. Maybe the bake should just skip objects that use such modifiers? Ton, you might be interested in the patch because it adds a new field 'origindex' to VlakTableNode, as suggested by Brecht. This maps from VlakRen back to the face in the source mesh. It is only populated when doing a vertex colour bake. Any feedback on this patch would be welcome. Cheers, Alex ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposal for View Docs on Right Click
On Wed, Oct 26, 2011 at 3:35 PM, Harley Acheson harley.ache...@gmail.com wrote: we don't want one doc for bpy.ops.texture.slot_move, better glob bpy.ops.texture.slot_*, or bpy.ops.texture.* and then link to a page explaining about blender texture system. I'd say we do. And I'd say that trying to figure out whether to use bpy.ops.texture.slot_*, or bpy.ops.texture.* shows just how arbitrary it can be to try to group these things. So don't try. Sure, that one page would just be about slot_move, but then some industrious soul would add links to a page on texture slots AND another link to a page on texturing in general. In the text of this page someone could add a hyperlink to a page about slot_copy. And anywhere that mentions moving texture slots could be hyper-linked to this page. This type of thing can only be done well when the atoms of information are small and predictable. Imagine writing in the wiki and wondering whether you can make something a hyperlink. Making the pages this specific means that you can easily guess what you can link to and also guess the target address, so you can do so without pausing to look anything up. If you have to stop and check to see whether a target document exists you might not even make the link. If you instead make larger pages that contain multiple items then you can get stuck when trying to maintain it. Say the page gets too long and complicated because people are adding too much useful information. If you were to break the page up into smaller logical parts you would then have to FIX most of the links that go to the page from elsewhere. So I guess my biggest point is that you can have lots of internal links in the wiki, like wikipedia, if the target pages are very specific and predictable. But you will get very few internal links if the pages are based instead on unpredictable arbitrary groupings. Harley Hi Harley, *Lots of things are arbitrary*, we can just link in to what makes most sense at the time, if it happens that 1 operator links to 3 docs - we add a submenu, if that submenu gathers 10 items - we remove some or have a wiki page which references others, if wiki pages like this are hard to maintain we write a HTML into the temp dir and use that --- if the whole system sucks: we kick it out or go back to square 1. Otherwise you raise some valid concerns but I think you also jump to conclusions about what people will do, overlooking that this can be maintained in a way which doesn't interfere with the wiki organization. You're comments about wiki internal linking would be best replied to be wiki authors. Its all speculation too until we try it. since this is easy to test in my spare time, I think this can work. - Add in sample mapping data and menu item into svn (py script containing mapping data and operator that uses it) - I can do this + get 1 panel working. - a group of us try get ONE category of buttons working, say all render buttons / settings. - If this works usefully we try get it ready for release (add in mesh, scene, world mapping too), otherwise kick it out. Interested in who's able to help 'ID -- wiki' mapping once the basics are in place. -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Proposal: Rename blenderbuttons
Hi all, I'm planning on renaming the blenderbuttons datafile to blenderbuttons.png (i.e. giving it a proper extension). This should make it easier to edit and/or view this file using standard image editing tools without having to save off a copy first. Are there any projects pending merges this cycle with heavy changes to this file which may benefit from being merged first? Otherwise, I'll be looking at doing this change tomorrow afternoon (Friday 28th, local time). Cheers, Aligorith ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposal: Rename blenderbuttons
On Thu, Oct 27, 2011 at 12:38 PM, Joshua Leung aligor...@gmail.com wrote: Hi all, I'm planning on renaming the blenderbuttons datafile to blenderbuttons.png (i.e. giving it a proper extension). This should make it easier to edit and/or view this file using standard image editing tools without having to save off a copy first. If you're going to do that, why not make it something a bit more self-explanatory, like blender_icons.png cheers Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] UI changes from cycles branch
On Tue, Oct 25, 2011 at 4:07 AM, Brecht Van Lommel brechtvanlom...@pandora.be wrote: Hi, Panel headers a bit darker now and increased button embossing: Before: http://www.pasteall.org/pic/show.php?id=19452 Latest: http://www.pasteall.org/pic/show.php?id=19501 This is certainly an improvement on the first proposal I also like the icons to be a bit more muted, again to avoid them grabbing attention too much with highlights. For me this is what really finishes it off, to make the interface nice calm, but maybe this is considered too dull. -1. Firstly I don't see the necessity of this - I think the current icons are excellent and strike a good balance between quick wayfinding and visual noise. But even assmung its needed, this still is not a good way to go about it. If you want duller icons, they need to be designed that way with a different colour scheme and design requirements that takes this into consideration. Doing an overall alpha blend is pretty heavy handed and disregards the intention of the designer. Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
