[Bf-committers] Help needed! Animation problems for 3D Audio GSoC
Hi guys! There's a serious problem with the way how animation works in regard to audio. The main problem is, that the animation system pushes the output, so it sets the data, renders a frame, advances to next frame (setting the data there) and renders again and so on, this works pretty good for video. But it doesn't work with audio, especially as audio has a very high temporal resolution (48000 eg. samples per second) compared to video (eg 25 frames per second) and moreover for audio the output device pulls the data, instead of the animation system pushing it, so the other way round. I talked to Martin (Poirier) and Joshua (Leung) and even we three together cannot think up a nice solution for the problem, maybe some genious mind here on the list who is more into the animation code than I am has a really nice idea. Here are specific problems in detail: * Subsample Accuracy: To avoid stair steps as we currently have in volume animation. * Multi Threading: Audio runs in a separate thread. * Speed: The access mechanism has to be realtime capable! * Asynchronous access: Audio playback is ahead of video playback normally (buffering the samples, feeding them to the output device). The first point can be solved easily with a proper interpolation if you have two nearby samples, one in the past, one in the future, so this basically requires the animation data to be cached/buffered somehow or at least asynchronous accessible. As the cached data also solves points 3 and 4 it's pretty obvious that we need the data cached, we had that conclusion already. Questionable is now how to get the cache? One obvious solution is to require the user to bake it, but this heavily impacts how easy the system can be used and as we also already concluded this is a really ugly solution. Better is the automatic caching which leads us to the problem point 2 multi threading. I don't know if it's possible to cache in the main thread? I bet not. And as long as blenders (animation) data isn't accessible multithreaded we still have no solution for the problem. So now your help is needed. Any ideas? If not I'll have to do the baking solution to finish the project. Regards ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Is alpha within Blender totally broken?
On Saturday, July 16, 2011 02:37:57 PM Troy Sobotka wrote: So far, I've been experimenting with several files and uptake tools using Blender in conjunction with Nuke. I have yet to be able to find a pattern that delivers proper alpha channels.Perhaps someone here can shed some light on the matter. I can't speak for Nuke, but if blender has a bug concerning alpha channels when rendering, then it also has the same bug in the compositer, because I've never had issues keying anything. The first two images look like what happens when trying to key a pre-multiplied image with a white background that isn't properly removing the matte. The second two look like trying to key with the matte being removed, but not useing linear color space blending in the compositing. But I don't know what your actual settings are. Straight-keyed Alpha, CM on, rendered to Half-Exr, Composited with CM on. (in blender) http://img692.imageshack.us/img692/779/compositescreencap.png -Reuben ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Windows 2000 build please.
On 17/07/11 09:38, Stephen Swaney wrote: On Sun, Jul 17, 2011 at 01:05:59AM +0200, Mathias Panzenböck wrote: On 07/17/2011 12:43 AM, Michael Fox wrote: You Couldn't be furthur from the truth, comparing win2k and XP is like comparing apples and oranges, they are vastly different internally, win2k is 16bit OS winXP in 32Bit, with different calls to different systems, may seem the same on the surface but underneith where we work, is 2 different worlds. Hence support for win2k was dropped Are you sure you don't confuse Win2k with Win9x/Me? After all Win2k is NT based and the direct predecessor of XP. (2k = Win NT 5.0, XP = Win NT 5.1) You might want to read what Mike Erwin said earlier in the thread: The current keyboard code (by jesterking I think) and upcoming 3D mouse support (by me) both rely on the Windows RawInput API, which only works on XP or newer. Far as I know, that is the only hard technical reason blocking a Win2000 build. That sounds like a bit of a show stopper. I'm pretty sure the Linux version doesn't rely on the Windows RawInput API. Speaking of which, I'm just trying to work out why anyone would be running Windows 2K rather than Linux. Has someone implemented a distributed Blender rendering engine that runs on botnets? There's a good reason right there to maintain the W2K build. -- Michael Judd 853 New Cleveland Rd Gumdale, Qld 4154 Email: m...@juddrobotics.com Phone: +61 (0)7 32452864 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Windows 2000 build please.
On Sun, Jul 17, 2011 at 10:35 AM, Michael Judd m...@juddrobotics.com wrote: On 17/07/11 09:38, Stephen Swaney wrote: On Sun, Jul 17, 2011 at 01:05:59AM +0200, Mathias Panzenböck wrote: On 07/17/2011 12:43 AM, Michael Fox wrote: You Couldn't be furthur from the truth, comparing win2k and XP is like comparing apples and oranges, they are vastly different internally, win2k is 16bit OS winXP in 32Bit, with different calls to different systems, may seem the same on the surface but underneith where we work, is 2 different worlds. Hence support for win2k was dropped Are you sure you don't confuse Win2k with Win9x/Me? After all Win2k is NT based and the direct predecessor of XP. (2k = Win NT 5.0, XP = Win NT 5.1) You might want to read what Mike Erwin said earlier in the thread: The current keyboard code (by jesterking I think) and upcoming 3D mouse support (by me) both rely on the Windows RawInput API, which only works on XP or newer. Far as I know, that is the only hard technical reason blocking a Win2000 build. That sounds like a bit of a show stopper. I'm pretty sure the Linux version doesn't rely on the Windows RawInput API. Speaking of which, I'm just trying to work out why anyone would be running Windows 2K rather than Linux. Has someone implemented a distributed Blender rendering engine that runs on botnets? There's a good reason right there to maintain the W2K build. Recently I got blender's GHOST building with SDL, this means theres no direct dependencies on the windowing system X11/GDI/Cocoa etc... though I only tested on linux. so it may be possible to make a windows/sdl build which doesn't have this limitation. In cmakes advanced options enable WITH_GHOST_SDL. ___ 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 troy.sobo...@gmail.comwrote: 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] Fwd: knifeless.blend animation
Hi all :) I’ve started working a bit on knife tool last days (reading code, playing a bit with it…), so here’s now my proposition about that tool: *Current state* Right now, you start it by hitting K and drawing (while K still pressed) a lasso gesture (modal part). When lasso is validated, knife cut is done (and modal part is finished). So basically, it works nice and smooth – there are just: — Some UI tweaks to be done in its panel (to hide “internal” properties like cursor or gesture curve, really easy to do). — Corner-cut pattern to re-enable (works fine for me, so again this is not a problem). *How it should work IMHO* I’d like to have knife behaving somewhat like transform tools, i.e. hit K enters modal, then you can switch options through a modal keymap, if you need it, and then draw your cut (either lasso with LMB, or straightline with MMB), and cut is done on gesture validating, like currently. IMHO, this would increase usability of the tool (esp. when you have many cuts to do, if the default settings are not good for you, having to use the UI to set them each time after the cut is painful). I’ve been playing with this idea, but I have problems, in that gestures are designed as “whole” modal funcs (they add a modal handler, have their own keymap [well, lasso/lines have none, btw], etc.). And it seems quite difficult to have a modal over (or inside) another modal… So I guess I’d have to find a way to have gestures without their “modal” part of code… In fact, if we want to have back things like snap to vertices, I might as well handle the whole gesture stuff inside knife cut code – which means I’d need acces to some lower-level gesture funcs… Anyway, I’d like to have your feelings about that proposed workflow first! :D Bastien Bastien Montagne montagne29 at wanadoo.fr Thu Jul 14 15:35:51 CEST 2011 wrote: Ahahah ! Excellent ! Ok, I gonna see what I can do (it doesn’t seem so hard, at first glance)… :) Ton Roosendaal ton at blender.org Thu Jul 14 13:59:59 CEST 2011 wrote: Hi all, http://www.youtube.com/watch?v=YS-ZauEIk_w Isn't that a great way to make a feature request? :) Both are old todo items already. Would be cool to get someone insipred to solve it! Laters, -Ton- Ton Roosendaal Blender Foundationton at blender.org www.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands Begin forwarded message: From: Paweł Kowal Date: 14 July, 2011 13:49:01 GMT+02:00 To:ton at blender.org Subject: knifeless.blend animation Hi Ton I've made an animation for you and Blender developers. So in exchange you can give us old knife and bevel back. :) Animation:http://www.youtube.com/watch?v=YS-ZauEIk_w Thanks for your work and our favourite software. Pawel ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Is alpha within Blender totally broken?
You are on the right tracks, Troy. The alpha issue is something we've been pondering about at Studio Lumikuu also. If you composite within Blender there really are no issues, but, in my case, using After Effects gives very weird results. I've always used premultiplied png -files before, as nothing else ever seemed to work, but from feedback I understood that this is plain wrong (the results were fine though, which tells me that Blender does it wrong). Anyways, I'm not able to look into this at the moment and produce any examples - I could check and report my results tomorrow. But just to let you know, I agree completely that there is something _seriously_ wrong about how Blender handles alpha channels. Cheers, -mats On 17.7.2011, at 6.06, Reuben Martin wrote: On Saturday, July 16, 2011 02:37:57 PM Troy Sobotka wrote: So far, I've been experimenting with several files and uptake tools using Blender in conjunction with Nuke. I have yet to be able to find a pattern that delivers proper alpha channels.Perhaps someone here can shed some light on the matter. I can't speak for Nuke, but if blender has a bug concerning alpha channels when rendering, then it also has the same bug in the compositer, because I've never had issues keying anything. The first two images look like what happens when trying to key a pre-multiplied image with a white background that isn't properly removing the matte. The second two look like trying to key with the matte being removed, but not useing linear color space blending in the compositing. But I don't know what your actual settings are. Straight-keyed Alpha, CM on, rendered to Half-Exr, Composited with CM on. (in blender) http://img692.imageshack.us/img692/779/compositescreencap.png -Reuben ___ 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] Fwd: knifeless.blend animation
Hi, before doing unnecessary work maybe you should check with bmesh too? If it's going to be merged anytime maybe it's better to work there? ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Is alpha within Blender totally broken?
From my little experience with color management, these issues sometimes have todo with not being in the right color space(linear) when compositing. Blender's internal as far as I have seen are not always consistent in this matter. Personally I've looked into parts of the code where compositing was done in color corrected space giving dark colors (More info on http://psy-fidelity.blogspot.com/2011/06/color-correction-revisited.html) and, while working on it I remember getting feedback about brightening as well though I can't remember the configuration that caused it. Since you work with exported images, my best guess is to check the image write functions, the final state and color space of the rendered result in blender and whether exporting the latter is done correctly with the former. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Is alpha within Blender totally broken?
What format are you using to export, png? Daniel Salazar 3Developer.com 2011/7/17 Αντώνης Ρυακιωτάκης kal...@gmail.com: From my little experience with color management, these issues sometimes have todo with not being in the right color space(linear) when compositing. Blender's internal as far as I have seen are not always consistent in this matter. Personally I've looked into parts of the code where compositing was done in color corrected space giving dark colors (More info on http://psy-fidelity.blogspot.com/2011/06/color-correction-revisited.html) and, while working on it I remember getting feedback about brightening as well though I can't remember the configuration that caused it. Since you work with exported images, my best guess is to check the image write functions, the final state and color space of the rendered result in blender and whether exporting the latter is done correctly with the former. ___ 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] Is alpha within Blender totally broken?
Some more info: As far as I know, in blender most image formats are written in color corrected space. OpenEXR is an exception as far as I remember. So maybe it's just a matter of non-conversion or erroneous conversion when writing the exr file? I've noticed similar behavior in other parts of blender. For instance, if you open a float image in the image editor, paint on it and save it as exr and reload it, you'll see subtle differences. This comes from the face that internally float images are handled as color corrected, not linear and when writing them to file no conversion is done. However, when -loading- the file, the image is tagged as linear and thus you get a color corrected result on color corrected colors. In my opinion, all float images should be in linear color space internally but apparently this is not the case. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Is alpha within Blender totally broken?
2011/7/17 Αντώνης Ρυακιωτάκης kal...@gmail.com: This comes from the face I meant 'fact', sorry! ___ 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 ideasma...@gmail.comwrote: On Fri, Jul 15, 2011 at 10:35 PM, Diego B bdi...@gmail.com 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] Can we please stop breaking APIs?
I have to agree with this completely. If the API contract is not maintained then the API is not worth learning. Having the API change without necessary reason after I've relied upon it to make something and sent it out the door makes the product unusable. It is better not to try and to make things only for a specific release -- in this case that would be 2.49. Sounds like you made a mistake in bothering to learn the 2.5 API at all. On Sun, Jul 17, 2011 at 7:04 AM, Matt Ebb m...@mke3.net wrote: I have a few things to say on this topic... On Sat, Jul 16, 2011 at 8:37 AM, Campbell Barton ideasma...@gmail.comwrote: On Fri, Jul 15, 2011 at 10:35 PM, Diego B bdi...@gmail.com 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
Re: [Bf-committers] Can we please stop breaking APIs?
I think this terms are becoming a bit unfair. Sure it might seem like little insignificant fixes here and there but let it accumulate for months and it becomes an important step up in usability. Of course we would like the API to never break but that just can't be done, specially by a single man. Back when we did the big gamelogic refactor, deprecated warnings worked wonders. I'd say that's the way to go here too. Don't let it accumulate into a second total re-write. Daniel Salazar 3Developer.com On Sun, Jul 17, 2011 at 5:22 AM, Jim Williams sphere1...@gmail.com wrote: I have to agree with this completely. If the API contract is not maintained then the API is not worth learning. Having the API change without necessary reason after I've relied upon it to make something and sent it out the door makes the product unusable. It is better not to try and to make things only for a specific release -- in this case that would be 2.49. Sounds like you made a mistake in bothering to learn the 2.5 API at all. On Sun, Jul 17, 2011 at 7:04 AM, Matt Ebb m...@mke3.net wrote: I have a few things to say on this topic... On Sat, Jul 16, 2011 at 8:37 AM, Campbell Barton ideasma...@gmail.comwrote: On Fri, Jul 15, 2011 at 10:35 PM, Diego B bdi...@gmail.com 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
Re: [Bf-committers] Fwd: knifeless.blend animation
In fact I've been reading the bmesh knife code recently, on my project to help close out the bmesh TODOs, and the code right now there may be doing some closer to what you want: hitting k takes you into a modal mode where successive left clicks make connected cuts; hitting e ends a cut and lets you start a new series; holding down CNTRL turns midpoint snapping on, holding down SHIFT turns all snapping off (by default, edge and vertex snapping are on); and using the middle mouse button temporarily takes you out of cutting mode so you spin the model. Who knows how long it will take to get bmesh into trunk (though I am trying hard to contribute to making that sooner rather than later), so it is probably worthwhile to fix the old version now, but it would be good to settle on similar behavior between old and new so that it will be easier for users to adapt to the change to bmesh when it comes. 2011/7/17 Αντώνης Ρυακιωτάκης kal...@gmail.com Hi, before doing unnecessary work maybe you should check with bmesh too? If it's going to be merged anytime maybe it's better to work there? ___ 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] Can we please stop breaking APIs?
I must say I agree with this completely. While I understand the need to make some occasional changes, on the whole it seems to be bad practice to change it as much as it has been recently. On Jul 17, 2011, at 5:04 AM, Matt Ebb m...@mke3.net wrote: I have a few things to say on this topic... On Sat, Jul 16, 2011 at 8:37 AM, Campbell Barton ideasma...@gmail.comwrote: On Fri, Jul 15, 2011 at 10:35 PM, Diego B bdi...@gmail.com 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
Re: [Bf-committers] Can we please stop breaking APIs?
A stable and backwards compatible API (and file format) is very important. Imagine if the C standard kept breaking its backwards compatibility every year? I think you owe it to your users to keep the API stable backwards compatible until a major version update (2 - 3 - 4, that's why Blender 2.5 should be called 3.0). My 2 cents, Erwin On Jul 17, 2011, at 6:00 AM, Nathaniel Lane carbon.based.life.form.from.ea...@gmail.com wrote: I must say I agree with this completely. While I understand the need to make some occasional changes, on the whole it seems to be bad practice to change it as much as it has been recently. On Jul 17, 2011, at 5:04 AM, Matt Ebb m...@mke3.net wrote: I have a few things to say on this topic... On Sat, Jul 16, 2011 at 8:37 AM, Campbell Barton ideasma...@gmail.comwrote: On Fri, Jul 15, 2011 at 10:35 PM, Diego B bdi...@gmail.com 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
Re: [Bf-committers] Can we please stop breaking APIs?
The change being complained about below is clearly to fit someone's notion of elegance, not functionality. As such, it wasn't a necessary changeand in my option it wasn't even a good change. If you don't supply a predictable API people will look elsewhere. It might take time before some other project takes the lead, but it will happen. It would help your API a whole lot if the documentation was written before the code. APIs need to conform to a contract to be useful. On Thu, Jul 14, 2011 at 11:41 PM, Mitchell Stokes moguri...@gmail.com wrote: Hello devs, I thought the 2.5 Python API was supposed to be considered stable, but lo and behold, a recent commit once again broke my scripts. The commit in question changes BGL.Buffer.list to BGL.Buffer.to_list() [1]. Bgui[2] makes use of BGL and is now broken. Furthermore, if I fix Bgui to work with Blender trunk and I release a version of Bgui before Blender 2.59 (which is possible), then Bgui would have a requirement of needing an in development version of Blender. If we're going to be changing APIs, can we at least keep old things around as deprecated for a release or two? [1] http://lists.blender.org/pipermail/bf-blender-cvs/2011-July/037581.html [2] https://code.google.com/p/bgui/ Thank you, Mitchell Stokes ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- No essence. No permanence. No perfection. Only action. ___ 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?
Update, added back bgl.Buffer.list, but it prints a deprecation warning. also added back slice support and fixed a crash on bad index access (since nobody found this in ~5 years tells me hardly anyone uses bgl.Buffer but whatever...). Since 2.5x my stance on blender API has always been to manage, documented breakages along the way since we evolve more then design, developers tend to add something that seems like a good idea at the time and later on discover it didn't work as intended or... later on add other functionality which makes the original out of place. We've even had functions in for over a year that never even worked (crashed infact), and nobody reported it. So I just don't buy it that once we call it stable that we should improving. @Erwin, The difference in blender is an application, not an SDK or a language. @Matt, you say that it is not documented is not a good reason to change/remove the feature, interesting that between py 3.2.0 and 3.2.1 they removed __class__ from the global namespace of a class, we used this in 6 or so places and I certainly noticed when blender broke on update. I reported a bug but was told I should never have been using it because its not documented. - Just to say other projects use this rationale - ofcourse you can argue both ways. So, everyone can agree that breaking blender is bad. But what we can't agree on is: - What is the blender API??? Operators? Addons? Python Modules?, Addons which have modules with other scripts might use?, any function in a module (even if its not defined in __all__ or documented)... And RNA, do we attributes in RNA that do nothing just so scripts don't break? If we really be strict about it, we cant remove tool options or preferences (even if they are not used) because a script could use it. Ok, this is not so much like changing bgl.Buffer, but it _is_ why I say our api will never be stable. However Its also silly to think that because some variable changes from a boolean to an enum that the api is horrible and scripts wont work anymore, which is why, practically (IMHO) this is not as bad as it sounds. On Sun, Jul 17, 2011 at 11:23 PM, Erwin Coumans erwin.coum...@gmail.com wrote: A stable and backwards compatible API (and file format) is very important. Imagine if the C standard kept breaking its backwards compatibility every year? I think you owe it to your users to keep the API stable backwards compatible until a major version update (2 - 3 - 4, that's why Blender 2.5 should be called 3.0). My 2 cents, Erwin On Jul 17, 2011, at 6:00 AM, Nathaniel Lane carbon.based.life.form.from.ea...@gmail.com wrote: I must say I agree with this completely. While I understand the need to make some occasional changes, on the whole it seems to be bad practice to change it as much as it has been recently. On Jul 17, 2011, at 5:04 AM, Matt Ebb m...@mke3.net wrote: I have a few things to say on this topic... On Sat, Jul 16, 2011 at 8:37 AM, Campbell Barton ideasma...@gmail.comwrote: On Fri, Jul 15, 2011 at 10:35 PM, Diego B bdi...@gmail.com 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
Re: [Bf-committers] Can we please stop breaking APIs?
Since 2.5x my stance on blender API has always been to manage, documented breakages along the way since we evolve more then design, developers tend to add something that seems like a good idea at the time and later on discover it didn't work as intended or... later on add other functionality which makes the original out of place. We've even had functions in for over a year that never even worked (crashed infact), and nobody reported it. So I just don't buy it that once we call it stable that we should improving. Ack, should be that we should stop changing or improving. ___ 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?
+1 to campbell, and keeping fallbacks and deprecation warnings for some time should really make this easy to manage and evolve Daniel Salazar 3Developer.com On Sun, Jul 17, 2011 at 7:49 AM, Campbell Barton ideasma...@gmail.com wrote: Update, added back bgl.Buffer.list, but it prints a deprecation warning. also added back slice support and fixed a crash on bad index access (since nobody found this in ~5 years tells me hardly anyone uses bgl.Buffer but whatever...). Since 2.5x my stance on blender API has always been to manage, documented breakages along the way since we evolve more then design, developers tend to add something that seems like a good idea at the time and later on discover it didn't work as intended or... later on add other functionality which makes the original out of place. We've even had functions in for over a year that never even worked (crashed infact), and nobody reported it. So I just don't buy it that once we call it stable that we should improving. @Erwin, The difference in blender is an application, not an SDK or a language. @Matt, you say that it is not documented is not a good reason to change/remove the feature, interesting that between py 3.2.0 and 3.2.1 they removed __class__ from the global namespace of a class, we used this in 6 or so places and I certainly noticed when blender broke on update. I reported a bug but was told I should never have been using it because its not documented. - Just to say other projects use this rationale - ofcourse you can argue both ways. So, everyone can agree that breaking blender is bad. But what we can't agree on is: - What is the blender API??? Operators? Addons? Python Modules?, Addons which have modules with other scripts might use?, any function in a module (even if its not defined in __all__ or documented)... And RNA, do we attributes in RNA that do nothing just so scripts don't break? If we really be strict about it, we cant remove tool options or preferences (even if they are not used) because a script could use it. Ok, this is not so much like changing bgl.Buffer, but it _is_ why I say our api will never be stable. However Its also silly to think that because some variable changes from a boolean to an enum that the api is horrible and scripts wont work anymore, which is why, practically (IMHO) this is not as bad as it sounds. On Sun, Jul 17, 2011 at 11:23 PM, Erwin Coumans erwin.coum...@gmail.com wrote: A stable and backwards compatible API (and file format) is very important. Imagine if the C standard kept breaking its backwards compatibility every year? I think you owe it to your users to keep the API stable backwards compatible until a major version update (2 - 3 - 4, that's why Blender 2.5 should be called 3.0). My 2 cents, Erwin On Jul 17, 2011, at 6:00 AM, Nathaniel Lane carbon.based.life.form.from.ea...@gmail.com wrote: I must say I agree with this completely. While I understand the need to make some occasional changes, on the whole it seems to be bad practice to change it as much as it has been recently. On Jul 17, 2011, at 5:04 AM, Matt Ebb m...@mke3.net wrote: I have a few things to say on this topic... On Sat, Jul 16, 2011 at 8:37 AM, Campbell Barton ideasma...@gmail.comwrote: On Fri, Jul 15, 2011 at 10:35 PM, Diego B bdi...@gmail.com 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
Re: [Bf-committers] Help needed! Animation problems for 3D Audio GSoC
On Sun, Jul 17, 2011 at 8:31 AM, neXyon nex...@gmail.com wrote: Hi guys! There's a serious problem with the way how animation works in regard to audio. The main problem is, that the animation system pushes the output, so it sets the data, renders a frame, advances to next frame (setting the data there) and renders again and so on, this works pretty good for video. But it doesn't work with audio, especially as audio has a very high temporal resolution (48000 eg. samples per second) compared to video (eg 25 frames per second) and moreover for audio the output device pulls the data, instead of the animation system pushing it, so the other way round. I talked to Martin (Poirier) and Joshua (Leung) and even we three together cannot think up a nice solution for the problem, maybe some genious mind here on the list who is more into the animation code than I am has a really nice idea. Here are specific problems in detail: * Subsample Accuracy: To avoid stair steps as we currently have in volume animation. Use bezier curves to plot the sound volume but I guess you have that bit figured out having just read farther. Why is the animation data not readable multithreaded? I could understand writable though. -- Douglas E Knapp Creative Commons Film Group, Helping people make open source movies with open source software! http://douglas.bespin.org/CommonsFilmGroup/phpBB3/index.php Massage in Gelsenkirchen-Buer: http://douglas.bespin.org/tcm/ztab1.htm Please link to me and trade links with me! Open Source Sci-Fi mmoRPG Game project. http://sf-journey-creations.wikispot.org/Front_Page http://code.google.com/p/perspectiveproject/ ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Can we please stop breaking APIs?
I think it is clear what is needed. Devs: Devs retaining the freedom and flexibly to continue to innovate and improve blender without being boxed in by old stuff, standards and crud. (I am sure without having to document it would be wonderful too! :-)). Programmers / Users: Documentation of changes that are clear and easily available. Perhaps they should ship with the product. Perhaps the change of the intro graphic would be a signal to watch out for changes? A transition period for that change to take effect that throws deprecation warnings during which old and new should continue to work. No one has addressed how long this should be. Should it be 6 months? That would make it one Ubuntu cycle. Or maybe 12 months? That should be enough time for anyone. It was said that an API is not a language but really for anyone that programs in it all day long, it is. Changing it is in effect changing the language that the programmer has to work in, often in annoying pointless ways (at least to the programmer). I see it like saying printf is not part of c language, its just a function, but we all know it is and changing it would really piss off a lot of people. Change is good when it is progress and results in a better product. We are all willing to put up with that but we don't like changes that do not appear to benefit us. I know that sadly we programmers do not know the benefits that the changes bring us because they are often hidden but we do know the pain of it when they get in our way and slow us down and piss off our bosses and customers. Thanks devs for all the good, hard work! -- 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] Blender developer IRC meeting notes, july 17 2011
Hi all, Here's the weekly notes of today's IRC meeting. 1) 2.58 and next release - New design for managing keymaps is under review, Brecht will handle this next week(s). - Campbell is back from holidays! Next week more bug fixing, and Unity UDK/FBX testing. Note: Unity could refresh direct blend reader (like they had for 2.4), would be nice target for them to work on. Campbell can advice. - Daniel Salazar reminds the much faster Mesh Deform binding code should be in release: http://codereview.appspot.com/4529048/ Daniel used it successfully for months. On Brecht's review list still. - Python changes discussion: First off: all changes are being gathered in wiki clearly: http://wiki.blender.org/index.php/Dev:2.5/Py/API/Updates Proposal: from now on, critical changes get announced first on the bf- python list for review: http://lists.blender.org/pipermail/bf-python/ The Python API owner team gets expanded with two new team members, proposal is to add Sergey and Daniel S. Campbell will use them to give approval on API updating as well. http://lists.blender.org/pipermail/bf-python/ - 2.59 splash committee: Sebastian K, Francois T and Daniel Genrich should appoint new judges. Notify Ton! - Knife tool upgrade fixing: under review/design still. Bastien Montagne gives it a try. - Bastien updated patch for Weight Group modifier. Campbell checks. - Nathan Letwory: Mike Erwin's SpaceNavigator branch is not ready for 2.59 yet, but they will try! Wiki page or doc with design overview is coming this week too. 2) Other projects, branches - Sergey: stripped the Carve boost lib (saves 6 MB). This needs a test in OSX (compile) and Windows (speed). https://svn.blender.org/svnroot/bf-blender/branches/carve_booleans - Question, how is Ocean Sim coming? Todd McIntosh or Matt Ebb know! - Note, branches ready for mergers can notify it here: http://wiki.blender.org/index.php/Dev:2.6/Source/Development/Merge_And_Integration_Plan - Nicholas Bishop updated skin and re-mesh patches with latest trunk: http://nicholasbishop.net/ 3) GSoC - Most of the students made cool midterm videos, Ton will collect and post article. - Midterm passed: one drop out (fluids), one didn't make it (game logic), 15 continued. Thanks, -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[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 hardl
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.
*edits his node_header.c back...*
On Sun, Jul 17, 2011 at 18:14, Lukas Toenne lukas.toe...@googlemail.com wrote:
Revision: 38452
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=38452
Author: lukastoenne
Date: 2011-07-17 16:14:52 + (Sun, 17 Jul 2011)
Log Message:
---
Removed the autoconnect call when adding new nodes, this hardly ever gives
usable results and leads to annoyed artists.
Modified Paths:
--
trunk/blender/source/blender/editors/space_node/node_header.c
Modified: trunk/blender/source/blender/editors/space_node/node_header.c
===
--- trunk/blender/source/blender/editors/space_node/node_header.c
2011-07-17 13:29:50 UTC (rev 38451)
+++ trunk/blender/source/blender/editors/space_node/node_header.c
2011-07-17 16:14:52 UTC (rev 38452)
@@ -94,8 +94,6 @@
if(node-flag NODE_TEST) node-flag |= NODE_SELECT;
}
- snode_autoconnect(snode, 1, 0);
-
/* deselect after autoconnection */
for(node= snode-edittree-nodes.first; node; node= node-next) {
if(node-flag NODE_TEST) node-flag = ~NODE_SELECT;
___
Bf-blender-cvs mailing list
bf-blender-...@blender.org
http://lists.blender.org/mailman/listinfo/bf-blender-cvs
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Is alpha within Blender totally broken?
Hi Troy, The issue you have is a combination of several issues; as others wrote as replies already, we have things reasonably OK work internally, but when it gets to colormanagement and file saving things get fuzzier. It's been noted on our todo wiki in many places that both 'colormanagement' (now only gamma correction) as our alpha methods need to be improved: - Support both premul as straight alpha internally. Some operations work best with premul, others with straight... especially color operations like gamma or RGB curves make premul fail easily. Internally in Blender, only premul is supported now. - Color management code currently only corrects rgb, but leaves alpha unaltered. That gives bad 24 bits gfx for premul alpha. - File formats can also hardcode define alpha types (premul or straight). Blender just saves the data as you deliver it. You can save ot premul-png for example, which is 'forbidden'. Of course Blender should save out correct pngs by default, but I'd rather fix our internal alpha methods then too. So yes... there's work to do here! :) However, if you'd export EXR to nuke, saved with ColorManagement on, it should all be fine. -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 16 Jul, 2011, at 23:37, Troy Sobotka wrote: So far, I've been experimenting with several files and uptake tools using Blender in conjunction with Nuke. I have yet to be able to find a pattern that delivers proper alpha channels.Perhaps someone here can shed some light on the matter. It has been noted before that there has been some mishandling of alpha with regards to all of the non linear output formats such as TIFF, PNG, etc. However, upon testing quite extensively with EXR, I am still struggling to see a proper use case currently. I have experimented with the following four combinations: CM ON - Straight Alpha CM OFF - Straight Alpha CM ON - Premul Alpha CM OFF - Straight Alpha In all of the instances, there is significant darkening or lightening near the edges, suggesting something is wrong. When ingested into Nuke, the results are equally confusing. I hope that someone can shed some light on the issue, as it is worrying. The same impacts can be noted when we use blurs, only they are augmented by a greater region of disparity where the alpha blurs occur. The following images are direct output from Nuke with proper premul settings where appropriate. The same issues appear in other image editors and different file formats. In this instance, the tests were conducted with EXR output files saved with RGBA. CM ON - Straight - http://img228.imageshack.us/img228/1639/cmonstraight.jpg CM OFF - Straight - http://img43.imageshack.us/img43/3961/cmoffstraight.jpg CM ON - Premul - http://img687.imageshack.us/img687/8082/ cmonpremul.jpg CM OFF - Premul - http://img194.imageshack.us/img194/6276/cmoffpremul.jpg The concern I have is that I believe Blender is mishandling alpha channels in all instances. This is partially obscured by the fact that whatever technique is being used to encode it is also being used to decode it. In some instances, the alpha channel effects are also difficult to notice, as it is subject to the size of the alpha region and the nature of the background. In the above tests we can clearly see the darkening over the magenta region near the antialiased alpha edges. This can be far more greatly seen when we execute a blur. I have done some testing with gamma adjustments on the alphas to try and rectify the situation, believing that it may be because of a log to lin or vice versa error, to no avail. Premul also doesn't seem to impact the results and solve the problems. Here is to hoping someone can lend some thought to the issues at hand. 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
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
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 venom...@gmail.com 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.
*edits his node_header.c back...*
On Sun, Jul 17, 2011 at 18:14, Lukas Toenne lukas.toe...@googlemail.com
wrote:
Revision: 38452
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=38452
Author: lukastoenne
Date: 2011-07-17 16:14:52 + (Sun, 17 Jul 2011)
Log Message:
---
Removed the autoconnect call when adding new nodes, this hardly ever gives
usable results and leads to annoyed artists.
Modified Paths:
--
trunk/blender/source/blender/editors/space_node/node_header.c
Modified: trunk/blender/source/blender/editors/space_node/node_header.c
===
--- trunk/blender/source/blender/editors/space_node/node_header.c
2011-07-17 13:29:50 UTC (rev 38451)
+++ trunk/blender/source/blender/editors/space_node/node_header.c
2011-07-17 16:14:52 UTC (rev 38452)
@@ -94,8 +94,6 @@
if(node-flag NODE_TEST) node-flag |= NODE_SELECT;
}
- snode_autoconnect(snode, 1, 0);
-
/* deselect after autoconnection */
for(node= snode-edittree-nodes.first; node; node= node-next) {
if(node-flag NODE_TEST) node-flag = ~NODE_SELECT;
___
Bf-blender-cvs mailing list
bf-blender-...@blender.org
http://lists.blender.org/mailman/listinfo/bf-blender-cvs
___
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] Help needed! Animation problems for 3D Audio GSoC
Hi, I'd like to ask people with good knowledge of Blender's animation and animation related structures to please consider this problem, this is rather important for neXyon's GSOC project. Thanks, Martin --- On Sun, 7/17/11, neXyon nex...@gmail.com wrote: From: neXyon nex...@gmail.com Subject: [Bf-committers] Help needed! Animation problems for 3D Audio GSoC To: bf-committers@blender.org Received: Sunday, July 17, 2011, 2:31 AM Hi guys! There's a serious problem with the way how animation works in regard to audio. The main problem is, that the animation system pushes the output, so it sets the data, renders a frame, advances to next frame (setting the data there) and renders again and so on, this works pretty good for video. But it doesn't work with audio, especially as audio has a very high temporal resolution (48000 eg. samples per second) compared to video (eg 25 frames per second) and moreover for audio the output device pulls the data, instead of the animation system pushing it, so the other way round. I talked to Martin (Poirier) and Joshua (Leung) and even we three together cannot think up a nice solution for the problem, maybe some genious mind here on the list who is more into the animation code than I am has a really nice idea. Here are specific problems in detail: * Subsample Accuracy: To avoid stair steps as we currently have in volume animation. * Multi Threading: Audio runs in a separate thread. * Speed: The access mechanism has to be realtime capable! * Asynchronous access: Audio playback is ahead of video playback normally (buffering the samples, feeding them to the output device). The first point can be solved easily with a proper interpolation if you have two nearby samples, one in the past, one in the future, so this basically requires the animation data to be cached/buffered somehow or at least asynchronous accessible. As the cached data also solves points 3 and 4 it's pretty obvious that we need the data cached, we had that conclusion already. Questionable is now how to get the cache? One obvious solution is to require the user to bake it, but this heavily impacts how easy the system can be used and as we also already concluded this is a really ugly solution. Better is the automatic caching which leads us to the problem point 2 multi threading. I don't know if it's possible to cache in the main thread? I bet not. And as long as blenders (animation) data isn't accessible multithreaded we still have no solution for the problem. So now your help is needed. Any ideas? If not I'll have to do the baking solution to finish the project. Regards ___ 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 [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 venom...@gmail.com 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?
On Mon, Jul 18, 2011 at 2:17 AM, Knapp magick.c...@gmail.com wrote: I think it is clear what is needed. Devs: Devs retaining the freedom and flexibly to continue to innovate and improve blender without being boxed in by old stuff, standards and crud. (I am sure without having to document it would be wonderful too! :-)). Programmers / Users: Documentation of changes that are clear and easily available. Perhaps they should ship with the product. Perhaps the change of the intro graphic would be a signal to watch out for changes? A transition period for that change to take effect that throws deprecation warnings during which old and new should continue to work. No one has addressed how long this should be. Should it be 6 months? That would make it one Ubuntu cycle. Or maybe 12 months? That should be enough time for anyone. 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 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. - Operator arguments, which are effectively a part of the api since for example exporting an object to some file format depends on them, many scripts use operators, any change to an operator argument could break a script. Also consider we never really standardized on these, even now I need to go over all importers and exporters and make their arguments consistent with eachother. - API's which are mostly for internal use - eg: `addon_utils.enable()` may need to have keyword arguments modified, `rna_info` module which is used for document generation may need to be changed too. I think its fair to say their are our own internal apis which are not likely to be used by extensions and we can keep updating these making breaking changes when needed - because they are written for a very specific purpose, they are also not apart of our api docs. - RNA attributes, in this case I think its fair to separate things like bpy.context.scene.objects from bpy.context.user_preferences.filepaths.use_save_preview_images, where accessing some very specific settings, changes in user preferences IMHO are acceptable without long discussions + deprecation + documentation, this goes for some other areas of the api which are not likely to be used by scripts, rna access to logic bricks, some parts of our windowing api. - Remove modules which are not used, sometimes we think to add utility modules which don't end up getting used at all, (even remain non-function and buggy in a recent instance), in this case its just not useful to deprecate IMHO. To allow changes in these areas to me this is pragmatic common sense, but it does go against the don't break the api mantra. It was said that an API is not a language but really for anyone that programs in it all day long, it is. Changing it is in effect changing the language that the programmer has to work in, often in annoying pointless ways (at least to the programmer). I see it like saying printf is not part of c language, its just a function, but we all know it is and changing it would really piss off a lot of people. Agree with this for core functionality, 'bpy', 'bpy.props', 'bpy.context', 'mathutuls', 'mathutils.Vector', ''... but further there are too many details that may change in sub modules. Change is good when it is progress and results in a better product. We are all willing to put up with that but we don't like changes that do not appear to benefit us. I know that sadly we programmers do not know the benefits that the changes bring us because they are often hidden but we do know the pain of it when they get in our way and slow us down and piss off our bosses and customers. Sure but its subjective, my main concern is that we give an api which is misleading in its implementation. With newer developers you see mistakes because if misunderstandings about how the api works. I clearly remember being fed-up with the 2.4x api and having to read its source code more then the api reference because it was just very confusing as to how the api was meant to work. While not every change is to this end, heres an example of how bgl.Buffer.list was confusing. # this does nothing (creates a list, modifies it and throws it away) buf.list[0] = 1, 2, 3 # this _does_ do something, since the list is made up of wrapped data buf.list[0][0], buf.list[0][1], buf.list[0][2] = 1, 2, 3 # So using a function in this case makes it more clear that the return value doesn't hold a connection to the original data. # a python developer can see that this function performs a conversion rather then accessing internal data as is common with attributes. buf.to_list()[0] = 1, 2, 3 # Now .to_list() is not an equivalent of
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 ideasma...@gmail.comwrote: 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] Blender developer IRC meeting notes, july 17 2011
On Mon, Jul 18, 2011 at 2:57 AM, Ton Roosendaal t...@blender.org 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
