on the one hand - quoted in agreement, on the other hand, the more time is spent on making videos the less free time there will be for coding.
I will try to make small updates on a more regular basis from now on. I seem to change my mind quite often on the specifics. Usually it’s for the better, but people should be aware in case there are objections.
-internals
I’ve figured out a good portion of the compile process now and it’s looking quite fantastic. In fact so much so, that I now have very little motivation to continue adding anything to the old system. The new way is just so much nicer and cleaner. It’s fun to see dozens of lines of code reduce to oneliners all over the place.
I said previously that I would implement the type system next, which I have done to an extent. However, I might instead just add decent type checking for primitive types, and then implement the compiler in its most basic form. I think that would be a whole lot better approach for the first release, and I might actually get that done during the summer months. If I continue adding things to the old, it’ll be a lot harder to switch it over to the new at later time.
-gui
I seem to waste way too much time on gui matters on blender’s side. Pynodes is very good at what it does, but it’s not exactly extensible, which is becoming a huge problem. There has been some talk about integrating the Qt gui library to blender, which I fully endorse. Most of these gui problems would just disappear if there was a Qt option. The big problem currently is that it needs a custom built blender version, meaning it can’t be used as drop in add-on.
I may have found a simple solution to that now. If it actually works, I’ll make a separate add-on dedicated just to that, so it’ll be useful for others too. Or I’ll try to persuade someone else do it…
I have grown quite fond of my new vertical design, so if I can get Qt working pleasantly, I will likely move in that direction. Imgur tells me that most people don’t actually click on image links, so here’s a thumbnail. I want to know if anyone vehemently opposes this style.
Personally it’s not being against this direction in general, the problem might be that you would force learning another separate visual language within the same software, personally i find the current one quite nice and clear, it could be improved, but are there any big advantages with yours? It’s a matter of “reuse what’s already working” i guess. imho
EDIT: maybe you might join forces with metalix about Qt integration? thread link
That’s a valid point, which I’ll have to evaluate. The problem I have with the current is that it’s very inefficient on screen area use. With the vertical style I can fit several times more stuff on screen, which reduces the need to scroll around. There are also a ton of graphical shortcuts I’d like to implement. Things like curves and color pickers in composite nodes. It’s not really practical with pynodes at the moment, so just to get them working, I’d have to recreate blendernodes in Qt. That doesn’t seem worth the effort, and I’d probably go with the vertical style in that case.
[edit] Actually there are a couple of ways to do augments with Qt on the existing node system, but they would not be nearly as nice. Still, it probably would be a good idea to implement them first before starting a whole separate system. Point taken.
And yes, I was referring to metalix’s efforts. I sent him a note about what I have in mind.
It was the voiceover that took 95% of the time, and I’m not going to do that again :). I will do a ton of stuff for testing alone, and recording/uploading them won’t take that long. Currently I’m doing mostly design work (i.e. not coding or testing), so I’m not producing demos for a while either.
@anvilSoup Nice that you want to do smaller updates with info 
It makes it much easier to follow
From the video and what you write it seems to me like you know what you are doing, which is great because even though I (and many others I guess) have an idea of the potential of this system, it might not be all who know how the internals work the best.
It sounds like you have found a foundation that you think is good which is also great. The foundation is the most important step in all projects
On your question about node gui i will comment on the layout idea which seems very nice and intuitive compared to many others. Nodes often turn to giant spaghetti networks that is has to follow and your layout seems to be easier to “read” than a big clump of nodes.
How do you adjust the nodes if they have parameters? Can they expand or tab them to access internal attributes or are they only for connecting?
On the graphics side I will only comment very lightly as I guess it is more of a generic system that have many kinds of styles? Like if it is integrated with blender the nodes would look like the nodes from blender?
I guess the colors of the nodes are meaningful (types of nodes?) but maybe the bevel effect and round corners etc is not strictly needed? Or maybe a white background? It might make it easier to read if the shape / effects etc were very subtle and the eye only focuses on the text and the color and can process the info very fast and fluidly?
The appearance of the nodes may not be important yet but there are many inspiring and nice ways to draw node systems:
http://noflojs.org/
http://nodebox.net/
https://code.google.com/p/coral-repo/
Anyway I just wanted to give you a little feedback as I am very interested and impressed by what you are making
This style is not immune to spaghetti either, but perhaps mitigates it a bit. Spaghetti management is something that I will focus on a lot. I’ll have a ton of small shortcuts and tricks that remove unnecessary wires, and I will do some documentation on how to build clean looking graphs.
The socket labels will fade in and out as the mouse hovers around the nodes. You can click on the nodes to access controls of unconnected sockets. Hopefully I’ll also have have hovering help docs, a bit like ctrl+hover in ZBrush
Node colors are a bit arbitrary, but they roughly tell which group of operations the node belongs to. Socket colors on the other hand are very clearly defined. Each socket with the same color are of the same type. Black outline around the socket implies an array of items of the same type.
Themes might be a good idea here. Nothing in the color scheme is final and I mainly picked the first colors that came to mind and looked decent. If the color scheme was more inline with blender nodes, it would probably look more “native”. However if I’m going to implement the same thing as stand alone system (eg. For phones/tablets), I’d probably keep it close to what it is now.
I recon bevels and such are largely matter of taste, so they should be themeable too.
I personally think strong bevels look very soft and friendly (a friend of mine agreed), but you obviously disagree and others might as well.
I’m surprised you’d want to make shape differences more subtle. I think having different shapes makes it a lot more readable specially when zoomed out. I’m actually trying to come up with more shapes for different “logical groups”. I’ve been fiddling with the concept of “compact” and “full” view nodes, a bit like they are in blender, but a node would take a different shape in the compact mode and would have a short hand label or a symbol. In the full mode it would be rectangular and have a full text label. So this could maybe be a toggled thing and the theme would decide which mode each node defaults to.
I think these are the kind of feedback and suggestions which must be reported and evaluated very well with the core Blender team (Lukas Toenne mainly i guess), if the current system has limitations and you have ideas on how to get it streamlined or how to get the life easier for developers (and you’re willing to get your hands on the topic as you’re doing), i’m sure the best thing to do is talk about it with the right people involved, because they’ll be more than welcome to get more help.
I just fear that a totally parallel project/system could bring to a fork which won’t benefit Flakes nor Blender, please don’t take it as pessimism
If you’re going to not release anything for a while that’s ok, but really, a mute screencast with the Text editor opened in a corner where you type what you do, would be more than interesting for everybody i bet, without the pain for voice recording etc.
The devs are well aware of the shortcomings. The big problem is that there isn’t really a system to speak of at the moment. Gui elements are done at a very low level and there is no python api for it. What takes minutes to do in Qt might take days in native Blender, and I personally have no earthly idea how I’d improve it. I’d basically just reimplement the equivalent of the entire Qt library, in which case I’d rather just use Qt.
The latter point I really don’t see as a problem. I will very likely have an external system anyway since I want to run it on mobile devices. It’s just a matter of whether or not the same interface will also run on Blender. It’s obviously a benefit to Flakes since it would have a unified front end. I don’t see why it would be a detriment to blender since it would still have all the same functionality (more in fact) as pynodes.
I appreciate your work and the contribution to all that it provides. Thank you. With all of the discussion of the SoftImage collapse taking down ICE, your work provides a positive direction to work with Blender.
Paul
I really think you should work over the UI issues that you are having with Lukas Tonne before making the decision to just throw out all of his hard work in favor of something written in QT.
Is much of this related to the preference of making a tree that goes from top to bottom instead of left to right, all Lukas would really have to do is add some more sophisticated curve drawing code to the connectors and allow for nodes to have sockets on the top and the bottom (providing it’s there to enhance functionality of course in case of things like value and boolean boxes on those ends).
Also, I would be in agreement if you think there should be node and data types that make things feel more like coding, but Lukas also has some WIP code in its own branch that adds exactly those things.
Doing any kind of custom UI work in Blender is a pain with the available tools. Qt would be a nice addition, but would also mean a lot of extra work. In any case, the API for UI elements needs a serious overhaul. There’s no reason for something to take hours or days to create in Blender that take 5 minutes in Qt.
Okay, so Blender will become so much like the big boys that it will too be hundreds of megabytes at the least in a .zip format and take a minute to load after double-clicking the icon, I personally think Blender should be reliant on less libraries in favor of deeply integrated custom solutions, not more.
Have you gone over with the UI team on what you would like to see in the API for UI elements, because if it turned out to be true that Blender’s developers consistently create broken systems to replace broken systems, then it would be big trouble for Blender’s future because it would give the impression that Ton and the core team doesn’t know anything about proper programming (I would expect to see crickets chirping in most BA threads a decade from now)?
The big software are so big because are comprehensive of a tons of example, scenes, texture and materials preset.
sodtimage start in about 10 seconds, or less, on my old workstation. 3dsm, well, is 3dsm (and as far I know don’t have Qt)
Anvilsoup, good work, I really like it. Have you estimated any ETA?
Relying on internal libraries is bad programming practice unless there’s a really good reason to do so. Why reinvent the wheel every time you want to do something? Stripping things like boost, OIIO, and ffmpeg from Blender would leave you with a really awful program… Others’ large sizes come from huge texture packs and videos and whatnot included with the downloads. Libs are hardly the majority of the downloads, and are definitely not the cause of startup times (and let’s be honest, Maya and 3DS take 5-10 seconds to start up on my machine, barely noticeably longer than Blender).
Well in the case of the node editor, that part of the UI has, for the past year or so, has received the most updates (look at 2.5x vs. 2.69, especially in the area of group nodes).
I don’t think Lukas Tonne is done with any future node UI upgrades, after all the time he’s put in to enhance it to where it is now, I think it would be wise to advocate he resumes work on his particle nodes project as part of Gooseberry because that will contain a number of elements and data types that will be very useful for Flakes. I don’t think that a somewhat knee-jerk reaction to throw out large chunks of the existing UI code is the best way to go especially after the establishment of a new UI team and after all of the time invested.
Heh, Lukas did not actually make pynodes for me specifically. It’s still tremendously useful for others even if I drop it. I probably won’t just yet anyway, but I will try to augment it with Qt. Making the changes you suggest would not be easy at the moment, and I recon it would not be very efficient use of Mr. Tönne’s time. A note on the last part at the end.
To this and other comments on loading speeds: Flakes itself actually takes more time to load than Qt, so it’s hardly an issue. I probably wouldn’t advocate integrating Qt into blender by default because bloat can be a concern, but as an optional add-on it’s perfectly fine.
Reiterating the point: nothing is being thrown away. Problem is that all the GUI work is for the long term, and I’d like to have a usable system like next month. If Blender indeed gets a proper GUI api in the coming years, and it’s practical for Flakes, the Qt bits can be retired quite easily as the internals are very loosely tied to the gui. Also, three months of serious contemplation is hardly a knee-jerk reaction. Coming up with the vertical style was just a push to hasten this a bit.
I think you are also misunderstanding how these systems work internally. Besides the GUI, there is very little in Lukas’ work that I can utilize in Flakes. I probably wouldn’t want that anyway since the scope of his work does not quite match mine.
I’m aiming the first release for the summer, but my estimates are known to be wrong.
Incidentally, metalix has not replied to me yet. He probably thought I was nuts :D. I’m gonna go ahead with the thing anyway. I need to experiment with some stuff that will be very important for the game engine work.
People voiced some concerns for viewport performance in the Softimage cluster 'ck thread. Of course with Flakes we ideally would like to generate forests with individual leaves or full cityscapes, but that would quickly choke the current system. I don’t have full solution for it, but I have thought about some Flakes specific workarounds. Viewport renderer is a massively difficult thing to code, but only if you go for universally applicable system. If we allow for some copouts, the process becomes dramatically easier to manage, and doesn’t necessarily have to be integral part of Blender.
Obviously in the extreme cases we don’t actually have the objects stored in memory. Just the transform data for a trillion leaves would take terabytes to store (for one frame). For fully deterministic procedural objects we can use so called lazy evaluation, which in this case means we only ever access and generate the structures as we need them and discard them immediately after. We also access and render only the things that we see, and ignore everything that is obscured by something else. The copout is that we don’t allow transparency and overlaying the lazy objects with the rest of the scene might occasionally look a bit wonky.
The same method won’t work for fully simulated data like particles, but for that there are some fun tricks that let us render billions of simple objects straight from disk cache in real time. The performance would be more dependent on the render resolution than particle count.
I even have a rather unorthodox method for rendering massive amounts of instanced deformed meshes (e.g. crowds), but fully researching and implementing that might not be a priority over the others.
This is obviously still just a research topic and won’t be a priority until later stages of Flake, but I’m fairly confident it can be done effectively.
Yes… Softimage.
This is my first post to the forums, as I come from the Softimage world. But just to say, when I get the cash, I’ll throw it to you to develop this. Blender could become a contender to Houdini or Softimage hands down with a nodal system like so.
So, just saying, you have my support, and once I learn how this whole Blender system works, you have my participation also. 
There is also hive nodal logic, which is now compatible with blender
Sent from my Nexus 5 using Tapatalk
Hello Draise and all other Softimage users who have taken interest to this. The video now has over 1000 views (a lot to me) and quite a few likes from Softimage users by the looks of it. I’m glad to have your support
So the Qt trick works as expected, which I actually knew from the start but did not know how convenient it would be. Looks like it’ll be just fine. I’ve been moving boxes with Qt sliders all morning :). I haven’t put it fully together yet, but I’ve tested all the major components and sketched the api that I’ll be creating/using. I think I’ll be fully Qt equipped pretty soon, which will certainly simplify a lot of things.