Re: [Bf-committers] Blender roadmap article on code blog
On Monday, 1 July 2013 at 20:21, David Jeske wrote: On Sat, Jun 29, 2013 at 7:41 AM, Ton Roosendaal t...@blender.org (mailto:t...@blender.org) wrote: 1) Include opt-in usage and automatic crash reporting in *every* blender build, and a web dashboard to live usage/crash stats to devs and the community. I always wondered what other projects/companies do with such reports. Is there a public example where I can see the handling of such report logging, with evidence for how this is being used well, the benefits? Or is it just for statistics? Billrey's blender blog recently posted a link to this old but excellent talk on Firefox UI design, from 2011. At 38 minutes, it talks about their Usage Statistics Heat Map, and how they used it to streamline the option locations when redesigning menus. http://www.youtube.com/watch?v=hMDBwa4huUY#at=302 The whole talk is really worth watching.. it's both an interesting visualization of some common UI design principles, and Firefox's approach to enabling open-source innovation by establishing clear design-rules to empower and enable more freedom within those design rules. There are a few other examples that I know of. Firstly, there are some good papers from Autodesk Research that talk in detail about how they use data from their Customer Involvement Program (read: usage data collection) to prototype and verify new features. A recent work is Patina [1], where they use heatmaps, like in the Firefox talk by Faaborg. However, they present these heatmaps to the user so that the user becomes aware of the features that other people (from the same community) use. This allows them to discover features of complex software. Another example is CommunityCommands [2] in which a user is profiled through their command usage and by means of a collaborative filtering technique new commands are recommended to the user, based on the type of usage. Chronicle [3] is worth mentioning as well, because it uses this type of data to allow the user to query and retrieve information from the design process of a document. Then there's work by Terry [4] who instrumented The Gimp to collect usage data with an open source ethos. The analysis of it isn't fully explored though. There's a good overview of how to employ usage data in usability studies by Hilbert and Redmiles [5]. Although the paper is from quite a while ago it introduces many aspects one has to think about when doing this kind of usability work. Another good example is from Heer and others [6] where they describe how they used usage data to understand user behaviour and manage to turn this into concrete improvements of their visualisation software. Microsoft also collects usage data [7], but I haven't found (also haven't looked too hard) many details. I personally think there is a lot of value in remotely collected usage data for a) users, as can be seen from the Autodesk research, and b) developers, as can be seen from [7]. Apologies for the barrage of references. Cheers, Vincent [1] http://autodeskresearch.com/publications/patina [2] http://autodeskresearch.com/publications/communitycommands [3] http://autodeskresearch.com/publications/chronicle [4] Terry, M., Kay, M., Van Vugt, B., Slack, B., and Park, T. Ingimp: introducing instrumentation to an end-user open source application. [5] Hilbert, D.M. and Redmiles, D.F. Extracting usability information from user interface events. ACM Computing Surveys (CSUR) 32, 4 (2000), 384–421. [6] Heer, J., Mackinlay, J., Stolte, C., and Agrawala, M. Graphical Histories for Visualization: Supporting Analysis, Communication, and Evaluation. Visualization and Computer Graphics, IEEE Transactions on 14, 6 (2008), 1189–1196. [7] https://www.microsoft.com/products/ceip/EN-US/default.mspx ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Best place to start a discussion on the direction of Blender?
On Tue, Jul 2, 2013 at 6:10 PM, Gene Crucean emailgeneonthel...@gmail.com wrote: Hey guys, Sorry for the possible noise first of all. I'm curious, where is the best place to start a conversation with the dev's about features and even Blenders overall direction? I don't want to just submit a feature request and have it float around in the ether for a decade Autodesk style. I want to help and I think I might have some valuable insight. Cheers -- -Gene bf-funboard is the place to go. -- Douglas E Knapp Creative Commons Film Group, Helping people make open source movies with open source software! http://douglas.bespin.org/CommonsFilmGroup/phpBB3/index.php Massage in Gelsenkirchen-Buer: http://douglas.bespin.org/tcm/ztab1.htm Please link to me and trade links with me! Open Source Sci-Fi mmoRPG Game project. http://sf-journey-creations.wikispot.org/Front_Page http://code.google.com/p/perspectiveproject/ ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Best place to start a discussion on the direction of Blender?
Perfect. Thanks Douglas. On Tue, Jul 2, 2013 at 9:28 AM, Knapp magick.c...@gmail.com wrote: On Tue, Jul 2, 2013 at 6:10 PM, Gene Crucean emailgeneonthel...@gmail.com wrote: Hey guys, Sorry for the possible noise first of all. I'm curious, where is the best place to start a conversation with the dev's about features and even Blenders overall direction? I don't want to just submit a feature request and have it float around in the ether for a decade Autodesk style. I want to help and I think I might have some valuable insight. Cheers -- -Gene bf-funboard is the place to go. -- Douglas E Knapp Creative Commons Film Group, Helping people make open source movies with open source software! http://douglas.bespin.org/CommonsFilmGroup/phpBB3/index.php Massage in Gelsenkirchen-Buer: http://douglas.bespin.org/tcm/ztab1.htm Please link to me and trade links with me! Open Source Sci-Fi mmoRPG Game project. http://sf-journey-creations.wikispot.org/Front_Page http://code.google.com/p/perspectiveproject/ ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- -Gene www.genecrucean.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Best place to start a discussion on the direction of Blender?
On Tue, Jul 2, 2013 at 7:07 PM, Gene Crucean emailgeneonthel...@gmail.com wrote: Perfect. Thanks Douglas. On Tue, Jul 2, 2013 at 9:28 AM, Knapp magick.c...@gmail.com wrote: On Tue, Jul 2, 2013 at 6:10 PM, Gene Crucean emailgeneonthel...@gmail.com wrote: Hey guys, Sorry for the possible noise first of all. I'm curious, where is the best place to start a conversation with the dev's about features and even Blenders overall direction? I don't want to just submit a feature request and have it float around in the ether for a decade Autodesk style. I want to help and I think I might have some valuable insight. Cheers -- -Gene bf-funboard is the place to go. -- Douglas E Knapp Creative Commons Film Group, Helping people make open source movies with open source software! http://douglas.bespin.org/CommonsFilmGroup/phpBB3/index.php Massage in Gelsenkirchen-Buer: http://douglas.bespin.org/tcm/ztab1.htm Please link to me and trade links with me! Open Source Sci-Fi mmoRPG Game project. http://sf-journey-creations.wikispot.org/Front_Page http://code.google.com/p/perspectiveproject/ ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- -Gene Don't overlook IRC! -- Douglas E Knapp Creative Commons Film Group, Helping people make open source movies with open source software! http://douglas.bespin.org/CommonsFilmGroup/phpBB3/index.php Massage in Gelsenkirchen-Buer: http://douglas.bespin.org/tcm/ztab1.htm Please link to me and trade links with me! Open Source Sci-Fi mmoRPG Game project. http://sf-journey-creations.wikispot.org/Front_Page http://code.google.com/p/perspectiveproject/ ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender roadmap article on code blog
Am 29.06.2013 16:41, schrieb Ton Roosendaal: - Where Python is too slow (I/O), we can also improve the api a lot still. For our UI now it's more than fast enough. There are two areas where it's notably slow: user preferences input and addon UI - due to the high number of layout elements I guess. However, it's acceptable in this area. Where python performance really bugs me is I/O. Due to GIL, python can't make use of multi-core systems (runs with max. 25% of an i5 with two real cores / four virtual cores). And multiprocessing isn't really applicable, since blender doesn't allow multiple threads accessing the RNA system without crashes. Looking at the OBJ importer, the real bottleneck is the mesh splitting code. It takes a serious amount of time for gigabyte-sized OBJs, and a huge amount of memory (like 500 MB OBJ, 6 GB mem). Not sure if one could optimize the python code, but a C/C++ importer would always be superior (see Meshlab speed!). Any plans on merging assimp support from Bratwurst into trunk? ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender roadmap article on code blog
Hi, Wouldn't it be possible to implement a c/c++ importer and expose it to the python api in a compatible way? The obj file structure is quite straightforward and should be easy to implement. But I have no experience with blenders python interface. /Jürgen Am 02.07.2013 um 19:45 schrieb CoDEmanX codem...@gmx.de: Am 29.06.2013 16:41, schrieb Ton Roosendaal: - Where Python is too slow (I/O), we can also improve the api a lot still. For our UI now it's more than fast enough. There are two areas where it's notably slow: user preferences input and addon UI - due to the high number of layout elements I guess. However, it's acceptable in this area. Where python performance really bugs me is I/O. Due to GIL, python can't make use of multi-core systems (runs with max. 25% of an i5 with two real cores / four virtual cores). And multiprocessing isn't really applicable, since blender doesn't allow multiple threads accessing the RNA system without crashes. Looking at the OBJ importer, the real bottleneck is the mesh splitting code. It takes a serious amount of time for gigabyte-sized OBJs, and a huge amount of memory (like 500 MB OBJ, 6 GB mem). Not sure if one could optimize the python code, but a C/C++ importer would always be superior (see Meshlab speed!). Any plans on merging assimp support from Bratwurst into trunk? ___ 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] expectations about spline-handle type-toggle behavior...
I'm making a patch to adjust (fix!) some odd behavior related to spine-handle toggling, which I filed in this bug.. http://projects.blender.org/tracker/?func=detailaid=35952group_id=9atid=498 The main bug I filed is that the docs (and user expectation), say that toggling a handle to free should cause the two handles to become disconnected from each other. However, the current code doesn't do this when only one of the spline handles is selected, because it sets that handle to free but leaves the other one aligned to the free one.. effectively making the spline feel like an aligned spline where one of the handles works and the other is locked (i.e. broken). I have a patch which fixes the above problem, and makes spline-handle type-toggling work much more predictably from my perspective. Can anyone tell me how the IPO_AUTO_HORIZ / HD_AUTO_ANIM spline-handle mode is used? Also, if anyone is a spline expert and cares about this, read the bug as I have a bunch of other questions. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] HiDPI notes for other OS'es
On Sun, Jun 30, 2013 at 4:14 AM, Ton Roosendaal t...@blender.org wrote: The node editor has been badly patched indeed, which is solvable, but not so easy. I postponed it to wait for decisions or designs how we want the node editor to evolve. I think I now understand what you meant about combining 2d and the widgets in the node editor being a challenge for the current coordinate model. You mean because the nodes themselves have widgets drawn into their faces right? The bug you mention (for adding nodes) is just a python scripting issue - it tries to do DPI magic there, which it shouldn't. As far as I can see, the retina node-placement bug is not caused by Campbell's recent patch that added those DPI calculations. It existed before he added that, and is unaffected by it. If you take out those calculations the bug is still present and exactly the same. The bug exists because there is a pixelsize (not DPI) compensation issue -- this is why it happens only on retina. If I understand what's going on the node-editor 2d camera zoom and origin are not being scaled for pixelsize, which means mouse events must be scaled for pixelsize before being used as coordinates to places new nodes. I think this could be fixed in v2d.region_to_view, as you mentioned in your other email. I've moved onto some other stuff, but if this doesn't get fixed in a while I'll turn back to it. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] expectations about spline-handle type-toggle behavior...
Personally I like this mode, but I could live without it I guess - for me it isn't a bug, I often combine vector/aligned or free/aligned. the former is more obviously useful, the second only marginally so ( you get one handle that keeps the tangent, and only slides in line, and the other handle is free to go (it's almost like one is parented to the other) the point I'm making, is that it doesn't feel like a bug to everybody. I don't feel strongly about it, but if it gets in my way I'll just file a bug in the future ;) On Tue, 2013-07-02 at 14:32 -0700, David Jeske wrote: I'm making a patch to adjust (fix!) some odd behavior related to spine-handle toggling, which I filed in this bug.. http://projects.blender.org/tracker/?func=detailaid=35952group_id=9atid=498 The main bug I filed is that the docs (and user expectation), say that toggling a handle to free should cause the two handles to become disconnected from each other. However, the current code doesn't do this when only one of the spline handles is selected, because it sets that handle to free but leaves the other one aligned to the free one.. effectively making the spline feel like an aligned spline where one of the handles works and the other is locked (i.e. broken). I have a patch which fixes the above problem, and makes spline-handle type-toggling work much more predictably from my perspective. Can anyone tell me how the IPO_AUTO_HORIZ / HD_AUTO_ANIM spline-handle mode is used? Also, if anyone is a spline expert and cares about this, read the bug as I have a bunch of other questions. ___ 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] expectations about spline-handle type-toggle behavior...
...and one more quick question... Do spline users miss the inability to do a standard mirrored spline, where both sides of the spline keep the same length? I don't see a way to get this behavior out of Blender's spline handles (though I could just be missing something). ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
