Sure, but we have concerns about intellectual property that prevent anyone to just directly mention another software here, which is why I got gently slapped on the wrist earlier (I described a bit too closely a piece of software which name begins with Hou and ends with dini).
Now for real, parameter referencing is just “connecting node sockets” in Blender, so that’s an improvement already.
Node muting (=bypass) is planned afaik. I heard someone important talk about it.
Inspecting at arbitrary point in the node tree I pushed for earlier but didn’t have much echo. Yet I concur, this is important. I mean, while working with nodes you go back and forth a lot. You want to know what happens at the end of this node, of that node, etc. If you need to reconnect to an “output mesh” each time it’s going to be very tiring. I think anyone who’s worked with nodes can appreciate that.
“Template” I don’t know what that does though. Same as in the software that begins with Ma and end with ya ? ie makes data appear in dark overlay wireframe, unselectable so as to act as a sort of reference ?
And ideally yeah but I don’t think a language specifically for this is in the works unfortunately. That’s glitter though
This is a really fundamental necessity to procedural modelling. Being able to read, in text, the output from a node helps with debugging, assessing data etc. Surely there will be a text viewer made for this? Modelling blind is going to put a lot of people off
An info button on each node that contains “extra” information.
It can store stats, performance, error/warnings, wiki link, and arbitrary extra information.
That would be a dream.
Food for thought, shall we have a different thread here for each of the sprints? For instance we just finished sprint 3, so it would be interesting to hear feedback related to that without adding to an already big thread.
Depends if it makes it more easily scannable for the development team I guess ? This one has become more of a general thread, so if you guys would like to immeditaly see feedback centered specifically on recent additions/changes, then I would say this is a good idea.
I’m for this, especially if you add specifics at the to of the thread of what is going/what you want feedback on. Otherwise these threads can get super long and hard to browse through. If that would make it easier for you guys, go for it!
Oh, that could be a great idea, focusing on features and problems related to the specific sprint, after that the team can do a review of what has been exposed and reach some conclusions that could help shaping the needs and focus in the following one and the thread can be closed.
Just wondering: why are the nodes encapsulated in a modifier? At first sight, the other way around, modifiers as part of the node tree would seem more logical and more in line with the ‘everything nodes’ concept.
The node modifier, or “Empty” as it’s called now, is really just a container for any evaluation that happens to the object in the node tree, so you can think of the node group attached the modifier as an evaluation of the object. Also, there are already nodes that are existing modifiers in the node tree-- subdivision, triangulate, etc.
Anyway, it’s useful to keep the concept of a modifier around as a container for a node group and a way to expose and change its most important settings.
How does the modifier stuff work for a node tree where you are outputting multiple different objects? For example turning a plane into a window with frame and sill where you want three separate objects as the output.
arrays of vertices, edges, faces, normals for each of these…data groups such as split edges(edge sharpness), creases for sub-division surfaces…
Right, and UV data etc. etc. etc.
I’m guessing they don’t want to split these all into separate arrays, internally in each node/operator sure, but I mean for exchange between nodes. Just a guess tho, have yet to fetch a build to test and check out more closely.
edit:
I missed that you had already replied to him, ah well.
As for "attribute nodes could also nullify some of the benefit of a node based workflow" - I’m not entirely convinced that it is an issue. That is if we can have novel nodes specifically for splitting some of that data out of the stream for manipulating it and then merging/replacing it up stream again(if need be) via another novel node perhaps.
Regarding the “join geometry” node : wouldn’t it make sense to use a diamond socket for this one ? you know the sockets Jacques came up with for the “particle influences” node a while ago, to which you could connect any number of inputs ? there’s no sense to be limited to two inputs per node, especially for the join node which doesn’t care about the order of inputs.