Re: [Bf-committers] Proposed change for (not) rendering with missing links
I have had to deal with similar issues in other applications. At the very least if it can't find some kind of external resource (like a texture), it should print a 'WARNING: Missing file blah' in the console, so that render farm software can be configured to trigger an error when it happens. On 1 March 2014 13:39, Alberto Torres wrote: > How about this? > > Make Blender aware of repositories (e.g. checking .git exists in any of the > parents) so it can have repo-relative paths (defaulting to something like > //../repo-name/ for older blender versions) , and to make lists of > dependencies. When you open a .blend you can check which dependencies are > met, instead of dealing with individual missing files. > > Also it can have an ignore list, e.g. for reference images not needed > outside the author's machine. > > > 2014-03-01 14:33 GMT+01:00 Ton Roosendaal : > > > Hi, > > > > If you work all alone, you can do what you want. > > > > If you want to give the project to someone else (or render farm, or > commit > > it to a version system) it should include such libraries. A project > > 'domain' can be as flexible as we want it, and be as limited too. > > > > -Ton- > > > > > > Ton Roosendaal - t...@blender.org - www.blender.org > > Chairman Blender Foundation - Producer Blender Institute > > Entrepotdok 57A - 1018AD Amsterdam - The Netherlands > > > > > > > > On 1 Mar, 2014, at 13:29, Juan Pablo Bouza wrote: > > > > > Ton Wrote: > > > > > > "Solution: make the fact user works on a project with relative paths > much > > > more visible and in control. The project path (from where relativeness > > > works) has to be explicit somehow. And especially - if user decides to > > > use a file outside the project domain - it can just refuse that, throw > > > big warnings, move it inside the domain, or pack it even." > > > > > > -1 to any proposal that would force assets to be inside of the project > > domain. For instance, you may want to have a texture library that is in > > some place of yo computer, and forcing things to be copied to the folder > of > > the project is just a waste of disk space. > > > I prefer big warnings and a more explicit relative path control :) > > > > > > > > > > > > > > > > > >> From: t...@blender.org > > >> Date: Sat, 1 Mar 2014 12:44:21 +0100 > > >> To: bf-committers@blender.org > > >> Subject: Re: [Bf-committers] Proposed change for (not) rendering with > > missing links > > >> > > >> Hi, > > >> > > >> Let's be clear; options, warnings, and especially YES-NO requesters > are > > all signs of lazy and weak design. > > >> > > >> The best way to solve this is to prevent this from happening. I know > > Daniel's cause, and it's just because a path was absolute, and not > > relative. Either a bug or a user error. > > >> > > >> Solution: make the fact user works on a project with relative paths > > much more visible and in control. The project path (from where > relativeness > > works) has to be explicit somehow. And especially - if user decides to > use > > a file outside the project domain - it can just refuse that, throw big > > warnings, move it inside the domain, or pack it even. > > >> > > >> Secondary: make a tool (operator) that checks for paths to be proper > > relative. That tool can be used at will (user), or a scripter can use it > > configure Blender to make it automatic. That then can be sort-of doing > > what's being proposed below, but it's only a debugging tool. > > >> > > >> The work we plan for Gooseberry's asset/project system is all about > > this. Sanitize how data is being referenced, re-used, shared, linked, > > stored, versioned, copied, and so on. There's the real job. > > >> > > >> -Ton- > > >> > > >> > > >> Ton Roosendaal - t...@blender.org - www.blender.org > > >> Chairman Blender Foundation - Producer Blender Institute > > >> Entrepotdok 57A - 1018AD Amsterdam - The Netherlands > > >> > > >> > > >> > > >> On 1 Mar, 2014, at 2:52, patrick boelens wrote: > > >> > > >>> The only problem I see with this solution is when you actually know > > you're missing resources (i.e.: third-party textures), but want to render > > regardless. > > >>> > > >>> I think for headless mode this would probably be less of an issue, > > especially considering who uses that and in which situations. > > >>> > > >>> Perhaps for GUI-Blender we could show a confirmation screen, > > operator-style? > > >>> > > >>> "You are about to render with missing resources (see > > render_errors.txt). Would you like to continue?" -> [Yes | No]. > > >>> > > >>> The second thing I'd like to address is: How do we make it clear to > > the user which resources are missing? Could a linked in .blend not be > > found, or is it a texture's image? Again, for headless mode it could > > probably just be printed to the console, so no issues there. But for > > regular use, perhaps a te
Re: [Bf-committers] Multiview branch feedback
On Tue, Jun 18, 2013 at 10:55 AM, Dalai Felinto wrote: > > All the per-stream tweak can be accomplished with the "View Switch" > node. e.g., to set the convergence you can do: > > http://dalaifelinto.com/ftp/tmp/multiview_convergence1.jpg > http://dalaifelinto.com/ftp/tmp/multiview_convergence2.jpg Is it possible to split the individual left and right views out of a multiview stream into two single view streams though? In that network it looks like you're applying two translations to two multi-view streams. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Multiview branch feedback
On Mon, Jun 17, 2013 at 10:51 PM, Adriano Oliveira wrote: > > But can you explain to me specifically why that is better than the > workflow used in the branch? > > Because it is more simple and better fits in actual Blender logic. It is > also the way everey other composite sistem works, as far as I know. > I haven't used this blender multiview branch and have only skimmed over this thread briefly, but it seems to me that it works in a similar way to nuke. In nuke, you can set up as many views as you like, and by default, nodes will apply the same processing to the multiple views in an input stream. It's possible to split off individual views into individual data streams, process them independently, and then join them back into the one stream if you like, and it's also possible to split individual parameters on nodes so you can apply different parameter values to different views. In general though, you're passing all views down your comp network together as a single data stream. There are also additional nodes that specifically deal with multiview inputs, for example nodes to change convergence. cheers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Python API breakage - squeaking wheels
I suspect I'm one of the people Ton is mentioning so I'll say a quick word here. These days at least for me, trying to work on an addon is frustrating and demotivating, and the number one cause of it is API instability. Maybe this is just something personal to my situation because I don't have a lot of time for this sort of thing these days but for the last several months the pattern has been something like: "ah I have some time on a Sunday afternoon, why not do a few improvements and make some more progress on the addon". So I update blender, and spend all the time I have available testing and hunting through commit logs and googling just trying to make the damn thing work again, without doing any creative/productive work of my own. Next time around, it's the same pattern over and over again. So these days there's little motivation to spend my free time finishing off the remaining last round of fixes, let alone updating to fix the next. It seems somehow acceptable now that scripts have to be updated every few months, because as long as people change addons that are included in SVN then there's no problem, right? Too bad if you don't want to work that way, or have custom/proprietary tools. To answer what kind of changes cause problems, *every* change is a potential breakage and can make the difference in the eyes of a user between an addon that works and an addon that doesn't. As I've mentioned in the past, imo theres much too low a priority given to api stability. Looking at those pages previously linked (better publicity for this would probably help), there's all kinds of minor renaming that all will break a script that is using it. Having consistent names for properties can be a nice hint as an aid to API users but constantly renaming things erases all minor benefits and just makes life difficult. I was also pretty astounded previously to have to update all of the template list calls, an absolutely fundamental ui function, which apparently could not have been implemented as a separate function or optional arguments? These sorts of changes would never happen in any other app I use with a scripting API. In specific one thing that I now have to fix is a bizarre error that's never happened before, has cropped up in the last couple of months and doesn't seem to show up in other examples included in blender, like ArmatureButtonsPanel. [1] Anyway, I know this could sound quite self centred. It's really not meant to be, just a description of what a constantly changing API means to someone in my position. If more time and effort is necessary to effectively use blender's python API then I'm probably just not able to devote in the requisite amount of time and energy, and I can accept that, and probably won't much more. It's disappointing though. Hope that provided some of the background you were looking for. cheers Matt [1] https://github.com/mattebb/3delightblender/blob/master/ui.py bpy.utils.register_module(): failed to registering class Traceback (most recent call last): File "bin/blender.app/Contents/MacOS/2.67/scripts/modules/bpy/utils.py", line 578, in register_module register_class(cls) AttributeError: expected Panel, InlineRibPanel class to have an "draw" attribute On Mon, May 27, 2013 at 1:50 AM, Campbell Barton wrote: > Id like to hear what API changes cause problems. > > * if its one large change that causes problems for every one using the > api (bmesh, pynodes) > * if its misc changes in blender which propagate down into the api - > (recent premul/alpha changes). > * if its from being strict and adding limits like the restricted > context, or disallowing data editing during drawing. (things that > shouldn't be done anyway). > * if its even intentional/known-about - Some end up being side effects > of other changes in blender. > > On Sun, May 26, 2013 at 10:59 PM, Ton Roosendaal wrote: > > Hi, > > > > Excellent, we do have a API change page :) > > http://wiki.blender.org/index.php/Extensions:2.6/Py/API_Changes > > > > Should get more prominent linking everywhere! > > > > -Ton- > > > > > > Ton Roosendaal - t...@blender.org - www.blender.org > > Chairman Blender Foundation - Producer Blender Institute > > Entrepotdok 57A - 1018AD Amsterdam - The Netherlands > > > > > > > > On 26 May, 2013, at 13:23, Ton Roosendaal wrote: > > > >> Hi all, > >> > >> This is probably just coincidentally, but just in past few days two > quite visible py scripters moaned in public about API breakage, more or > less mentioning to give up on it. > >> > >> Communication is really King here. That means for every release, a > simple quick to find doc with API changes has to be available (or is there > one?). > >> > >> We can also reconfirm the procedures for api changes, to go along our > release cycle: > >> > >> - Announce in BCon1 or BCon2. > >> - Add it in BCon2 latest. > >> - Testing, feedback during BCon3 and BCon4. > >> > >> We also have
Re: [Bf-committers] Python API change breaks Rigify
On Mon, Feb 18, 2013 at 6:24 PM, Nathan Vegdahl wrote: > > I just also wanted to make the point that additional API support will > likely be necessary because of the restriction. Supporting > non-empty-by-default collections is a good example. ^ That would be very handy for addon devs. cheers ___ 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 [53355] trunk/blender: This commit frees list ui items from their dependencies to Panel, and hence from all the limitations this i
On Sat, Dec 29, 2012 at 10:36 AM, Bastien Montagne wrote: > Yes, all lists now use it… See e.g. the 'properties_material.py', > 'properties_data_mesh.py', etc > Oh, I see... So this breaks API compatibility, and all scripts will need to be updated? ___ 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 [53355] trunk/blender: This commit frees list ui items from their dependencies to Panel, and hence from all the limitations this i
On Fri, Dec 28, 2012 at 8:20 PM, Bastien Montagne wrote: > > This UIList has a draw_item callback which allows to customize items' > drawing from python, that all addons can now use. Incidentally, this also > greatly simplifies the C code of this widget, as we do not code any > "special case" here anymore! Hi, is there some example python code for these changes? thanks ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Revisiting Color Curves
As far as I an remember since it was introduced, you could zoom out and manipulate the curves outside the 0-1 range. You may need to press 'unlock zoom' or something to do it though. I haven't used the new compositor though so don't know if this functionality remains. On Sun, Sep 23, 2012 at 3:32 PM, Troy Sobotka wrote: > With native scene referred values, 1.0 is effectively meaningless. > > Might it be possible to implement a method to display a region of the > data in the curves window by specifying a lower and upper limit? ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender Voxel texture file format?
It's very primitive - just a 3d grid, represented as an array of float values with a header that contains info on resolution etc. The header is here: http://projects.blender.org/scm/viewvc.php/trunk/blender/source/blender/render/intern/include/voxeldata.h?view=markup&root=bf-blender Would be nicer in the long term for it, and smoke cache perhaps, to use field3d or something more interchangeable. On Tue, Jun 26, 2012 at 9:35 AM, Tobias Oelgarte wrote: > Is there some information/documentation available in which format the > "Blender Voxel" texture files are written? I wanted to create an > exporter/importer for this format but i can't find any documentation how > it should look like. > > Tobias Oelgarte > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] The Future of Blender Projects WAS meeting notes
On Fri, Jun 22, 2012 at 12:05 AM, Ton Roosendaal wrote:
> with the evident benefits but also with as danger that it can go out of
> control with a huge pile of postponed todo items and issues. :)
>
> http://en.wikipedia.org/wiki/Technical_debt
This is an issue for blender, and has been for a while. It may not be
as exciting to rally volunteer developers around, but I think
post-2.6, a period of 'paying off these debts' would be very good for
blender users, especially those using it in production.
I think that this isn't just related to short release cycles though, a
lot of it's also due to the open movie projects ('Business pressures'
in that list, I suppose). They certainly have their benefits, but they
also leave a lot of unfinished work in their wake.
One of the original ideas for the open movies was to use a practical
animation project to 'get blender ready for production', however in
the heat of the project, under deadlines and resource pressures, this
becomes more like 'fit in the minimum required to allow this
particular production to get done'.
Using blender in production at the time, I was quite sensitive to this
happening during BBB, with features implemented well enough for the
team's specific purposes, but not so practical for other use cases. It
happened in Sintel (hair dynamics is one example), and it now seems to
be happening in Mango. One example that I'm familiar with right now is
how the render API seems to have been bypassed and all but forgotten,
during the rush to get Cycles in a usable state.
Another issue is that the open project are usually exploring new
territory for the development team - that's often a major reasons for
existence of the projects (eg. 'improve blender's furry hair styling
and rendering' or 'improve live-action vfx compositing'). It's great
to have a focused target, and it's often a good way to get things
done. The danger however is that often the coders and artists involved
have little experience in a particular field that they're exploring,
and the design decisions and implementations may turn out to not be so
good in hindsight, and maybe aren't so good to commit to for Blender.
There's a tendency to think that since a movie project got completed,
then that particular area of functionality is 'solved', eg. "BBB got
finished, therefore hair styling and rendering is done, and we can
move on". In reality, Blender users can be left with tools that really
don't work that well outside of the project's specific needs, or tools
that now with the benefit of hindsight and experience, should have
been implemented in a better way. However if developers keep moving on
to newer things, and if this happens across all areas of
functionality, the end result is an application made up of parts which
are all first-draft attempts, which work 'ok' in some situations but
not in others, and never smoothly and elegantly.
One positive example on the other hand was the render branch after
Sintel. The easy thing to do would have been to satisfy the casual
users who want to play with new toys, add it all in, and move on.
After all the development work that was done on it, it was really
commendable to see self-reflection and the willingness to step back,
critique it, and say "This isn't right for Blender and its users, it
needs to be done a better way", and throw a lot of it away. In the
end, it led to cycles, which I'm sure most Blender users will be much
happier using in the long term, and is hopefully shaping up to be
something that's actually a great tool to use, not just a 75% done
first-version.
This is also a good argument for doing movie project-specific
development in a separate branch. Adding these things into trunk as
they are coded makes it much more difficult to revert later on.
So! For these open projects to become more effective ways of achieving
the goal of improving Blender as a package, not as a project-specific
tool, there needs to be a period of critique and further work after
each project. I know from experience that at the end of a tiring job
when you just want to forget it all, have a rest, and move on, the
last thing you want to do is go back over it all and re-work it, but
that's the difference between doing this development for that movie
project only, or for Blender in general.
Questions need to be asked - "Is this the right way to go?" "Should we
revise this with better design decisions?" "What worked and didn't
work well during the course of the project?" "What hacks did we have
to do to make this work, that we should clean up?". And even if the
design is good, and it worked well, and you wouldn't do it differently
a second time around, it's still very important to ask "Is this enough
for general use by other Blender users, not just this open movie team
working on this project?". Some of these will come out as feedback
from other users during the course of the project. Each time a
response to feedback is: "It's not a target for our project", it would
b
[Bf-committers] Remove vertex colours in startup.blend?
Hi, I'm doing some work on my render exporter to bring it up to date with Blender 2.63. I noticed that the startup.blend cube now has vertex colours, which causes some issues for this exporter - I override colours with the active vertex colour layer by default, which was fine in previous Blender versions since vertex colours weren't on the default object and had to be explicitly added. I'm happy to work around this, but it's probably better to just get rid of the vertex colours on the cube anyway, since they're unnecessary. I don't have a working build setup here - if anyone thinks this is a good idea, would you be able to please remove the vertex colours and replace the startup.blend? thanks Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] collapse/flatten modifier stack?
mesh = ob.to_mesh(scene, True, 'RENDER') ? On Sat, Mar 24, 2012 at 4:51 AM, Bassam Kurdali wrote: > The original object is fine, yes, and has all the modifiers intact. the > new object is the *unmodified* mesh, not the end result of the modifier > stack, which is what I'm trying to get. > I would do it by applying modifiers, but, with multimodifiers, applying > one at a time is not going to work (unless someone can tell me how) > TL;DR: bpy.ops.object.convert isn't the answer. > cheers > Bassam > On Fri, 2012-03-23 at 10:18 +, cont...@steamreview.org wrote: >> Presumably you are still looking at the original object. keep_original >> means that a new one is created. It'll be made the active object by the >> operator. >> >> > Thanks Tom >> > On Wed, 2012-03-21 at 22:05 +, Tom Edwards wrote: >> >> You're missing this: >> >> >> > >> >> bpy.ops.object.convert(keep_original=True) >> > I tried it and I got the default i.e. original mesh, i.e. it didn't >> > apply the modifier stack, but removed it. Is there something I'm >> > missing? >> > >> >> >> >> Which is exactly what you want. It is quite obscure though! >> >> >> >> On 21/03/2012 9:04, Bassam Kurdali wrote: >> >> > Hello list, >> >> > This has come up before, albeit in a python context: the desire to get >> >> > the result of the modifier stack as a mesh. There was some discussion >> >> > over the desirability of hard-coded py api, and a question of why not >> >> > just use the apply modifier approach one by one. >> >> > >> >> > I've encountered both the use-case and the problem today. >> >> > >> >> > use-case: collapsing the stack/applying shapekeys for prepping a >> >> rigged >> >> > model for 3d printing. >> >> > >> >> > problem: this is the first 'cannot be done' problem I've encountered: >> >> > >> >> > Multimodifiers (correct me if I'm wrong) cannot be simply applied one >> >> by >> >> > one: they need to be applied together. And afaik there is no mechanism >> >> > to do this. >> >> > >> >> > Is there anything I'm missing? this seems totally undoable, I wonder >> >> how >> >> > render-engines deal with it? >> >> > >> >> > cheers, >> >> > Bassam >> >> > >> >> > ___ >> >> > Bf-committers mailing list >> >> > Bf-committers@blender.org >> >> > http://lists.blender.org/mailman/listinfo/bf-committers >> >> > >> > >> > >> > >> >> >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers > > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Weekly developer meeting minutes, march 4 2012
On Mon, Mar 5, 2012 at 6:05 AM, Nathan Vegdahl wrote: > > I agree. But I would still rather see hinge deprecated than improved. > I guess we just have different thresholds for "added back-end > complexity" vs "shorter workflow". To me, this has a very minor > workflow benefit, but appears to make quite a lot of changes and add a > fair amount of complexity to the transform code base. +1 As a general rule, blender is already too far on the 'overcomplicated hard-coded special cases' side - it needs more in the way of simple, rock solid, generic tools that work capably and reliably, that can be adapted to your own usage patterns. This seems harder to achieve in open source where volunteer devs like to work on their own little systems and portions of code, but it's better for users in the long run. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Color Unpremultiply
On Mon, Feb 20, 2012 at 2:07 AM, Troy Sobotka wrote: > Yes. Yes. Yes. Completely agree. It's my fault! > > I did _try_ to get the blasted thing on the output node, but the UI > goes fuzzy on some of those special nodes, of which the output is one. There, there :) The Colour Management option doesn't really belong there either, but it's there since half of what was involved in that work was linearising inputs to BI, and it was added before Blender really started to open up to the prospect of seamlessly using external renderers through the render API, and well before it shipped with two renderers by default. In the future, if people will be working on further implementations of this sort of thing (using a CMS for example), it would be good to keep in mind the question of how to present an accurate impression of how all this fits together in blender. At the least, a first step would be clearly separating the options concerning how colour/imagery is imported into any particular renderer (which should be handled in the properties owned by that renderer itself) vs what's going on in the rest of the pipeline surrounding that (eg. comp and file output). Right now, the distinction between BI render and comp settings is still a bit murky (eg. the sky/premul/straight option), and it needs a bit of a push into a renderer-agnostic future. cheers Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Color Unpremultiply
On Sun, Feb 19, 2012 at 4:15 PM, Brecht Van Lommel wrote: > > So for me this is more a question of what the best default is, if > having this enabled for premultiplied alpha images is considered > better then in principle I have no problem if this gets enabled by > default. However there is an extra issue which is that currently we > have no way to know if the image is premultiplied or not. For render > output maybe to some extent, but even then compositing can change the > kind of alpha that the render has. Well, the image viewer kind of 'implies' that output images should be premultiplied (otherwise they'll look bad), but this is probably also the fault of there being no option to choose how to interpret imagery that you're viewing, to correct accordingly. Even so, it would make sense to me that the output option would be aligned with whatever the viewer does (by default at least), so that if the viewer assumes premultiplied images by default (which in turn encourages artists to premultiply their imagery so it looks correct in the viewer) then it may be a good assumption that the output is premultiplied too, and divide accordingly. This is just talking defaults though - the option is still required. Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Color Unpremultiply
On Fri, Feb 17, 2012 at 8:04 PM, gespert...@gmail.com wrote: > First of all, the text in the tooltip is a little bit misleading. The > operation performed isn't done to avoid a fringe on light backgrounds. It's > done because colorspace conversions shouldn't be performed on premultiplied > data. > The resulting effect when doing it wrong is indeed a fringe, but what the > operation does is to deliver a properly converted image, not avoiding a > fringe. > This may sound silly, but I think that using a more accurate tooltip would > have an educational effect because people would know what it does or would > investigate more rather than "this is for reducing a fringe". > A fringe can come from a wrong compositing earlier, and believing that > color unpremultiply will fix it is wrong. +1, correct > Apart from that, I wonder if it's really necessary to have that option > instead of just applying it whenever premultiplied alpha is selected and > the output file is gamma-corrected. Eh? I presume you're talking about the render option that does this at the end of the pipeline before saving imagery out of the renderer/compositor, and not the option per image that does this when loading the image, right? The Sky/Premul/Straight options are purely blender internal renderer things, they don't have any bearing on what comes out of the compositor. You can un-premultiply a transparent image in the compositor and pipe it straight to the output if you like, and while it will look bad in the viewer, it is a valid thing to do if you really want to. In this case, you don't want another divide before colour space conversion and need the option, no matter what sky/premul/straight option is set for BI. For situations where you're just rendering through BI straight to disk with no compositor, and the system knows it's Premul, you may have a point. But afaics that's not how this option works - it's a bit misleading having this option in the shading panel, which is full of BI related properties, since this is something that happens at the end of blender's entire imaging pipeline. If you want to make things clearer, perhaps the option should be on the compositor output node itself, and when you're not using the compositor, rendering straight out of BI, it could just do the right thing automatically since it has all the information to make that decision itself. Much of a muchness really, though... ___ 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 [44256] trunk/blender: BMesh Merge
Congratulations for this milestone! Especially Geoff - it's been what, 4? 5? years in the making? :) On Sun, Feb 19, 2012 at 7:12 PM, Campbell Barton wrote: > this is the work of quite a few developers over the years. > > > Key Contributors > > > * Geoffrey Bantle (aka) Briggs, original author. > * Joe Eager (aka) joeedh > > More recently > * Howard Trickey > * Ender79 aka Ender79 :) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Render Layer Proposal
On Wed, Jan 18, 2012 at 5:24 AM, Ton Roosendaal wrote:
>
> Instead of explaining why you need it, or calling it "better" or "more
> useful", just write down a neutral and very precise specification of how it
> looks what you want? It seems to me you like some Openexr file version that's
> between the MultiLayer and the regular (RGBA+Z) exr file we have?
I think he's asking for an easy way to output render layers/passes to
individual files.
It's generally not good practice to include all layers/passes/outputs
etc in a single EXR file if you're going to comp with it. Due to how
EXR stores data, the entire file must be read before any data is
accessed, so reading RGBA channels will also need to wait for all
other exr layers as well, which slows things down in a compositor by a
factor of how many layers there are. In most comp pipelines
(especially on network storage), i/o is a significant bottleneck, so
single files are used to allow access on demand.
I agree blender's render layer/pass system could use some significant
improvements, this being just one of them. Hopefully with cycles, it
can move to more of a 'named output' type system rather than hard
coded as in blender internal. I made some notes on this topic in a
forum discussion previously - it's pasted below if anyone's
interested.
cheers
Matt
-
The terminology blender uses here is a bit non-standard. Where Blender
has render layers and render passes, other renderers have render
passes and outputs (AOVs - arbitrary output variables).
The way most renderers with programmable shading that I'm familiar
with work, is that within your shader (whether that be code or a node
tree or whatever), you can define any number of outputs in addition to
your main colour output. You can then send whatever data within your
shader network that you're interested in, to that output. For example
you could wire a raw texture colour straight to an output before it's
used for shading. Once you've defined outputs within your shader, then
in your scene you can add those named outputs to your render. So if
your shader defines an output named 'tex_colour', if you add an output
named 'tex_colour' to your scene to be rendered, it will generate that
additional image buffer at the same time as your beauty render. This
means that you have complete control over what the contents of your
AOVs will be, and at render time can choose which ones you are
interested in.
As for render passes (render layers in blender-speak), in blender
internal, these don't give you a lot of control - they're just mainly
for layer visibility with some additional things like overriding
materials. Other apps ('Takes' in Houdini, 'Render Passes' in XSI
afaik) do it differently, where you are given a blank slate to
override bits of data in your scene with whatever you want. This is a
bit like if you have a linked scene in blender, but can specifically
override certain properties. So in your render pass you could do the
same thing as blender - unlock and disable/enable renderability, or
for example if you want a shadow only pass you can unlock and turn off
certain lights and replace your shaders with a special shadow catcher
shader, or perhaps you could only show the contribution of certain
objects to GI, or whatever. The possibilities are endless, it's just a
simple way of rendering various versions of your scene via a kind of
'diff'.
These are pretty standard ways of achieving this sort of functionality
- it's a lot more flexible and practical than blender is currently,
and potentially simpler internally as well.
As for hooking such functionality up to external renderers, for AOVs,
there just needs to be a way to add any extra named image buffers to
the render result, rather than filling in the hard-coded
diff/refl/ao/blah blah that exists currently. This shouldn't be
terribly difficult to implement on the blender side. As for render
layers, there's not really much interaction between that and external
renderers at the moment - external renderers are free to re-use BI's
render layers interface, but doing things like iterating through
render layers, collating visible objects and sending them off to be
rendered, is all up to the exporter script. Alternatively it *might*
be possible for renderer addons to implement their own 'Poor Man's
Render Passes/Takes System' themselves, but it would be a lot better
if blender had a system for this internally that all renderers could
use.
___
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 [43428] trunk/blender: Carve booleans library integration
On Tue, Jan 17, 2012 at 6:44 AM, Campbell Barton wrote: > > IMHO its a weak solution unless there is some intent to maintain the > older (currently unmaintained) booleans code, or someone can show > examples where the older code consistently wins out. > After having used the old boolean modifier, I can't imagine the older code winning out on a quality level at all ;) The reason I mention this is not to promote the idea of having two options for people to actively choose from, but mainly for compatibility when loading up existing setups. If you're using booleans for simple modelling (eg. sphere + cube) then there's not really much difference and you can happily proceed. However, if you're using booleans as part of a more complex procedural setup - eg. followed by shrinkwrapping or array merging, or any other things that depend on topology, then if you load up your file and the topology output by the boolean modifier has changed, then it can break existing setups. This breakage could be obvious, or it could be the sort of thing you only notice at certain frames after it's been sent off for render. Either way, you have no way of fixing it by going back to the old backend that you have have created your procedural setup to work with/around. In pipelines using other apps that put a greater emphasis on procedural modelling, people generally avoid changing geometry modifying tools in-place (which can have unexpected results), but rather use versioning so that old setups remain identical. If you guys have the burden of maintaining the code, I understand your reluctance - in this case IMO it's a case of judging where the balance is between code maintenance effort vs likelihood of blender users getting screwed by procedural setups that involve the existing boolean modifier. Maybe you'll judge it's not that likely - it's your choice. Either way, I'm trying to bring up the point that it's not just about what is 'better', it's also how much potential disruption it can cause by forcing the change for all existing instances of the modifier. cheers Matt > On Tue, Jan 17, 2012 at 4:42 PM, Matt Ebb wrote: > > Sounds really good! > > > > One thing though - is the old code going to be kept around? If it is, it > > would be good to make the choice of backend optional in the UI, and > default > > old files to the old backend. If someone's tweaked the old modifier to > give > > acceptable results, it could potentially cause an existing setup to freak > > out when the new backend is used giving different output and topology. > > > > IMO better to 'deprecate' by making it optional for a while, than change > > behaviour in all existing files with no recourse. > > > > cheers > > > > > Matt > > > > > > On Mon, Jan 16, 2012 at 4:46 PM, Sergey Sharybin >wrote: > > > >> Revision: 43428 > >> > >> > http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=43428 > >> Author: nazgul > >> Date: 2012-01-16 16:46:00 + (Mon, 16 Jan 2012) > >> Log Message: > >> --- > >> Carve booleans library integration > >> == > >> > >> Merging Carve library integration project into the trunk. > >> > >> This commit switches Boolean modifier to another library which handles > >> mesh boolean operations in much stable and faster way, resolving old > >> well-known limitations of intern boolop library. > >> > >> Carve is integrating as alternative interface for boolop library and > >> which makes it totally transparent for blender sources to switch between > >> old-fashioned boolop and new Carve backends. > >> > >> Detailed changes in this commit: > >> > >> - Integrated needed subset of Carve library sources into extern/ > >> Added script for re-bundling it (currently works only if repo > >> was cloned by git-svn). > >> - Added BOP_CarveInterface for boolop library which can be used by > >> Boolean modifier. > >> - Carve backend is enabled by default, can be disabled by WITH_BF_CARVE > >> SCons option and WITH_CARVE CMake option. > >> - If Boost library is found in build environment it'll be used for > >> unordered collections. If Boost isn't found, it'll fallback to TR1 > >> implementation for GCC compilers. Boost is obligatory if MSVC is used. > >> > >> Tested on Linux 64bit and Windows 7 64bit. > >> > >> NOTE: behavior of flat objects was changed. E.g. Plane-Sphere now gives > >&g
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [43428] trunk/blender: Carve booleans library integration
Sounds really good! One thing though - is the old code going to be kept around? If it is, it would be good to make the choice of backend optional in the UI, and default old files to the old backend. If someone's tweaked the old modifier to give acceptable results, it could potentially cause an existing setup to freak out when the new backend is used giving different output and topology. IMO better to 'deprecate' by making it optional for a while, than change behaviour in all existing files with no recourse. cheers Matt On Mon, Jan 16, 2012 at 4:46 PM, Sergey Sharybin wrote: > Revision: 43428 > > http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=43428 > Author: nazgul > Date: 2012-01-16 16:46:00 + (Mon, 16 Jan 2012) > Log Message: > --- > Carve booleans library integration > == > > Merging Carve library integration project into the trunk. > > This commit switches Boolean modifier to another library which handles > mesh boolean operations in much stable and faster way, resolving old > well-known limitations of intern boolop library. > > Carve is integrating as alternative interface for boolop library and > which makes it totally transparent for blender sources to switch between > old-fashioned boolop and new Carve backends. > > Detailed changes in this commit: > > - Integrated needed subset of Carve library sources into extern/ > Added script for re-bundling it (currently works only if repo > was cloned by git-svn). > - Added BOP_CarveInterface for boolop library which can be used by > Boolean modifier. > - Carve backend is enabled by default, can be disabled by WITH_BF_CARVE > SCons option and WITH_CARVE CMake option. > - If Boost library is found in build environment it'll be used for > unordered collections. If Boost isn't found, it'll fallback to TR1 > implementation for GCC compilers. Boost is obligatory if MSVC is used. > > Tested on Linux 64bit and Windows 7 64bit. > > NOTE: behavior of flat objects was changed. E.g. Plane-Sphere now gives > plane with circle hole, not plane with semisphere. Don't think > it's really issue because it's not actually defined behavior in > such situations and both of ways might be useful. Since it's > only known "regression" think it's OK to deal with it. > > Details are there > http://wiki.blender.org/index.php/User:Nazg-gul/CarveBooleans > > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Updated BMesh Merge Proposal
On Mon, Jan 2, 2012 at 9:04 PM, Campbell Barton wrote: > > I think this is enough - we could disable loading the file at all and > then blender wont crash - or only allow loading when --debug is passed > for people who know what there doing. not sure its worthwhile - > people are warned and they can upgrade there blender. > I think it's very worthwhile for blender to not crash if it can be avoided - preventing the file from loading is a much better scenario than crashing and losing everything. Particularly when there still isn't a warning yet to save changes in your existing file, when opening up a new one. cheers Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Node API
Sounds excellent, Lukas. On Thu, Dec 29, 2011 at 9:09 PM, Lukas Tönne wrote: > > The Cycles render engine already uses C++ node class definitions, > generated from the internal RNA information, to convert node data from > the editor into the internal shader graph. At this point, however, the > node types are still all defined as part of the blender core code, > instead of being generated as part of the Cycles external system. It > would be good to have a way of registering node implementations from > C/C++ the way we can do in bpy. > While there will probably need to be something like this for BI nodes, perhaps as an alternative for C++ support, the cycles nodes could just be converted to python defined? I don't know if the cycles nodes actually do anything in blender, I presume they're just inspected and the graph exported to a cycles representation. Defining them in python would be better off for the render API in general, since it would be using the same interfaces as other external renderers. I realise that cycles has already left that behind with its in-source access, but imo the more it can be kept as 'official, but just another external renderer' sharing the same public APIs, the less chance there is of returning to the bad old days where blender internal was the only game in town. cheers Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Depsgraph proposal
On Fri, Dec 23, 2011 at 7:49 PM, Nathan Vegdahl wrote: > let's at least not pretend that "detect cycle + call x > times" is a real solution to granularity issues. Blender will still > have a granularity issues with it's dependencies, it will just be > pushed x levels down (at a performance cost of x). When the idea of a 'depgraph project' was first announced, I thought that this was exactly what was going to be tackled. IMO lack of granularity is the single greatest problem with blender's dependency system as it stands - much more important than things like lack of threading. It's not just a problem for character animation, but has far-reaching consequences for the rest of blender too (eg. bad physics behaviour, dodgy 'collision modifiers' etc). I realise it's probably a very difficult problem to solve internally, but I wonder if it's really worthwhile to be spending the resources on a redesign here if this issue isn't seriously addressed. For some of these other non-character animation problems where data needs to be depended on and accessed at different points in the evaluation chain, not just after final evaluation, I'm not sure they even can be solved by re-cycling several times (correct me if i'm wrong!), since what's needed for these tasks is access to and control over how data is transferred and evaluated through the system. These limitations also cause roadblocks for further tools from being developed such as node based modifiers, better physics systems like node based particles, node based animation/contraints. In modern cg and fx, animation is not just objects or bones moving around any more, it's complex procedural geometry creation and animation, scripted variable expressions and relationships, data flow connecting separate systems like physics solvers. I really think if this depgraph project is intended to set blender up for the future, it needs to do more to acknowledge and prepare for these sorts of functionality, even if it's not possible to implement them all right now. cheers Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Color space and alpha issues
On Mon, Dec 19, 2011 at 8:03 PM, François T. wrote: > > As usual I'm more for the teaching rather the hiding :) > As Matt said, only comp expert are going to want to mess with this anyway > (I'm even sure some expert will bypass it in some cases). But people who > wants to get serious about it will have to learn it no matter what with any > application out there > I don't think hiding anything's a good idea, on the contrary I think it needs to be more explicit, but above all it should work correctly by default for simple scenarios. I agree its better for peoples own sake that they learn this stuff for more advanced usage, but it shouldn't be a requirement in order to get blender to do simple things correctly. I think probably a nuke style solution with premul default but options on each node to un-premul/premul before and after its operation would be a good way to go. This could mean that a) It could be switched on by default for nodes that need it, so a simple setup throwing down a file in and a colour correction node will just do the right thing b) hopefully if individual nodes had these sorts of controls, if you want to keep your input unassociated, troublesome nodes like defocus and vector blur could infer this and take it into account, hopefully not mangling your data so much if you want to keep it around. c) you could of course turn all these options off and do it all explicitly if you want too. cheers Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Color space and alpha issues
Here's a few more thoughts: I agree that in terms of data storage for final imagery, premultiplied can be more flexible - eg. representing transparent, but emissive colours, which can potentially be useful for things like emissive volumetric elements. Personally I haven't run up against too many use cases for this myself, it's hard to know how big of an issue this is. It's also potentially possible to do this kind of thing with extra AOVs too... That infamous Adobe thread has interesting background info in there, but I think it's a little bit of a red herring for this issue in Blender - it's more focused on specific behaviour that Photoshop has when loading EXRs, rather than the merits of premultiplied vs unassociated alpha. There are alternative EXR plugins for Photoshop that work better, keep the alpha channel separate from colour info as an additional channel or layer mask rather than trashing RGB info where alpha is 0. >From my own personal experience in recent versions of Blender's compositor, premultiplication is a real pain in the butt. It makes it very difficult to do things to the colour independently, like colour corrections, filtering, or manipulating the alpha channel independently with blurs, erosions, etc. Several of the nodes like defocus and vector blur seem to require premultiplied input and it's very frustrating to have any colour information that may have been masked away, thrown away out of necessity. Trying to work around this leads to more complexity and dodgy behaviour. The issue with compositing is that the image buffers are not just used for final storage and distribution, but they're used as a work-in-progress scratch pad, and it's often that the way you work with channels doesn't always represent something logical (eg. keeping masked out RGB pixels around so you can retrieve them later). The advice I got from the comp lead on my previous project was that his recommended convention for working in Nuke with premultiplied inputs was always to manually un-premult before any colour/filtering operations and premult back again at the end of that chain before over-ing with other imagery. Most nodes in Nuke have options on them to automatically premult and un-premult before and after that node's operation, which is handy, though if you've got a few corrections in sequence it makes more sense to just do it once at the start and end of that particular chain. This is bearable, though a bit cumbersome and sometimes easy to forget since sometimes the effects of this are more subtle and don't leap out as being obviously bad, even if they are incorrect. And I don't think this recommended convention was always adhered to (people not being aware of this/new starters/communication difficulties/etc) - I remember opening up comps from other artists in various departments who weren't doing this. With this in mind, at least for the compositor, I'm sympathetic to the idea of making the correct behaviour the simplest, and default, especially in Blender when there is probably a smaller proportion of imaging experts who understand this well in the userbase. cheers Matt (PS. I really recommend dropping the term 'key alpha'! That word has way too much confusing/conflicting usage already, especially in blender) On Mon, Dec 19, 2011 at 8:41 AM, Brecht Van Lommel < brechtvanlom...@pandora.be> wrote: > Hi, > > You also linked to this post here, which makes a point that I didn't > fully get yet: > > http://groups.google.com/group/ocio-dev/browse_thread/thread/65e84a85416a8637/962ea485d1a210a3?lnk=gst&q=thoughts+on+alpha#962ea485d1a210a3 > > There is actually no right way to do color space conversion on images > with alpha, it depends on the background that they were or will be > composited over. For color correction operations it's similar, to make > it behave like painting applications it should work on key alpha, but > this isn't necessarily "right". > > So perhaps there's still toggles needed to control if these operations > should happen on premul/key alpha (for image load/save, and for color > correction nodes). > > Brecht. > > On Sun, Dec 18, 2011 at 8:28 PM, Troy Sobotka > wrote: > > I thought I'd add the "infamous" thread over at Adobe here regarding > > associated versus unassociated alpha in the context of a system that > > needs to support various formats. > > > > In this case, for those unfamiliar, this was the thread in which Adobe > > responded to their (mis) handling of the EXR format. > > > > The players here are: > > > > Zap Andersson - seasoned image professional now with Autodesk. > > Florian Kainz - architect of the EXR specification. > > Chris Cox - veteran architect at Adobe. > > > > http://forums.adobe.com/thread/369637 > > > > TL;DR version: > > > > Unassociated alpha systems cannot adequately deal with the inherent > > specifics of associated alpha systems. > > > > I've also added a "Further Reading" section to Brecht's page. > > > > Hope someone finds it insightful, > > T
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [41508] trunk/blender/source/blender/ editors/interface/interface_handlers.c: Enabled ndof devices for controlling colour wheel an
Hi,
As far as I'm aware there's currently no way to customise built in UI
handlers like this one. For this one in particular, I really don't think
it's a problem, it's very simple. But I'm guessing this response comes from
frustration with the ndof 3D View navigation, and if so I agree with you, I
don't find it usable at the moment. On a quick glance that's an operator so
it might be possible to do that with a modal keymap. I'll be away for a
little while but I can possibly take a look at that if I have free time
when I return.
cheers
Matt
On Fri, Nov 4, 2011 at 2:38 PM, Daniel Salazar - 3Developer.com <
zan...@gmail.com> wrote:
> It's not a matter of sensitivity, what happens is everyone has a different
> way to use the device: tilt vs pan vs roll vs inverted axis. Currently
> everyone just adds what ever they feel it's best but why can't this be
> configurable like keymaps are?
>
> Daniel Salazar
> 3Developer.com
>
>
> On Thu, Nov 3, 2011 at 9:30 PM, Campbell Barton >wrote:
>
> > Do you mean configure sensitivity or disable options like this?
> >
> > On Fri, Nov 4, 2011 at 1:41 PM, Daniel Salazar - 3Developer.com
> > wrote:
> > > Gah all this seriously needs to be configurable, what a mess if
> everyone
> > > just ads their own preferences
> > >
> > > Daniel Salazar
> > > 3Developer.com
> > >
> > >
> > > On Thu, Nov 3, 2011 at 8:31 PM, Matt Ebb wrote:
> > >
> > >> Revision: 41508
> > >>
> > >>
> >
> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=41508
> > >> Author: broken
> > >> Date: 2011-11-04 02:31:00 + (Fri, 04 Nov 2011)
> > >> Log Message:
> > >> ---
> > >> Enabled ndof devices for controlling colour wheel and cube UI controls
> > >> (eg. colour pickers). Tilting the ndof device up and down and rolling
> it
> > >> left and
> > >> right will move the 'colour cursor' in screen x and y, and twisting
> the
> > >> ndof device
> > >> will rotate the cursor around the colour wheel (hue). Now you can turn
> > off
> > >> the
> > >> lights and pretend you have a fancy DI deck!
> > >>
> > >> Modified Paths:
> > >> --
> > >>trunk/blender/source/blender/editors/interface/interface_handlers.c
> > >>
> > >> Modified:
> > >> trunk/blender/source/blender/editors/interface/interface_handlers.c
> > >> ===
> > >> ---
> trunk/blender/source/blender/editors/interface/interface_handlers.c
> > >> 2011-11-04 01:15:04 UTC (rev 41507)
> > >> +++
> trunk/blender/source/blender/editors/interface/interface_handlers.c
> > >> 2011-11-04 02:31:00 UTC (rev 41508)
> > >> @@ -3216,6 +3216,63 @@
> > >>return changed;
> > >> }
> > >>
> > >> +static void ui_ndofedit_but_HSVCUBE(uiBut *but, uiHandleButtonData
> > *data,
> > >> wmNDOFMotionData *ndof, int shift)
> > >> +{
> > >> + float *hsv= ui_block_hsv_get(but->block);
> > >> + float rgb[3];
> > >> + float sensitivity = (shift?0.15:0.3) * ndof->dt;
> > >> +
> > >> + int color_profile = but->block->color_profile;
> > >> +
> > >> + if (but->rnaprop) {
> > >> + if (RNA_property_subtype(but->rnaprop) ==
> > PROP_COLOR_GAMMA)
> > >> + color_profile = BLI_PR_NONE;
> > >> + }
> > >> +
> > >> + ui_get_but_vectorf(but, rgb);
> > >> + rgb_to_hsv_compat(rgb[0], rgb[1], rgb[2], hsv, hsv+1, hsv+2);
> > >> +
> > >> + switch((int)but->a1) {
> > >> + case UI_GRAD_SV:
> > >> + hsv[2] += ndof->ry * sensitivity;
> > >> + hsv[1] += ndof->rx * sensitivity;
> > >> + break;
> > >> + case UI_GRAD_HV:
> > >> + hsv[0] += ndof->ry * sensitivity;
> > >> + hsv[2] += ndof->rx * sensitivity;
> > >> + break;
> > >> + case UI_GRAD_HS:
> > >> + hsv[0] += ndof->ry * sensitivity;
> > >> +
Re: [Bf-committers] UI changes from cycles branch
On Tue, Oct 25, 2011 at 4:07 AM, Brecht Van Lommel < brechtvanlom...@pandora.be> wrote: > Hi, > > Panel headers a bit darker now and increased button embossing: > > Before: http://www.pasteall.org/pic/show.php?id=19452 > Latest: http://www.pasteall.org/pic/show.php?id=19501 > This is certainly an improvement on the first proposal > I also like the icons to be a bit more muted, again to avoid them > grabbing attention too much with highlights. For me this is what > really finishes it off, to make the interface nice calm, but maybe > this is considered too dull. > -1. Firstly I don't see the necessity of this - I think the current icons are excellent and strike a good balance between quick wayfinding and visual noise. But even assmung its needed, this still is not a good way to go about it. If you want duller icons, they need to be designed that way with a different colour scheme and design requirements that takes this into consideration. Doing an overall alpha blend is pretty heavy handed and disregards the intention of the designer. Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposal: Rename "blenderbuttons"
On Thu, Oct 27, 2011 at 12:38 PM, Joshua Leung wrote: > Hi all, > > I'm planning on renaming the "blenderbuttons" datafile to > "blenderbuttons.png" (i.e. giving it a proper extension). This should > make it easier to edit and/or view this file using standard image > editing tools without having to save off a copy first. > If you're going to do that, why not make it something a bit more self-explanatory, like blender_icons.png cheers Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] UI changes from cycles branch
On Mon, Oct 24, 2011 at 10:21 AM, Brecht Van Lommel < brechtvanlom...@pandora.be> wrote: > Hi all, > > Here's a patch with a subset of the UI changes in the cycles branch > that I'd like to merge into trunk. Are there any objections to this? > I'd personally like to hear the rationale for these rather than just saying here's the patch. Some of it seems a bit more like a matter of taste too, rather than something that's designed for a wide audience, so I'm curious to hear the reasoning. > I don't think they would need any documentation updates, it's just > small things that wouldn't confuse anyone in screenshot: > * Remove emboss on areas and regions > * Remove button emboss > * More subtle colors and gradients on buttons > Most of these I don't think it would be a problem to make the embossing a bit more subtle, but I'm not keen on removing it all entirely. Even just a subtle hint of shape and shading really helps to distinguish the buttons from everything else - not just in the literal sense of give it an affordance 'this is a button, you can click on it' but mainly for some visual difference between the rest of everything else on screen. When everything is flat with single pixel outlines (not just buttons, but also other dividers, grids, scrollers, lines in other editors like the animation/timeline editors), it loses a sense of visual hierarchy and rhythm - it all tends to merge into one soup of lines and flat shaded areas, and makes it harder to find things quickly in the UI. > * Black arrows on menu button > -1, Way too low contrast, there's almost no point in having them there. Makes them look like other dark UI widgets like radio buttons, which is not good. > * Panel header changed look & smaller > Seems ok, but I would give it an extra pixel or so of padding both above and below, it's quite cramped and loses its sense of importance in wayfinding (becomes much more like just another button). > * Screen splitting widgets look > Not a fan of how it is now, but perhaps if it was the dark triangle with a hint of the 'gripper' lines blended on top it would work better. > * Toolbar/properties expand button look > Looks great > I'd still like to change the font in trunk, but it seems hard to get > an agreement on this. Some tests: > Again, I'd like to hear the rationale - I think the font in trunk right now is very good. If it's to make things smaller and more condensed, be wary of cutting off one's nose to spite one's face - you *need* whitespace in design, it's not just wasted areas where more can be crammed in. cheers Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [41124] trunk/blender/source/blender/imbuf /intern/openexr/openexr_api.cpp: #fix: Saving OpenEXR images as floats ignores color pr
2011/10/20 Αντώνης Ρυακιωτάκης > Generated images from within blender(by pressing new float image in > image editor) are in sRGB space. The incorrect behaviour prior to this > commit can be seen by making a new float image, painting on it, saving > as exr and reloading. The colors will differ. > Well, that's not good behaviour, and should be fixed itself. If you're painting on a float image, it should be linear, and gamma corrected at display time. Introducing different colour profiles in float images is adding in a new layer of complexity when this system needs *less* weird conditions and checks :) Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [41124] trunk/blender/source/blender/imbuf /intern/openexr/openexr_api.cpp: #fix: Saving OpenEXR images as floats ignores color pr
On Thu, Oct 20, 2011 at 10:04 AM, Antony Riakiotakis wrote: > Revision: 41124 > > http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=41124 > Author: psy-fi > Date: 2011-10-19 23:04:48 + (Wed, 19 Oct 2011) > Log Message: > --- > #fix: Saving OpenEXR images as floats ignores color profile. This was not > noticable in renderer because it works in linear color space. Painting on > the image editor, saving and reloading was problematic though. > What's this about? Float images in blender should *always* be linear. If they're not, there's a bug elsewhere which got them in that situation. cheers Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] node ior
It's been like that for years, same with the transmission settings as well. Last time I tried, there were other problems using refracting materials in node trees too - it doesn't really work properly and is better to just avoid avoid node materials for this purpose (or use another renderer :). On Sat, Oct 15, 2011 at 4:09 PM, Daniel Salazar - 3Developer.com < zan...@gmail.com> wrote: > gah, got a bit of a problem here, afaik the nodetree gets the IOR for > the entire material from what ever node it decides. So i'm having to > set the same ior for all the shaders in a nodetree which is by itself > annoying, however it get's worst when certain materials are shared > with other nodetrees where I wan't other IOR values. Since blender > doesn't support mixing multiple IOR materials I guess we need to move > IOR to the Render Pipeline Options panel and make ir a nodetree > option? > > cheers > > Daniel Salazar > 3Developer.com > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Tweak to default material
-1 As I mentioned to Daniel in chat, subjective ideas of what 'looks good' or not don't really belong in defaults (fwiw i've only had this enabled <5% of the time when rendering in blender). Defaults should err on the side of simplicity and being as correct as posisble. Of course, being able to set your own personal defaults for any newly created properties would be very handy. Matt On Thu, Oct 13, 2011 at 1:11 PM, Daniel Salazar - 3Developer.com < zan...@gmail.com> wrote: > Hi, I'd like to make cubic interpolation on by default for new > materials since it make's them always look "better". Is that ok? Don't > come up with "it's not physically correct" because I'll have a laugh > :) > > Daniel Salazar > 3Developer.com > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] obj location & matrix
Oh, my mistake - I've actually completely misunderstood your original question (serves me right for replying without coffee..) To get a new matrix, you might need to update the depgraph via scene.update() etc. after you've modified the object's position. cheers Matt On Fri, Sep 30, 2011 at 9:26 AM, François T. wrote: > oups sorry didn't even know about it. I'll subscribe to it then. > just one thing though, so this is updated only if the user moved the object > himself, but not if we change position via py script ? that's what you are > saying ? > > thx > > 2011/9/29 Matt Ebb > > > On Fri, Sep 30, 2011 at 8:02 AM, François T. > >wrote: > > > > > > > > > empty_tmp.matrix_world.to_translation().x > > > > > > > afaik, matrix.to_translation() returns a vector copy of the translation > > component. It's not modifying the values in the original matrix. > > > > btw, bf-python mailing list is better for this :) > > > > matt > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > http://lists.blender.org/mailman/listinfo/bf-committers > > > > > > -- > > François Tarlier > www.francois-tarlier.com > www.linkedin.com/in/francoistarlier > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] obj location & matrix
On Fri, Sep 30, 2011 at 8:02 AM, François T. wrote: > > > empty_tmp.matrix_world.to_translation().x > afaik, matrix.to_translation() returns a vector copy of the translation component. It's not modifying the values in the original matrix. btw, bf-python mailing list is better for this :) matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [40677] trunk/blender/source/blender/ editors/animation/anim_filter.c: Reverting part of r.40659
On Thu, Sep 29, 2011 at 9:43 AM, Joshua Leung wrote: > Reverting part of r.40659 > > The output of an automated tool is not a valid excuse for clobbering > code to increase maintenance headaches later on. > It might be a good idea to reiterate for new developers: Please avoid committing in other peoples' code without the permission or understanding of the module owner. There have been a couple of occasions in the last week or so where people have done seemingly innocuous fixes in other code which have ended up causing problems or bugs. If you've found something which you think should be fixed and it's not 100% urgent (like its breaking compilation), just ask the owner of the code first, or make a patch. Just because you have access to commit everywhere in blender doesn't make it always a good idea :) cheers Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] blender font is unclear
On Wed, Sep 21, 2011 at 11:59 AM, Yousef Hurfoush wrote: > The changed font is unclear & harder to read, i think at least for me, are > there any others? > a sample of now & before : > http://www.pasteall.org/pic/show.php?id=18226 > +1, at least for English I think the previous font is much easier to read. There's a bit more tracking to prevent the letters smooshing into each other so much, the shapes are clearer since it's not condensed, and at least anecdotally seems to anti-alias better too, at least on my mac. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Wiki upgrade 2011
Seems like a good improvement! It would be nice though if the colour
scheme/design were more consistent with the rest of the Blender website
though - right now it seems like a completely separate site, when it should
feel more like it belongs to the rest of Blender and is part of the official
website.
cheers
Matt
On Tue, Sep 20, 2011 at 10:50 AM, mindrones wrote:
> Hi!
>
> Finally, the Blender wiki has been upgraded, and has now:
>
> * a new navigation system
> * a new search engine
> * a new skin, codenamed Naiad.
>
> For more information about the facts and about the people involved,
> please have a read at the project page at:
>
> http://wiki.blender.org/index.php/Meta:Upgrades/2011
>
> Some information about the new skin and a feature video are available at
> http://wiki.blender.org/index.php/Meta:Skins/Naiad
>
> If you are registered in the Blender Wiki and you can't see the new
> skin, please check your preferences ("Appearance" tab) and choose the
> skin called "Naiad".
>
> Also, please report any wiki bug using the menu at the bottom on the
> right. Any feedback is more than welcome! :)
>
> It's been though, but we're proud :)
>
> We hope that Blender wiki readers will find the wiki experience more
> pleasant and enjoyable now!
>
>
> Regards,
> Luca
>
>
> _
>
> http://www.mindrones.com
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender developer IRC meeting notes, September 4, 2011
On Mon, Sep 5, 2011 at 2:14 AM, Ton Roosendaal wrote: > > - Ocean sim branch: Matt Ebb noticed pending todos here, he advised to > wait with it. > Hi, I've fixed those in the latest patch I sent to Todd - if he can upload that, it should be good to be reviewed now I think. cheers, Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Guidelines for developer logs, docs & blogs
On Thu, Sep 1, 2011 at 7:55 PM, Ton Roosendaal wrote: > Hi Matt, > > Benjamin's response is correct. It's firstmost just "best practice". > > And you know me, I'm very much not paranoid. My guideline advice comes > from a careful review of our present situation with some lawyers > (including softwarefreedom.org). I contacted them based on actual > (potential) legal issues we might get in. Fortunately there's no > 'competitor' who started public legal actions yet, but you can be sure > they're looking at Blender closely. > Yeah, I wasn't having a go - more like saying "it feels stupid to me, but it may well be a necessary stupidity because there are other stupid people out there". Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Guidelines for developer logs, docs & blogs
I believe the idea is: "don't mention other applications or they might accuse you of stealing ideas from them". i.e. as far as I know, it's better to infringe on a patent by accident than it is to do it knowingly, so try to avoid making it seem like you know of other similar functionality in other apps. To me this seems a bit paranoid, but I think that interpretation is the intent of Ton's advice. cheers Matt On Thu, Sep 1, 2011 at 10:19 AM, Bogomir Bogomirov wrote: > Hi Douglas, > > As much as I am aware of the state of these matters, the example you have > provided isn't bad, just inappropriately written. Since Photoshop® is a > trademark of Adobe Systems Incorporated, their respective guidelines (ref. > http://www.adobe.com/misc/trade.html) state the correct way of identifying > the specific software should be: > > "[...] using Adobe® Photoshop® software to edit 2d textures. [...]" > > where this applies to its first and most prominent mention. For further > details, please review the URL I have provided above. > > In fact I really doubt any company (or organization) would discourage the > public use of their trademarks, brand names and taglines, since mentioning > them brings attention to the relevant products (and therefore advertises > them for free). Using such IPs in public posts however should be done right, > and a careful read of the various EULAs and trademark guidelines will keep > you safe (as much as boring and trivial as it might sound). > > Maybe this is what Ton had in mind, calling for extra attention when > starting this thread. > > > Regards, > > Bogomir Bogomirov > http://bogomirov.org > > > > -Original Message- > From: bf-committers-boun...@blender.org [mailto: > bf-committers-boun...@blender.org] On Behalf Of Knapp > Sent: Wednesday, August 31, 2011 3:56 PM > To: bf-blender developers > Subject: Re: [Bf-committers] Guidelines for developer logs, docs & blogs > > > - Stay away from mentioning commercial packages in user/tech docs ever. > > - Document work in ways it shows the design process and ideas you > > explored > > As an example say I just make a tutorial on youtube under xomagick and > said something about using photoshop to edit 2d textures. Is that bad? > I can stick to saying gimp from now on. Or is this not what you had in > mind? > > -- > Douglas E Knapp > > Creative Commons Film Group, Helping people make open source movies > with open source software! > http://douglas.bespin.org/CommonsFilmGroup/phpBB3/index.php > > Massage in Gelsenkirchen-Buer: > http://douglas.bespin.org/tcm/ztab1.htm > Please link to me and trade links with me! > > Open Source Sci-Fi mmoRPG Game project. > http://sf-journey-creations.wikispot.org/Front_Page > http://code.google.com/p/perspectiveproject/ > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Compositor nodes-rerouting
Nice! Not too keen on how the wires get 'pinched' though, I can imagine that getting annoying. It would probably be better if it tried to keep the beziers tangent and smooth between the incoming and outgoing wires. I think the points themselves (and the arrows) are too big, but that's easy to change. Also would be good to have the 'selected node wire highlight' follow all the way from node to node, not just stopping when it hits the reroute point. Another note, better to test this, get sizes right etc with lots of nodes and zoomed right out. No production scenes have just 4 nodes in them, there will be several, and you need to zoom out ot see them all, so it would be good to know if it's awkward when used in that context or not. In response to Daniel, I think a modifier key is ok, it depends what other future candidates there could be for a modifier-less click/drag on a wire itself (eg. dragging on a wire to pull it out of a socket and/or plugging into a new one) Matt On Wed, Aug 31, 2011 at 5:49 PM, j.bak...@atmind.nl wrote: > Hi all, > > I want to discuss this proposal. Many people have requested it, but I want > to be sure if it is satisfying, or that there are other things that can be > introduced. > > I have limited the proposal to the Compositor tree, but it could be done > for other tree's. > > = Proposal = > > This proposal is a UI enhancement on the node editor to allow better > workflow with large node systems. > > Noodle line > > By using MouseClick-SHIFT on a noodle a point will appear. The user can > positioned this point (Reroute point). > This point can attach noodles at North, South, East, West > An arrow will be drawn on noodles between two reroute points > If noodles reach a certain length, an arrow will be drawn. This way users > can see the direction of the line. > Every point can have multiple outputs. Eg you can add multiple points this > way if you can connect the Combined socket of the renderlayer to other > nodes in a structured way. > > Current patch is limited to the compositor node tree. > > http://www.youtube.com/watch?v=l_gyLt-TAzk > http://projects.blender.org/tracker/index.php?func=detail&aid=28443 > > > = Impact = > > DNA > > There is a new NODE_FLAG and SOCK_FLAG called NODE_REROUTE and > SOCK_REROUTE. telling the UI that it need to draw differently. > > UI > The point is a special node, "RerouteNode". All nodetree will have one. it > will be in a new submenu named "Helper" in the add node menu. This sub-menu > will not be visible on screen. > > === Operators === > > a new operation will be added where the user can click on a line holding a > certain key and this will add a RoutingNode in that position. > > === drawnode.c === > > For the RoutingNode a new function is introduced to draw the node. > When drawing bNodeLink that is connected to a routingnode a different > algorithm will be used for drawing the bezier. > > If the distance traveled on the x-axis is longer than the y-axis the link > will be connected to the east or west of the node. If the y-axis is longer > it will be the north of south. > > When it is connected to the north of source, the bezier will be adjusted to > draw it correctly. > > When a line will be between two reroute nodes, an arrow will be draw on the > line. This way the user know where the line is heading to. > > nodes/???_ > > All node types will get a RerouteNode. currently only the compositor will > get one. > A rerouting node contains one input socket and one output socket and uses > pass buffer to pass the data to the next node > > > mail2web - Check your email from the web at > http://link.mail2web.com/mail2web > > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender Release Cycle
On Wed, Aug 17, 2011 at 3:06 PM, Campbell Barton wrote: > > Here are some suggestions > *disclaimer that this is colored by my own experience & preferences, I > may be overlooking some issues* > +1 ! Here are some more ideas of mine: 4) Improve testing on branches (continued) The problem with branches is that not many people use them, everyone just wants to use trunk, because that's where the action is. At least from my perception, most of the time when people do use branches, its just to see some new feature, poke at it a bit, then leave it alone - not really pushing it to the limit in real work. A solution for this could be to make trunk the 'boring' branch with mostly just bug fixes etc, and have a development branch which people can merge their own branches into for testing (like the gsoc salad branch). Another idea that Ton had many years ago which I still like is for coders to find an artist 'buddy' to help them throughout the development process, someone with whom the developer can work with closely for feedback and testing. A good portfolio of work done with a branch can go a long way to vouch for its readiness for inclusion into trunk. 5) All new features are developed in branches For all substantial new features everyone must use branches - core devs and module owners included. Module owners are capable of committing weird/bad/unreliable/poorly tested code, just like anyone else, and this code should be tested in quarantine as well. 6) Documentation Ton says this every year or so, but anyway again - before review/merge into trunk, a new feature should have at least a minimal form of user documentation, and some brief code/design documentation. Shouldn't have to be too comprehensive, but should at least help reviewers/module owners/etc understand the code they're reviewing, or find any design flaws up front. 7) Enforcement Technically there are policies like these already in place (eg. should have documentation) but they're never/rarely enforced. Most of the time now, if people commit weird/bad/undocumented/untested stuff to svn everybody just shrugs their shoulders and moves on. These will only work if project admins and committers agree to call each other out on these points and also accept it when they have to abide by them. So if something is checked into trunk without going through a branch, or without proper documentation, or without enough testing, it must get reverted out of trunk. There can't be a stigma or fear of hurting people's egos here, it's just a matter of doing what's right for the project. And ideally with a short release cycle, it's not the end of the world if your code doesn't make it in to a release anyway, since the next release is just around the corner. Anyway, I really do think this is a serious issue - the last couple of years show that pretty well, and there's the potential for it to get a lot worse as blender gets more and more complicated, and takes on new scope. In the end, limiting the addition of code that's not up to scratch results in more, better features, as less core dev time and resources are spent on bugs, and more on the cool stuff! cheers Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender Release Cycle
On Tue, Aug 16, 2011 at 2:55 PM, Campbell Barton wrote: > > With time based releases only consider show-stoppers as new bugs which > were introduced since the last release or anything that makes blender > unstable for common use. > For what it's worth, I really like the idea of time-based releases, but there's a big caveat which I think hasn't been properly solved yet. The whole idea is based on keeping trunk stable (i.e. not allowing it to go into long periods of instability while coders work on things heavily in situ), and to use branches for work-in-progress stuff and merge them into trunk when they're properly ready and won't disturb trunk. This is great in concept, but it's also this part that is the problem here. Time and time again, branches aren't tested well enough before merging. I've seen it so many times over the last several years - features getting added without having major bugs found by testers, dodgy code getting added without a proper code review or oversight from other committers, and when these things happen, the code tends to stick around. (I'm sure I'm not blameless in the past here myself, either). For the last couple of releases it wasn't so bad since there weren't any major new features (but even then there are still plenty of bugs), but I'm a bit concerned about what will happen especially now the kids on the internet are getting all excited about opening the floodgates of new code for 2.6, which probably hasn't had nearly enough testing/review either. I think for this to work, project admins will need to be much stricter about what is acceptable to go into trunk. If there are still signs of problems in a newly merged bit of code when coming up to release time, it needs to be ruthlessly pulled out before release (in order for the developer to work on it some more before the next cycle), and not just allowed to slip through. I think if the last year or two of blender development has shown anything, it's that quality control is a huge issue, and that blender needs *quality code* much more than it needs *more code*. It's quite an inefficient use of resources when the more experienced and skilled blender developers (the ones on the BF payroll) are spending their time bogged down fixing silly bugs. At least when I was doing it, I found it rather demotivating too. So I think this shorter release cycle can be an improvement, but if and only if it's taken as an opportunity to be stricter about the inclusion of insufficiently tested/poorly written code. If not, it'll probably make things much worse. cheers Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [39084] trunk/blender: KEYMAP REFACTORING
On Sat, Aug 6, 2011 at 6:45 AM, Brecht Van Lommel < brechtvanlom...@pandora.be> wrote: > Revision: 39084 > > http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=39084 > Author: blendix > Date: 2011-08-05 20:45:26 + (Fri, 05 Aug 2011) > Log Message: > --- > KEYMAP REFACTORING > Sounds excellent - thanks, brecht! ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Exposing Tool Settings - issue with 2.5x
On Fri, Aug 5, 2011 at 3:20 PM, Campbell Barton wrote: > > Yep, but there is still a conflict here in how settings are exposed, > should the operator be synchronizing between scene->toolsettings and > operator options at all? > > Its error prone - if a python script for example runs a bunch of > operators it can adjust the scene->toolsettings used when they next > run live unwrap. > > once we add last-used settings. should this be used rather then > initializing the options from the tool settings? > Yes - as far as I'm aware the only reason toolsettings is used at the moment is for this purpose - to store the most recently used settings for particular tools. Ideally this sort of functionality should be enabled for all operators. For all I know the scene->toolsettings is just there still as a stopgap measure from 2.4 for this sort of purpose, it would be better to replace it entirely. > This option is internally (scene->toolsettings->uvcalc_flag & > UVCALC_TRANSFORM_CORRECT), the idea is to be able to do other > transformations and have the UV's be corrected - just transforming a > vertex loop could work too for example. > This option is meant to work more like mesh mirror, where multiple > tools use it. > Could it not be a per-operator property? It would be more consistent with other tools that way, and a bit more controllable. Also if settings are stored if its something you like to use it only needs to be switched on once... matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Exposing Tool Settings - issue with 2.5x
On Fri, Aug 5, 2011 at 2:53 PM, Campbell Barton wrote: > > Unwrap can have a settings menu which can be in both. > * Image Space -> UVs -> Live Unwrap Settings (toggle under live unwrap > option) > Sure, because it's a thing that's 'built in' to the UV editor, not an operator > * 3D View Space -> UV Mapping Menu -> UV Unwrap Settings (toggle under Unwrap) --- *this one is a bit awkward IMHO* > I don't understand this - the UV unwrap *operator* has its properties in the operator properties area, like any other operator. It shouldn't be in a menu > Edge Slide UV options > * 3D View Space -> Mesh -> Edges -> Edge Slide UV Correct (toggle > under Edge Slide) > ... will go in Ctrl+E menu too - same menu in this case. > Uh? why not in the edge slide operator properties area? ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Exposing Tool Settings - issue with 2.5x
On Fri, Aug 5, 2011 at 2:13 PM, Campbell Barton wrote: > 3) Operator Options - don't mean regular operator options, rather > operator options that store the settings used in the > scene->toolsettings, for re-use. This is how LSCM Unwrap options are > exposed, since the settings used apply to live unwrap, not just on > executing the operator. > Ideally, *all* operator properties should be stored for re-use later - so when you run an operator, then run it again, it will default to the last most recently used properties. Perhaps a little button to reset the operator properties to factory defaults too. I think we discussed this a bit at the winter camp so many moons ago, but nothing concrete emerged from it. As for Live Unwrap, this is an exception rather than a rule because it's a weird implementation. Live Unwrap shouldn't be using properties from the unwrap operator, it should have it's own properties since it's a different tool. As for where those properties can be, I can see in this case it could go quite easily as a menu option next to where live unwrap is, eg. Live Unwrap Algorithm -> Conformal / Angle Based (or whatever naming makes sense). Failing that it could go in the image editor UV panels when live unwrap is enabled. tl;dr: * +1 to storing settings for *all* operators, with a nice button in the op properties to rest to factory defaults * Huge -1 to persistent 'settings' panels like in 2.4x that don't relate to anything you're doing in context. Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposal: Canvas compositing
Hi Jeroen, I'm not keen on this proposal - it seems to mix two concepts and does it in a bit of an odd way. First concept is region of interest, or bounding box: It should be possible to define regions of interest within which only the contained pixels will be processed/output/etc. This can be used for things like the oldskool preview window in blender's compositor to only update a cropped subset of the pixels to speed things up while tweaking, but can also include things like having different data windows and display windows (like EXRs contain). Sometimes you'll want to render an EXR with overscan, so the data window is larger than the display window, which lets you do things like add distortion, camera shake, etc using the extra pixels around the edge of the visible frame so there aren't edge artifacts. The second concept is a matter of transforming nodes: IMO this should really be implemented as a 3D transformation matrix per node (better to use 3D to be future proof, even if only 2D is used atm). I'm pretty sure most other good compositors do it this way as well. All transform nodes should just be modifying that matrix, passing on a reference to the original buffer, and not doing any processing of their own. Rather, whenever real pixels are needed (for example, a blur) in the function that retrieves the buffer (or tile) for the blur node, it should then sample the original buffer once, using the current transform matrix. This allows concatenation of transforms (as in Shake and Nuke), where you can have as many different transform nodes one after the other like rotate->shear->scale->translate->rotate, and it will only sample the image once, to prevent deterioration in image quality. There's a bit of info on these things here and in the nuke docs: http://www.nukepedia.com/written-tutorials/10-tips-to-optimising-nuke-and-creating-efficient-workflows/ Matt On Wed, Aug 3, 2011 at 1:27 AM, j.bak...@atmind.nl wrote: > Hi all, > > Some of you might already know this, but I have done some effort in making > canvas compositing working in Blender. > > I have made a draft-proposal to see where it should go to. I would like to > have feedback on the user interface level. How can we make this usable to > our users? How can we keep the render width/height settings in sync with > the canvas width/height? > > In the current compositor the composite works on a by code defined > coordinate system. This coordinate system (ImBuf x, y) cannot be changed or > even used by the user. This proposal will open up this coordinate system > and implement canvas compositing in Blender. This is possible as the > compositor redesign project does not enforce a coordinate system and > handles data/memory in a different way (no buffers). > > This will introduce 4 new concepts in the compositor > > - Ordered List Item Canvas (being the existing background grid) > - Viewport (the camera that the compositor looks through, the area that > will be the result of the composite) > - Positionable input nodes (data can be positioned/scaled/rotated on the > canvas) > - Backdrop handles (interactive handles on the backdrop) > > > The link below has to proposal including sample images and a (technical) > video. > > http://ocl.atmind.nl/doku.php?id=design:proposal:compositor_canvas > > Happy Blending! > Jeroen > > > mail2web.com – Enhanced email for the mobile individual based on > Microsoft® > Exchange - http://link.mail2web.com/Personal/EnhancedEmail > > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Syntax Highlighting & Alternate Languages
On Wed, Jul 27, 2011 at 2:49 PM, Sinan Hassani wrote: > I use GameKit and this feature would be very useful. It would also be > nice to add HLSL and Cg highlighting in addition to Lua and GLSL. Some > people are using blender2ogre plugin with GameKit and therefore use the > Blender text editor to write Ogre materials which might include both > HLSL and GLSL shaders (using Ogre unified shader mechanism). So syntax > highlighting of other languages would be very useful. > Yep, there are other examples such as Renderman SL, too. Perhaps it would be better if such functionality could be accessible via the python API so people could write their own types of syntax highlighting independently. At least defining a list of common keywords to highlight would be nice! Not a terribly high priority request though in my personal opinion. cheers Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] new dependencies for (spacenav / ndof / 3D mouse) support
This is probably a bit of a useless comment, but I remember the 2.4x implementation of orbiting the space navigator always seemed terribly awkward. That old way was inverted compared to the 3ds max plugin that came with the 3dconnexion driver, and the 3ds max version always felt much easier to navigate. So I haven't tried this implementation in blender 2.5 yet, but if it's the same as the 2.4x version, then I can totally see where Daniel is coming from. But yeah, an option for this would be best of course! cheers Matt On Mon, Jul 25, 2011 at 9:20 AM, Daniel Salazar - 3Developer.com < zan...@gmail.com> wrote: > Well be sure to share some of that, maybe I'll suddenly get it :D > Thanks for the option, will test and report back ASAP. Also the open > source driver seems much nicer, no need for that annoying window open > all the time. happy > > Daniel Salazar > 3Developer.com > > > > On Sun, Jul 24, 2011 at 5:12 PM, Mike Erwin > wrote: > > Daniel Salazar wrote: > >> Double reading the comments you posted it seems they are talking about > >> *fly mode*, which as I said works as expected > > > > Those comments were about orbit navigation, with some fly-mode > > sprinkles on top. For the one that mentioned fly mode, I was standing > > right beside him, so I'm doubly sure! Whatever they're smoking, it > > seems to be popular. > > > >> When you navigate your normal view (not fly mode) you do it in object > >> space and not in camera space, ie: drag mouse to the left and "camera" > >> orbits to the right, that is why this mode should really work inverted > >> as it is right now. It's really what feels natural > > > > Ok, you convinced me. I have much respect for your work and > > professional opinion, so will add the option to orbit in either object > > or target-camera mode. As for which is the default... we can > > rock-paper-scissors-lizard-spock for it. The config file workaround > > would fix this but break all the other parts you say work well. Give > > me a few minutes... > > > > Mike Erwin > > musician, naturalist, pixel pusher, hacker extraordinaire > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > http://lists.blender.org/mailman/listinfo/bf-committers > > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [38649] branches/soc-2011-pepper/source/ blender: == RNA Property Updates get called by Animation System now ==
On Sun, Jul 24, 2011 at 2:34 PM, Joshua Leung wrote > Log Message: > --- > == RNA Property Updates get called by Animation System now == > Thank you very much! ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Can we please stop breaking APIs?
On Mon, Jul 18, 2011 at 5:03 PM, Campbell Barton wrote: > @Matt, read you're mail and agree with you're suggestions on > deprecation, but for this to work we need some better way to notify of > deprecated api usage. > it worries me a bit that mac and win users (even script devs) don't > use the console so much anymore, of course they should not have to... > but for the moment deprecation warnings are just prints, so its > something we need to address. > Agreed. Is there any way that a deprecation warning could be hooked up to blender's reports system, to give a little warning in the reports area of the header? I can't remember precisely right now but doesn't it already report on python errors there? Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender developer IRC meeting notes, july 17 2011
On Mon, Jul 18, 2011 at 2:57 AM, Ton Roosendaal wrote: > > - Question, how is Ocean Sim coming? Todd McIntosh or Matt Ebb know! > Hasn't been changed since my work on it finished earlier in the year. I brought it up to date with SVN a month or two ago, but that's as far as it goes. It's mostly in a good state, but there's also some code that should be cleaned out. I'm happy to give any assistance I can to someone that's interested, but I have no time of my own to spend on it at the moment. Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Can we please stop breaking APIs?
> > I am not trying to be difficult here, but there are cases it doesn't > really make sense or isn't likely to even help much. > I agree, the situation isn't as simple as "don't change anything at all", and to clarify, that's not what I was saying, so I'm sorry if that's how it was interpreted. But it's also not as simple as "blender is in development so anything is up for grabs and can change at any moment for whatever reason". I'm also not saying that improvements, like this buffer one, shouldn't happen - the main thing is that things don't just suddenly get *broken*. There are varying levels of necessity for things to change, and they need to be treated differently, but with as much sensitivity as possible to the peopel affected by the changes. For example, it could be: * Big structural refactors internal to blender: There's not much (like deprecation) that can be done here other than give as much advance warning as possible on mailing lists, blender release notes pages. Same with if an operator gets changed drastically and has new properties * Changes like this recent buffer one: Add the new method of access and deprecate the old one for a blender release or two. * Changes to naming or organisation for consistency or 'niceness': Perhaps rather than change bit by bit, putit off for a while and gather a big list with advance warning and do a whole bunch of changes simultaneously (like what happened earlier with the big rna name reshuffle), ideally deprecating old versions for a release or two. If just changing a couple of names, definitely deprecate. Like you say, also good to take likelihood of usage into account, i.e. don't rename something that's commonly used just for the hell of it. On Mon, Jul 18, 2011 at 1:59 PM, Campbell Barton wrote: > Throughout this discussion deprecation has always been an option and > something we agree can be used at times, my main concern is that we > deprecate stuff and don't remove it as happened with 2.x time frame > for removal - every second release?, whatever it is we need to be able > to manage it but I think a year is too long. > I agree, 6 months (especially if the attempted 3 month release schedule can be maintained) should be enough. The main thing is that things don't just break immediately. The value of deprecation is that it allows and empowers people to manage change themselves, and manage their time spent on it. Say you're a TD in a studio and have a bunch of custom python tools written. A new blender version comes out, you test it for a bit, and all is well. After you've used it for a little while you're in the middle of a project and then one of your less-often-used tools that an artist wants to use has broken because of some little change. This is really annoying and messes up your project management, since it forces you to stop what you're doing and spend time on fixing things immediately in order to continue, losing time on your job. When stuff like this happens, no matter how 'small' the change, it's really, really annoying. If that change was deprecated instead, perhaps you'd get a little warning icon in blender's reports header. Then you can say "right, I'd better change that soon, I'll do it right after this deadline when I've got a bit more time". It gives you the ability to manage the change yourself and fix things on your own schedule. I'd also like to make the point that using as much deprecation as possible (with reporting internal to blender, in the console, reports header, etc) is the best way to go. Announcing and warning on mailing lists like bf-python is also great, *additionally*, but it shouldn't be a requirement of using blender to be signed up to all these mailing lists and reading all the discussions that happen inside. I try my best to stay as involved as possible these days but even I have trouble keeping up with things, especially when busy with 'real work'. cheers Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [38452] trunk/blender/source/blender/ editors/space_node/node_header.c: Removed the autoconnect call when adding new nodes, this h
I agree the old behaviour was pretty awful sometimes. Perhaps it can be improved by making it more explicit and context sensitive. For example in Houdini if you add a node (RMB/Tab) on empty space in the network view, it will add the node on its own, where if you RMB to add a node, but clicking on an existing node's output, it will connect the new node up to that output. This is really handy, and *much* better than preferences or alternate hotkeys for different versions of the same too (I'm not too keen on how this is creeping into blender's compositor). Same in Fusion (compositor) - adding a node clicking in empty space will add it on its own, clicking on an existing node will insert it after that node in the stream. Matt On Mon, Jul 18, 2011 at 3:37 AM, Daniel Salazar - 3Developer.com < zan...@gmail.com> wrote: > This should not come back as it was. Some specific cases like the mix > node can be an exception but the rest is just total madness > > Daniel Salazar > 3Developer.com > > > > On Sun, Jul 17, 2011 at 11:33 AM, PabloVazquez.org > wrote: > > Its been a topic for a while already, but in my perspective, -1 on this. > > > > In 2.4x was more intuitive, adding a Mix node with two nodes selected > > (say two rgbcurves) will automatically connect them, saving time, of > > course would be better if they connect in the order we select them, so > > is more predictable but still was better than now only connecting with > > the active node. > > Another example, adding a Separate RGB then Combine RGB node would > > connect all of the inputs/outputs in 2.4x, not the case in 2.5x. > > > > I know is easier to remove than to fix, but at least should be a > preference. > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Can we please stop breaking APIs?
I have a few things to say on this topic... On Sat, Jul 16, 2011 at 8:37 AM, Campbell Barton wrote: > On Fri, Jul 15, 2011 at 10:35 PM, Diego B wrote: > >> Nope, the api is not stable and probably wont be until blender > >> development ceases. > > > > so.. that mean that the api never will be stable ? because blender is > > always in development, like > > any other software. > > In practice we end up stabilizing most areas and don't just break > stuff indefinitely - But bigger changes mean api breakage is > unavoidable in most cases - BMesh, Particle Rewrite, Curves/Nurbs > branch... etc. > I don't think it follows that because blender is always in development (like any other software) that anything is up for grabs and users can never expect to be able to rely on a stable API. I think most people can understand that if a major part of the software changes internally, then the API may have to change as well, and with a managed path of warning and deprecation, the pain of transitioning can be managed. But this is not the sort of problem that is in question here - some of these changes, which I thought would stop after the 'stable' 2.5 release, are smaller, syntactic changes. They're not due to any major internal reorganisations, they're not part of fixing design problems, they're little things that really aren't that *necessary*. Like the previous change that affected me (which I only found out about when things stopped working), it was moving ExportHelper from io_utils to bpy_extras.io_utils. That was something that has nothing to do with reflecting changes internally in blender, it was a somewhat arbitrary decision to make things 'nicer' or more organised. >From the point of view of a developer who's involved in blender, who reads every commit log, who hangs out in IRC, who knows exactly what's happening in the API, this may not seem like a big deal, but for other developers outside that circle, or users who just want to their tools to work when they download a new blender, it's a huge difference - it's the difference between something working or not working at all - there are no varying degrees of difficulty here. Trying to make the api syntactically nice is not a bad goal on its own, but it *is* a problem when it conflicts with the API's usability. And that usability is not just about how much you have to type, or if the names are good syntactically, it's about how much trouble it is to actually develop tools with it and get work done. Having an unstable API that can change for seemingly small and arbitrary reasons really damages the API's usability much more than less-than-beautiful syntax or organisation does. So the legitimate need for having things well organised and with nice syntax and naming has to be balanced with having a usable, stable API. In some cases (like the one I brought up, IMO) the solution should be to just sigh, and live with something that's not 100% perfect, because fixing it causes a greater problem than it solves. In other cases, this can be handled with deprecation, warnings, grace periods to allow people to transition. Agree we should deprecate in some cases - at the moment its arbitrary > when to do so. Currently I just check if any addons/scripts use it and > if its documented. > If not, this is a reasonable indication its not widely used. (nobody > complained when convert_to_pyobject() was renamed for eg.) > This is absolutely not a reasonably indication. The fact is you really don't know at all who is using this stuff out there. I've done a reasonable amount with the 2.5 API now - not extensive by any means, but none of my stuff is included in addons. The benefit of having a python API is that you don't need to spend time being involved in IRC, mailing lists, etc in order to get work done developing tools. Scripters and TDs can just write stuff in python and never show a single other soul, or keep it for their studio to use internally, or distribute it themselves on the net, or give it to a client who has hired said coder to make a python tool. The API is not just to enable blender developers to make included blender tools or addons in python, there's a much, much wider world outside that sphere. So anything that can improve interaction and communication that doesn't involve being deeply involved in blender dev (eg. prior warnings in documentation, deprecation messages, grace periods, etc) is very much appreciated. Anyway, I really appreciate the work that's being done in the API, and it is miles ahead of what we had before. I just don't want to see baby thrown out with the bathwater, having a API that can be considered nice at a given moment in time, but is a total pain to use for real work because it's constantly breaking. cheers Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Scene Linear Middle Grey Assumptions
On Sun, Jul 17, 2011 at 3:00 AM, Troy Sobotka wrote: > Can anyone cite where Blender's internal representation of middle grey > is? Has one been defined? > > It would seem that for ingestion and output, the reference model would > be wise to locate one. For example, within Open Color IO, the > reference compositing space appears to select a value that aligns with > the optical middle grey value of 0.18[1] > 'middle grey' is not a photometric quantity and can't really be defined precisely. It's also important to note that it's not an absolute value either, it's more of a proportion defined as being between black and a 'properly exposed white diffuse reflector' The definition they're using in OCIO seems fine, and it's perfectly easy to just say we can adopt that definition for blender. That doesn't mean though that anything that's a value of 0.18 must look 'middle grey' on your screen - what you actually see on your screen is entirely dependent on whatever profile/gamma function is being used to convert that from linear to display. 0.18 after converting from linear to sRGB gamma is roughly 0.5, which in an ideal world should give you a halfway-grey appearance, but that can differ with different profiles, monitor calibrations, etc of course. Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Keymap storage & management
On Tue, Jul 12, 2011 at 1:51 AM, Ton Roosendaal wrote: > > - The "Preset" map is not only to mimic other maps, but can be used > for cases like "2.4 power user map" or "Optimal Laptop map" as well. > This will be in our distros. > One note: keep in mind for these sort of presets to work properly, they need to encompass more than just key bindings - they also need to control things like zoom and orbit styles, 'release confirm' setting, etc.. cheers Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [37260] trunk/blender/source/blender: Support for update callbacks in python defined RNA properties as discussed last meeting .
oh! I guess I didn't see that anywhere - was looking in datablocks view, and thought I did dir() on the self argument to the update function but must have missed it. My apologies, I'll check it out right now. cheers Matt On Tue, Jul 5, 2011 at 7:10 PM, Brecht Van Lommel < brechtvanlom...@pandora.be> wrote: > Hi Matt, > > There is in fact a self.id_data, and it should work here? > > http://www.blender.org/documentation/blender_python_api_2_57_release/bpy.types.bpy_struct.html#bpy.types.bpy_struct.id_data > > Brecht. > > On Tue, Jul 5, 2011 at 10:13 AM, Matt Ebb wrote: > > Hi Campbell, I've been looking into this feature a bit further and tried > to > > use it in my scripts, and it's not quite as useful as I'd expected. > > > > The main reason for this is the limited access to other blender data - I > can > > access self (the property itself), and I can access context, but there's > not > > a lot I can do with that. For example if I'm adding an update function to > a > > material property, there's not really any easy way of finding the > material > > that the property is attached to, via context. I've noticed this for the > > dynamic enums too, just self and context really isn't enough to be > useful. > > > > What would be really handy is if there was something similar to RNA usage > in > > C, where you have access to not only the pointer itself, but also the > data > > that contains that pointer (ptr->data) and also the top level ID block > > (ptr->id.data). This would be much more practical for update functions, > > enabling the sort of things that are commonly done in the C RNA > definitions. > > > > One possibility could be to pass those pointers as arguments to the > update > > function, but I also wonder if it would it be possible to expose the > > ptr->data and ptr->id.data as children of the python RNA property object > > itself? Perhaps in a similar way to how an RNA property contains flags > like > > read only and hidden, its type and subtype, units, etc. Then in an update > > function you could use self.id_data or something like that. I have no > idea > > about the practicalities of how this could work in python though, it's > just > > an idea. > > > > Regardless, having access to data such as this, however it may be > > implemented, would be very useful! > > > > cheers > > > > Matt > > > > > > On Sat, Jun 25, 2011 at 12:09 PM, Campbell Barton >wrote: > > > >> @Matt, yes it does use the internal RNA update function, it also > >> disables the readonly state (if set) for the duration of the update > >> call. > >> > >> Agree the animation system should be calling update functions though I > >> think we need to have it optimized for arrays. > >> If you have 20 layers all animated, ideally wouldn't call update 20 > >> times for example. > >> > >> Slightly related is the layer animation bug, where setting the layer > >> doesn't always work right because blender ensures at any point in time > >> at least 1 layer is enabled. > >> > >> IMHO it's worth looking into collecting RNA writes per datablock and > >> assigning arrays so the 'set' functions get the new array as a single > >> assignment (currently each index is assigned individually). > >> With this we could run each properties update function once too. > >> > >> - Campbell > >> > >> On Sat, Jun 25, 2011 at 1:20 AM, Daniel Salazar - 3Developer.com > >> wrote: > >> > Indeed it's weird.. see this example with a driver based on > >> > scene.frame_current. It will not update on frame change but it can be > >> > tricked to do so by adding a variable pointing to an object (even to > >> > itself) with an object level property animated. In this case I > >> > inserted a keyframe on bounding box display type! :p after that it > >> > will correctly update on frame change.. even if the variable isn't > >> > even used in the expression > >> > > >> > http://www.pasteall.org/blend/7167 > >> > > >> > what's going on? > >> > > >> > cheers to you two! > >> > > >> > Daniel Salazar > >> > 3Developer.com > >> > > >> > > >> > > >> > On Fri, Jun 24, 2011 at 7:06 PM, Matt Ebb wrote: > >> >> On Tue, Jun 7, 2011 at 3:50 AM, Campbell
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [37260] trunk/blender/source/blender: Support for update callbacks in python defined RNA properties as discussed last meeting .
Hi Campbell, I've been looking into this feature a bit further and tried to use it in my scripts, and it's not quite as useful as I'd expected. The main reason for this is the limited access to other blender data - I can access self (the property itself), and I can access context, but there's not a lot I can do with that. For example if I'm adding an update function to a material property, there's not really any easy way of finding the material that the property is attached to, via context. I've noticed this for the dynamic enums too, just self and context really isn't enough to be useful. What would be really handy is if there was something similar to RNA usage in C, where you have access to not only the pointer itself, but also the data that contains that pointer (ptr->data) and also the top level ID block (ptr->id.data). This would be much more practical for update functions, enabling the sort of things that are commonly done in the C RNA definitions. One possibility could be to pass those pointers as arguments to the update function, but I also wonder if it would it be possible to expose the ptr->data and ptr->id.data as children of the python RNA property object itself? Perhaps in a similar way to how an RNA property contains flags like read only and hidden, its type and subtype, units, etc. Then in an update function you could use self.id_data or something like that. I have no idea about the practicalities of how this could work in python though, it's just an idea. Regardless, having access to data such as this, however it may be implemented, would be very useful! cheers Matt On Sat, Jun 25, 2011 at 12:09 PM, Campbell Barton wrote: > @Matt, yes it does use the internal RNA update function, it also > disables the readonly state (if set) for the duration of the update > call. > > Agree the animation system should be calling update functions though I > think we need to have it optimized for arrays. > If you have 20 layers all animated, ideally wouldn't call update 20 > times for example. > > Slightly related is the layer animation bug, where setting the layer > doesn't always work right because blender ensures at any point in time > at least 1 layer is enabled. > > IMHO it's worth looking into collecting RNA writes per datablock and > assigning arrays so the 'set' functions get the new array as a single > assignment (currently each index is assigned individually). > With this we could run each properties update function once too. > > - Campbell > > On Sat, Jun 25, 2011 at 1:20 AM, Daniel Salazar - 3Developer.com > wrote: > > Indeed it's weird.. see this example with a driver based on > > scene.frame_current. It will not update on frame change but it can be > > tricked to do so by adding a variable pointing to an object (even to > > itself) with an object level property animated. In this case I > > inserted a keyframe on bounding box display type! :p after that it > > will correctly update on frame change.. even if the variable isn't > > even used in the expression > > > > http://www.pasteall.org/blend/7167 > > > > what's going on? > > > > cheers to you two! > > > > Daniel Salazar > > 3Developer.com > > > > > > > > On Fri, Jun 24, 2011 at 7:06 PM, Matt Ebb wrote: > >> On Tue, Jun 7, 2011 at 3:50 AM, Campbell Barton >wrote: > >> > >>> Revision: 37260 > >>> > >>> > http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=37260 > >>> Author: campbellbarton > >>> Date: 2011-06-06 17:50:20 + (Mon, 06 Jun 2011) > >>> Log Message: > >>> --- > >>> Support for update callbacks in python defined RNA properties as > discussed > >>> last meeting. > >>> This means script authors can perform actions using these callbacks > rather > >>> then on drawing which puts blender in a readonly state. > >> > >> > >> Late reply, I'm just getting some time to look into editing scripts to > use > >> this and wanted to say thanks for this Campbell, it's great. Just to > >> clarify, is this implemented as a proper RNA update function which will > act > >> exactly like any other C-defined ones? If so, that's great, but useful > >> either way. > >> > >> Probably worthwhile bringing up this issue again too (certain rna > properties > >> not running update functions in animation system), since it may be > affected: > >> > http://lists.blender.org/pipermail/bf-committers/2010-November/029482.htm
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [37986] trunk/blender/source/blender/ editors: Todo item:
On Fri, Jul 1, 2011 at 1:02 AM, Ton Roosendaal wrote: > My preference is something that aligns visually to the seperators between > regions; for testing and hacking pleasure I've added two quick versions, > a small tabbish thing and a triangle. Enable these with debug menu, > ALT+CTRL+D, values 1 or 2. > As far as these go, I think the tabs are pretty good. Another thing that might help too is for them to have a tooltip when the mouse is over them, telling you what they will do (eg. reveal properties region) Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Better approaches to Defocus?
On Wed, Jun 29, 2011 at 8:33 AM, François T. wrote: > I guess I'm just one of those who like to keep things seperated and when > I'm > looking for a vblur who finds a vblur node and not a defocus node which as > a > vblur capability. Just a design thing. but again just my opinion so not a > big issue :D > I agree philosophically that separate tasks should be in separate nodes, but in a practical sense for this particular issue it's not that simple. Having these two combined in one operation could potentially help things a lot. It's always a problem when trying to both defocus and blur animated footage - sometimes you can improve things a bit by experimenting with which one should come first for any given situation, but in the end there are *always* artifacts that are impossible to work around. Either way, with the two separated, you're trying to defocus or motion blur something based on a z buffer or motion vector channels that are no longer accurate. Trying hacks like blurring z buffers or motion vectors just bring in problems of their own. This is a major problem when trying to render production animation with blender with composited motion/dof blur - it's always painful to know that there are inevitably going to be artifacts no matter what, and hoping that people just don't notice is not really acceptable. I used to always try to do my best to work around/patch up these problems but it always made me feel very uncomfortable knowing that I was delivering frames like this... Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] splitting (off) hair
On Tue, Jun 28, 2011 at 10:25 PM, Lukas Tönne wrote: > I'm reluctant to spend more time trying to fix a system that is broken > by design (and intended for general redesign anyway) ... I would > rather try to separate hair code from particle code, so the two > systems don't interfere with each other so much. 100% agreed, very big +1 from me! ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Node property panel enhancement
+1. it can be nice to have controls on the nodes for a few select things, but should be a minimal amount or none at all. The current situation has a few problems: 1) lack of space on nodes is a deterrent to adding further options that might be very useful 2) lack of space on nodes causes options that do get added to be crammed in very tight, or with giant nodes 3) with a network full of giant nodes, that number of nodes that you can see and interact with at any given time decreases, since less nodes fit in the view at a zoom level that's usable Splitting this up would help a lot. matt On Tue, Jun 28, 2011 at 4:42 AM, Lukas Tönne wrote: > +1 > > In my own nodes stuff (particles-2010 branch) i even have this > already. This was primarily intended to avoid cluttering the node > options with very advanced and rarely used special settings, though it > may be debatable whether it is a good idea to hide such settings at > all (can't even remember what node i used this for right now). It uses > the default ui callback if no "special" draw function is defined. > > On Mon, Jun 27, 2011 at 8:30 PM, Troy Sobotka > wrote: > > On Mon, Jun 27, 2011 at 11:12 AM, pete larabell > wrote: > >> +1 on this. > > > > I'll second this. > > > > I find that both Nuke's panel approach and Blender's > > "within-the-node-itself" approach have some advantages in certain > > contexts. > > > > Having, if I understand you correctly, a fluid layout for the node UI > > elements would be a huge asset. > > > > On a side note, with regards to viewers (and apologies for hijacking > > this thread potentially): > > > > 1) Will multiple viewers be available for look test LUTs? > > > > 2) Have you thought about how display characterization is going to fit > > into this pipeline? As I understand it OCIO will handle the transform > > to a known space, but that space must still be reconciled against the > > display's characterization. > > > > With respect, > > TJS > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > http://lists.blender.org/mailman/listinfo/bf-committers > > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Speed pass
On Sun, Jun 26, 2011 at 6:16 AM, Tobias Kummer wrote: > Hey there, > > I looked around a bit but didn't get any decent info on how blenders > speed pass is constructed. How are the RGBA values derived from the > scene according to the movement? > As far as I remember, it's 4 floats in image space: speed[0] displacement from previous frame in X speed[1] displacement from previous frame in Y speed[2] displacement to next frame in X speed[3] displacement to next frame in Y And you need a z buffer to go along with it too. cheers Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] bpy callback patch (replace scriptlink like functionality from 2.4x)
On Sat, Jun 25, 2011 at 1:04 PM, Campbell Barton wrote: > Hey Matt, > Having notifiers in python could work but I think the purpose is quite > different and more on a WM level to avoid showing old data. > > There is a use case for a notifier is so python defined space (when we > get them), can check if some data was modified and redraw. > > But scriptlinks are used differently, eg: > * Before/After each frame is rendered call a function every time, in > background mode and wait for the call to finish. > In contrast with notifiers: > * If a render is done let me know about it if you're not too busy (ei, > the queue doesn't flood), and I'll deal with it when I'm ready > (sometime later when the notifiers are handled). > Makes sense. Thanks! ___ 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 [37260] trunk/blender/source/blender: Support for update callbacks in python defined RNA properties as discussed last meeting .
On Tue, Jun 7, 2011 at 3:50 AM, Campbell Barton wrote: > Revision: 37260 > > http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=37260 > Author: campbellbarton > Date: 2011-06-06 17:50:20 + (Mon, 06 Jun 2011) > Log Message: > --- > Support for update callbacks in python defined RNA properties as discussed > last meeting. > This means script authors can perform actions using these callbacks rather > then on drawing which puts blender in a readonly state. Late reply, I'm just getting some time to look into editing scripts to use this and wanted to say thanks for this Campbell, it's great. Just to clarify, is this implemented as a proper RNA update function which will act exactly like any other C-defined ones? If so, that's great, but useful either way. Probably worthwhile bringing up this issue again too (certain rna properties not running update functions in animation system), since it may be affected: http://lists.blender.org/pipermail/bf-committers/2010-November/029482.html cheers, Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] bpy callback patch (replace scriptlink like functionality from 2.4x)
On Fri, Jun 24, 2011 at 11:27 PM, Campbell Barton wrote: > This is something thats been requested to be brought back from 2.4x > for quite a while, > however I wasn't that happy with scriptlinks having to be setup per > datablock, then scanning every datablock on frame change to see if any > have frame change scriptlinks for example - not too efficient and > cumbersome to manage scripts attached to each datablock. > Hi Cam, I'm curious how this differs from Notifiers and Listeners inside blender already? Are there some problems inherent in making a 'python listener' for example which could then react when blender notifiers are sent? cheers Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Bf-committers Digest, Vol 83, Issue 26
Hi, On Sun, Jun 19, 2011 at 8:43 PM, Peter Schlaile wrote: > I know, your first idea was adding a very simple text tool, but there it > usually doesn't stop. You will be faced with people, who want to do > something special to the text, have it 3D extruded, adding parameters and > then you start to add a seperate 3D renderer to the sequencer. > I find this very hard to believe. It's not uncommon for video editors to have simple text tools for adding titles, subtitles, etc. FCP has it, Vegas has it, Premiere has it - compositors like Nuke, Fusion, Shake have it, and none of them have gone down a slippery slope resulting in 3d extruded text effects. If anybody needs something like that, they can easily render it in Blender, but for 90% of the usage cases, having a quick, simple way to edit text in-place would be a real boost. It's very easy to define that such a tool is for simple 2d text rendering only - for anything more complicated you use other effects in the sequence editor, or use 3d text in blender (which is a total pain in the rear when used for this purpose), or do what you have to do now if you want anything usable: make images in an external app like Photoshop. (BTW: your text-tool even doesn't solve Algorith's problems. Fun fact :) > He wanted some automatic layout with his title cards, and so the whole > thing needs some fancy scripting to be right in all circumstances.) > I don't see how it wouldn't solve his problems - all you'd need is a text area with width, height, X and Y position, plus some formatting options like left/right aligned/centred and vertical alignment top/middle/bottom. Along with a font and size, that's pretty much all you need, it's what most other editors have, and covers most normal use cases. No scripting required. The idea is to have something that is super fast for the 90% of situations where you want text - not to have something that's totally flexible but clumsy to use. To summarize: I think, the most easy way to add this to blender is to add > some small features to the scene strips, so that parameters can be passed > to a scene and add some small operators, which make it possible to handle > all this with python templates. > Blender already has an API for drawing 2d text to a bitmap. To me, that's a lot simpler than a solution that has to access disparate parts of blender and tie it all together with scripts, and more efficient than kicking off blender's internal 3d renderer every time you want text. cheers, Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] SVN commit: /data/svn/bf-blender [37537] branches/soc-2011-pepper: == Simple Title Cards for Sequencer ==
Personally, I think a text strip has been sorely missing from the sequencer (and compositor) for a while, and it's great to see it added. Doing it via blender scenes and python is a really slow, nasty overcomplicated way of doing something which really should be quite simple, and is a really simple, common, basic tool in most other editors. Editing the text from the sequence editor interface and having it rendered directly to a strip is the fastest and best way of having such a feature, and it's something I would have loved to have had plenty of times. Note: I haven't tried the current patch but it would be best as a generalised 'text strip' rather than anything aimed specifically at title cards, with properties like text box height and width, and typographic/paragraph controls too. cheers Matt On Thu, Jun 16, 2011 at 9:26 PM, Joshua Leung wrote: > Hey Peter, > > Cheers for the feedback! > > Indeed, as I started to pick through things, the issues faced by users > who would want to use this as a base on which to start extending it in > some ways did come up. Sure, a script which sets up a generic template > would be nice in this situation, and is one way I'd thought of doing > it. > > Some factors which made me favour this approach though were that: > 1) Using this approach, we let automation take over making sure that > the text fits and is aligned nicely in frame when things change. From > experience, I've ended up scaling and re scaling text, moving it all > over the place trying to get it to fit and be in frame. Registering a > special operator for this, and/or trying to find somewhere decent to > put it so that it can be easily found is an issue. > > 2) Text colours can be set in one place with this method, without > fudging with material settings (and doing material-unlink dances after > copying some text and deciding you want it a different colour - then > again here, the level of control over this stuff is entirely > hardcoded) > > 3) AFAIK, scene strips were synonymous with constantly being > re-rendered and re-evaluated every single time they're encountered, > when doing scene evaluation combined with rendering is a comparatively > sluggish process for Blender. The alternative would have been to force > people to always render these out to image files (something that I'm > trying to avoid here) before they could be used. (*1) > > 4) With this approach, including text in the sequencer feels more like > a "first-class" entity than just a weirdo heavy-duty workflow, where > you have a proliferation of "scene" strips in your timeline which are > essentially just there to display text (but outwardly don't > communicate this) > > 5) There's also the issue of a buildup of scene files in the file, > each one for a different slide, making it easy to accidentally delete > the wrong one from the file, and also making it slower to find the > scene to go in and edit its text. (*2) > > - > > (*1) From your mail below, it sounds like that's something the cache > voodoo might be able to take care of under certain circumstances. As > only a very infrequent user of VSE, I wasn't aware of this. > > (*2) I'm not really convinced about the idea of these template > parameters for the scene strips. It sounds even more like a > specialised hack from user perspective than shoehorning an entire > strip type with some predefined slots where people commonly place text > for common purposes. > > --- > > Anyhow, as an "experimental" feature, this was certainly a good > exercise for seeing how such functionality could look like, and to > generate debate over what use cases for this sort of stuff users have. > (It was also a good exercise in exploring how the sequencer works, > though I might add that the number of places where you have to > redefine how a new strip type is a bit excessive) > > Personally, this is probably sufficient, though maybe with a few more > optional slots for text. If nothing else, I can now save off this > build for future use where necessary ;) > > Perhaps as you suggest, an operator which generates some preset > title-card scene setups would be handy to have. Though it's the > details of how we allow people to tweak the content there which > worries me a bit. > > Regards, > Joshua > > On Thu, Jun 16, 2011 at 10:35 PM, Peter Schlaile > wrote: > > Hi Algorith, > > > > don't you think, we should add some other extensions to > > blender, that make it possible, to script something like this with > Python? > > > > Problem is: you wrote a *very* special solution for a > > very special problem you had, and I'd like to keep the > > sequencer core clean and simple. > > > > Would be cool, if you could specify a SCENE as template and only fill in > > parameters. > > > > Add some tweaks to the SCENE strip, that make it optionally render to > > files by default, add template parameters for the SCENE strip and there > > we go. > > > > Then your title cards will end up as ONE additi
Re: [Bf-committers] Sensor Size
Hi guys, sorry to have not been keeping track of this stuff, I've been busy. I'll try to make time to look at the updated patch on the weekend (hopefully). As far as I can see right now from a cursory glance, all that's needed is to make blender's internal camera respect the vertical/horizontal FOV settings - from memory right now it's done automatically based on the longest render dimension. btw, this pixel space focal length is a bit of a red herring - it's unecessary for blender and is a bit of a distraction from the issue at hand, which is making it possible to convert real world lens units into a final FOV inside blender. cheers Matt On Wed, Jun 15, 2011 at 2:26 AM, Lars Krueger wrote: > > > @Lars > > > > Hi again! > > > > > Yes, it does: The sensor size that is currently fixed at 32 units. > > Otherwise we already have all the data: > > > - image size (nx,ny) are required for the size of the output image > > > - focal length (f) is a property of the camera > > > > This patch only adds a variable sensor size, and changes the focal/fov > > accordingly. So to me it looks like adding the variable sensor size > > (dx/dy) is the first step to implement focal length units in pixels. > > Or am I missing the point? > > Input info should be all there now. Depending on how the rest of the > projection code is implemented you're either done or have to change all > computations that use the focal length. > > Simple test: make a test scene, double the image size and leave everything > else constant. The object in the image should be half as wide/high as before > because all you pixels increased in size. > > -- > Dr. Lars Krueger > > > Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir > belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Patch: Adaptive time step for fluid particles
What he means is that if you run two sims with the exact same settings, will the results be exactly the same? This is pretty important. cheers Matt On Tue, Jun 7, 2011 at 12:05 PM, Alex Fraser wrote: > - Original Message - > > From: "Shaul Kedem" > > No, I mean is it deterministic? > > >From one run to the next, yes, you should get the same result. > > In terms of being predictable, I did some tests with the TwoPipe demo, in > which water drains through a hole (you may need to increase the fluid > interaction radius to see this effect). With zero subframes, it takes a long > time to drain; with more subframes, it tends to take less time (time in > frames, not computation time). However, it starts to converge for subframes > > 3 or a Courant target < 0.2, and barely changes beyond subframes = 8 or > Courant target = 0.1. So it seems to become more accurate with smaller time > steps, but you should rarely need to go beyond those values. > > The adaptive subframe code gives a stronger guarantee that your simulation > will be stable, but it's not predictive, so for some simulations a constant > time step is still more appropriate. > > Cheers, > Alex > > -- > Alex Fraser > Software Engineer > The Victorian Partnership for Advanced Computing > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [36710] trunk/blender/release/scripts: move generic bpy helper modules into bpy_extras.
Hi Campbell - just a heads up, this commit wasn't mentioned here:
http://wiki.blender.org/index.php/Dev:2.5/Py/API/Updates
It has the effect of breaking compatibility since you now need to import
bpy_extras.io_utils rather than just io_utils. This makes it difficult
(well, messy, with a try/except) to support 2.57 and current svn versions.
What's the policy on this sort of thing now that 2.57 is out? I thought
there would be less breakage happening now ;)
cheers
Matt
On Mon, May 16, 2011 at 5:51 PM, Campbell Barton wrote:
> Revision: 36710
>
> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=36710
> Author: campbellbarton
> Date: 2011-05-16 07:51:02 + (Mon, 16 May 2011)
> Log Message:
> ---
> move generic bpy helper modules into bpy_extras.
>
> Modified Paths:
> --
>trunk/blender/release/scripts/startup/bl_operators/add_mesh_torus.py
>trunk/blender/release/scripts/templates/operator_export.py
>trunk/blender/release/scripts/templates/operator_mesh_add.py
>
> Added Paths:
> ---
>trunk/blender/release/scripts/modules/bpy_extras/image_utils.py
>trunk/blender/release/scripts/modules/bpy_extras/io_utils.py
>trunk/blender/release/scripts/modules/bpy_extras/mesh_utils.py
>trunk/blender/release/scripts/modules/bpy_extras/object_utils.py
>trunk/blender/release/scripts/modules/bpy_extras/view3d_utils.py
>
> Removed Paths:
> -
>trunk/blender/release/scripts/modules/add_object_utils.py
>trunk/blender/release/scripts/modules/image_utils.py
>trunk/blender/release/scripts/modules/io_utils.py
>trunk/blender/release/scripts/modules/mesh_utils.py
>trunk/blender/release/scripts/modules/view3d_utils.py
>
> Deleted: trunk/blender/release/scripts/modules/add_object_utils.py
> ===
> --- trunk/blender/release/scripts/modules/add_object_utils.py 2011-05-16
> 07:48:43 UTC (rev 36709)
> +++ trunk/blender/release/scripts/modules/add_object_utils.py 2011-05-16
> 07:51:02 UTC (rev 36710)
> @@ -1,116 +0,0 @@
> -# # BEGIN GPL LICENSE BLOCK #
> -#
> -# This program is free software; you can redistribute it and/or
> -# modify it under the terms of the GNU General Public License
> -# as published by the Free Software Foundation; either version 2
> -# of the License, or (at your option) any later version.
> -#
> -# This program is distributed in the hope that it will be useful,
> -# but WITHOUT ANY WARRANTY; without even the implied warranty of
> -# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> -# GNU General Public License for more details.
> -#
> -# You should have received a copy of the GNU General Public License
> -# along with this program; if not, write to the Free Software Foundation,
> -# Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
> -#
> -# # END GPL LICENSE BLOCK #
> -
> -#
> -
> -import bpy
> -import mathutils
> -
> -
> -def add_object_align_init(context, operator):
> -space_data = context.space_data
> -if space_data.type != 'VIEW_3D':
> -space_data = None
> -
> -# location
> -if operator and operator.properties.is_property_set("location"):
> -location =
> mathutils.Matrix.Translation(mathutils.Vector(operator.properties.location))
> -else:
> -if space_data: # local view cursor is detected below
> -location =
> mathutils.Matrix.Translation(space_data.cursor_location)
> -else:
> -location =
> mathutils.Matrix.Translation(context.scene.cursor_location)
> -
> -if operator:
> -operator.properties.location = location.to_translation()
> -
> -# rotation
> -view_align = (context.user_preferences.edit.object_align == 'VIEW')
> -view_align_force = False
> -if operator:
> -if operator.properties.is_property_set("view_align"):
> -view_align = view_align_force = operator.view_align
> -else:
> -operator.properties.view_align = view_align
> -
> -if operator and operator.properties.is_property_set("rotation") and
> not view_align_force:
> -rotation =
> mathutils.Euler(operator.properties.rotation).to_matrix().to_4x4()
> -else:
> -if view_align and space_data:
> -rotation =
> space_data.region_3d.view_matrix.to_3x3().inverted().to_4x4()
> -else:
> -rotation = mathutils.Matrix()
> -
> -# set the operator properties
> -if operator:
> -operator.properties.rotation = rotation.to_euler()
> -
> -return location * rotation
> -
> -
> -def object_data_add(context, obdata, operator=None):
> -
> -scene = context.scene
> -
> -# ugh, could be made nicer
> -for ob in scene.objects:
> -ob.select = False
> -
> -obj_new = bpy.data.objects.new(obdata.name, obdata)
> -
> -base = scene.objects.link(obj_new)
> -base.select = True
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [36779] trunk/blender/source/blender/ blenkernel/intern/fcurve.c: modify fcurve evaluation for bool/enum/ int values.
On Saturday, May 21, 2011, Campbell Barton < > How about have boolean values use a different truth test then > converting to an int and checking == 0? Personally I'm in two minds, on one hand I think the previous behaviour is the only one that makes sense for animating booleans, so that would be an improvement over it currently, but on the other hand the same arguments can still apply for integers (value becomes 3 when it passes the 3.0 mark, easier to predict what the final integer value will be by just looking at the digits before decimal point). I guess I'm wondering what's the problem that's trying to be solved here- is it float inaccuracy? Is it the behavior when crossing zero? They both seem quite abstract to me, relating to corner cases that aren't terribly likely to be run into day to day. I'm not opposed to the idea of fixing these issues somehow but I really don't think it should be done at the expense of having sensible fundamental behaviour that's encountered much more frequently. Regardless of what happens though it is *absolutely* essential that it's consistent across the entire animation system - setting values via RNA, python, drivers, fcurves, expressions, anything, all must behave the same way. I can't stress this enough. So the current situation of drivers evaluating differently has to be resolved. cheers Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [36779] trunk/blender/source/blender/ blenkernel/intern/fcurve.c: modify fcurve evaluation for bool/enum/ int values.
Hi Cam, On Sat, May 21, 2011 at 4:16 AM, Campbell Barton wrote: > The way fcurve editing tools work right now the curves are clamped to > whole numbers, so in practice I don't think users entering fractional > fcurves for int inputs is such a problem. > It would be good to know exactly in which cases this rounding would happen - I can imagine there could be lots of other places where this could confound things - fcurves with modifiers, drivers, creating fcurves from python, expressions if blender ever gets that capability. Also inconsistencies between how one part of the animation system treats these inputs to another could cause problems for people too - I see that drivers currently evaluate floats to True when they pass 1.0, not 0.5. The 0-1 behaviour is very clear (once the curve passes the 1.0 point, it's True), understandable for users, and every other application I know of at least behaves this way. float precision error makes me think rounding at 0.5 this is worth keeping, > with larger values and some modifiers applied I bet values over say - > 1 can become .999 which then would get rounded down to .0. > Rounding at 0.5 means just means its less error prone even after > driver, modifiers, unit-scaling. > This is such a minor issue in the scheme of things I don't think it's very relevant compared to the others things mentioned. Most of the integer values people will be animating are 0/1 or at least numbers with very few digits. I really don't believe that this is enough to warrant it. And even in the imo quite unlikely case that maybe it does become a problem in practice, it would be better to solve this technical problem internally in a way that doesn't change behaviour for users, or old files. cheers Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [36779] trunk/blender/source/blender/ blenkernel/intern/fcurve.c: modify fcurve evaluation for bool/enum/ int values.
On Fri, May 20, 2011 at 10:17 AM, Campbell Barton wrote: > > Aligorith and I discussed this before committing, and are aware of the > implications. > > To me if you are editing floats, but have them converted to ints later > it makes most sense (on a user level), to round them. If the GUI makes > it unintuitive then it should be made intuitive (grid lines when > zoomed in for example), if you want I can add this. > Rounding them to whole numbers, sure, I totally agree, and if floor() works better then I'm all for it. But when animating bool values it makes perfect sense that as soon as your curve crosses from 0 to 1 (not 0 to 0.5), the value is switched on. Same goes for integer values, animating my curve from 4.0 to 4.51 should not switch the value to 5. cheers Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [36779] trunk/blender/source/blender/ blenkernel/intern/fcurve.c: modify fcurve evaluation for bool/enum/ int values.
On Thu, May 19, 2011 at 10:39 PM, Campbell Barton wrote: > Revision: 36779 > > http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=36779 > Author: campbellbarton > Date: 2011-05-19 12:39:57 + (Thu, 19 May 2011) > Log Message: > --- > modify fcurve evaluation for bool/enum/int values. was converting from a > float to an int which means 0.9x evaluates to 0.0, negative numbers are also > rounded up. > > Round at 0.5 instead & treat negative numbers the same. > Hi Cam, I don't think this is such a good idea - if you're animating a bool/int property with a curve you want it clearly defined. Currently having it stay 0 until the curve passes 1 works well, it's very explicit and clear as to where the transition will be. Having a curve progressing from 0 to 1 switching values now at 0.5 is quite untintuitive in the context of fcurves. cheers Matt PS. This commit also may have broken old animations in some files. ___ 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 [36654] trunk/blender/source/blender/imbuf : remove imbuf crect and profile_filename when building without LCMS
On Fri, May 13, 2011 at 2:53 PM, Campbell Barton wrote: > Revision: 36654 > > http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=36654 > Author: campbellbarton > Date: 2011-05-13 04:53:20 + (Fri, 13 May 2011) > Log Message: > --- > remove imbuf crect and profile_filename when building without LCMS > Hey Cam, if you like you can just get rid of it all (all of that lcms v1 stuff) entirely - it's a left over proof of concept that isn't connected up, doesn't actually do anything and probably should have been cleaned out by now. cheers Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] FW: console window back to appear
On Wed, May 11, 2011 at 9:32 AM, Doug Hammond wrote: > I like that idea. > > More commonly though we want the console log for any python back-trace, and > having the addon info there keeps it in the same place and is less of a > process/ordeal for the user to deal with. Ideally all that stuff can be piped through to blender's internal console, like the rest of blender reporting is/should be - I guess for that there needs to be a reports handle passed through to the render API. Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Camera Guides
On Tue, May 10, 2011 at 10:28 AM, Campbell Barton wrote: > in fact Ton also disagrees :), he > suggests camera BG images to have a FG option. This sounds best to me! Especially if camera bg/fg images support alpha (not sure if they do atm) Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [36451] branches/bmesh/blender: = bmesh version of prior trunk commit=
weird, here's the original commit from last year: http://lists.blender.org/pipermail/bf-blender-cvs/2010-April/027513.html In any case, i think it might be better to keep it with the release confirm preference rather than adding a new one for one specific tool only. It goes hand in hand, especially if you're using a tablet etc. cheers Matt On Tue, May 3, 2011 at 12:09 PM, joe wrote: > It wasn't in the code, and if it was it wouldn't have worked (the > launch event isn't recorded when edgeslide is executed after loopcut, > so I had to add an RNA property that lets you pass it to transform). > > Joe > > On Mon, May 2, 2011 at 7:55 PM, Matt Ebb wrote: >> On Tue, May 3, 2011 at 11:52 AM, Joseph Eagar wrote: >> >>> I added a new Input user pref, for ending edge slide >>> on mouse up after a loop cut. I can see ton's point on >>> the extra strain of click-hold-and-drag workflows. This >>> is might only be useful for tablet users. >> >> I thought this already happened if you have 'drag immediately' on or >> whatever it's called now, I added that behaviour for this reason. >> >> cheers >> >> Matt >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers >> > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [36451] branches/bmesh/blender: = bmesh version of prior trunk commit=
On Tue, May 3, 2011 at 11:52 AM, Joseph Eagar wrote: > I added a new Input user pref, for ending edge slide > on mouse up after a loop cut. I can see ton's point on > the extra strain of click-hold-and-drag workflows. This > is might only be useful for tablet users. I thought this already happened if you have 'drag immediately' on or whatever it's called now, I added that behaviour for this reason. cheers Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] No more subsurf and mirror modifier with scupt mode?
Hi Sergey, sorry to drag this up again, but I wanted to respond (I've been away the last few days). On Thu, Apr 21, 2011 at 5:45 PM, Sergey I. Sharybin wrote: > Looks like it was implemented in 2.49 exactly in the same way as it > was before enabling sculpting on deformed mesh in 2.5 and i don't find > it intuitive. Well, for the purposes of poly modelling it's quite good - especially when you have reference designs and you're tweaking it to fit shapes from camera etc. Anyway I can't speak for Tristan, but he told me it was the main reason he uses blender for poly modelling, even in high end studios where he has access to many other tools. Anyway, there was a big difference between the previous 2.5 situation and 2.49, in that previously in 2.5 it would interpret the sculpt strokes using the vertex locations of the original base level mesh. In 2.49 it allows you to actually sculpt on the subdivided surface and even if you can't sculpt on the mirrored part of the mesh this is usually fine for this purpose. If you're already using mirror modifier when poly modelling you're probably only concentrating on one half of the model anyway. Check out this video of 2.49 - the setup is a base mesh, with mirror and subsurf modifier - it shows how you can sculpt correctly on the original vertices that are transformed to the limit surface, on one side of the mirrored mesh. http://mke3.net/blender/devel/2.5/sculpt_subsurf.mov Anyway, I'm not the one that's been using this feature, perhaps I can get him in touch with you. I just know he's been bugging me about it every time I work with him ;) cheers Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Camera view navigation rant
On Mon, Apr 25, 2011 at 7:55 AM, Daniel Salazar - 3Developer.com wrote: > Also a lock camera to view option would be great so we can just move > the camera like we move any other viewport This is really all that's needed imo. Funky fly modes and game controls may seem cool at first, but they're red herrings - not nearly as useful as just being able to rotate the view consistently as you would normally. I use it all the time in Houdini. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] No more subsurf and mirror modifier with scupt mode?
On Thu, Apr 21, 2011 at 5:07 PM, Sergey I. Sharybin wrote: > Hi Ronan! > > Yep, you're right -- constructive modifiers (like array, mirror, > subsurf,...) were disabled when sculpting. This was made to make > sculpting more obvious and enable sculpting on deformed mesh. I forget the issues involved here, but I recall sculpting (modifying base level mesh, as you would in edit mode) with mirror and subsurf on was supported properly in 2.49 - a modeller friend I've worked with relied on this a lot - using the sculpt tools to tweak poly modelled objects. What's the difference between how it worked in 2.49 and now? is it possible at all to restore similar functionality as 2.49? cheers Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [36201] trunk/blender/source/blender/nodes /intern/CMP_nodes/CMP_huecorrect.c: Committing patch [#26960] bu MiikaH, fixes bug:
On Mon, Apr 18, 2011 at 8:20 AM, Daniel Salazar - 3Developer.com wrote: > oh? will this affect old blends and if so how? Perhaps - probably if the Hue shifting was used, it will change things, yes. The old behaviour was clearly wrong, my bad. Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Why has "CTRL y" been removed from blender ?
I didn't say exclusively, I said as a lowest common denominator. Like I said, no shortcut setup will work on every keyboard layout, so you have to pick *something* to optimise for. A US keyboard is probably most common so that's what it is. Of course there are now customisable shortcuts so you can make whatever presets you like for whatever keyboard layout you have. Matt On Sun, Apr 17, 2011 at 7:01 PM, Damir Prebeg wrote: > Blender is designed exclusively for US keyboard? Does that mean that > Blender will never support non English diacritic sings as ČĆŽŠĐ? ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Why has "CTRL y" been removed from blender ?
On Sun, Apr 17, 2011 at 5:37 PM, Damir Prebeg wrote: > Again, as I've said, CTRL+SHIFT+Z is perfect for standard US keyboard > users. For the rest of us (or at least users of QWERTZ) it's not. But > according your responses I see that we'll have to change that > individually. No shortcut organisation will be ergonomic for all keyboard layouts - there will always be someone who finds it inconvenient. As a lowest common denominator blender is designed for use with a US keyboard - for others, that's precisely what having customisable shortcut keys is for. Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Geometry in Compositor or Quadrangulation???
On Tue, Apr 12, 2011 at 3:35 PM, Daniel Salazar - 3Developer.com wrote: > Indeed! :) *but!* there are other uses for having a geometry node in > the compositor like bringing geometry normals, vectors, alphas and > what not and all interactive (no need for regular render). It's what > other compositors do to integrate the 3D view with the compositor. We > can see this as a step of integration. What do you think Matt? I think it's a bad idea. Blender already has a renderer and that's what it's for. Duplicating code to make an entirely separate renderer that's only used in the comp would end up in a world of overcomplicated pain. If there are problems with the workflow of rendering elements to be used in comp, then that should be worked on itself, I don't think the solution is to ignore it and build an entirely separate thing. But that's all putting the cart way before the horse anyway, when so much of blender's compositor is still at quite a basic level for 2d manipulations. Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Geometry in Compositor or Quadrangulation???
On Tue, Apr 12, 2011 at 2:19 PM, pete larabell wrote: Id be happy to make it a REAL > comp system that gets done somewhere else (VSE?) but im not a comp. > guy myself and didnt/dont understand where people WANT it done. If > someone... Maybe there was a misunderstanding here. Yes, in the compositor, editable interactively in the viewer where your footage is displayed is exactly where this sort of functionality should be. It's pretty shocking that there's even a discussion about this! Now whether the current code base supports implementing this cleanly and easily or not is a separate issue. Currently there's no kind of generic manipulator system to let you interact with nodes via an image viewer (like what you'd find in any other compositor), and I think that's a pretty strong pre-requisite for doing this properly. Having said that though, it's not really a blocker for coding the spline rasterisation in a comp node, you can easily get that working independently with a crappy/hacked up ui to specify the spline points. However having a proper means of interaction *is* a blocker for having a finshed, usable tool that should go in any released version. Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Geometry in Compositor or Quadrangulation???
On Tue, Apr 12, 2011 at 12:23 AM, pete larabell wrote: > In my efforts to better understand Blender's mesh/data representation, > I feel that doing an "easy" 3d_to_2d rasterizer for compo. tools would > be better for me to start with. Hi Pete, if the purpose of this is for spline roto shapes in the compositor, I wouldn't worry about full 3d to 2d stuff, or mesh data, or anything like that. The whole edit-mesh-in-3d-view-for-comp-matte is just a cheesy workaround for not having proper roto shapes editable in the compositor itself, and is much worse workflow wise. Ideally all you really need is to store your spline data in the comp node (can even reuse blender's beztriple structures etc perhaps) then tessellate* and render that to a greyscale soft matte. Although the problem of not currently being able to edit the bezier points in the image viewer still exists (hence the reason for all this 3d view->render layer->comp tomfoolery), there can be other workarounds for UI to use temporarily too. Trying to make a totally generic system of rasterizing blender's 3d data is really overcomplicating things and makes things too unclear between actual rendering and a super fast/interactive, specialised tool for roto. Matt * Is there any way of rendering (soft) spline shapes without tessellation? point sampling somehow? I have no idea, be interesting to know what other graphics libraries/compositors do. ___ 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 [36047] trunk/blender/source/blender/ python/intern/bpy_rna.c: change to fcurve keyframe coords broke simplify addon since the pro
I guess I'm asking under what conditions the rna arrays will be wrapped in python as vector types now - i.e. is there a chance that non-vectors could end up being represented as vectors this way? Eg. if the array in rna is just supposed to represent an array of single float values? cheers Matt On Fri, Apr 8, 2011 at 12:23 PM, Joshua Leung wrote: > If you're talking about why the fcurve keyframe coords are wrapped as > PROP_NONE instead of as vectors, the current problem is that wrapping > these that way tags them as being subject to units-system tinkering, > which is in most cases completely and utterly wrong (i.e. time or > rotations in meters/inches?!). > > On Fri, Apr 8, 2011 at 1:50 PM, Matt Ebb wrote: >> On Fri, Apr 8, 2011 at 11:40 AM, Campbell Barton >> wrote: >>> Revision: 36047 >>> >>> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=36047 >>> Author: campbellbarton >>> Date: 2011-04-08 01:40:54 + (Fri, 08 Apr 2011) >>> Log Message: >>> --- >>> change to fcurve keyframe coords broke simplify addon since the property >>> was no longer wrapped by python as a vector. now fixed size float arrays >>> with PROP_NONE subtype are wrapped as vectors since its convenient to >>> have x/y access. >> >> Is that all fixed size float arrays of rna size 3? or all float arrays >> in general? Sounds like if it is meant to be an array of single floats >> (for example) it wouldn't be right to wrap as a python vector type? >> >> cheers >> >> Matt >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers >> > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [36047] trunk/blender/source/blender/ python/intern/bpy_rna.c: change to fcurve keyframe coords broke simplify addon since the pro
On Fri, Apr 8, 2011 at 11:40 AM, Campbell Barton wrote: > Revision: 36047 > > http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=36047 > Author: campbellbarton > Date: 2011-04-08 01:40:54 + (Fri, 08 Apr 2011) > Log Message: > --- > change to fcurve keyframe coords broke simplify addon since the property > was no longer wrapped by python as a vector. now fixed size float arrays > with PROP_NONE subtype are wrapped as vectors since its convenient to > have x/y access. Is that all fixed size float arrays of rna size 3? or all float arrays in general? Sounds like if it is meant to be an array of single floats (for example) it wouldn't be right to wrap as a python vector type? cheers Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] GSoC 2011: Improving Retopology Tools
On Mon, Apr 4, 2011 at 9:27 AM, Sergey Kurdakov wrote: Alice's thread has already veered way off-topic and I hate to derail it even further, but I feel the need to comment on this for the sake of other students that may be reading: > the applicant must win an application so it should be interesting and > not trivial. This is true, but it doesn't mean that a GSOC proposal must do complicated things or use complex algorithms internally. It's often better for blender to have really well thought out and well crafted simple tools that work really nicely and are achievable in the scope of the gsoc, than it is to attempt to make complicated intensive tools that a) may not even get finished over the summer and/or b) may not be that useful in real world conditions. I don't mean to make a false dichotomy, but designing and creating simple, useful, tools that people love to use can easily be as much work as implementing a complicated algorithm, and can often be more productive for artists in the end. So students, if your proposal is mathematically or algorithmically complicated that's great, but you shouldn't feel discourages if it's not, as either can be challenging in their own way and can both make acceptable GSOC projects. cheers Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] GSoC 2011: Improving Retopology Tools
On Mon, Apr 4, 2011 at 8:03 AM, Sergey Kurdakov wrote: > all mentioned approaches was like these: take arbitrary mesh and make it > better. > it is developed with simple interface with mesh in - mesh out. > > in case you can suggest any better algos - and I provided best in > class of retopo algos Hi Sergey, i think there's a bit of confusion - the point for these tools is to have something manual and hands-on, so users can lay down polys exactly where they want them to be. Just like normal mesh modelling but as part of a retopo workflow. Having extra funky automatic tools can be great too, but it's a different thing. You still also need tools with manual control, even if only just to clean up problems after an automatic topology generation algorithm. So these manual tools are probably not mathematically intense, but implementing them will require good UI and workflow design, and working with artists to make them useful and efficient. So that's the purpose behind this wishlist item, to improve the manual editing tools for drawing/tweaking mesh topology manually on an existing reference surface, not to implement a fancy algorithm that guesses and generates geometry for you. Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Wiki log of API changes.
On Mon, Mar 14, 2011 at 4:16 PM, Campbell Barton wrote: > Now things are more stable I started a wiki for this: > http://wiki.blender.org/index.php/Dev:2.5/Py/API/Updates Thank you *very* much, this will be a big help! cheers Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Mapping and Soft Limits suggestions
On Fri, Mar 11, 2011 at 8:18 PM, Tobias Oelgarte wrote: > + (Add) - Parameters for Sampling/Blur in Procedural maps: > Don't see the need for them. If you have problems with moire effects, > you could always adjust the antialiasing settings for the renderer or > add focus blur with composite nodes. Then you have sharp lines in the > front and no moire in the back. Those are pretty nasty workarounds and shouldn't be necessary. And depending on what you're using such textures for, (eg. spec/bump maps) even with blurring it can still cause temporal aliasing - flickering. The main problem is that none of blender's textures (other than image maps) are properly filtered/antialiased. For some like clouds, blend, maybe others, it should be possible to do 'analytically' or via fading off higher frequencies etc, for other more complicated ones perhaps oversampling the texture itself could be an option (as opposed to oversampling the entire shading in the render). Regardless, this is a problematic long-standing issue in Blender, that it would be great to see an enthusiastic coder work on - perhaps a good project for someone new looking to get involved. Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Moving to Python 3.2.x
On Wed, Mar 9, 2011 at 10:00 AM, Martin Poirier wrote: > > Unless the benefits outweighs the hindrances, there's nothing lost by waiting > until the next minor release. This sounds sensible to me. Considering the widespread inconvenience caused by these sorts of things, it would seem that unless there's something dire that needs to be fixed by an update immediately, then it would be much better to wait a while so people can build from their linux distros easily, so that people using external modules don't get stuck, and so that any new bugs brought in by a new Python version can be avoided. Just because a new Python version is released doesn't mean that blender needs to start using it immediately - many 3d apps are still using Python ~2.5. Like Martin said, it's a case of benefits vs hindrances, and as time goes by and more people are getting on board with Python in Blender 2.5, the hindrances side of the equation is getting heavier and heavier, which means these changes need to be approached with a greater level of sensitivity and care. I feel this also applies to API changes now too. I'm not against change in itself, but I do feel that the current degree of external costs in the cost/benefit relationship isn't being given serious enough treatment. cheers Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [34914] trunk/blender/release/scripts/ui/ properties_material.py: Commit patch [#25939] material panel proposal by Ervin Weber (lu
On Friday, February 18, 2011, Ton Roosendaal wrote: > Whether you like it or not, it's how the system works. The trouble is though that there are more idiosyncracies and hidden complexities in the system than just these, that this new organisation doesn't express clearly. You end up running up against these when you try to use it anyway- for example the odd refraction behaviour in node trees and how some of the raytracing related settings (eg transmission settings) only take effect from the parent material container and not sub-material-materials. So should these be reflected in the ui too? I think it would be worse if it were. That's what I mean by saying if you want to represent the internal system accurately, the ui will make less and less sense. Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
