Re: [Bf-committers] Sculpt stroke questions
Also the Grab brush is best to grab backfaces too.. I know that Letterip and Jason Wilkins did a lot on this code.. maybe they can give insight? On 24/08/2013 15:41, Jonathan Williamson wrote: In most cases I agree, this would be a good change. However one case where it would cause problems is using the inflation brush on thin objects (like fingers) to fatten them. You really want to inflat in all directions, not just one side at a time. This tends to lead to lumpiness. On Saturday, August 24, 2013, Hadrien Brissaud wrote: I don't see any scenario where one would like the backfacing vertices to be affected by brush strokes, but that's just me. Thanks a lot for fixing this, I'll test and report sometime later. Hadrien On 24 August 2013 13:31, Antony Riakiotakis kal...@gmail.comjavascript:; wrote: Yes. The standard brush should be fixed in current svn. However brushes such as the clay strips brush behave weird due to the plane offset issue and the fact that the front faces only option is not always enabled. This last part is left to the user but the first part should be fixed in the code. The point of this question is to make sure there are no legitimate reasons to take back facing vertices into account when calculating the sculpt plane. ___ Bf-committers mailing list Bf-committers@blender.org javascript:; http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org javascript:; 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] Import Mesh with VertexColor?
Probably not teh answer you want to hear but a few years ago when I was going back and forth between blender and maya I wrote a simple vertex colour ascii format file and exporter's /importers for blender and maya.. sadly I don't have the code and even if i did blender side would be 2.49 so would need scrapping and starting again and maya side would need to be re-written for max/softimage anyway.. just saying it's not too hard to 'roll you own' solution in some of these cases.. Ultimately I'd like full featured fbx IO but until then... On 17/07/2013 18:52, Thomas Volkmann wrote: Hi, it's the time of the year again, when I want to use Blender for some 'real' tasks at work. And as usual I am having huge problems getting my Data into and out of Blender. Last time it was Camera animation that I couldn't get into Blender*, this time I'm using the vertex-colors when importing a mesh into Blender (from Softimage or Max). So my question: Am I doing something wrong, or is it just not supported? Again my usual plea (short version): If Blender wants to take part in professional pipelines, the data IO is crucial! cheers, Thomas *workaround: export to fbx and use the Autodesk FBX-converter to convert to collada -dae If someone is interested, there is a initiative for a standard Cameradata IO format: https://groups.google.com/forum/#!topic/xsi_list/G3Fuwh0qG7I ___ 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, July 14, 2013
Will this have any use/crossover on Blender internal renderer? On 15/07/2013 15:43, Knapp wrote: On Mon, Jul 15, 2013 at 1:41 PM, Ton Roosendaal t...@blender.org wrote: Hi, Bart asked me for a user-readable text about OpenSubdiv for BlenderNation: OpenSubdiv is Pixar's open source project to handle Subdivision Surface generation and drawing. In Blender this is currently handled by 1 thread only, and it needs to generate the subsurfed data first, before it can draw. OpenSubdiv instead: - allows full threading, including use of GPU - creates and draws subsurfed on the fly, so you don't need to generate/store data - has excellent crease support - has adaptive (screen space) subdivision - supports Ptex natively (non UV texture mapping) In Cycles OpenSubdiv will replace the incomplete subdivision surface implementation, to enable faster BVH builds and lower memory usage for subdivision surfaces, as well as Ptex rendering support. Integrating will require a lot of work inside Blender however, so it will take some time before there is an official release with OpenSubdiv support. Especially support for multires and sculpt will be complex. A planning for this work and a set of actions still has to be defined. Nevertheless, Brecht is already on it, and expects to have a first WIP demo of Cycles-OpenSubdiv at Siggraph next week! Note about the license: OpenSubdivs Apache license is only GPL V3 compatible. Blender is GPL V2 or later, so that should work fine. However, we do need to check every library we use too, Carve still is GPL V2 only (already connected with Tobias about it). Thanks, -Ton- This is a good user video about it. http://www.youtube.com/watch?v=xFZazwvYc5o ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposal on Default Settings
On 06/05/12 18:28, Gianmichele Mariani wrote: I tend to agree with everyone on both the trackball and the manipulator proposal. It will sure make it harder for people coming from other software. Enabling this in the initial presets is probably a better idea (Blender classic, Maya, Blender Pro). Have you talked with Nathan? I know he was working on better keymaps which in some way crosses the better defaults ideas. .Gian Suggestion: It's 2012 so...enable VBO! On Sun, May 6, 2012 at 5:47 PM,shota...@gmail.com wrote: The only thing I'm against is the manipulator. Its familiar for users coming from other packages, its a great visual cue for all out new users, and its good for animation for things like gimbal lock. Otherwise I like it! --Original Message-- From: PabloVazquez.org Sender: bf-committers-boun...@blender.org To: bf-blender developers ReplyTo: bf-blender developers Subject: [Bf-committers] Proposal on Default Settings Sent: 6 May 2012 17:50 Hi Devs (and curious people on the list like myself), As mentioned in the meeting, here is a list of proposal defaults based on community feedback from users (both old and new), and teachers. http://wiki.blender.org/index.php/Proposed_Default_Settings There are fair reasons for each one of these changes, if you need more explanation you can ask here or in the Wiki. Cheers! -- Pablo Vazquez CG Artist - Blender Foundation Certified Trainer Twitter: http://twitter.com/venomgfx E-Mail: cont...@pablovazquez.org Website: http://www.pablovazquez.org ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers Sent from my BlackBerry® ___ 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 continuous grab works terribly with a graphics tablet... a dangerous default unless it can be made smart enough to know what kind of input it has and act accordingly... ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] 3D Cursor and Border Select
Tweak border select on lmb does work a treat, but is really annoying without click on empty space also being deselect it's a setup I used extensively when 2.5 first enabled keymaps Just saying because I'm totally +1 on not doing piecemeal changes to keymaps there's also an irony that blender historically relied so much on key shortcuts for *any* speed of operation, but the real speed gains come from knowing *whatever* keys well a rationalisation of shortcuts can be good, but is almost always hated by anyone that uses the software all the time On 26/02/12 16:16, Ton Roosendaal wrote: Hi Daniel, Note that LMB-tweak can be set to border select (modal). That's what users will expect anyway, and it will keep working together with lmb-click for other non-modal ops. Putting a modal ops (like border select) to lmb-click will be very annoying. -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 26 Feb, 2012, at 1:29, Daniel Salazar - 3Developer.com wrote: In my personal use experience and more importantly when teaching to students setting the 3D cursor with LMB click is one of the main sources of headaches. Cursor just moves around every second on the student's files What I do is set it to double click, this makes it harder to set by mistake while being just as simple to set when needed Also this enables me to change border select behavior to be just click and drag, no need for pressing B, which is the expected behavior by everyone it seems I'd like to propose this changes to be made as soon as possible cheers Daniel Salazar patazstudio.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 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposal: Object creation
As someone who almost never wishes I could go back and change object parameters because a cube, sphere, pyramid or whatever is only useful 99.99% of the time as some geometry to start editing into something else I have a couple of questions. The appeal of modelling in blender is that it's just so much more immediate than other tools. Having the object locked to only its initial creation parameters when entering edit mode sounds very cumbersome. How will you make it not so? Also, how will your system work if I add an object whilst in edit mode? There was a python solution a while back that would allow you to do transforms etc and then go back and change the creation parameters as long as you hadn't edited the created mesh. (entering edit mode was the key there I believe) IIRC it only worked on primitives created in python rather than the native ones, but if that worked for all primitives It strikes me that is a much more blender solution... Seriously though, in real world use rather than theoretical tests does anyone use a primitive /without /editing it? for me that's so rare i'd class it as almost never. On 04/10/11 10:35, Martin Bürbaum wrote: Thomas Volkmanntho...@heulfritze.de wrote: +1 That means for example, that you can change the segmentsnumber of a sphere at any later time (as long as you didn't do anything else to it). Did I get that correctly? Pretty much, yes. Not sure how the needed changes would break existing tools and scripts, though. e.g. The generated mesh data would still be there, but scripts can not edit them (or depending on implementation, not find them at all). Cheers, Martin ___ 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] Proposal: Object creation
On 04/10/11 11:19, Thomas Volkmann wrote: Maybe the sphere wasn't the best example...I'll try another one: Torus-knot-addon. You have to decide what it should look like the instant you add it to your scene. If you want to change it after you added other stuff, you have to completly redo it :/ Hmm, esoteric ;) I'd say box/sphere are the classic examples. The old python based redo for addons coped with that, as long as you hadn't entered edit mode on that object.. My point boils down to: Entering edit mode is a clear statement of intent that you want to hand edit the mesh so you shouldn't have to do something else to be able to do that. Adding a cumbersome convert step to cope with the (in my view) rare case that you have a primitive knocking about your scene that you decide much later to edit seems to be the wrong solution... Talk to Meta androcto about the python add implementation and why it was removed. Besides, a power user in that rare case will just snap the cursor to the old primitive and ADD a new one... or just add a new primitive elsewhere in the scene and share the mesh data... ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Proposal: Object creation
Ok, sounds good! On 04/10/11 11:50, Martin Bürbaum wrote: The appeal of modelling in blender is that it's just so much more immediate than other tools. Having the object locked to only its initial creation parameters when entering edit mode sounds very cumbersome. How will you make it not so? I _mostly_ agree when it comes to primitives. But that still doesn't mean that the option of non-destructive behaviour is not useful :-) Any idea to make this as transparent as possible is welcome. The first idea I have would be to make the conversion completely transparent. I.e. as soon as you change the content in edit mode you get an indicator that the object can now be modified, but parameters can not be tweaked anymore. (A simple undo would revert this of course.) Another way would be to make the locked creation an optional/separate process. Also, how will your system work if I add an object whilst in edit mode? Nothing changes here. Adding stuff in edit mode (i.e you already have the object unlocked) would behave like it does now. You can redo operators, but you can obviously not change the parameters in the long run. There was a python solution a while back that would allow you to do transforms etc and then go back and change the creation parameters as long as you hadn't edited the created mesh. (entering edit mode was the key there I believe) :-D That was what I referred to in my original mail - that is/was my code. It was canned because of various issues. The main problem was basically that the framework I'm proposing right now does not exist yet. And no, there was no locking involved in the scripts (or smart behaviour like recognizing if edit mode was entered). It was more of a workaround than solution. This proposal aims for the latter. IIRC it only worked on primitives created in python rather than the native ones, but if that worked for all primitives It strikes me that is a much more blender solution... Please keep in mind that internally there is no difference if the object was created by Blender directly or from python. So having a framework that _supports_ this new way of creating objects will then enable us to use it to do useful stuff with it. IMO it's not supposed to be a replacement, other may have a different view on it though. Worst case: I'm all for keeping the existing way of adding object if we can't find a decent way of making this transparent. Seriously though, in real world use rather than theoretical tests does anyone use a primitive /without /editing it? for me that's so rare i'd class it as almost never. The proposal is not focused on primitives-only, it's a general view on object creation. As you mentioned already there are a lot of more complex mesh scripts that could benefit from the integration of a system like this. I personally don't do it often with _primitives_. But IF I do it's a bit of a pain checking the geometry to see how the mesh looks and the re-create with exactly the same geometry but one parameter tweaked :-/ Workflow of users differ heavily, so I assume other people use it even more than me and not at all. Discuss! Cheers, Martin ___ 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] Proposal: Canvas compositing
On 02/08/11 16:27, j.bak...@atmind.nl wrote: - Positionable input nodes (data can be positioned/scaled/rotated on the canvas) - Backdrop handles (interactive handles on the backdrop) Looks really cool and presumably easier than current transform nodes... As a dual screen user I'd question why this has to be just the backdrop of the node editor... Image editor or perhaps movie clip editors would seem to be candidates for this Especially if matte/mask creation is to be added at some point (drawn masks especially) If render layers have the render size from their scenes and canvas gets its render size from the scene that contains it then I wonder where a problem might arise? Why does the canvas need to be different than the render size? If i need it to be different i can have the composite in a separate scene to the renderlayer... If it must be separate then a set rendersize from canvas or set canvas to rendersize operator would surely fit the bill? I'm assuming the rotation, translation and scale relative to the canvas will all be exposed somewhere... (it sounds like your adding this data to the render layer node itself, so should be exposed so it can be driven by node input, animated, receive numeric input etc What does this mean for the current pan and zoom of backgrounds in the compositor? (always a bit of an invisible function in my book, being keyboard shortcut only) given the onscreen widgets for the canvas, are they to set the canvas size (probably only needed once per session) or to pan and zoom? (used constantly) Obvioulsy if the canvas is in another/its own space type then you can use standard 2d view nav. Maybe the node editor could get modes like the sequencer? viewer, nodes or combined? I'd still argue that the idea of transform nodes isn't bad for additional animation (say you make a sub comp as a node group and want to animate the transform of the whole result Anyway, these are just some initial thoughts! ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] The dilation I am seeing in Blender is imo not good. I thought I'd propose an alternative (if there's support)?
+1 I always thought I was just using bake margins that were too small! these results look amazing! Definately worth pursuing in my book! Hiding the unwrap seams by manual choice is one thing, but the reduced artefact here is much nicer On 21/07/11 01:13, Morten Mikkelsen wrote: The dilation I am seeing in Blender is imo not good. I thought I'd propose an alternative (if there's support)? Here's a close-up of the dilation blender does -- http://jbit.net/~sparky/blender_dial/bakezoom_BI_dial.png Here's a close-up of the dilation I was able to do outside of blender using diff. code -- http://jbit.net/~sparky/blender_dial/bakezoom_other_dial.png The bumped visual you get using the first one is this (ugly filtering scar) -- http://jbit.net/~sparky/blender_dial/scr_BI_dial.png The visual you get using the other method is this (significantly more subtle) -- http://jbit.net/~sparky/blender_dial/scr_other_dial.png The blend file to produce the texture is up there -- http://jbit.net/~sparky/blender_dial/bmake.blend This is the full-res baked result you get with dilation using blender -- http://jbit.net/~sparky/blender_dial/bake_BI.png and this is using the alternative dilation -- http://jbit.net/~sparky/blender_dial/bake_other_dial.png I dumped everything here http://jbit.net/~sparky/blender_dial/ incl. a blender file. Let me know what you think. Cheers, Morten. ___ 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] Material Nodes: No normals in worldspace?
On 21/07/11 00:37, Tobias Oelgarte wrote: in this simple case. It could be much easier and powerful to have worldspace normals and maybe even the view-vector in wordspace coordinates. This would allow many new possibilities for reflection mapping and other cool stuff. On top of that it would work smoothly together with GLSL and shouldn't be so hard to implement. Maybe this can convince one of the programming gods to implement this feature? It would be much easier! For reflection I've found the current system works fine, but if normals were changed to world space then view would have to as well It'd be nice to get object origins and current shading points world coordinates available in the nodes too so you could do x distance from empty for example... I know you can a bit of that in texture nodes... but would be nice in material nodes! ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Better approaches to Defocus?
And my proposal changes that how? On 28/06/11 21:14, François T. wrote: yeah it's just you can have other purpose of VB which is not related to Mblur or dof. 2011/6/28 michael williamsonmicha...@cowtoolsmedia.co.uk In general I agree, I love the group node stuff, but when both node types are sortof related and need the zbuffer as input and essentially destroy it making it unusable for the other it seems to make a lot of sense to combine in this case. You could have 3 separate nodes... dof, vector blur and both... or it could be a single node with 3 modes... it needn't be cluttered or have any extra overhead for the unused stuff... Dof and motion blur are extremely common things to use together the user shouldn't have to jump through hoops to get them to play nice... I guess there's an argument for shipping a library of node groups too... but that's another topic. On 28/06/11 20:02, François T. wrote: yeah and if you only need one of them, you get an other complicated node for nothing. With nice grouping system and precomp, and better UI as well, you can manage a clean not too complicated node setup. I believe the new group system is a step in that direction, still need a bit more work though but since it is much more customizable, you can hide some crazy setup and just bring the needed value at the top of your node. I think that's the spirit rather than having one big node which does everything and nothing at the same time just my opinion though F 2011/6/28 michael williamsonmicha...@cowtoolsmedia.co.uk On 28/06/11 17:41, Daniel Salazar - 3Developer.com wrote: glitches, it's all glitches! how i'd love some good dof and vblur nodes:) Daniel Salazar 3Developer.com Even better would be a unified DOF/Vblur node so you can have both together without overcomplicating teh node setups! Currently they're pretty incompatible! ___ 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] Tool Shelf Toggling On/Off Tab Mockup
Sadly there's no key to restore a minimised header! (they're all to easy to close when using a tablet with no way to restore in the cycles branch! (for headers I'd like to see the old 2.49 way and disable minimising them) ON TOPIC, I'd prefer tool props to be its own panel it's too small when at the bottom of the toolshelf I always use F6 in preference The toolshelf itself is invaluable in paint, sculpt etc but something I don't use ever when modelling... the operator panel on the other hand is something I'd very much like to have on screen all the time when modelling but hardly ever when painting! I only mention to illustrate that people are different and like different things and a flexible UI should accommodate ;-) On 13/06/11 10:01, M.G. Kishalmi wrote: I like how Brecht solved this in the cycles branch: he removed the (+) icons all together. there are keys for props [N] and tools [T] and menu entries (in view) for all 3. maybe we can simply add a key for tool-props? suggestion: [ALT]+[N] or maybe.. don't allow the tool-props to be hidden at all? just find a way to have it sit there at the top/bottom of the tools nicely. cheers, mario On Mon, Jun 13, 2011 at 6:19 AM, Jonathan Smithj.jay...@gmail.com wrote: You are probably right, using a lot of space doesn't seem to be the best answer.. back to drawing board. On Sun, Jun 12, 2011 at 11:31 PM, Jim Williamssphere1...@gmail.com wrote: I'd agree. Find ways to use less real estate, not more. On Sun, Jun 12, 2011 at 9:04 AM, Aurel W.aure...@gmail.com wrote: Hi, I think that this would be rather unpractical, it takes way to much visual space for what it represents. If i want to collapse those panels, i want them gone, not taking a lot of space on the screen like those huge buttons. Blenders gui already got way too unefficient in 2.5, especially when it comes to, space needed for certain gui elements and panels. aurel On 12 June 2011 13:28, Jonathan Smithj.jay...@gmail.com wrote: I have written up a mockup/proposal on a different way to do the closing and opening of the Tool Shelf and Properties Shelf UI, other than using the little plus icons, on my talk page. http://wiki.blender.org/index.php?title=User_talk:JayDez I am, unfortunately, not a good enough coder to actually implement this, so I'm just putting it out there as an idea, either for another coder to implement, or just to promote discussion about the way this works, since I don't think that it is done very well in the current version of Blender. Any comments on or critiques of the mock up would be welcome. Cheers, Jonathan ___ 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 -- No essence. No permanence. No perfection. Only action. ___ 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] Blender developers irc meeting,
On 12/06/11 16:26, Ton Roosendaal wrote: - Bug tracker at 174 open reports now. 2) Other Projects - Cycles: Brecht made notes for how Texture Workflow could work: http://wiki.blender.org/index.php/Dev:2.5/Source/Render/TextureWorkflow He will continue on this with also UI proposal (mockup, proof of concept code) and then ask for official reviews. 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 Reading that wiki entry i have a couple of comments. Quote: /Do we need a full shaded GLSL draw mode for offline renders, given that we already have a Rendered draw mode, or do leave this as a game engine feature? / I really must say ABSOLUTELY! Texture painting has come a long way, this SOC promises much more and to lose GLSL would be a huge blow just when Blender is becoming a real contender in this area. Bump map preview in GLSL is a killer feature and a big bonus for texture painting right now that alone is worth the hurt. Painting specularintensity maps/glossiness maps is also very nice using GLSL (and useful for more physically correct shading models where glossiness == roughness and a specular intensity == fac on a mic closure... Not to mention simpler stiuff like painting an alpha map. I think that users can accept GLSL not being a /perfect/ representation of the final result, but close enough. Obviously, painting in rendered mode would be for those demanding absolute final output, but on even a butch system I'd still prefer a quick preview. Quote: /Mapping and Stacking / /Questions / * /Do we need a type of texture stack, or are mix nodes enough? / * /Do we go for fatter texture nodes that contain e.g. mapping and color modification options, or for multiple lighter nodes? If we go for fatter nodes, how can we avoid the UI getting crowded by showing all those options? If we go for lighter nodes, how can we make managing them easier? / * Personally I think that having a primary focus on a clear node editor is fine Using groups should be the focus for removing UI clutter I think that having lots of nodes isn't a problem as you can easily have macros to add specific setups As long as the node editor is a central place to see what is going on then it's fine. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender developers irc meeting,
On 12/06/11 19:58, Brecht Van Lommel wrote: Assuming you use those in your scene, GLSL is not going to match the scene lighting well anyway and it's likely to be slow for editing. So I think it's reasonable to not try to match the scene lighting and make some approximations to make it more editing oriented rather than trying to do accurate lighting, instead of trying to match t Oh, Ok. For sure, that'd be fine... I know I like using a couple of hemi lights and a sun but I guess the GL lights for solid could meet needs... It might be an idea to make a bunch of presets for the solid GL lights and improve access (rather than having them tucked in prefs), but I guess that's a different discussion I feel a potential addon coming on! ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender developers irc meeting,
On 12/06/11 20:05, michael williamson wrote: On 12/06/11 19:58, Brecht Van Lommel wrote: Assuming you use those in your scene, GLSL is not going to match the scene lighting well anyway and it's likely to be slow for editing. So I think it's reasonable to not try to match the scene lighting and make some approximations to make it more editing oriented rather than trying to do accurate lighting, instead of trying to match t Oh, Ok. For sure, that'd be fine... I know I like using a couple of hemi lights and a sun but I guess the GL lights for solid could meet needs... It might be an idea to make a bunch of presets for the solid GL lights and improve access (rather than having them tucked in prefs), but I guess that's a different discussion I feel a potential addon coming on! ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers Although it's nice being able to just spin the sun sometimes! ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Fracture Tools don't work in Blender 2.57
I committed a fix for this just yesterday ;-) Cheers, Mike On 16/04/11 09:51, Markus Kasten wrote: Hello, The Fracture Tools don't work in the official Blender 2.57 release, caused by serval Python API changes. I created a patch and send it to the original author, but I still have no answer (send it about a week ago, probably the mail has been eaten by his spamfilter). Maybe somebody from the bf-committers mailing list can apply them to the subversion repository. I uploaded the fracture_ops.py patch here: http://www.pasteall.org/20738 and the edited data.blend with fixed Bomb- and Recorderscript here: http://www.pasteall.org/blend/6013 Greetings from Germany, Markus Kasten ___ 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] Frame Rate: Time Remapping
I used this feature for the first time about a week ago... I'm using an svn build a week or so old and it works for particles if you bake... I've heard it's not working for cloth and smoke has its own time value for simulations Part of the issue is that this feature doesn't seem to work for everything... and until it does then what would be most intuitive doesn't matter! That said, It's quite easy to use as is, (if you find it in the first place) but: If the renderer could have non integer frames then it could all be much simpler and intuitive The first place I looked to slow down time was the render step size: If you could set the render step size to a float value step = 0.5 would render twice as many frames and so be half speed... Done! When that didn't work the second place i tried was the sequencer: I set a scene strip to have a speed effect strip that doubles its duration hoping it'd render the interpolated frames... Instead it renders as in source and just holds them as if they were any other image sequence... Once I found the feature it was pretty easy to use, but with the quirks already mentioned by some (having to drag further on the timeline... non baked things going beserk... On 25/03/11 08:42, Troy Sobotka wrote: On Mar 23, 2011 11:39 AM, Tobias Oelgartetobias.oelga...@googlemail.com wrote: The feature works partially, but some strange things are happening: Are you certain it still works in SVN? It seems potentially broken. I would like to have this feature back or reimplemented, since it is the only simple way to adjust the timing. As someone with a smidge of experience in film work, I could not agree at all that the implementation works or is, from the vantage of a motion picture tool, simple. I wonder if there are things we could do that would serve motion picture artists better here? 1) Should time remapping be given the central piece of UI real estate where it is currently located given frequency of use? 2) Within other contextual application workflows, does the current implementation resemble or appear understandable to a motion picture artist? 3) Aside from (2) above, given understanding of the two adjustable variables, does it work as expected? I worry that in all of the above questions time remapping may be sub optimal in its current implementation and execution. Would this be more well suited as a technique to leverage out of the VSE? At the very least it would seem logical to migrate the current implementation to an alternate panel of lesser prominence. Sincerely, 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] Proposal: to remove the TexFace options
Downloading now! How do the changes affect GL view and the texture painting workflow? I have tons of scripts and addons dealing with UV and texture face workarounds, so am curious how this works. On 11/03/11 12:16, Dalai Felinto wrote: Hello there, the code is read, up and running here. I sent it to the tracker because it will make easy for review (I'm going to ask to Benoit to take a look at the BGE changes, but it would be nice if someone could take a quick look at the Blender part as well - Brecht do you think you could take a look at it?). [1] If someone wants to test it I made builds for the three main plataforms [2], [3], [4]. I didn't address backward compatibility, so I still would like to hear what is the best solution. I don't think an automatic conversion is a good idea (it would affect rendering, and split materials will likely get messy). So still looking for help into find the best alternative here. Are there bugs? Likely (it's a big patch after all). But I've been chasing them over the week and believe it's all manageable. If you can help testing, please report them in the patch entry. And the one million dollar question is: Can this be incorporated before Blender 2.57 release? if there is no agreement by Sunday I will see if I wake up early to discuss that in the meeting. [1] - Tracker - http://projects.blender.org/tracker/index.php?func=detailaid=26461group_id=9atid=127 [2] - Windows build - http://www.graphicall.org/builds/builds/showbuild.php?action=showid=1754 [3] - Linux build - http://www.graphicall.org/builds/builds/showbuild.php?action=showid=1751 [4[ - OSX build - http://www.graphicall.org/builds/builds/showbuild.php?action=showid=1753 Thanks, Dalai -- www.dalaifelinto.com @dfelinto ___ 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 [34914] trunk/blender/release/scripts/ui/ properties_material.py: Commit patch [#25939] material panel proposal by Ervin Weber (lu
On 16/02/11 21:56, Tobias Oelgarte wrote: What i really dislike is the confusion between program internal view and the users perspective. We have a panel that is called Transparency. But you can't get transparency with this panel alone I would have to agree... It would seem to me that moving these checkboxes to the pipeline section makes sense at some levels but muddies the waters at the same time. Surely usability should be paramount. A simple solution to keep all parties happy would be to simple duplicate the checkboxes... why not have the button in pipeline (where it makes sense for nodes) and in the transparency panel where it just made a lot of sense? Duplicating the button is so trivial, and personally I think workflow for blender could be greatly enhanced with more places to access functions from. it needn't be this or that it can be both! ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] extension clause
What happens when a third party writes a script that links to an external library? an example in the current code would be the quicktime libs THE USER has to sign up for the licence agreement of the quicktime sdk, obtain the source and then compile their own blender... This is common in music software too for Steinbergs VST support: user gets SDK by signing up to EULA then compiles their own version It's fine in teh above cases to distribute the code without Infecting either Apples code or Steinbergs... Both SDKs have a EULA that prohibits re-distribution, which presumably protects them... it's the end user doing the linking In blender's case this becomes interesting with say the Autodesk FBX sdk which has a similar restriction... So here's what I don't get: Are things really any more complicated if a compile wasn't necessary? say if Quicktime support, VST or FBX could be added via a python script? just because it's compiled on the fly? Requiring the user to sign up to any 3rd party libs agreement with a no re-distribution clause (common in commercial software) then there can surely be a commercial path to extend blender already existing That or Apple, Steinberg and Autodesk are already infected by the GPL by no act of their own... I'm guessing this must be the case else the blender Vray script would infect vray? Or is the act of compiling the difference? ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] extension clause
On 22/11/10 21:21, Michael Williamson wrote: . It's fine in teh above cases to distribute the code without Infecting either Apples code or Steinbergs... i meant the linking code! ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] hotkeys and sculpting
My initial reaction was ewww, muscle memory It's about the only shortcut I use in sculpt mode (I switch brushes using the toolbar) so I've never had Toms problem... But after thinking a while, I'd think that rather than moving it to something obscure it'd be better on all those keys freed up because you're in sculpt mode ctrl seemed a much better candidate as lasso select will never be used in sculpt mode, and it's consistent with painting apps like, well, painter! and ctrl is right there as a home key... but then I remembered that ctrl is used in sculpt now! ... so what about RMB? select is awkward and feels like a mistake in sculpt mode... especially when you accidentally select and drag other objects in the scene... it may not suit all tablet users, but feels more progressive than choosing a random unused key On 15/07/10 02:41, Jonathan Williamson wrote: I would agree with changing the key for this However, rather than H, which is quite far from the normal left-hand location on the keyboard, perhaps we could do Q and/or W? These don't make much sense from an abbreviation standpoint but they are easy to reach and available. F doesn't really make much sense either. Jonathan Williamson Instructor - http://www.blendercookie.com Personal Trainer - http://www.mavenseed.com Founder/Artist - http://www.montagestudio.org On Wed, Jul 14, 2010 at 2:16 PM, Tom Mletter...@gmail.com wrote: For sculpting I'd really like to have the Fkey related key combos changed to some other key. The reason for this is that even though I use Blender almost exclusively for sculpting work - whenever I want to switch to the flatten brush, I press the FKey. Thus I would recommend that the brush radius, strength, and angle functions currently bound to the FKey be moved to a different key - perhaps the HKey. ___ 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] Proposal to Remove Features
/File browser should hide hidden files and filter types by default. Every file browser does this, and it just seems to be what you want nearly always anyway. Especially on mac/unix hidden files are really in the way in the home directory. / Yes please! could it filter more types? sticky coordinates is something I've HAD to use in the past (followed be a script to convert to UVs) because of project from view not working quite right if that's fixed then fine! * Controversial list: *I'm sure that I'm not alone, but here's the things on that list I have used (and so would miss) all edges option should be on if removed! it's crucial to be able to see all the edges rather than hiding them for game dev blend sky is useful for quick access as well as lighting... bounds draw type is something I use a lot for organising scenes for games worlds... shadow render pass seems like a bad thing to remove... particle line/path/billboard seems to have no alternative? I presume that if the cubic material interpolation option is removed it'll be switched on right? On 08/07/10 18:30, Brecht Van Lommel wrote: Hi, Here's a proposal to remove a number of features before 2.6. I've been gathering items on this list for the last few months as I came across them. If there is enough agreement I can make the changes quickly. If you agree or disagree with items on the list, please read the explanation at the top and comment on the wiki page. http://wiki.blender.org/index.php/Dev:2.5/RemoveFeaturesProposal Thanks, Brecht. ___ 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] Interaction Presets...
Great feature! I've noted some things with the Maya keymap and have done a new version... get it here: http://www.cowtoolsmedia.co.uk/scrip...es-maya.py.zip http://www.cowtoolsmedia.co.uk/scripts/mikes-maya.py.zip In doing so, a couple of things came up! 1) in edit mode with the Maya preset Alt-lmb doesn't rotate the view... It's correct in the keymap so un-clear why this is happening 2)In my edited version of the maya keymap Alt-lmb works, alt rmb (view zoom) is broken in edit mode... - in my keymap I changed select with to RMB so there may be a clue there... 3)lmb-drag: border select in maya creates a new selection, shift-lmb-drag toggles the select state of what you drag over... * toggle isn't do-able with box select in blender... * If i trigger box select extend with shift-lmb tweak the action can only be completed by releasing the shift key... feels wrong Notes on my preset version: Because the standard blender select is very un-maya like I've kept it out the way with select with set to rmb and set border select to be explicity LMB rather than select... This causes a conflict with setting the 3d cursor so I moved that to ctrl-shift lmb I also added clicking on empty space = deselect all... ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Interaction Presets...
michael williamson wrote: In doing so, a couple of things came up! 1) in edit mode with the Maya preset Alt-lmb doesn't rotate the view... It's correct in the keymap so un-clear why this is happening ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers Ok, so it's our old friend Alt + select mouse being used for viewnav conflicting with edge loop select... the cascade-ing effect of these changes Any suggestions for a new home for edgeloop select? (would also allow emulate 3 button mouse and LMB select in default keymaps I guess) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] wacom tablet issues
/ Hi all, I'm wondering if anyone else has experienced the following issues with Wacom tablets under 2.5, or if it's just me. I can't really submit a bug report because the issues themselves are unpredictable. I'm assuming that it's related to the Wacom tablet because people using mice at work don't seem to have the same issues: - When sculpting, sometimes the tool continues to modify the mesh even after the pen has left the tablet. (Repeatedly clicking off the model or tabbing in and out of Blender solves the issue.) - When UserPreferencesEdit.drag_immediately is true it works as expected, but every so often the behavior defaults to how it works when UserPreferencesEdit.drag_immediately is false. Toggling the value in the preferences window has no effect; restarting Blender fixes the issue. - The corner drag handle that's used to split areas is extremely hard to click on. (With a mouse it's much less so.) - There's a noticeable (50 - 100ms or so, by my estimate) lag between when you put the pen to the tablet to rotate the 3D viewport and when the viewport actually begins rotating, moving, or trucking. This lag is considerably lessened by going into full screen mode, but it's still apparent enough to cause a jump when positioning the view. I think the problems have something to do with a threshold value; past a certain pressure threshold the system registers a click, but sometimes that threshold is not passed yet the system driver sends a click message, which confuses Blender. Is there a way to debug tablet values directly inside Blender by, for example, reading RNA and having it pump into text fields created by Python? Perhaps some way to piggyback on system messages for input without eating those messages? Thanks, ~ Charles / I get the sculpt stroke not ending when I lift the pen from the tablet too (sometimes, not all the time, not often enough to be annoying! I too cannot narrow down exactly how it happens but suspect it might be related to a view nav move also... ... (ubuntu 9.10 64bit with an intuos4) ...so it seems it's on all OS! probably not a driver thing I don't use drag immediately so cannot confirm corner drag handles are very hard to hit (also on my tablet pc) I almost never use a mouse though so cannot comment on whether that's easier I don't get (haven't noticed) any lag when rotating the view ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
