First of all, thank you for giving so much feedback! I will definitely keep it in mind while working on the editor.
Splitting the editor up in different parts could be a good thing, but right now I’m feeling that the strong point of the editor is that it all works together. The painter on its own isn’t that special but when it is connected to the node editor it makes a lot more sense to use it. From the other side, I get you point that it will be too generic and confusing.
In my head, I already decided that I will be focusing on the texture/painting part of the editor and that the other topics are for a different time. (there are already some good assets out there that focus on scripting etc.)
Still I could separate the painter from the graph editor to give people a choice and have more/better marketing options.
1. Snapping is a feature. (if you mean the nodes snap to the grid?)
2. This is a great idea and I will have a look in to it. (Right now, you can use node groups to move them together.)
3. Zooming isn’t a thing right now, I have been experimenting with it and there are some options, I’m testing this in the painter and previewer part and when I find the right way of doing this I will add it to the main editor.
4. In some previous versions, I had values on the nodes, and in some cases this is helpful. But why I’m not doing this on the texture editing nodes is because it is all about the visual part, numbers aren’t that important.
(here is a screen from an older version.)image image2
5. I will have a look at that!
6. Good idea, right now only the gradient line changes from color.
7. This would be great some more visual feedback on what you are about to do. I was also thinking about a status bar, this for information and for showing the progress when loading a big file or do some heavy calculations.
But thank you, and as I said this is a really early version and I’m always looking for some feedback to improve!
Sorry for not replying to your reply but making a new comment…the forum just doesn’t allow making extra lines, and it makes long paragraphs look messy.
The texture editor can be useful and unique even without the other editors. Even though you said it won’t be special without the node editor… You should make it into a node editor, just not with the other editors. Like, you could export it into a texture and use it wherever you want, like if you have the other editors as well, use it with them, or even if you don’t it will be useful for the normal material editor, for example.
You also said yourself that combining so many things that the only common thing between them is that they are edited in a node editor can be confusing, which in my opinion is a deal breaker.
And about the editor:
1. When I say snapping I am not talking about you moving it and it will snap to the grid after you release, but snapping like when you drag it it will snap (like in Unity’s animator). So it won’t move smoothly.
4. It is about the visual part, but numbers do matter. Like in the brightness one. It can be very useful for complicated calculations, instead of just constant numbers. You could connect other nodes to it if you had it on the node, which can really increase what people can do.
Here are some other extra things about the editor I thought of:
1. Comments. Just like in code. I thought about something like in Unreal, where you can go to each node and add a comment, and you can make a big comment on a group (which actually looks like what you did with the node groups, but the first part I think you should definitely do).
2. On the scripting thing (which you said you kinda put aside for a little bit, since it’s not that unique, but I will still give you feedback on that for later), I think you should, have different colors for each kind of knob (again, this idea comes from Unreal :P). Like, for each type (no need to make a different color for each kind of knob, like input or output, you know those by the side). So I am talking about the type, so a boolean will be different from a float, or a Vector3. As well as execution pins (this is a name I stole from Unreal, like always), which will say what comes after what. As for user defined types, you can either color them by the type of the type (like enum, struct, class, etc.), or let the user select a color/texture for it.
3. Separation for structs. Again, another thing from Unreal. Structs could be separated to their variables. Like, a Vector3 will be separated to X, Y and Z, a Quaternion will have X, Y, Z and W, etc..
4. Again, about the scripting thing. For the user to make a custom method that is callable by the node editor, make an attribute. Here are the properties I think you should allow the user to have:
- Display name: The default name will be the name of the method, but if the user gives this property a value, this value will be used.
- Call type: It can either be pure or callable. Again, those names are completely stolen from Unreal. Callable means it has execution pins, so it’s only being called when the execution pin is connected, it is used when things are being changed in it. Pure means it doesn’t change anything, but it only returns a value, and it is only being called when the callable function that uses it’s value is called, it’s useful for things like getters.
- Category: You could have foldouts for each category. A / will mean it’s a sub-category. The category doesn’t have anything to do with the name, so the last word will not be the name but the category.
- Keys: When searching, it will help finding something when the name doesn’t match (like a function called “Equals” will have a key for “==”).
- Background image/Text: Unreal ripoffs! 😀 An image that will be in the background of the node.
5. If you want to implement generics, I found this great free asset to help you: https://bitbucket.org/rotorz/classtypereference-for-unity