A fork? Without any current C/C++ programmers? Oh dear lord…
@Btolp
…you could also say, it’s a fork, without a handle…
Guys, come on. He made a three-year-big game, two little python plugins for blender and admined two forums. I don’t see why not knowing C/C++ could be an issue.
Tiles,
why not make a addon first that fixes what you think is broken for the ui.
I was thinking sheets you pop buttons on that you then tie to commands in blender. This way you can setup ANY ui.
and widgets, (dropdown list etc) that interface with the backend?
then any user is free to customize the ui, and then trade setups and ideas as a file?(with almost no python)
Reading the PDFs
http://www.bforartists.de/data/Bforartists_UI_redesign_Designdoc_Part%201_-general.pdf
and
http://www.bforartists.de/data/Bforartists_UI_redesign_Designdoc_Part%202-_theming.pdf
in my eyes shows that you have thought about everything in detail… have you talked directly to Blender itself about trying to work with them rather than forking blender?
sarcasm
[SUB]ˈsɑːkaz(ə)m[/SUB]
noun
- the use of irony to mock or convey contempt.
Just sayin’ 
FWIW, Tiles is obviously putting some effort into this. More than most people on the forums. I just don’t see it going anywhere lacking a C/C++ coder. Sad fact of open-source volunteer work, hard as the managers might work - you still need the coders to implement the changes.
I don’t see anything wrong with it. Look at Linux. It got dozens and dozens of forks. No one is complaining. I thought anything open source would lead to all kinds of branches growing in many directions.
I love the idea of taking Blender to another level. But I always assumed it would take more resources not less. I have also assumed it would best be done as a joint effort with the Blender Foundation. Blender is a moving target. And from what I hear not so easy to find people familiar with programming in C languages and also familiar with Blender’s code.
Considering even how hard it is to do what the BF does to even keep up and the fact that there is already a community of people who believe in it, and willing to help and also precious few actually qualified, a fork is not really a practical solution unless it has deep pockets. Additionally, even so, a fork would not be as potentially strong of an idea in my opinion unless it actually did merge back with Blender. Because unless you have absolutely unlimited funding, you are going to be better off availing yourself of all the work being done on it concurrently. It was not clear if that was the plan or not. But a fork… well isn’t that what it means? Maybe I missed something.
And starting off a project with a negative premise of “blender is the hardest tool to learn” might spark some flaming interest from the usual flamers. But are these the people qualified to actually do something about it? And are not those who are qualified to help actually doing all they can to actually improve Blender already?
So are you really not just preaching to the choir here? How will you gain the support away from the community of Blender Foundation over to another project? What is the reward and realistic chance that it will be worth committing to with 0 funding?
I think these are things you have to consider when moving ahead with a project like this.
From what I can see the answers to these important questions have not been provided.
Have fun and good luck.
You’re mixing up Linux distribution “forks” (e.g in the way that Ubuntu is based on Debian) with a fork of a program.
There may be some companies maintaining custom versions of the Linux kernel. However, there’s no real fork to speak of, and for good reason: Merging changes back to a fork becomes increasingly harder and more laborious, the more the codebases diverge - it’s likely that improvements on one end never end up at the other end. Tiles probably doesn’t really understand how this works yet. Also, dealing with this is not interesting work, so good luck finding volunteers for that.
No one is complaining. I thought anything open source would lead to all kinds of branches growing in many directions.
Forks are generally avoided like the plague. When they happen, there is usually a significant conflict within the development community. In this case it’s odd that the initiator isn’t even one of the original developers and doesn’t have any other developers behind him.
I know when the Blender project started on its road as an open source program, Ton Roosendaal at the time was actually one of the most active developers (when Blender didn’t have much in the way of paid developers or volunteer help).
He’s more of a manager now, but he used his code skills to help get the project off the ground. This is different as Tiles cannot readily contribute to give it the initial boost that many FOSS projects need to survive.
I would rather see a branch that is active ‘fall off’ to fork,
then a fork out of nowhere.
a branch can always be easily merged back most of the time right?
In hindsight my previous reply was probably a bit harsh, you obviously put a lot of work into this. Just understand that you’re mixing in a lot of personal preference, which is fine, but doesn’t lead to objectively good design.
For future reference, the better way to do something like this is to discuss your ideas openly to see if anyone was interested beforehand. You come off sounding like you assume that a majority of users that hate the UI and that your project is a necessary thing, rather than just a cool alternative for anyone who isn’t satisfied with the default. Which is pretty tasteless when talking about a free application developed by volunteers.
A branch has to be actively maintained to make an eventual merge less painful, but even then it can become a nightmare. It all depends on the code divergence. In this sense, the only difference to a fork is that there’s an expectation that eventually a branch fully becomes part of the main codebase again (if it isn’t abandoned). That obviously influences the development decisions. The sooner a branch is merged back, the less drudge-work goes into maintaining it.
Compare this with a fork, where two different sets of developers want to develop into different directions. There will be much less coordination and less mutual consideration regarding code changes. For example, it seems extremely unlikely that the current Blender developers will consider supporting Qt as a new UI framework (a huge effort in its own right) when there’s already a planned effort to make the current UI more customizable.
Since I don’t know anything about coding I can only wish you good luck on such a huge project. I always thought that a fork would come from a studio that takes Blender and creates it’s own version of it to use it as an inhouse tool (since a studio would probably have enough resources to do such thing…), but again I wouldn’t really know how that’s done, so no much to comment in that area.
Now, as a user, and an advertiser my only suggestion is: Make it attractive first, starting with the name.
It doesn’t have to be related to Blender, and it surely doesn’t have to be related exclusively to 3D. From the top of my mind only 3DsMax and 3DCoat have the “3D” in the name; also, non of them have anything like “artists” in the name. Actually that makes it sounds worst.
Silo, Modo, Maya, Mudbox, Zbrush, Lightwave, Softimage, Cinema4D, Wings, Truespace… see what I mean?
On a side note, I always thought “Truespace” was a great name for a 3d program… Sounds great and it’s easy to create a concept and a slogan out of it. Maybe think of something like that…?
Then make it attractive visually, the current logo and website are just not inviting. From the marketing point of view, you should think of this first. Have a viable product that you can show, and then make it look AWESOME. There’s no other way around it.
I’ve skipped through the documents a little bit and a few comments:
- The move away from a shortcut centric UI is discussed for blender development as far as I know. Nothing concrete yet though. I agree with you that this should be coupled with a more intuitive interface.
- The move to Qt is quite drastic (and expensive deveopment-wise) if you aim just to get a “standard interface” with square corners. For myself I don’t see what such a move would solve and from what I’ve read you don’t either.
- A lot of the points in the documents is just about looks of the program. If you aim for an easier program you should focus on how to solve workflow issues (make it easier for people to do task A, B etc). Editor hopping is a real problem but it’s not solved by beautiful UI. Some workflows, such as UV editing require multi editor setups - define your seams in 3D see the result in 2D. Node Material definitions or even motion tracking (which you pulled out of 3D view because it’s not relevant to modelling…not a good idea) and animation are similar. Use one editor as a configuration tool and see the result in another editor. If you want to throw away things not relevant to a workflow, you need to define what a workflow is (and not in a narrow, modelling only oriented way but in a way encompassing all functionality). And you have to do it carefully enough so people won’t have to hop between workflows to access tools that are in different workflow sets. I think “object modes” come close to the notion of workflow though they were not done exactly with a workflow concept in mind. I’m not even sure if a workflow can be defined strictly to be honest. Maybe the problem needs another notion to properly describe.
thinking longer about this, this whole proposal is up in the same alley as the Andrew Price UI ribbon office for Blender “proposal”.
only difference?
IMO Tiles has not have reached the Andrew/piewdipie critical mass of “glamorous/famous” shine around him which for the other mentioned ones IMO mostly consists of young kids which like to get shouted at or simply like to get ripped of with overpriced products.
Looks like a lot of thought went into this. Not sure I agree with many of your ideas, and I think you have about a snowballs chance in hell of attracting existing developers, but I nevertheless wish you good luck on your endeavour, and honestly looing forward to see what comes out of it.
…but the name sucks donkey´s arse…