Re: [Bf-committers] Booleans: Carve solver has been removed
Hi, sergey@gmail.com (2018-02-08 at 1546.40 +0100): > It is just more efficient to stick to a single solver, which is fully > controlled by us, and much better maintained (last commit to Carve upstream > was done years ago). Less than a year https://github.com/folded/carve/commits/master . But the other points are probably more important. GSR ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Option to Pin an Object's Tools Panel
Hi, mafteiuscaiv...@gmail.com (2014-11-05 at 2234.28 +0100): > 2014-11-05 19:25 GMT+01:00 Nkansah Rexford : > > When an object is added, it comes with its related options for tweaking as > > seen in the Tools panel. Upon doing anything else to the object, like > > scaling or rotating, those options vanish. > > > > Is there a way to bring that particular options back? For instance, if I > > set the Rings on the UV Sphere to be 10, but I later want it to be 20, can > > I bring back that panel again without having to create a new Sphere again > > to access those settings? > > The way some other 3D apps solve this is by making the object parametric so > you can change settings at any point for it. However if you want any edits > done to it(like in edit mode) you lose those options. Blender only has this > state I guess the first time you add the item. The other way around, those apps are parametric from the ground up and so they give you the controls all the time. Blender just puts the creation settings as those do, but is just a cosmetic detail (before it was popup, now it is mouse travel) because it was not and so far is not parametric. At least the settings could appear again in case of undo/redo, but doesn't seem to be the case with a simple cube, it just shows "Operator". GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Any git suggestion to force the commit date to be correctly ordered when pushing?
Hi, dfeli...@gmail.com (2014-07-11 at 1222.38 -0300): > >From time to time I forget to re-set the time of some individual > commits (git commit --amend --reset-author) and I end up with commits > showing up in the wrong order in bf-cvs list. (most recent example: > 1aabbf8 and 92c8dd1). It tends to happen when I'm working in a branch, > and squash commits. 92c8dd1 has Date: Mon Jul 7 12:30:43 2014 -0300 index 1c3e223..0b80a57 1aabbf8 has Date: Mon Jul 7 12:46:25 2014 -0300 index 0b80a57..a9516e6 Notice 0b80a57 and 12:30 < 12:46. https://developer.blender.org/rB92c8dd16dfa9c1ffe7f4d2912bf1bf78b82c3894 has Committed dfelinto Fri, Jul 11, 4:43 PM https://developer.blender.org/rB1aabbf8476a253b49437691c041bede34d8f4227 has Committed dfelinto Fri, Jul 11, 4:44 PM Now 4:43 < 4:44 (no time zones/offsets... *sigh*). And pages even point 92c8dd1 is the parent of 1aabbf8. All looks correct, doesn't it? Or do you mean it should be "1aabbf8 parent of 92c8dd1"? > If the only issue is the order that bf-cvs uses to show the commits > than it may not be an issue. But I suspect it may lead to > misinformation in the future and could be avoided. The proper way is to use git log or similar tools that look at the repository data. Mail systems don't have to always process the emails in the same order, so they are not trustable sources for this. http://lists.blender.org/pipermail/bf-blender-cvs/2014-July/date.html currently shows 92c8dd1 then 1aabbf8, but could have picked other order if one of the emails was delayed. Your own mail app could be showing them in any order. Mails apps don't have to know about git specifics. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Git issues and workarounds
Hi, sergey@gmail.com (2013-11-27 at 0239.37 +0600): > > "git commit -a" also should be avoided. It may not cause issues of the > > same level than "git commit ." but it will keep on causing the issues > > of a single commit changing unrelated things or even errors. > I never had issues with using -a. And for now doing `git commit -a` COULD > cause issues meanshile `git commit .` DOES give issues on every call from > the working dir root. Was 50fbebe0 done with "git commit -a"? That explains 780459e4. ;) It was just cosmetic, but other errors can be compile breaking (half edited files with true syntax errors, eg), and in any case, using something like git, there is no reason for such noise. There is a need to "change gears" and use the tools with more precision. There are status, diff, log, --amend, "squash"... to check and solve issues before pushing. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Git issues and workarounds
Hi, sergey@gmail.com (2013-11-23 at 0329.22 +0600): > If you're using `git add .` or `git commit .` stop doing this. Two reasons > for this. > > First one is that this will stage changes to submodules and place them into > commit (without notifying you about this is commit comments). > > Second one that AFAIR it'll add all untracked files to your commit. > Including possible backup files, core dumps and so. > > Use `git commit -a` to include changes to all tracked files and take care > of using `git add /path/to/specific/file` if you need to add new files to > the repo. "git commit -a" also should be avoided. It may not cause issues of the same level than "git commit ." but it will keep on causing the issues of a single commit changing unrelated things or even errors. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Commiting someone else patches (Re: [4ea79fc] master: Patch T37363: ...)
Hi, brechtvanlom...@pandora.be (2013-11-19 at 0801.42 +0100): > Please don't it add like this. You can add it add in a section at the > end of the document but you should mention very clearly that it does > not work with our code review tool at the moment, otherwise we are > going to get a lot of confusion. I would love this to work but let's > try to work with what we have. Well, you already changed that, thanks. The text I wrote was placed in a per topic basis (apply, generate, etc), but the lack of support was mentioned a couple of times to remind of current method (git am could be used for final commit once green lighted, for example). > The best way to work is to use arc at the moment. No experience with arc, so I will leave you, or someone else, to write that part of Patches altogether. Or decide how to reorganize Code Review vs Patches pages, they repeat each other in some parts, and the first mentions arc. Talk about confusion, if there are a CR page and another Patches, it seems logic to some degree that CR would to cover the generics and refer to the Patches for the specifics. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Commiting someone else patches (Re: [4ea79fc] master: Patch T37363: ...)
Hi, osp...@studenti.unina.it (2013-11-18 at .33 +0100): > Maybe the documentation can mention "git format-patch" for exporting > patches, and "git am" for importing them, this way the commit message > too will be the same the patch author wrote. Yes, good idea, sadly the Code Review does not support the mailbox style approach. Added to http://wiki.blender.org/index.php/Dev:Doc/Tools/Patches anyway, hoping the support lands soon, as it is a better way to do things with git. > > Already added this info to > > http://wiki.blender.org/index.php/Dev:Doc/Tools/Git . > Also be careful about the rebase operation, it should be safe when > done from from "git pull --rebase" but in general rebasing must not be > done on public branches, only on local development ones, this is often > overlooked by new git users. This is something higher ups should address. Currently the docs suggest making rebase a default setting. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Commiting someone else patches (Re: [4ea79fc] master: Patch T37363: ...)
Hi, nore...@git.blender.org (2013-11-18 at 0307.44 +): > Commit: 4ea79fcdda6523faf875128ef3d6e8a8ecff67c9 > Author: Joshua Leung > Date: Mon Nov 18 16:06:31 2013 +1300 > http://developer.blender.org/rB4ea79fcdda6523faf875128ef3d6e8a8ecff67c9 > > Patch T37363: Highlight bone layers with active bones (as for Object Layers) > > Patch by Jose Molina Garcia (sentinel), with style fixes by myself. One of git features is that it can differentiate commiter from author, so it can go in the proper header instead of hidden in the logs in non standard format. ;] When using submitted patches it should be automatic, but there is always git commit --author "A U Thor " for manual override. Already added this info to http://wiki.blender.org/index.php/Dev:Doc/Tools/Git . GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Guidelines to format commit logs
Hi, brechtvanlom...@pandora.be (2013-11-15 at 2039.00 +0100): > Sending a reminder for after the switch to git, we have guidelines for > how to format your commit logs to keep it all easy to scan quickly, > understand for users and turn into release notes. > > The wiki page with guidelines is here: > http://wiki.blender.org/index.php/Dev:Doc/New_Committer_Info#Commit_Logs Will Blender follow the git standards of first short line summary followed, if needed, by a blank line and extra explanations, and limiting the number of columns in logs? git doesn't complain if you don't, but you don't get nice output either then, it's assumed the logs are git style. Examples of tools that depend in that for better/proper results are git log --pretty=oneline (or short) for the first line having proper meaning on itself, gitweb for the column limits (the blender one is already showing huge side scrolling). There is plenty of talk and examples about this: http://ablogaboutcode.com/2011/03/23/proper-git-commit-messages-and-an-elegant-git-history/ https://wiki.openstack.org/wiki/GitCommitMessages http://gitref.org/basic/#commit https://www.kernel.org/pub/software/scm/git/docs/user-manual.html#creating-good-commit-messages Luckly compared to SVN, this time some checks can be done via hooks, instead of having to pest everyone by email and then getting ignored anyway. Or by using pulls by someone after reviewing, instead of pushing by everyone without control. What is more, now with git there is no excuse for huge commits or commits that mix different things like improvements and fixes, or things from different topics. Changes can be organized logically, in small steps. But people must do that right to begin, or follow the pull approach so master is clean. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] remove face flip tool?
Hi, ideasma...@gmail.com (2012-03-03 at 0018.56 +1100): > As I understand it this tool swaps the direction of the edge between 2 > or more selected triangles. > > Is this tool worth adding back? - Its very similar to edge flip, the > main advantage AFAIK is that in some cases its easier to select a > bunch of triangle pairs - rather then the edge in-between each one. Yes, it's worth adding back, very useful when fixing low poly models so every triangle counts, as quads to triangles gives the wrong split half of the times. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] blender UI state
Hi, kelvinsh...@gmail.com (2012-01-20 at 2005.42 -0500): > Why not simply draw a faint outline around the box and text? So basically it would be a faint button with a box (and check mark) on the left side. And still not everyone will think that zone is clickable, because the box is the one that looks like a button and the line could be a decoration outline. :] GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] blender UI state
[Offlist] Hi, trumanblend...@gmail.com (2012-01-21 at 1116.01 +1100): > Hi All, > > Slight improvement on the image Campbell posted: > http://www.pasteall.org/pic/show.php?id=24767 > > IMO check boxes can cause extra clutter if not used judiciously, using > toggle buttons instead means that the area used to indicate True/False > coincides with the label and is more space efficient. Also, using toggle Also gives a way better hint of what zone can be clicked. It becomes obvious that the zone is big, even before you pick the mouse. So easier to hit and thus faster interaction with the program. Some toolkits accept clicking the label, others only the small square. The box-only mode is slowest while the box-and-label mode is as fast as the full-button case... if you ever learn you can do that. Too many people will never ever try clicking the label, and will always aim at the tiny square. Good job. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] SVN error in particle merger sept 2011...
Grrr... > For first appearence of nodes, see r6527. ^composite. And while at it, nodes in general appear in r6157. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] SVN error in particle merger sept 2011...
Hi, dfeli...@gmail.com (2011-12-24 at 1721.01 -0800): > Not a big deal. But the real deal break for is that I can't get any info > before revision 10342. Most of the nodes were added back then, but the > commit log is simply: > > "Initial commit. Not in build system so shouldn't interfere with anything > at this point. Will commit modified versions of existing files once build > system is tested." > (so no real info on the nodes themselves and their whereabouts) That is the commit that splitted nodes into many files. See http://lists.blender.org/pipermail/bf-committers/2007-March/017838.html > I couldn't find anything in orange branch either. So, does any one know > where did the node work start? Specifically the UVMapNode. Before, all nodes were in a small set of files, like: source/blender/blenkernel/BKE_node.h source/blender/blenkernel/intern/node.c source/blender/blenkernel/intern/node_composite.c source/blender/blenkernel/intern/node_shaders.c source/blender/include/BSE_node.h source/blender/makesdna/DNA_node_types.h source/blender/src/drawnode.c source/blender/src/editnode.c source/blender/src/header_node.c For first appearence of nodes, see r6527. UV Map node was added in r9270, to node_composite.c. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] I don't have time to fix it right now
Hi, m...@cs.umn.edu (2011-10-27 at 1101.41 -0500): > I don't have time to fix it right now but it looks like someone > committed a nested addons inside of the addons repository. Done. People should be able to remove release/scripts/addons/addons/ (only the last subdir, keep release/scripts/addons/ and everything else at that level) to clean up the local repos. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] redo operator with last used settings (patch)
Hi, magick.c...@gmail.com (2011-10-18 at 1820.57 +0200): > > Tick this box :) > > > > File -> User Preferences -> Editing -> New Objects -> Enter Edit Mode > That is cool and does do the trick. So how long has that been there? I > am embarrassed to ask. :-) A lot... because since Blender start, that was the only way. The setting was added in last years, and now defaults to the inverse of the old way. GSR ___ 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 [40903] trunk/blender/source/blender/ blenkernel: header cleanup (no functional changes)
Hi, ideasma...@gmail.com (2011-10-10 at 2255.34 +1100): > Good points, lets review after 2.60 release. > http://thedepression.org.au/wp-content/uploads/2010/04/Leunig-1024x604.jpg The tags are there for access by other means than the code repository, like source tarballs. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposal: Object creation
Hi, martin.buerb...@gmx.at (2011-10-04 at 1113.02 +0200): > Follow up of the "redo operator with last used settings (patch)" thread > http://lists.blender.org/pipermail/bf-committers/2011-September/033725.html > > I propose a new way of handling newly created objects in Blender. > I'm sure this may not have a high priority right now, but discussion and > planning is never a bad thing IMHO. > I'll not go into detail how this should be implemented since Blenders > internal architecture is still new to me. I'll add my basic ideas though. > > C&C welcome (especially from the coding and framework perspective). > > -- > OBJECT CREATION > > Everything created with an "Add" operator is initially locked from editing > and can only be changed by tweaking its parameters (see below of editing). > > My basic idea would be to store a unique identifier (operator name?) and the > defining parameters (operator parameters?) in that object somehow. > Maybe making this its own object type (e.g. "Generated") would work? > > > PARAMETER EDITING > > The parameters of the object can then be tweaked (in object or edit-mode, see > below) to ones linking. > > I imagine this would be done by taking the the operator and parameters and > "redo" them. > > > CONTENT EDITING > > After creation you can enter edit mode, but you will not be able to change > anything except the parameters. > When one wants to edit the data of the object directly (mesh/curve/etc.) it > will be converted to an "editable" object. > That means that after that the object behaves no different than it does right > now in Blender. > > This can be done automatically (with a small prompt to the user) or > explicitly by "unlocking" (i.e. converting) the object. > I'm not sure if dropping the operator & parameters it was created with is > good or bad at this point. This reminds a lot of what happens with NURBS, Meta or Text objects. So one Blenderish approach would be to add a new object type that has high level controls and can be converted into meshes when needed. It would fit the user workflow 100% and you have other code examples to follow. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [40184] branches/hive/release/scripts: added the hive system Python libraries
Hi, sjdv1...@gmail.com (2011-09-13 at 1255.22 +): > Revision: 40184 > > http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=40184 > Author: sjoerddevries > Date: 2011-09-13 12:55:21 + (Tue, 13 Sep 2011) > Log Message: > --- > added the hive system Python libraries > > Added Paths: > --- [...] > branches/hive/release/scripts/modules/spyder/modules/atom/.bzr/ > branches/hive/release/scripts/modules/spyder/modules/atom/.bzr/README > branches/hive/release/scripts/modules/spyder/modules/atom/.bzr/branch/ > > branches/hive/release/scripts/modules/spyder/modules/atom/.bzr/branch/branch.conf > > branches/hive/release/scripts/modules/spyder/modules/atom/.bzr/branch/format > > branches/hive/release/scripts/modules/spyder/modules/atom/.bzr/branch/last-revision > > branches/hive/release/scripts/modules/spyder/modules/atom/.bzr/branch/lock/ > branches/hive/release/scripts/modules/spyder/modules/atom/.bzr/branch/tags > > branches/hive/release/scripts/modules/spyder/modules/atom/.bzr/branch-format > > branches/hive/release/scripts/modules/spyder/modules/atom/.bzr/branch-lock/ > branches/hive/release/scripts/modules/spyder/modules/atom/.bzr/checkout/ > > branches/hive/release/scripts/modules/spyder/modules/atom/.bzr/checkout/conflicts > > branches/hive/release/scripts/modules/spyder/modules/atom/.bzr/checkout/dirstate > > branches/hive/release/scripts/modules/spyder/modules/atom/.bzr/checkout/format > > branches/hive/release/scripts/modules/spyder/modules/atom/.bzr/checkout/lock/ > branches/hive/release/scripts/modules/spyder/modules/atom/.bzr/repository/ > > branches/hive/release/scripts/modules/spyder/modules/atom/.bzr/repository/format > > branches/hive/release/scripts/modules/spyder/modules/atom/.bzr/repository/indices/ > > branches/hive/release/scripts/modules/spyder/modules/atom/.bzr/repository/indices/187d3a45d072a9d1334c4b400801e32b.iix > > branches/hive/release/scripts/modules/spyder/modules/atom/.bzr/repository/indices/187d3a45d072a9d1334c4b400801e32b.rix > > branches/hive/release/scripts/modules/spyder/modules/atom/.bzr/repository/indices/187d3a45d072a9d1334c4b400801e32b.six > > branches/hive/release/scripts/modules/spyder/modules/atom/.bzr/repository/indices/187d3a45d072a9d1334c4b400801e32b.tix [...] What is the reason to store lots of BZR internal files into Blender SVN? GSR ___ 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 [39991] trunk/blender: Merging r39693 through r39989 from vgroup_modifiers branch into trunk.
Hi, ideasma...@gmail.com (2011-09-08 at 1523.35 +1000): > How do you ignore it? > > I only see these options-- > > /dsk/data/src/blender/bmesh> svn merge -r39990:39991 > https://svn.blender.org/svnroot/bf-blender/trunk/blender > Conflict for property 'svn:mergeinfo' discovered on > 'release/scripts/startup/bl_ui/properties_data_bone.py'. > They want to delete the property, you want to change the value to > '/trunk/blender/release/scripts/startup/bl_ui/properties_data_bone.py:36154-39990'. > Select: (p) postpone, > (mf) mine-full, (tf) theirs-full, > (s) show all options: s > > (e) edit - change merged file in an editor > (df) diff-full- show all changes made to merged file > (r) resolved - accept merged version of file > > (dc) display-conflict - show all conflicts (ignoring merged version) > (mc) mine-conflict- accept my version for all conflicts (same) > (tc) theirs-conflict - accept their version for all conflicts (same) > > (mf) mine-full- accept my version of entire file (even > non-conflicts) > (tf) theirs-full - accept their version of entire file (same) > > (p) postpone - mark the conflict to be resolved later > (l) launch - launch external tool to resolve conflict > (s) show all - show this list > > Select: (p) postpone, > (mf) mine-full, (tf) theirs-full, > (s) show all options: Have you tried "tf"? Or postpone, svn propdel and svn resolved. You could even test the merge with --dry-run and manually change things you want to discard before really doing the real one. GSR ___ 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 [39991] trunk/blender: Merging r39693 through r39989 from vgroup_modifiers branch into trunk.
Hi, ideasma...@gmail.com (2011-09-08 at 1452.55 +1000): > Thanks for this but I'm still in the dark as to how to correct the problem. Not a "problem" as the thread says, consolidation of mergeinfo is normal, and removes props from subpaths. > This will be a problem for everyone trying to merge from trunk into > their own branch (unless theres same way to ignore this conflict I > don't know about). For now, ignore it, manual editing of that prop is not recommended. In case something bad happens, probably the culprit is something else, like forgetting to svn update before trying to do something (merges, commits, etc). Operating as much as possible from the root of the branch is also a good way to avoid problems. GSR ___ 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 [39991] trunk/blender: Merging r39693 through r39989 from vgroup_modifiers branch into trunk.
Hi, ideasma...@gmail.com (2011-09-08 at 1327.44 +1000): > This commit deletes mergeinfo on many files where no changes are actually > made, > eg: > > Property changes on: > trunk/blender/release/scripts/startup/bl_ui/properties_texture.py > ___ > Deleted: svn:mergeinfo > > > Anyone know how to avoid this? - also how should we go about adding it back? The svn:mergeinfo prop was added to a higher level in the same commit. It sounds like http://svn.haxx.se/users/archive-2010-03/0571.shtml and then ignorable. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposal: Split up Outliner code
Hi, aligor...@gmail.com (2011-07-11 at 1355.57 +1200): > Hi, > > Ok, that looks similar to an alternative version I had in mind earlier. > > I'll be starting work on this this afternoon. Hopefully we don't have > any other commits in outliner.c in the meantime, otherwise merges are > going to be a pain. Lock the file in svn to reduce the possibility of that. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Let us switch to git, pretty please
Hi, nat...@letworyinteractive.com (2011-05-27 at 1008.18 +0300): > > Another thing thats been discussed is having an SVN hook in our > > existing repo which keeps a GIT repo in sync. Currently the available > > GIT repos have some lag from trunk, With git matching trunk it would > > help us evaluate GIT without having to switch completely (interested > > in Nathan's opinion on this), it comes up from time to time as > > something we should do. > > Running from my machine or directly with hook, whenever a new branch is > created syncing fullblender takes a day or two. Having this hosted on a > different machine than mine at home is always a good thing to look into. > The barebone repo is 1.83GB right now. 1 day to push the git result or to import the branch op into git? The later here takes more or less the same than a (huge) commit, so it sounds suspicious (and git network ops are also rather efficient, so the first is also weird to hear...). GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Let us switch to git, pretty please
Hi, g.ula...@gmail.com (2011-05-27 at 0929.04 +0600): > I'm not sure switching the whole repo to git is a nice idea. Last time > i've checked this it was very painful to work with libs/ repo cloned > with git -- simple `git status` used to work ages. Maybe this is because > of plenty of binary files, not sure. And size of that local cloned repo > was also incredible big -- several gigabutes, iirc. Yep, total is >3.5GB: .git/ ~1.5GB, blender/ <80MB, lib/ ~2GB. In some OSes, only blender/ and lib/tests/ are useful (<120MB, plus whatever .git would be). Anyway, git status is fast here... could it be one of those cases that depends in the OS or filesystem? > Git for codebase works really nice when you've got plenty of branches -- > no pain with all this re-branching and so. Simple `git rebase` and here > we go. There's also advantage for releases -- tagging happens much nicer > with git. Speaking of different habits or workflow, some of the git tools work better when using "git style". Take for example commit messages, first line is vital for some tools as it is used as summary in many places. Even commiting multiple topics as a single thing is disencouraged, and commiting to a tag is just impossible (in svn it works just because it is a branch, BTW). If you take other style, things work (or not), but you are going to expend too much time "fixing" the differences, and DVCS, everyone has to be own admin, so to speak. So the questions is if changing the software is worth if the methods stay the same. [...] > P.S. as one more disadvantage, we'll be unable to have that r in > splash screen. It could be short commit SHA, but not sure it'll be useful. As useful as the svn rev number, show what was used to create the binary. It can make older-newer checks impossible if no access to the repo, but otherwise a minor problem. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [36564] trunk/blender: set svn end of lines to native
Hi, ideasma...@gmail.com (2011-05-09 at 0815.38 +): > Revision: 36564 > > http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=36564 > Author: campbellbarton > Date: 2011-05-09 08:15:38 + (Mon, 09 May 2011) > Log Message: > --- > set svn end of lines to native > > Modified Paths: > -- > trunk/blender/intern/bsp/test/BSP_GhostTest/BSP_GhostTest.dsp > trunk/blender/intern/bsp/test/BSP_GhostTest/BSP_GhostTest.dsw dsp and dsw files are CRLF. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] .blend magic number & MIME type
Hi, jhar...@colorhythm.com (2011-03-17 at 0211.27 -0800): > can anyone provide a magic number for .blend files? file cmd database has it (I wrote it long ago and updated it as needed), lastest version is: #-- # $File: blender,v 1.5 2009/09/19 16:28:08 christos Exp $ # blender: file(1) magic for Blender 3D related files # # Native format rule v1.2. For questions use the developers list # http://lists.blender.org/mailman/listinfo/bf-committers # GLOB chunk was moved near start and provides subversion info since 2.42 0 string =BLENDERBlender3D, >7 string =_ saved as 32-bits >>8 string =v little endian >>>9bytex with version %c. >>>10 bytex \b%c >>>11 bytex \b%c >>>0x40 string =GLOB \b. >>>>0x58leshort x \b%.4d >>8 string =V big endian >>>9bytex with version %c. >>>10 bytex \b%c >>>11 bytex \b%c >>>0x40 string =GLOB \b. >>>>0x58beshort x \b%.4d >7 string =- saved as 64-bits >>8 string =v little endian >>9 bytex with version %c. >>10bytex \b%c >>11bytex \b%c >>0x44 string =GLOB \b. >>>0x60 leshort x \b%.4d >>8 string =V big endian >>>9bytex with version %c. >>>10 bytex \b%c >>>11 bytex \b%c >>>0x44 string =GLOB \b. >>>>0x60beshort x \b%.4d In some (many now, as it saves space) cases, the file can appear with gzip magic, but still plain .blend extension (IOW, contrary to GIMP style, where the user directly knows about compresion as extension becomes .xcf.gz or .xcfgz). Just gunzip the blend and examine the output (or in file case, file -z). > also, did anyone end up registering the MIME type > "application/x-blender" with the IANA? even if not, is that the one we > should use? Not registered with IANA, there were some tries to document all and follow the required submission steps. Currently on hold. http://wiki.blender.org/index.php/Dev:Source/Development/Projects/Blender_File_Format/MIME_Type GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender Startup Time
Hi, the...@yahoo.com (2011-02-26 at 1956.16 -0800): > It's slightly different then a normal splash screen though. It only > shows up when opening the default file only (so not when loading an > existing file on startup) and it links to recent files, so it's > arguable that it probably speeds up the workflow in common cases. Yeah, I know, you could call it "in app splash" as it is included in the window after the main one appear, not a separate one before. The point about duplication still holds, but I guess people just get used to many things when pushed into them (it would be nice to know how many launch Help/Splash to get recent files). I always launch with a file or the config file (all files are loaded but last one stays so alias blender="blender ~/.blender/startup.blend" does the magic). I find this workflow faster and a lot more integrated as a whole with all apps launched from common "file manager", as shell is normally at root of a project, saves me nagivating in different apps because they lack "recent files" or they have it but does not know about a given file. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender Startup Time
Hi, j.jay...@gmail.com (2011-02-27 at 0740.30 +0900): > I think It's important to note that we do have a splash screen, and it will > take a certain amount of time to click through that. So we can just change > the load order (Since the overall load time is not that significant), making > Blender itself load as fast as possible, and everything else that is not as > critical can load immediately after. This will give the impression of > loading faster. Unless that is what you mean by 'lazy loading'. Splash screens make things feel slow, per se. ;] And give two different GUIs for the same tasks (open recent at start vs open recent once working, eg). Some call it bad gui and thus some apps are getting rid of them to simplify and get directly into work with unified GUI, Blender went the reverse path (before it was just a reminder of "new version, saving user config recommended"). But yeah, as there is a splash (unless hacked out), it could load things there while it waits the user to pick something or dismiss it. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender Startup Time
Hi, ideasma...@gmail.com (2011-02-25 at 1300.36 +): > One thing I found was disk speed on a 'cold start' to be the major bottleneck, > Does anyone know some way we could asynchronously cache certain files > on load so when they are needed it wont lag so much? When it says "function body removed", does that mean all in a single file but no real useful code? Or in other words, reading less files cuts time to 36-44% and reading same number of files, but smaller in size, to 25-31%. Also reading zip of normal files is just a bit slower than reading the combined version. Do you see a trend? It is not exactly disk speed, more like disk seeks, which is basically the issue all modern software is hitting as nobody realizes CPUs have gone a lot faster, RAM a bit faster, but disks are more or less stuck where they were years ago (8ms seeks, ~100 or less disk ops per second), specially if reading non contiguous sectors (ignore SSD for now). Add more files in the form of config, icons, thumbnails, etc and the performance sucks. I remember someone saying that disk access is like tape access was, rewind kills you. GSR ___ 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 [35131] trunk/blender: fix for cmake not having the correct svn revision in buildinfo, now generate a header every build with the
Hi, irieshins...@yahoo.co.jp (2011-02-25 at 1406.42 +0900): > Hi GSR, > > Rev number cannot be detected at all. Please fix it. *sigh* thanks, r35137. GSR ___ 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 [35131] trunk/blender: fix for cmake not having the correct svn revision in buildinfo, now generate a header every build with the
Hi, nicholasbis...@gmail.com (2011-02-24 at 2220.54 -0500): > Googling a bit gave me a partial solution, small patch below. (Checks > for a .svn directory before trying to use the cmake module.) This > fixes the build with git-svn, although it doesn't actually feed it a > correct revision number. Commited, thanks, r35135. I have some ideas about getting a better string, but slightly busy ATM to try them with proper checkout, local changes, etc to see where they break. If needed ASAP and you want to try, basically something along "git svn find-rev HEAD", "git svn info" or peek in .git/ contents. GSR ___ 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 [34535] trunk/blender/source/blender: More logical ordering of Empty draw types.
Hi, zan...@gmail.com (2011-02-01 at 1830.42 -0600): > OK guys, no matter what, blender will not look the same in the future. Why does it have to change? Change for the sake of change sucks (or you are trying to sell something and your only way is "changing the paint"). This new default is less informative than before. Try rotating an empty. Ooops, you do not see what is XYZ anymore, because default manipulator mode does not match. It only works as old empties when it is set to the right mode and the empty is selected. Before it was a quick glaze, now it requires selection and maybe even changing the manipulator mode (and back to what you were using, and select whatever you had before, of course). That does not sound a change for better, but one that makes things slower. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposal: Blender OpenCL compositor
Hi, j.bak...@atmind.nl (2011-01-22 at 0952.44 +0100): > image. The highest/lowest value is calculated once (not parallelized) > the pixel processor is parallelized. Not very good example ;] as this searching problem is near as much parallelizable as the pixel processor would be. Split the work into N workers, every one gets total_pixels/N (or tiles or whatever), looking for the local max and min. Then scan the N maxes to get the final max, and the same with the N mins. Even if you have a system with 1024 "workers", that is only an extra non parallel pass of 1024 checks (assuming you do not parallelize it again, having four workers doing 256 each and finally compare four results, for example). So the questions if you want to process in pixel stacks (what is the final result for X,Y pixel before X+1,Y is known) or buffers (work in one set of tiles and never look at them except if something down the node tree changes). If you want the final full image, you will do the full work in both cases anyway. Exceptions aside, you probably want buffers approach (with tiled internal organization, that is fine), because that way the code cache gets lots and lots of hits, and data one probably too. The other way you are trashing all caches. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Makefile support
Hi, t...@blender.org (2011-01-16 at 1951.57 +0100): > I already gave up on Makefiles for OSX a month ago or so... it was > giving me inpredictable instable builds, and trying to figure out why > I gave up after a day. When new functions are added or old dropped, it does not detect all the dependencies and you have to do a full build, instead of a quicky one. Or so it seems. > It seems to me it's still used by a couple of people here. I'd like to > know if there's - apart from personal taste - there's important > reasons to keep supporting it? The system is close to collapse under > its own weight, seems to me. :) Here it keeps going. I would ask people in Irix or similar, if they really need it or we can move to cmake. It could also mean dropping scons and just get one single build system, finally. > Let me confirm that switching to CMake was painless and quick and it > builds faster than ever. I'm not totally happy with the noisy colorful > prints of cmake, but I'm quite sure that's a matter of time to get > solved too. You can disable colour, even if by just tricking it into a pipe like "| grep --line-buffered ''" or with the right parameter/option. OTOH, if you want to use "| less -R" you lose colours without option to keep them (the -R would show them). Nevermind cmake colours are mostly per line, instead of useful syntax highlighting (important words, not full blocks of the same colour). It even lies and adds useless lines (now that we are talking about its output), saying it has built something when in reality it did not because the targets was up to date. > Obviously; if we remove makefiles from svn, it'll allow "in source" > builds for cmake. cmake documentation recommends against that, some things depend on out of tree builds, maybe Blender does not use them now, but could and then you have to go back to out of source. Better not depend on it. Anyway, commiting the result would not work (full paths are not portable), and out of tree has other adventages, like tools not wasting time with meaningless files or being able to clean "for sure". GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] color wheel upside down
Hi, troy.sobo...@gmail.com (2011-01-17 at 1952.47 -0800): > > Would it be possible to display the color wheels "correctly" ? I actually > > don't know if there is a correct or wrong way, I guess not, but to me it is > > upside down. > > Which one is correct? > > http://www.willrosecrans.com/blog/2010/09/color-wheels/ Look at Blender ones, the red is at the bottom, while all in that page put it at the top or the right side, following typical starts for clocks or angles (resp.). That is what he is pointing, that Blender is yet another style with hard to explain "0 points down". If anybody knows the vital reason to do it, better document it ASAP. And if the video scopes do something else as he pointed, that is really bad, because it is inconsistent with itself and only causes headaches. One of the two will have to change, that has no way to be reasoned. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Decimation / Surface Simplifier...
Hi, sergey.fo...@gmail.com (2011-01-11 at 1031.06 +0300): > If asm is not 'build in' c code or can be modularized into separate files > then maybe http://www.tortall.net/projects/yasm/ can be used - it is > fairly portable across platforms. > > it is still should be decided if asm at all is acceptable, but at > least - this way - it will be one code for all platforms. Define "all platforms". :] PPC is in the way out, but what if ARM catches in general computers? Or what would do Debian anyway? They ship for many plataforms, small or big "market", they do not care. Or what if the ASM is SSEx level? AMD64 means SSE2 but does not guarantee SSE4, and X86 CPU with just SSE1 are still running fine. The sane way is having C generic version and then optional ASM versions that do the same but faster. The reason is two fold, first compatibility fallback, second a good reference to check the results match. If you are lucky the compiler generates a rather good op code stream from the plain C and then you just save time trying to maintain the hand made ASM. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] how update all?
Hi,
ideasma...@gmail.com (2011-01-06 at 0446.58 +):
> Existing files can also botch svn updating (highly annoying for
> automatic updates), or when going back in svn history *.pyc files can
> stop directories getting removed.
>
> On *nix you can ensure a clean checkout with this:
> svn status --no-ignore | grep ^I | awk '{print $2}' | xargs rm -rf
>
> Answer from cdhowie:
> http://stackoverflow.com/questions/4515586/clean-an-svn-checkout-remove-non-svn-files
That command is troublesome when filenames have spaces, and only
deletes actively ignored files anyway (some of which you would like to
keep, like source search caches), but not local modifications or
unversioned files which is part of what was asked for. The best is
probably a combination of svn-clean and svn revert... or just svn
checkout (slow but only way to make sure).
GSR
___
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 [33962] trunk/blender: CMake: use blender_include_dirs("${OPENGL_INCLUDE_DIR}") rather then blender_include_dirs(${OPENGL_INCLUDE_
Hi,
rd6t-k...@asahi-net.or.jp (2011-01-02 at 2100.53 -):
> The build with VS and CMake goes straight now. Thanks for the fix!
> >> blender_include_dirs("${OPENGL_INCLUDE_DIR}")
Out of curiosity about what was causing the problem, could you make it
print the contents of OPENGL_INCLUDE_DIR? Thanks.
GSR
___
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 [33936] trunk/blender/source/blender/ blenkernel/intern: Silencing some compiler warnings (gcc)
Hi, ideasma...@gmail.com (2010-12-31 at 0744.36 +): > What GCC version are you using? > > I dont get any warnings with either of these files: > gcc version 4.5.2 > > warning flags: > -Wunused-value -Wclobbered -Wold-style-declaration -Woverride-init > -Wuninitialized -Winit-self -Wmissing-include-dirs > -Wignored-qualifiers -Woverride-init -Werror -Wall -Wcast-align > -Werror=declaration-after-statement > -Werror=implicit-function-declaration -Werror=return-type > -Werror=strict-prototypes -Wno-char-subscripts -Wno-unknown-pragmas > -Wpointer-arith -Wunused-parameter -Wwrite-strings > > - float start, end; > > + float start=0.0f, end=0.0f; It is not a matter of version, but parameters. You put a lots of -W (I wonder if it would not be shorter to use -pedantic, -Wextra and then disable some) but miss -O1 (or higher) so -Wuninitialized does nothing. Currently there are a small group of warnings left, specially in .cpp files about signed with unsigned comparison or offsetof. Other small handful are about printf, caused mostly by LLP64 vs LP64 and a meaningless intprt_t (the warnings probably only appear on ILP32) for which I have a tentative fix, but being "lib" files no idea if worth. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A proposal for further 2.5x UI evolution
Hi, pildano...@post.cz (2010-12-17 at 1244.27 +0100): > But, you have to look, and you have to scroll. > Remember that clicking is actually faster than looking, and in a good written > ui, > I don't have to look to see if my property is there. > also as said, my proposal talks about outliner, which definitely needs more > space. When you say "look", do you mean "search with click and scroll"? Or just "look with eyes"? Because eyes are faster than clicking, as clicks require arm/hand precise motions (plus eyes too). GSR ___ 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] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [33578] trunk/blender/source/blender/ editors/curve: Related to previous commit:
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 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] extension clause
Hi, blenderw...@gmail.com (2010-11-21 at 1117.09 -0800): > e) the company is sued by the FSF for breaking GPL. The FSF can only sue if they own the copyright. And that is exactly what they do and why they ask for copyright assignment for contributions to FSF code. In Blender case, it would had to be a legal action started by Blender Foundation and or contributors, no other could. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] text Hinting patch
Hi, t...@blender.org (2010-11-15 at 1625.15 +0100): > Revisiting topic: why is kerning different then? If we could combine > the crispy hinting with the narrow 1 pixel kerning, it would be all OK? > > On Thu, Oct 28, 2010 at 5:50 PM, Michael Fox > > wrote: [...] > >> http://mfoxdogg.com/development/text_hinting_fix.txt Do you mean why allowing hinting changes apparent kerning? Hinting pushes outlines to fit the pixel grid better, so pixels at full intensity are used instead of spreading over extra pixels (some at lower intensity). Simplest and more visible case would be 1 pixel full intensity vs 2 at lower intensity to represent a thin "stick". And kerning pushes full glyphs to reduce or increase separation with the glyphs around, for example in "VA" the V top could go over the A bottom, so it looks more like "\//\" than "\/ /\". Lets zoom into the right zone of the V and the left zone of the A, one char here == pixel on screen, "#" means full intensity, "|" means lower, "." means no intensity. - Hinting off, some lines fall between two pixels and become fuzzy (other times they are single pixel, see second diagram), but the separation is small and probably near constant all over the string: ..||.|| Both fuzzy, one pixel separation .||.||. ||.||.. ..||.#. First fuzzy, second sharp, still one pixel separation .||.#.. ||.#... So distances among items are right, both glyph to glyph and inside the same glyph, but the stroke intensity will vary wildly, and look fuzzy. - Hinting on, with bad luck (or poorly designed font) that each glyph is pushed in different directions: ..#...# Both sharp, moved away .#...#. #...#.. ...##.. Both sharp, moved towards each other ..##... .## Then intensity is near constant (exceptions are corners that would be lower intensity), but the distances would vary, making some letters in the same word touch and others be separated a lot like if they had half space in between. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [32823] trunk/lib/windows: New Freetype libs for MSVC 2008.
Hi, din...@gmx.de (2010-11-02 at 0013.49 +0100): > Revision: 32823 > > http://projects.blender.org/plugins/scmsvn/viewcvs.php?view=rev&root=bf-blender&revision=32823 > Author: dingto > Date: 2010-11-02 00:13:49 +0100 (Tue, 02 Nov 2010) > > Log Message: > --- > New Freetype libs for MSVC 2008. > > Committing version 2.4.3 here. Compiled "LIB Release" with MXVC 2008 Express > Edition Thanks, that was fast. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Trunk compile scons/msvc broken on windows due to changes in blf_glyph.c
Hi, din...@gmx.de (2010-11-01 at 1100.23 +0100): > Hey gsrb3d, > i get the errors: > source\blender\blenfont\intern\blf_glyph.c(39) : error C2006: > '#include': Datein > amen erwartet, aber 'Bezeichner' gefunden > source\blender\blenfont\intern\blf_glyph.c(39) : fatal error C1083: > Datei (Inclu > de) kann nicht geöffnet werden: "": No such file or directory > scons: *** > [D:\blender_dev\code\build\trunk\source\blender\blenfont\intern\blf_g > lyph.obj] Error 2 > scons: building terminated because of errors. Yeah, thanks, got a similar report via private mail. The problem is that Blender's freetype (the one under lib/windows/) is an ancient version, 2.1.7 from 2004-02-12. So two options: someone with MSWindows updates the lib to a version with the functions, which means at least 2.1.10, or if not possible in near future, I will recommit with #ifdef. To get some perspective of the versions: newest is 2.4.3 from 2010-10-03, Debian Stable has 2.3.7 from 2008-06-29, Blender's lib/darwin-9.x.universal/ has 2.3.9 from 2009-03-12, lib/darwin-8.x.i386/ has 2.1.10 from 2005-06-12 and lib/windows64/ has 2.3.5 from 2007-07-02. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] text Hinting patch
Hi, c...@blenderbuch.de (2010-10-29 at 1109.27 +0200): > > Do you mean that you like fonts like in the image? It is still hinted > > but without antialias. I ask because people seem to mix all the terms > Yes I like that look. Then you like mono options (and all other things default). > As I understand hinting it is used to enhance the rendering of vector > fonts to the pixel-grid. However it is always used together with > sub-pixel rendering and because we can't have half pixels grey pixels > are used, the effect is a "build in" antialiasing. I think there is a big general confusion in terms, lets see if we all are in the same page: - hinting: extra info provided by font designer about how to "deform" the glyphs to give better results (or sometimes different... just look at the autohinters or the poorly hinted fonts, plus the fact that hinting info could target an exact rendering style, giving really bad results with others). - antialiasing: fake higher resolution in a low resolution representation. Normally this results in grey pixels or multicolor pixels. Some people have a bad response to AA fonts, starting with "it looks blury" moving to "it looks like poorly inked print" or "there are rainbow halos" and reaching "I get headaches" level. No idea which software cares about gamma and the colours involved, even if it is important for AA. - subpixel rendering: one way of antialiasing, using the pixels as 1/3 of what they are (ie, the separate R, G & B channels). Those are the rainbow halos some see. It must target the monitor type exactly or it will look bad. Blender code request no hints and supports no subpixels. It also asks that (manually tuned?) bitmaps are discarded. > And yes, not using hinting messes the kerning a bit, I don't care for > short menu texts. The image was generated with hinting, if that is what you refer to... but I think the font is Vera derived, which IIRC is targeted at AAed rendering. I forgot which hinting policy it targets, I know it sucks for sharp mode (I avoid that family and use others that can look sharp). Which leads us to the fact that the font in use is also part of the result (or the problem ;] ). I am experimenting with other fonts to see if it is worth to replace the font (both for AAed or not use). > And we have so many user configurations, that we can afford another one ;-) I committed it as disabled, feel free to make the "sharp = 0;" a non "recompile configuration". :] GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] text Hinting patch
Hi, c...@blenderbuch.de (2010-10-28 at 1205.04 +0200): > Typographically maybe not so nice but I personally don't care, I tend to > get a headache from these hinted and antialiased fonts, first thing I > switch off on new Systems. Do you mean that you like fonts like in the image? It is still hinted but without antialias. I ask because people seem to mix all the terms and not realize that sometimes they are orthogonal, plus some just never see differences caused by rendering options and others do (even to the point of getting headaches, like you, in some combinations). http://www.infernal-iceberg.com/blender/gui/blender-sharp-fonts-crop.png If so, I can commit the code that does this, only thing missing is making it user controlable without recompile (change "int sharp = 0;" to something that picks the value from somewhere else). GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender Proceedings, proposal
Hi, lars_e_krue...@gmx.de (2010-10-26 at 1938.49 +0200): > How about getting an ISBN? Reason: This makes it a citable Are you sure you do not mean ISSN? GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] OpenGL Profiles Project?
Hi, mburr...@yahoo.com (2010-10-06 at 2155.27 -0700): > > So in the end there should be a manual override system on > > top of code > > that tries to do a first guess. Just like the swap method > > selection. > My suggestion for the Python API for the exceptions list satisfies > that. Yes, you need the "manual control" one way or another; the > fundamental difference I'm proposing is that, instead of having > *every* user needing to modify those exceptions manually, that we > save them back out and store them in such a way that they can be > submitted as a patch so that, ideally, only one user (or at least a > small subset) need to actually bother with the manual > control. Everyone else just downloads an update and benefits > automatically. That is exactly what is going on with swap method, people can manually select if they see fit. Read that again, it says "can", it does not say "must" or "have to". Out of the box they get a best guess that should work in many cases, only in the special ones it becomes "must" if they want good behaviour. When such new case is found and reported, the code is changed to cover it and the "must" goes away. Sincerily, it pretty much sounds like you both are saying the same but not realizing it is. Only real diff is current method has GUI for override and C code for control, and you propose all in Python. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] OpenGL Profiles Project?
Hi, mburr...@yahoo.com (2010-10-06 at 0815.35 -0700): > The irony is that, at least IMHO, the specific example you gave > actually supported my idea of *not* having user intervention. > > Specifically, you're putting the burden on the user to determine > whether their graphics card supports GL_POINTS correctly or not. End > users don't want to bother with that; they just want to get > modeling! Some cards/drivers claim X, then give you "X by software" (looks correct, but too slow) or "X done to the basic level required by spec" (compliant but slow and/or not looking as expected by coder that wanted the extras). In both cases, being able to manually pick Y is a lot better than being stuck with X, even if down the road an exception will be added so Blender knows it has to pick Y, because all that time you have been "enjoying" X. Or the other option, the driver gets fixed or improved and X becomes fast and implements the full spec, so now Y is the wrong thing. One example inside Blender is swap mode (triple buffer, overlap, etc). It sounded like a great thing, but once people started testing with other cards than the developer's one, problems appeared. Auto select was added to tune "out of the box" behaviour, but manual override was kept. As another example of thrusting the drivers to use advertised options, that are slower and worse looking than the old fallbacks, you can check the latest rants arround KDE. Probably if they had an manual override from start they could had collect user reports to make better guesses, whilst people would be getting good performance until a new release that integrates the changes is done. So having a manual option means reducing the pains but also the delays from updating to guess code. IE, happier users, and even better, people being able to test what workarrounds must be added or if the old workarround can be disabled now or still needed. [...] > The code could also store what exception set from the exceptions > file matched the current profile. If/when the Python API is called > to change a value in the profile, we automatically write out the > updated exceptions to the exception file. That way, developers (and > hard-core users) have a way of tweaking the exceptions file without > manually editing it, and plus they can check the tweaks in > real-time. If someone tweaks their particular setup to a "better" > profile, all they have to do is submit the updated exceptions file > as a patch, and we merge in the new set of exceptions (after any > appropriate testing, of course). So in the end there should be a manual override system on top of code that tries to do a first guess. Just like the swap method selection. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [31068] trunk/blender/build_files/make/ nan_definitions.mk: Makefile fix: on PowerPC architecture SSE compile should not happen.
Hi, t...@blender.org (2010-08-06 at 1053.42 +0200): > Hi, > > > No because PPC could get AltiVec optimizations. Rare but not > > impossible. > > That is precisely the point, then you make a WITH_ALTIVEC. > Such ifdefs then tell what goes on (= good), and not what you use if > for (= arbitrary at best). As I already said in other email, it could be the case that the raytracing optimizations are not just SIMD based. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [31068] trunk/blender/build_files/make/ nan_definitions.mk: Makefile fix: on PowerPC architecture SSE compile should not happen.
Hi, nicholasbis...@gmail.com (2010-08-05 at 1632.46 -0400): > Could do WITH_SIMD then? It could be a way, yes, but it still less descriptive of what it really does. SIMD could apply too to any other part of code like mesh handling or compositing while WITH_BF_RAYOPTIMIZATION means raytracing is optimized (which can be done via SIMD or via plain C tricks). GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [31068] trunk/blender/build_files/make/ nan_definitions.mk: Makefile fix: on PowerPC architecture SSE compile should not happen.
Hi, t...@blender.org (2010-08-05 at 1604.56 +0200): > Makefile fix: on PowerPC architecture SSE compile should not happen. > Note for the coder here, is it correct to enable SSE with a general > WITH_BF_RAYOPTIMIZATION flag? Just call it WITH_SSE? More clear :) No because PPC could get AltiVec optimizations. Rare but not impossible. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [30452] branches/soc-2010-jwilkins: == MatCap Shade Mode ==
Hi, jason.a.wilk...@gmail.com (2010-07-17 at 2229.35 -0500): > So actually, the way it behaves right now is almost exactly the same way as > if you did the 5 or 6 steps to set up a matcap material and then started > switching images. It currently does allow you to select any image loaded > into blender. Ahh, OK, it sounded like it was doing something special with images. I tried to compile & test your GSoC branch, but crashed on launch. > What you seem to be objecting to is making it even easier to reference a > matcap by loading an *entire directory* of matcaps at once into the selector > without having to open the file select dialog. Actually I guess what it > really is is that regular images might not be referenced this way. I'll > consider that but for now I'm moving on since this feature isn't an official > part of my GSoC project :) No, what I am objecting is about special cases. If an image is needed, it should go like any other, so user benefits from the rest of the infrastructure, like being able to adjust curves or paint over it or packing (or not packing). In this case what seems to be missing is multi select to load many images, just like importing many meshes from another .blend already works fast. Improving that for image loader would benefit everyone, like when you have to pick many image maps to do a multi sheet UV work. BTW, MatCaps are also a nice way to do NPR renders, been there, done it, just set a texture with Nor coordinates, IIRC. ;] It could even be used in postpro too, as material swapping trick, but Map UV node misbehaved in edges. So please do not assume where the MatCaps are going to be used. :] It is rather old, 2001 or older, based in the following forum+product and paper: http://forums.cgsociety.org/showthread.php?t=26323 http://www.worley.com/Media/images/html/g2/eaton_artmode.html http://www.cs.utah.edu/npr/papers/LitSphere.pdf The "new" Zbrush part is probably generating the sphere from photos via user guidance. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [30452] branches/soc-2010-jwilkins: == MatCap Shade Mode ==
Hi, jason.a.wilk...@gmail.com (2010-07-18 at 0117.43 +0200): > In the future I intend to load the MatcCp selector with images from > a directory the user selects and keep none of the images in the > .blend file at all. I think this would be the best way. What about making it use any image Blender knows? Be it packed into the .blend or referenced with relative or full paths. No special cases, just whatever can be accessed in the Image Window. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposal to Remove Features
Hi, micha...@cowtoolsmedia.co.uk (2010-07-09 at 0836.52 +0100): > "all edges" option should be "on" if removed! it's crucial to be able > to see all the edges rather than hiding them for game dev And off for tasks with high vertex count, otherwise the view becomes a big colour blob (in some other apps it is a multicolour blob, but useless too). So keep. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposal to Remove Features
Hi, bre...@blender.org (2010-07-08 at 1930.21 +0200): > Hi, > > Here's a proposal to remove a number of features before 2.6. I've been > gathering items on this list for the last few months as I came across > them. If there is enough agreement I can make the changes quickly. If > you agree or disagree with items on the list, please read the > explanation at the top and comment on the wiki page. > > http://wiki.blender.org/index.php/Dev:2.5/RemoveFeaturesProposal >From plain list: - if removing old plugins means getting a new system that works soon, OK. Nodes is half there, but some of the included ones are lacking, and proper plugability is missing. I guess that having both methods means none gets finished (I had the issues with bricks node recently, 2.5D and only grounds!?). - edge render... merge the freestyle project? >From controversial list: - how would one make something disappear for typical cases of item swapping (pick thing, make thing explode, etc)? Layers work both for rendering and 3D view. - what replaces dupliframes as modelling tool? When I tried with modifiers, no idea if the tutorials were too simple or the mod was not to the same level of completeness, so I went back to known method. - env map texture is a quick way to have some effects (not everything is about mirrors, so not everything needs raytracing) or even create env maps for other applications. - shadow render pass should stay, it helps with postpro tweaks. On the rest, no many comments. There are things that just had to be done long ago, like relative paths, and others make no sense at all now, like keeping pinning when there is nothing to pin. There will probably people that use the rest constantly, so they are better for talking about them. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [29506] trunk/blender/extern/bullet2: == SoC Bullet - Bullet Upgrade to 2.76 ==
Hi, aligor...@gmail.com (2010-06-17 at 0442.44 +0200): > Revision: 29506 > > http://projects.blender.org/plugins/scmsvn/viewcvs.php?view=rev&root=bf-blender&revision=29506 > Author: aligorith > Date: 2010-06-17 04:42:43 +0200 (Thu, 17 Jun 2010) > > Log Message: > --- > == SoC Bullet - Bullet Upgrade to 2.76 == > > Updated Blender's Bullet to 2.76 in this branch only. [...] > Modified Paths: > -- > branches/soc-2010-aligorith-2/extern/bullet2/readme.txt > trunk/blender/extern/bullet2/CMakeLists.txt > trunk/blender/extern/bullet2/Makefile > > Added Paths: > --- > trunk/blender/extern/bullet2/Bullet-C-Api.h > trunk/blender/extern/bullet2/BulletCollision/ > trunk/blender/extern/bullet2/BulletCollision/BroadphaseCollision/ [...] It put all in trunk and only a file in your branch. :-/ GSR ___ 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 [29496] branches/render25: Render Branch: remove a few options
Hi, letter...@gmail.com (2010-06-16 at 1138.23 -0800): > On Wed, Jun 16, 2010 at 11:12 AM, Brecht Van Lommel > wrote: > > > * Doubled Sided Lighting: just always do this, not much use in being able > > to turn this off, and it works only in the viewport anyway. > > Brecht - turning off double sided gives drastic viewport speedup - > probably double? And does it not help when creating things where correct normal matters, like games or 3d printing? Yes, I know, there is show normals, but that can get messy. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Installation/file paths
Hi, d...@trollwerks.org (2010-05-12 at 1103.23 -0700): > I believe they changed the /tmp directory because it is cleaned out on > reboot which kind of breaks 'recover last session'. Or at least kind of > recall reading that in the .deb changelog. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=298167 security. > Depends on a separate partition for /tmp I'd imagine. Separate logical partition, yes, disk based, no (tmpfs uses swap when memory is needed), some OSes do it by default. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Installation/file paths
Hi, kin...@gmail.com (2010-05-12 at 1230.51 +0200): > GSR wrote, On 12/05/2010 02:23: > > That is a distro workaround to fix a Blender vulnerability (classical > > symlink attack). > Yes maybe (I'm no security expert) ... but do you mean Blender should > not adopt this workaround on unix-like system? This is what both the > proposal and the debian package suggest on this platform (I haven't any > suggestions about OSX and Windows). Unix has things like mkstemp for this. That was a quick workaround, not a right solution. > As I read your previous emails, you are not in favor with temporary > files located in $HOME directory because of networked user directory > setups. I think those setups are usually managed by some sysadmin ( or > crasy geek user :D ) and therefore Blender should be deployed and > configured by them with environment variables or system-wide config files. Normal users will have to clean up their home. Normal installs do that for you with system wide directories (typically on reboots or based in file age) . GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Installation/file paths
Hi, ideasma...@gmail.com (2010-05-12 at 0933.27 +0200): > By the way, last time I checked - gimp do this for their swap folder, > I recall having to point this elsewhere when we used networked home > dir's at the blender institute. Did you know they also do not create back ups of files so a failed save can mean lost work? And that they never save work in progress, losing work again? Sorry but "Foo throws trash in the street, so it is right to throw it" is not a valid reason. Also, some systems default to faster defaults for placed used for temp files which means you get better speed too, not just the automatic cleanups. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Installation/file paths
Hi, kin...@gmail.com (2010-05-12 at 0122.41 +0200): > When I was digging into the Debian package for blender 2.5, I found the > following patch to move temporary files into the $HOME/.blender instead > of /tmp : [...] > It has been applied in this package build since 2.46 but I did not try > it in 2.5 ... maybe it still works. That is a distro workaround to fix a Blender vulnerability (classical symlink attack). GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Installation/file paths
Hi, m...@mke3.net (2010-05-11 at 1816.59 +1000): > http://wiki.blender.org/index.php/Dev:2.5/Source/Installation/Proposal And a third thing, BLENDER_USER_CONFIG should have a BLENDER_SYSTEM_CONFIG counterpart to store the system wide defaults. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Installation/file paths
Hi, m...@mke3.net (2010-05-11 at 1816.59 +1000): > http://wiki.blender.org/index.php/Dev:2.5/Source/Installation/Proposal Oops, I forgot other thing: the other proposal avoided dots in paths, as it seems some tools get confused when they find dots and get stuck into thinking that means a "extensions". Does that still matter? Ie, 2.52 or 252? GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Installation/file paths
Hi, m...@mke3.net (2010-05-11 at 1816.59 +1000): > http://wiki.blender.org/index.php/Dev:2.5/Source/Installation/Proposal Saving temp to user locations is discouraged, it can cause serious slow downs when the directory is network based. Some are suggesting using same place than base blend for quit and temp blend, which would make sense, if auto cleaning is not desired and what is more important, it would avoid collisions in cases like editing foo/items.blend and bar/items.blend (even having PID, you still have to guess which items.blend it refers to). GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Argh, the GCC segfault bug again!
Hi, c...@blenderbuch.de (2010-04-30 at 1907.17 +0200): > Strange that this file wasn't changed since some weeks?! I did compile > Blender the last week several times. Maybe something else changed, and this depends in that other thing. > A hint for me how I can do this? Where do I get this "preprocessed code"? Compiling with -save-temps should give you a .i file. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [28485] trunk/blender/intern/guardedalloc/ intern/mallocn.c: reverting 28469, there is no use in using a long, while the allocation functions only accepts an int.
Hi, ideasma...@gmail.com (2010-04-28 at 1015.26 +0200): > Revision: 28485 > > http://projects.blender.org/plugins/scmsvn/viewcvs.php?view=rev&root=bf-blender&revision=28485 > Author: campbellbarton > Date: 2010-04-28 10:15:26 +0200 (Wed, 28 Apr 2010) > > Log Message: > --- > reverting 28469, there is no use in using a long, while the allocation > functions only accepts an int. > - only wastes 4 bytes per alloc. > Also would be most correct to use size_t Oh, I thought you were just solving a problem with the struct, not that mallocn.c still is 64 bit uncompatible. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Accessing Files (new config locations, fopen wrapper, etc)
pen syntax? Might just be historical reasons and we can use > fopen syntax everywhere? We could go with fopen only if you want, open calls would need to be translated, but IIRC they sometimes differ, so the translation would go with less features (O_NOFOLLOW, S_IRWXU, etc). So that is why I put both. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Accessing Files (new config locations, fopen wrapper, etc)
Hi, and...@aweikert.de (2010-04-02 at 1201.23 +0200): > The functions getSystemDir and getUserDir are added to GHOST, which adds > a pretty nasty dependency to BLI_blenlib - have you any idea on how to > solve this? I moved to GHOST per Plisson suggestion, to support Cocoa. > There are quite a few functions that need consulidation: BLI_where_am_i, > BLI_where_is_temp, get_install_dir, BLI_gethome_folder, > BLI_gethome_system, BLI_gethome_user and for Windows there's also > BLI_getInstallationDir... > In these functions you can also find the code that needs to go into the > windows version of getSystemDir and getUSerDir. > I think that a bit of planning needs to be done how to consolidate this > with your proposal, otherwise we'll just add more to the mess that is > alsready there. They idea is to clean up all those once the system is in place. > The last issue I have with the environment variables is that if you > create them automatically with BLI_setenv, you will add them to any > computer where you fun Blender for example form a usb thumbdrive even > thought the user there might not want to have anything blender > installed. (Unlikely I know ;) ). > I would prefer to leave a user's system untouched in this case. Pardon? Do envvars in MSWindows work differently than in Unix? In Unix, an envvar that is set is known by who set it and its childrens. It never propagates to parents nor to brothers (and this is the reason you can do export FOO=1 in one shell and export FOO=2 in another shell). > I do hope we can solve these issues to be able to clean up the old > system and user directory handling and getting to a much nicer > installation of Blender. Me too. :] GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Accessing Files (new config locations, fopen wrapper, etc)
Hi: I wrote a doc about the on going file access wrapping API and the effects on configuration files. http://wiki.blender.org/index.php/User:Gsrb3d/Accessing_Files Related documents: http://wiki.blender.org/index.php/Dev:2.5/Source/ResourceFilePaths http://wiki.blender.org/index.php/Dev:2.5/Source/Architecture/EnvironmentVariables and files: intern/ghost/GHOST_C-api.h intern/ghost/intern/GHOST_C-api.cpp intern/ghost/intern/GHOST_System* source/blender/blenlib/BLI_bfile.h source/blender/blenlib/intern/BLI_bfile.c GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Preference file changes for Vista/Win7, network installations, and large domain deployments
Hi, and...@aweikert.de (2010-03-30 at 1920.16 +0200): > For the multi-user installation, there is a start of a description in > the wiki where the paths that blender uses are set via environment > variables, which I don't really like since they are cumbersome on > Windows to setup. They are also likely to be forgotten to set by users > or point to wrong versions of Blender etc. which will lead to bug > reports and at least some maintenance work for the devs. The env vars are, first, a method to pass the info to children processes (and to receive from parent if Blender is being launched from scripts), and second a configuration system. The default initialization is from a file and some internal code (to handle versions, etc) so only very advanced users should need to change things by hand, the rest should be fine with defaults or a file rewritten by Blender. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] set "F6" pop-up-panel to pop-up automatically by User Preference's selection
Hi,
rogerwic...@yahoo.com (2010-03-17 at 1502.11 -0700):
> just delete a file in Vista. go ahead. you will never want another popup.
> I am so sick of confirmation popups "If you change the extension of a file,
> it might not open, or not open properly using installed applications. Are you
> sure you want to do what you just did, you stupid human idiot scum who acts
> randomly and without thought?"
> Add to your list: badly worded confirmations "Do you only want to view
> the content that was delivered securely?", badly labeled buttons, ("No, Yes")
> or
> simply users in a rush click the wrong button. Or worse, one package had
> a blocking popup that was not modal, and promptly got hidden behind
> the window it was blocking. ugh.
So because other apps do it wrong, all are wrong? Those examples are
about getting it right (depend on names for app association, always
use verbs for buttons, respect window stacking). Please, next time
pick examples where the thing is not just done stupidly done wrong.
GSR
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] set "F6" pop-up-panel to pop-up automatically by User Preference's selection
Hi, bill...@me.com (2010-03-17 at 1816.35 +0100): > So, the concept we talked about back then was to make sure the user > is always presented with these controls, even if the toolbar is > hidden, but keep the non-blocking aspect. One way to do this would > be to open a floating panel, much like 2.49, which would > automatically appear whenever the user enables a new tool, but only > if the toolbar is closed. That way the user always has access to > these vital controls while always optimizing to screen space. > Here's a mockup to illustrate: > http://www.reynish.com/files/blender25/tweak_operator.png The only difference with popups is that they require big mouse move to be reached (instead of appearing near/under cursor, fastest by Fitt's law) and precise click for closing (instead of shake your mouse, like a throw away gesture). And vs the toolbar, that it uses only part of the side and appears and vanishes automatically. I start to wonder if popups were not so bad after all, but I can be sure I am not the only that never had issues with popups, but dislike extra scrolling and clicking, otherwise this thread would had not started. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender MIME type
Hi, jdpf.p...@gmail.com (2010-03-03 at 1129.12 -0500): > I'm not particularly knowledgeable about the process or requirements > for securing an official IANA MIME type, but seeing as blender has a > large user-base, perhaps it would be nice to be all official about > registering the .blend file type with IANA. Old thing, frozen due to lack of interest: http://wiki.blender.org/index.php/Dev:Source/Development/Projects/Blender_File_Format/MIME_Type GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] SVN HTTPS certificate expired
Hi: While updating, the following appeared: ---8<--- Error validating server certificate for 'https://svn.blender.org:443': - The certificate is not issued by a trusted authority. Use the fingerprint to validate the certificate manually! - The certificate has expired. Certificate information: - Hostname: svn.blender.org - Valid: from Fri, 07 Mar 2008 17:04:27 GMT until Sun, 07 Mar 2010 17:04:27 GMT - Issuer: http://www.cacert.org, Root CA - Fingerprint: 67:4a:16:75:16:92:63:d2:5a:b2:49:b4:67:55:90:1d:a5:01:83:97 (R)eject, accept (t)emporarily or accept (p)ermanently? --->8--- It seems the cert is old, temporarily accepting will work. Whoever is in charge of this, please take a look at this and get a new cert. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] faster usage of panels via pie menu
Hi, rogerwic...@yahoo.com (2010-02-09 at 1936.00 -0800): > interesting. what takes my time (and vertical space) is scrolling > thru expanded panels, and i find myself constantly collapsing > them. If I were allowed to request a feature, it would be a hotkey > to collapse all panels within a context. Invoked as a hotkey, the > Home key perhaps, since home in the image editor and sequencer scale > the contents to fit within the viewable area. As an icon, perhaps > the same little circled + thing used in the outliner window to > expand/collapse, placed next to the pushpin on the context header, > to expand/collapse all. To me, finding the panel/option you want is > all variations on a collapsable menu strategy, like the outliner or > menu/submenu lookups. I had a hack to experiment with that concept. Press number keys, and panels open or close. Call it visibility for panels, like in 3d view layers, or panel accelerators, like in menus. Anybody interested in testing the idea can try how it feels now. Known issues are that reordering does not changes the keys and that position of mouse is important (focus collision with buttons). If anybody is interested in doing it better, go ahead. http://www.infernal-iceberg.com/blender/number-shortcuts-for-panels-20091203b.diff GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Composite nodes question
Hi, arkan...@gmail.com (2010-01-10 at 1629.22 +0100): > -I have noticed is that normal and z buffers are anti-aliased. Doesn´t > this produce incorrect results at object edges? Are you using the full sample option? If yes, I would say the node needs a change to work with that and allow AA filtering to be done at end (others do too, for example the UV map one, same effect, crap in edges). GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] 2.5 UI font
Hi, bill...@me.com (2009-12-09 at 0014.49 +0100): > Three possible solutions I can think of: > 1: remove horizontal layout - use vertical instead > 2: keep it as-is to ease transition to vertical > 3: Implement clever way to make panels 'wrap around' and spill contents into > the next panel column > 4: Use a simple type of 'autofit' to make panels fit into the available space > without spilling/splitting panels over multiple columns > Did I miss any? 5. Provide an horizontal engine, that targets fixed height and variable width panels (in columns steps). There seems to be horizontal users, so there should be not problem to get people to help and maintain the layouts. Even in some case with wide screens, horizontal mode is good, as currently there are too many vertical areas and eat work zone quickly. Automatic systems will always make horizontal second class, with wasted space or strange column splits, instead of a properly human controlled layout, just like vertical is. By manual setting things, buttons can be properly fit to horizontal contraints instead of reshuffle based in what is inheriting vertical single column and placing as it comes from vertical related decissions. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] 2.5 UI font
Hi, m...@mke3.net (2009-12-09 at 1814.21 +1100): > * Should be *simple* and easy for non-designer coders to use and > maintain, with minimal effort (this disagrees with ideas of making two > completely custom layouts for horz and vert) It seems there is an user base with good motives for a first class horizontal layout, so instead of having a group grumbling about how they have to cope up with something else, you can redirect them into doing something positive: maintain the other layout in a unified way and benefit everyone. > * Should be elegantly expandable, so that when new features are added > or new options appear (eg. modifiers, constraints, whatever comes > next) the whole UI isn't rearranged, which ruins muscle memory. (this > disagrees with designs that push panels back and forth, jumping to > different columns). Please explain this point because currently vertical layout pushes around other panels when one above changes or by adding new panels (easy test, enter and exit mode for mesh, transform changes size and mesh view appears). > * Should make good use of available space Forcing vertical, as is or via automatic convert, into horizontal does not. > * Should be clear, organised and quick and easy to find something if > you don't already know where it is See point above about avaliable space. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] 2.5 UI font
Hi, din...@gmx.de (2009-12-08 at 1903.45 +0100): > honestly. 2.5 was designed for vertical buttons window in the first > place, everything else is up to the user, who can modifiy the layout > files as he wish. So there will be lots of redundant work that is not properly shared. There should be no problem if layout engine provided horizontal functions, just add two functions draw_horizontal and draw_vertical, move current contents of draw to draw_vertical and make draw have an if/else decide (until h is implemented, use v one). Finally let users become new developers and contribute the draw_horizontal code. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] 2.5 UI font
Hi, magick.c...@gmail.com (2009-12-08 at 1410.28 +0100): > > just 2 screenshots, it's an attempt to transpose > > a 2.49 layout too 2.5 > > 2.49 http://dwarf.free.fr/blender2.5/Capture-4.png > > 2.50 http://dwarf.free.fr/blender2.5/Capture-3.png > I see what you are saying here but with 2.5 you can just use the N and > T keys to get rid of those panels in a flash and bring them back but > most of the time you can just use hot keys. And after they appear, navigate them. Fast keys and then not so fast, too many things behind every key, so there will be need for extra actions. Probably there should be 2 bars more, operator and view, to move out parts of toolbox and properties. The reasons are simple, operator is basic now, and sometimes it is rather huge (try extrude), but it gets tucked in small space of a panel penalizing heavy keyboard users by having the toolbox and also mouse users by having to rearrange the separation. And object/transform properties are being mixed with view settings, ie, something of common use with something that is used sparingly. Currently you can move things around and colapse some panels, but the default are what they are, and every area you use will need intervention to setup panel order, drag the zone or click the headers over and over. Plus things keep on moving and hiding, which was criticised in previous version (and with reason, it is not very good for muscle memory if things are barely constant). Defaults matter, being able to reconfigure is not a good reason to not improve defaults, the user efforts should be in the real work and not the "metawork" of handling app widgets. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [24935] trunk/blender/source/blender/ editors: First changes to implement the 2.5 snapping proposal ( discussed back in May and recently on IRC).
Hi, the...@yahoo.com (2009-11-27 at 1031.35 -0800): > The UI part and workflow changes are a result of long discussions > with users and members of the UI team. Where? Pages I read do not mention it or have been rarely updated http://wiki.blender.org/index.php/Dev:Source/Blender/Proposals/2.50_UI_design http://wiki.blender.org/index.php/BlenderDev/Blender2.5/UIKeyboardLayouts > Now, to go back on the constructive side, the proposal is online, > people should comment (and have done so already) if they agree or > disagree with anything: > http://wiki.blender.org/index.php/User:Theeth/Snapping The discussion page for that page appears empty. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [24935] trunk/blender/source/blender/ editors: First changes to implement the 2.5 snapping proposal ( discussed back in May and recently on IRC).
Hi, the...@yahoo.com (2009-11-26 at 1237.39 -0800): > Modifier keys have been used as normal keys in games for decades, > there's nothing especially new here. Let's forget Blender is a not a game nor other of the multiple devices with keys and buttons but a computer tool... do those games use modifier keys as "normal keys" or as "modifier and normal keys"? Seriously, what goes with adding things out of the blue that nobody else does, and at the same time replacing long standing Blender methods just because others do not use them... sorry, it is hard to follow which logic applies to future UI. Are all on going behaviours experiments? Just add and later clean up inconsistencies, useless extra clicks, etc? Last doc I know about this topic was one by Jean Luc. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [24935] trunk/blender/source/blender/ editors: First changes to implement the 2.5 snapping proposal ( discussed back in May and recently on IRC).
Hi, the...@yahoo.com (2009-11-26 at 2047.56 +0100): > http://wiki.blender.org/index.php/User:Theeth/Snapping Being a writer myself, I can imagine the nightmare trying to explain the highly confusing terminology, and a non standard keyboard operation, in an article or book (or in classes), just as other things have been pointed before. "Click" is "pointer click" and has been for decades, modifier keys change other things and just that. There must be a different word that can be used (tap?) and even so you declare mouse motions are allowed (so it becomes a drag in that case). And the changing the long stablished function of modifier keys is debatable. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Svn Rev 24718 BLI_bfile.c error
Hi, dpla...@webafrica.org.za (2009-11-21 at 1159.10 +0200): > but I noticed that #include existed at the top of the file > conditional to a non win32 build and was commented out. > libgen.h is needed for "dirname" used at BLI_bfile.c:250 Enabled the header. It will probably fail in other plataforms, but that is to be expected as I can not test them (see all the FIXME in defines for example). GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] meetings for new developers
Hi, ra...@info.upr.edu.cu (2009-11-20 at 1433.38 -0500): > I really like the idea about meettings for new devs, though I feel some > envy because anything that smell to live, chat, internet is science > fiction to me :) and that brings me the question about a strong offline > support: > >What about a good offline reference, tutorials, even a book (ok, a > downloadable pdf) something like a Blender Beginers Developer´s Guide? > > Is there a plan for it in the future? > Investing resources in documentation is by no means a waste, and often > something understimated in the open source world. Hey, a beautifull help > documentation (for users and developers) is the best marketting resource > of a software. The main drawback of a highly dynamic program like > Blender is that the software evolve much faster than its documentation > or the features/code/UI change a lot making learning materials rapidly > obsolete but I guess it represent a defy full of oportunities and not a > source of problems. > If someone want to make a very special contribution to Blender and is not > a developer I think this could be a good project, he even could > specilized on Blender official documentation from now on. You just discovered the root, if there was documentation, the meetings would not be a big issue, maybe even not needed at all. You are not the first to ask for it either, some months ago there was another thread, but it ended with something like "time is limited". But now it seems time is less of a problem so it can be used for meetings, help some small group of people and generate raw information. I am not saying meetings are a bad idea, but I think the focus should turn 180 and instead of going towards videos and unprocessed logs, etc, use them to pin point which parts require with more urgency documentation (or cleanups) and write it. Probably inline as much as possible (so when coding more things or fixing, updating is also faster) with any graph or global arch thing outside. Invest time wisely. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Actuall usability of some tools and new features
st to make panels more distinguishable. I do not see this... maybe because I use different colours for titles than labels? It seems to be blamed on Blender a lot but I think to many times the fault lies on themes (2008 UI talk had something about confusing button types, IIRC, same kind of problem), so probably the default theme needs changes. > 5. Almost last but not least, I'm not sure that replacement of the > main menu (space key) with search is so bright idea. Let's imagine > that Bill has suddenly decided to remove start menu button and usual > Win key function replace with Run dialog... In that same search > menu, let someone try to scroll to see all commands while slightly > moving the mouse cursor. That's a quite impossible task. Yeah, Space should go back to toolbox tasks, and something else for the search system. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Actuall usability of some tools and new features
Hi, the...@yahoo.com (2009-11-19 at 1101.32 -0800): > As Brecht said, manipulators are still there, there's nothing new under the > sun, it's just an additional way to invoke the tools, it doesn't replace any > of the existing methods. Yes, I agree about direct manipulation via shortcuts or manipulators. But it seems people see buttons and forget the other methods. Give them a mouse, and they forget tab key navigation, and so on. The thread just demostrates it, and so do other points in UI design, people are not informed about something or they forget, and then "new problems" arise. * So I would like to use this thread to advice any teacher or document writer to give extra coverage to the fast methods and not just the obvious ones. GSR *: Worst is if the problem is from creator side and not from user side. I just found the redefinition of toolbar button appearance "because gradients look bad". Consistency, common semantics, mouse motion and clicking optimization, etc... blah, ranting again. Sorry. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Actuall usability of some tools and new features
Hi, s...@student.chalmers.se (2009-11-19 at 2050.15 +0100): >> "Having to open a panel each time you want click a button in it just >> seems quite slow to me, and also makes it harder to find things at a >> glance." > - It is faster than having to scroll, and it is faster to find desired > settings since the interface is much less cluttered. It is much faster > to find things at a glance as this is the problem of todays layout, and > the very problem i am trying to adress. windows with little content can > be pinned by default. I have serious doubts, opening requires clicking small targets (maybe many until you find it) and scrolling is just click & drag a huge target, with fast eyes looking for things. Because you are scrolling by grabbing the full zone, not the tiny scrollbars, right? If people go to scrollbars to do small zone drags, it just proves the point about too obvious things just slowing down users. For trully huge zones scroll bar is faster than multiple grabs, but for small things not so (ironic that improvement backfires in some cases, but not less true). Good organization makes scroll minimal, while keeping everything related in sight instead of forcing user to remember invisible things that apply to the current context. One thing is removing useless things and other going to far and removing near everything. For example, recently Carsten complained about the missing keys F# to access buttons. I would even add that subpanel state could be bind to number keys (a la 3d view layers). The F# keys were faster and many power users realized that, instead of clicking buttons on screen. That kind of interface is the one Blender had, and IMO should keep / recover / expand. Count the clicks, the keys, the motions, the time you have to think instead of just let your muscles "take over". All those can be tested and measured, but sometimes imagining the workflow is enough. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Actuall usability of some tools and new features
Hi, the...@yahoo.com (2009-11-19 at 0904.17 -0800): > > > --- On Thu, 11/19/09, Damir Prebeg wrote: > > > 1st. issue: Select cube and click on that translate button. > > How far can you move cube to the left side of 3D View? Same > > with Scale button, how much can you scale up that object? > > With the continuous grab option (which should work on all platforms), there's > no limit, the mouse pointer just wraps around the 3D view. Except for tablets, where continous grab will never work (the pen goes out of the tablet and the action ends). It amazes me how sometimes tablets are considered vital and other they are totally ignored. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] 2.5 release
Hi, ant...@kyperjokki.fi (2009-11-18 at 0918.54 +0200): > Knapp kirjoitti: > > Agreed, as beta, is fine to release it but without all the planed > > buttons? I have never seen that before on a beta. > > > > One definition of alpha and beta I've heard is: > * alpha is when you're still missing features, have known bugs. often > not that interesting for end users, but has things that work. > * beta is when you are kind of feature complete, and don't have loads of > known bugs / missing things - but those are expected to be found in the > wide user involving beta testing, before release candidates > > Based on that it would be normal to have missing buttons and stuff in an > alpha, but not in a beta which should start to look like the final > thing. I've no idea whether this is a common conception, just something > that was used in one project (probably the lead there got it from > literature) and which has seemed to make sense to me since. I thought it was clear that definitions mattered nothing in Blender land after releasing RCs that add features on top of previous RCs... that or RC in Blender does not mean what is the common expansion for the acronym: release candidate. Which would be an issue too. Could someone explain me if common meanings of terms are going to matter in future or not? GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
