Re: [Bf-committers] Lack of coordination and communication in Blender development
Kai makes a good point. Sometimes I'll see something new and think cool, but why is today the first time I'm hearing about this?!? So I understand the impression of things happening behind closed doors. When is the best time to share an idea though? The second it's thought up or after working out the details? At this point why not code it up to test how well the idea works? And once the code is done, why bother presenting it as an idea or design? It works, it's done! From the inside this seems like getting things done. From the outside it seems like working behind closed doors. I'm really bad about this myself :) but catch myself getting annoyed when other people do the exact same things. I don't think anyone is *hiding* their work though. Just following habits of not being actively open. Even if an area will be owned by one or a few people, it's important to have designs out in the open so everyone knows what's going on. Earlier is better. Lots of comments surrounding any design will be nonsense -- or input of wildly varying levels of quality as Martijn put it more politely. But I'd rather sift through noise than seem to be working in secret. And it's also important to document things that were *considered* but not chosen as part of the final design. Broader documentation of decision-making processes will reduce surprises and hopefully eliminate the impression that core developers ignore the needs and ideas of others. What is the proper forum for proposals and other design docs? code.blender.org? wiki pages for work in progress? I see posts on blenderartists and Twitter and G+, which seem unofficial but also reach an audience that might not follow the mailing lists or hang out on IRC. Great, now I suddenly have the urge to document my own stuff. Mike Erwin musician, naturalist, pixel pusher, hacker extraordinaire ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Lack of coordination and communication in Blender development
On Sat, Aug 15, 2015 at 12:49 PM, Kai Kostack kaikost...@gmx.net wrote: Hello Martijn, hello Antony, I'd like to emphasize that I have great respect for every person involved with Blender development. I'm following the mailing lists more or less since 2004 and I remember often core redesign took place only within a small group of people and not so much in public. This isn't always a bad thing, though. As developers, it's our job to do what the wider Blender community *needs*, and sometimes that conflicts with what it *wants*. The mesh refactor and the debate over ngons was a perfect case of this: a lot of people were disturbed by the idea of supporting ngons in Blender. This never bothered me, nor did it bother other senior developers. We knew the users would come around in the end, so we simply went ahead and did it anyway. I do agree that Blender needs a better way to coordinate tasks between developers, but I don't think a big open process is the answer. That's what nearly killed Gimp. Part of this is Blender's lack of modularization compared to other 3D software, which is what the current redesign effort is aimed at. A more modular/graph-based design will make it a lot easier to implement features without stepping on other people's toes. Scorpion81 and me will take care of a list of the requirements. We don't even expect guarantees, we only would like to make sure our interests are not overlooked this time and at least being considered. This tends to be a time constraint problem more than anything else. The best thing to do is to keep reminding people you exist, so they'll keep you in mind. Above that I really think the interaction between core devs, hobby devs and users could use improvement in this regard. Thank you so far. Best, Joe ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Implicit Surface Nodes
Hi all. I've been working on a pynode proof-of-concept for an implicit surface node system (basically, node-based metaball surfaces). This network: http://www.pasteall.org/pic/91966 Produced this surface: http://www.pasteall.org/pic/91967 It's a little hard to read the network since I've not finished group nodes yet (which I plan on using to implement higher-level, more artist-friendly nodes). Basically, all it's doing is calculating a (crude) metaball cube, using perlin noise to warp the domain space. The nodes are designed to form extremely simple symbolic expression trees, the idea being to generate code for a GPU marching cubes tessellator. These trees are designed to be symbolically differentiated; you can see a 'Scalar Derivative' node in that network, it does not use finite differences. I'll be publishing the code soon (everything is done in python as an add-on). I still need to work out the details of how these nodes will be tied to scene objects, and I don't have a working implementation yet of the fancy marching cubes algorithm (dual grid) you use for hard-edged objects ( :( ). Anyway, I just thought I'd share. Best, Joe ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Lack of coordination and communication in Blender development
Hello Marc, I appreciate your answer but we're aware of what you're explaining. We have a more fundamental problem. Currently there is a redesign of various Blender internals ongoing. Design decisions will be made that are crucial for our modifier to meet all required coding conventions. Our workarounds have been criticized as bad by core developers earlier. However, those hacks have been necessary until now because it couldn't be solved otherwise due to bad Blender design. So, now that there is the chance to fix those issues in depth we would like to monitor that design decision making process and comment early on on it to make sure, they don't oversee some requirements that will be important for us in the future. At the moment it looks like everything important happens behind closed doors. -- Kai ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Lack of coordination and communication in Blender development
Hi Kai, As far as I am aware nothing has happened behind closed doors so far. Everyone is trying to give input of wildly varying levels of quality. It would be good if you could put together a (partial) proposal or at least a list of things you think you need (based on current limitations?) in order to successfully integrate the fracture modifier. The 2.8 process has only just begun and it seems early to be wanting guarantees to be heard or making assertions that the core team is not listening. I would suggest to any and all people wanting to influence what happens next, make a good (partial) proposal or at least try and describe the current limitation you feel should be addressed. Martijn On Sat, Aug 15, 2015 at 8:20 PM, Kai Kostack kaikost...@gmx.net wrote: Hello Marc, I appreciate your answer but we're aware of what you're explaining. We have a more fundamental problem. Currently there is a redesign of various Blender internals ongoing. Design decisions will be made that are crucial for our modifier to meet all required coding conventions. Our workarounds have been criticized as bad by core developers earlier. However, those hacks have been necessary until now because it couldn't be solved otherwise due to bad Blender design. So, now that there is the chance to fix those issues in depth we would like to monitor that design decision making process and comment early on on it to make sure, they don't oversee some requirements that will be important for us in the future. At the moment it looks like everything important happens behind closed doors. -- Kai ___ 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] Lack of coordination and communication in Blender development
I will also adopt Martin's position here. The design of the interaction model with physics, node driven mesh construction and dependency graph is still in it's infancy. Making generic comments on design of blender is not helpful either. Most people on this list have no idea of the context in which you are referring (myself included). Please be more specific: How does blender's design block your progress and what would you like to see. Is any of the current redesigns of blender internals blocking your progress and how? Only big recent internal redesign I can think of currently is the looptriangle refactor, but I don't see how this could be hindering physics in any way. On 15 August 2015 at 20:36, Martijn Berger martijn.ber...@gmail.com wrote: Hi Kai, As far as I am aware nothing has happened behind closed doors so far. Everyone is trying to give input of wildly varying levels of quality. It would be good if you could put together a (partial) proposal or at least a list of things you think you need (based on current limitations?) in order to successfully integrate the fracture modifier. The 2.8 process has only just begun and it seems early to be wanting guarantees to be heard or making assertions that the core team is not listening. I would suggest to any and all people wanting to influence what happens next, make a good (partial) proposal or at least try and describe the current limitation you feel should be addressed. Martijn On Sat, Aug 15, 2015 at 8:20 PM, Kai Kostack kaikost...@gmx.net wrote: Hello Marc, I appreciate your answer but we're aware of what you're explaining. We have a more fundamental problem. Currently there is a redesign of various Blender internals ongoing. Design decisions will be made that are crucial for our modifier to meet all required coding conventions. Our workarounds have been criticized as bad by core developers earlier. However, those hacks have been necessary until now because it couldn't be solved otherwise due to bad Blender design. So, now that there is the chance to fix those issues in depth we would like to monitor that design decision making process and comment early on on it to make sure, they don't oversee some requirements that will be important for us in the future. At the moment it looks like everything important happens behind closed doors. -- Kai ___ 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] Lack of coordination and communication in Blender development
Build a branch. Do whatever you want to the internals. Try and keep all new official features up to date so the branch can be ready for merging at a moments notice in a year or two when it's super-awesome and ready. Make sure there are well-documented progress on a forum so other people who are interested won't have to guess at what they should or can do. There have been cases where several artists on BA.org have pooled the branch building uploads on threads so that the primary dev was free to do more important work(If the dev explains to people showing up how to do it first:). Fresh builds being posted on a regular basis(posted by several users covering several operating systems) helps with rapid progress and bug repair fixes, stream-lines feature requests. Now you have a small group of dedicated people working together on something they love without feeling worried about what every one else is doing. If you build it they will come- ((paraphrase)Ghost of Jim Morrison. :) On Sat, Aug 15, 2015 at 8:39 AM, Kai Kostack kaikost...@gmx.net wrote: Hello folks, I'm writing on my behalf but also on behalf of the Fracture Modifier developer scorpion81. We are a bit disappointed about how the redesign process of certain Blender internals evolves. There are a lot of communication channels but obviously they aren't used for core decision making or even for brainstorming. We feel being excluded from those important steps. It is looming ahead that we may ultimately be faced with a fait accompli, which - in my opinion - cannot be the goal of an open source development venture like Blender. We think it is not to early to criticize this practice for this very reason. Seeing increasingly frustration building up in dedicated developers who only try to make everything right and make their work fit into the current or future Blender design but get almost to none help on doing so makes me sad. The Blender development community needs to become more open and more inviting to new developers as it needs them. They are valuable! But they also need support, they need positive reinforcement, they need answers. Help them to make the impossible possible and not the other way around. I would love to make suggestions on how to immediately improve that situation but I'm not sure what way to go, it's certainly not easy to change old habits. I just know that something has to change. Maybe a weekly meeting per each module team (or working group, or task force) on whose module is currently being worked on at a central place like IRC would improve communication with new developers, stakeholders etc. - Other suggestions? Thank you. -- Kai ___ 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] Lack of coordination and communication in Blender development
Hello folks, I'm writing on my behalf but also on behalf of the Fracture Modifier developer scorpion81. We are a bit disappointed about how the redesign process of certain Blender internals evolves. There are a lot of communication channels but obviously they aren't used for core decision making or even for brainstorming. We feel being excluded from those important steps. It is looming ahead that we may ultimately be faced with a fait accompli, which - in my opinion - cannot be the goal of an open source development venture like Blender. We think it is not to early to criticize this practice for this very reason. Seeing increasingly frustration building up in dedicated developers who only try to make everything right and make their work fit into the current or future Blender design but get almost to none help on doing so makes me sad. The Blender development community needs to become more open and more inviting to new developers as it needs them. They are valuable! But they also need support, they need positive reinforcement, they need answers. Help them to make the impossible possible and not the other way around. I would love to make suggestions on how to immediately improve that situation but I'm not sure what way to go, it's certainly not easy to change old habits. I just know that something has to change. Maybe a weekly meeting per each module team (or working group, or task force) on whose module is currently being worked on at a central place like IRC would improve communication with new developers, stakeholders etc. - Other suggestions? Thank you. -- Kai ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Lack of coordination and communication in Blender development
I think step 1 in any proposal for change, we need a new 'map'/flow diagram of the current system, any proposed change would be a editied version of this map, (if we are redesigning anything from a low level) I have steadily been trying to digest commits, and understand what everything does, could steps be taken to refactor blender to make it be more approachable for coders in their blender infancy? could there be 1 day a month we set aside to helping new developers get into the flow of commiting? Thank you all for your hard work, BPR On Aug 15, 2015 11:58 AM, Antony Riakiotakis kal...@gmail.com wrote: I will also adopt Martin's position here. The design of the interaction model with physics, node driven mesh construction and dependency graph is still in it's infancy. Making generic comments on design of blender is not helpful either. Most people on this list have no idea of the context in which you are referring (myself included). Please be more specific: How does blender's design block your progress and what would you like to see. Is any of the current redesigns of blender internals blocking your progress and how? Only big recent internal redesign I can think of currently is the looptriangle refactor, but I don't see how this could be hindering physics in any way. On 15 August 2015 at 20:36, Martijn Berger martijn.ber...@gmail.com wrote: Hi Kai, As far as I am aware nothing has happened behind closed doors so far. Everyone is trying to give input of wildly varying levels of quality. It would be good if you could put together a (partial) proposal or at least a list of things you think you need (based on current limitations?) in order to successfully integrate the fracture modifier. The 2.8 process has only just begun and it seems early to be wanting guarantees to be heard or making assertions that the core team is not listening. I would suggest to any and all people wanting to influence what happens next, make a good (partial) proposal or at least try and describe the current limitation you feel should be addressed. Martijn On Sat, Aug 15, 2015 at 8:20 PM, Kai Kostack kaikost...@gmx.net wrote: Hello Marc, I appreciate your answer but we're aware of what you're explaining. We have a more fundamental problem. Currently there is a redesign of various Blender internals ongoing. Design decisions will be made that are crucial for our modifier to meet all required coding conventions. Our workarounds have been criticized as bad by core developers earlier. However, those hacks have been necessary until now because it couldn't be solved otherwise due to bad Blender design. So, now that there is the chance to fix those issues in depth we would like to monitor that design decision making process and comment early on on it to make sure, they don't oversee some requirements that will be important for us in the future. At the moment it looks like everything important happens behind closed doors. -- Kai ___ 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
[Bf-committers] Lack of coordination and communication in Blender development
Hello Martijn, hello Antony, I'd like to emphasize that I have great respect for every person involved with Blender development. I'm following the mailing lists more or less since 2004 and I remember often core redesign took place only within a small group of people and not so much in public. I usually don't comment on such practices but I think this time it is an important opportunity to get this modifier right. We didn't want to wait until everything is cast in stone so that we are doomed to continue to hear from the devs who are commenting on our ideas that there is no way to implement them right. Scorpion81 and me will take care of a list of the requirements. We don't even expect guarantees, we only would like to make sure our interests are not overlooked this time and at least being considered. Above that I really think the interaction between core devs, hobby devs and users could use improvement in this regard. Thank you so far. -- Kai ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
