Re: [Bf-committers] Blender roadmap article on code blog
On Thu, 27 Jun 2013 12:33 Campbell Barton ideasma...@gmail.com wrote On Thu, Jun 27, 2013 at 10:58 AM, Jed jedfreche...@gmail.com wrote: I agree about the existing Python code being hard to read. Am happy to take criticism for python code, but curious which parts you found problematic to follow. One particularly crufty bit I was looking at recently is the Smart UV Project module (http://preview.tinyurl.com/ldujq8r). None of the functions have doc strings, large portions of the code are commented out and presumably obsolete, unusual naming conventions, etc. The Lightmap UV unwrapping module is much better but also doesn't have any doc strings. I've tried to include examples in the text editors templates to help give users some samples of working scripts, is there some area you think should be added to here that would help? The examples are very helpful, however most of the time my questions are more Why than How and inevitably about some corner case that isn't quite covered by one of the cookbook recipes. I don't know that this is necessarily a documentation issue as much as I simply haven't committed enough time to fully understanding how Blender's internals work. This certainly goes to David's point about the difficulty of diving in for casual users, unfortunately I don't know how to bypass the learning curve. Fortunately, the last time I spent much time on scripting Blender was ~3 months ago and I remember thinking at the time that the more conceptual API documentation had improved since the last time I looked at it. I had a quick look over google's standards and while we don't follow all, a lot of them are aligned with pep8 (and common sense), if you think there are some we could benefit from, I'd be interested to know which ones specifically. I like that Google's standard is explicit about how to document things like function arguments and return values, whereas PEP 257 doesn't really give any guidance other than do it. Numpy's docstring style guide is also quite good about this. I might quibble with some of Google's choices but the main things I like about it for my own projects are that: it is in one place, is pretty comprehensive, I can point someone else to it and expect a reasonable result, and I didn't have to write it. I know Blender has a style guide for C code and it would probably be good to have one for Python, even if it is just a paragraph saying Follow PEP 8 257. Integrating ipython is fairly straightforward I suspect a lot of users would greatly appreciate IPython's improved object introspection and user friendliness. Cheers, -- Jed Frechette ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] UV packing and island margins
I'm hoping someone can explain the logic behind how UV island margins are handled in Blender. As far as I can tell there are 3 locations where island margins can be set to affect UV packing: Pack Islands, Smart UV Project, and Lightmap Pack. All three of these handle the user entered margin value differently. I'm still working my way through the code to understand exactly how it works but Pack Islands seems to use a different margin for each island based on the diagonal of the island's bounding box, the user entered margin, and a fudge factor. The final gutter between islands also depends on the size of the surrounding islands as they all have their own unique margins as well. Smart UV Project has its own implementation of a similar scheme, however, in its implementations all margins end up scaled relative to the size of the largest UV island. In contrast, Lightmap Pack interprets the user entered margin value as a fixed percentage of the UV area dimensions. The first two approaches seem extremely counter intuitive. I don't particularly care how big my island margins are relative to the size of the islands but I do care how big they are relative to the texture space. In that regard, Lightmap seems like it is doing the right thing. If I'm planning to use a 2K texture map and know I want a 16 pixel margin I would like to be able to enter 16/2048 as the margin and know that is what I'll get. You can almost do this with Lightmap Pack, although you have to enter 1600/2048 because the input margin is divided by 100. I'm not sure if this is bug, most other parts of Blenders UI seem to consider values in the range 0-1 as representing the range 0-100%, not 0-1% like Lightmap does. One simple change that would start to unify this area would be replacing Smart UV Project's packing code with a call to Pack Islands, I have a patch that already does this. One downside to this change is that although Smart UV's current packing is very inefficient in terms of texture space it is much faster than Pack Islands, something like a factor of 10 in a few quick tests I ran. In practice I'm not sure if this is really an issue. I usually end up running Smart UV Project, then running Pack Islands, then running Pack Islands again because the default margin is not what I wanted; so getting a more efficient pack directly out of Smart UV would speed things up. After that changes to Pack Islands could be looked at. I'm certainly not an expert on these matters so hopefully someone who is can correct me if I've made any mistakes or bad assumptions. Given that none of this behavior is really documented it seems like it would be helpful to make it more consistent and predictable. Best, -- Jed Frechette ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Minimal Blender specs - 5 year old systems OS
FWIW, I see 3D content creation as a fundamentally high-end endeavor. Being able to start learning Blender on low-end systems is great. However, I want Blender to be taken seriously as a professional tool, not just something you play with until you are able to afford real hardware and software. If development is being held back by attempting to support old hardware and OS versions and no one is willing to step up and support those bits then their use should be depreciated.I would much rather see the limited developer hours available put towards moving Blender forward rather than attempting to maintain compatibility with an ever increasing list of legacy hardware and OS versions. -- Jed Frechette ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
