I would like to use this space to hear from you what you like and dislike about the current implementation of the MagmaFlow Editor. Feel free to post thoughts on your subjective experience, wishlist items (e.g. multiple Output Nodes, multiple Output sockets per node, multiple Editors open at the same time etc.), features you like and use most, feature you never use, feature you would use if they were implemented better, pretty much anything you feel would influence the future of this sub-system.
Thank you in advance!
In return, I will try to comment on your proposals and give you an idea where things might be heading in the coming months.
Ok, so this is the thread where I complain about stuff and you point out that the features are already there, I just didn’t read the right part of the manual, right? Oh well, here goes…
Hates:
Plain text copy/paste. Would make it sooooo much easier to share snippets of KCMness. Loved it in Shake and Fusion for this reason. Node based editing loves to share, and plain text is the way to do it.
Collapsing bug I reported earlier. It gets cluttered.
Piperouter/Elbows? Visually simple way to anchor a connection in the flow space.
Zooming and the Depot. It’s ugly, I know you can’t do anything about it, but I’m griping anyway.
(un)SignedDistance. I know, it’s not KCM related but PRT Volume, but hey, I only notice it when using KCMs. Likewise, PRT Volume sets normals to face normals only, not smoothed. Sorry.
Offset texture reads. Still no workaround, right? I’m thinking you supply a vector to the IN:Map and that’s where the color comes from. Would also allow us to do alternate UVW channels this way.
Reorder. It rarely works, and when it doesn’t, you can’t undo. So I went from an ugly flow to an unreadable one.
Swizzle/mov. It’s harder than it needs to be. There’s so many examples of this in other applications, I can’t say which I would like best. Discuss?
Help link is broken as of 1.6? I’m sure that will get fixed. Just thought I’d toss it in.
Clamped curve lookup. Even if we had to get a curve out of the curve editor for UI reasons, I could live with that.
No “automagical” insertion of convert ops when there is a type mismatch. Actually, there’s no indication of an error if you do connect the wrong types. I don’t want to see any hidden conversion, I just want a Box#3 style insertion of a conversion op.
Accuracy needed to connect to inputs. You have to click exactly on the circles/squares to make the connection. I’d rather have something like Fusion where you can drag to the entire node and it connects to the first open input.
Loves:
Non modal window. Also, copy/paste between KCMs. Would be swell if we could have 2 editors open, but the current setup where you can change KCM’s and the editor changes works well enough.
Ability to change what a node is after it is wired up. Sooooo goooood!
Keyboard shortcuts. Feel like I need an “editors’s keyboard” sometimes, but at least the options are there and well thought out.
Nope, this is the thread where you tell us what is broken and what isn’t and we rewrite MagmaFlow 2.0 from scratch to fix the former and keep the latter.
Do you mean a text-form representation of the flow? I am not sure I follow 100%.
The next version will allow very easy generation of flows using MAXScript calls, and potentially it could emit a MAXScript code out of a flow. Would that be useful?
Not sure I follow. Can you post an illustartion? Do you want a small node where a connection just passes through it (would be easy to implement), or a way to guide the wires (which woudl require Helium changes)
We discussed it this very morning and if we can do something about it, we will. (might force us to license the Helium source code)
The PFlow Geometry Lookup does it right, but it has access to the TriMesh. The PRT Volume uses the normals of the Level Set. It should probably sample the actual geometry for the smoothed normal. I think that the SignedDistance is already fixed, but I might have heard wrong - Darcy will know.
We would need a Texture Operator that gets a map and can have inputs to provide sampling location / UVWs or whatever else is needed. I think it is already on the wishlist.
I am exploring alternatives. Funnily enough, for the types of flows I am connecting, it works 99% of the time. Alternatively, we could remove it completely and leave it to you to reorder by hand
Post your ideas, we can discuss.
Works for me in 1.6.1. Unless you mean a different help option?
We are exploring our options. I am not crazy about the current implementation.
Good point. The current editor doesn’t have clear knowledge of what is expected in each input (although it is hinted by the socket names). There are manual buttons to insert converters, but I understand what you want. Will see if we can do that.
This is a Helium issue. I could look into faking it somehow, or we could modify the code should we license it. In general, I almost never use the mouse wiring, either hit the SPACE with the two nodes selected or try to use the auto-connect feature. This shows that the problem is really bad
Current prototype already supports arbitrary number of windows (they get registered in a central location to prevent you from opening more than one for the same modifier/render element). This means you will be able to copy and paste between any number of open editors.
In addition, we are looking into supporting multiple Outputs per flow, so a single modifier could affect several channels, e.g. Color, Emission and Density out of the same calculation…
It was very important to us to preserve this, and we are jumping through hoops to allow it with the new code. I think I will have it working again this weekend.
I will try to preserve the existing system(s) - keyboard,menus,depot. Might have to add some intelligence to allow automatic and manual customization of keyboard shortcuts for new nodes. This is because in the old version, a node had to be defined once in the core and once in the UI script. In the new system, all nodes are defined in the core and the UI queries Krakatoa to see what nodes are available. Thus, if you get a new version of the DLR and have the old script, the new nodes will still appear and work without modifications to the UI. The new nodes will have a pre-defined category in the core, but I would have to decide what second keystroke to assign based on available letters etc. We will see how it will go once it is re-implemented…
I had the same initial feeling is Chad’s first sentence, um what did I miss that is already there
I have some of the same love/annoyances/hates/wishes, although not as exhaustive
Loves:
Keyboard Shortcuts & Right-Click menus, a customizable Ctrl+RC menu would be cool.
All auto magic features like switch channels/types/functions/ect/ect without losing wiring.
Blops! Just a touch of love, if possible, see below.
The fact that magma-flow even exists
Small Annoyances:
The Modifier name update when you change the output channel could be a little more dynamic.
Would like auto-collapse after x-seconds of node depot after I drag a new node to the field. Currently remains open until I close it.
Hates:
The Curve Editor nodes little curve editor window, bah way to small, I rather dislike it so much I try other things first.
Better new node insert handling. I would expect that if I drag a new node on top of an existing wire that it would auto-magically wire first input and output. Even selecting a wire right-click new node could auto-wire.
Mouse Drag Single/Multiple Select Nodes is mustard. You have to have the whole node encompassed within the bounding to select a node(s), drives me nuts.
Blops with multiple inputs would be nice if you had the option to add a separator between internal nodes inputs. For instance, two nodes within a blop require separate channel feeds. One needs three inputs the other only one, a separator in between these in the blop so you more easily know which input (if the same channel is required) you are wiring too.
Debug is still a little strange, it is still useful, though I have absolutely no idea how it could be improved.
Chad’s # 11. Totally! would at the least ask me if I want to insert one.
Chad’s # 12. This stinks too, Slate exhibits similar behaviour. Although I kind of like how the Slate Editor works/looks better, you at least have bigger targets and if you drag into nowhere (empty spot in the field) you get the add node menu, that is pretty cool. Maybe even a left hand panel with the node depot?
Wishes:
A field navigator. All nodes based systems have them standard.
This seems to be a Max issue - renaming modifiers lags, even sometimes when you rename a modifier manually on the stack. Will see if I can call the renaming function more often
The Depot auto-collapses if “Auto-Collapse Categories on DragAndDrop” is checked in the right-click menu of the Depot. Unless you want a different type of collapsing…
I think I could draw a preview of the curve on a button in the command panel and open a large curve editor floating window when you press that button… Will see if I can have multiple of these open at the same time…
This is a limitation of Helium - except for a handler that tells me when a user created/deleted a wire, I cannot do anything with the wires myself. If we get the code, we might be able to fix this.
Same as above - this is how Helium works, don’t think there is a Crossing/Window switch anywhere. If we can fix it, we will (drives me nuts too).
I see, that should be quite easy to implement. I haven’t touched the new BLOPs yet, but they will be awesome since most of the handling is now in the core. Should be faster to handle flows with many nested BLOPs too.
We intend to improve it as much as possible It should become faster, too. I might add some form of PDV-like spreadsheet view to show how a changing input modifies all nodes’ values or something. And I hope to make the graphs faster.
See above - I don’t get any notification from Helium unless the user successfully wires or unwires two nodes. We will see if we can fix that.
I think it should be possible to write one, not sure how useful it will be, but it is worth a try.
I suppose that could work. What I meant was that with other applications that had an ascii file format (and KCM’s are similar in that regard), you often can copy something and it ends up as plain text in the clipboard, so you can paste it into SciTe or Notepad or Outlook or Google Talk or this forum or whatever and either edit or share or post the snippet. The application knows how to parse the data for the copy and the paste, so even if it isn’t in the native format it can convert it automatically.
Best case, I could copy a chunk of a KCM, paste it into notepad, save as “snippet.KCM” and be able to either paste it into a new KCM or load it as a KCM snippet. Not sure that’s possible with the way KCM’s are written now, but that’s how it works in Fusion or Shake (or Notepad for that matter).
Guide the wires. Seems like it would be a sort of null op, if nothing else, just passing data though unchanged. Like when an operator is set to passthough (and the in/out datatype is the same). Ideally it would look different than a normal op, so you didn’t THINK it was just a passed-through node.
From what I see here the normals don’t look like what I would expect from the level set.
In Fusion, they have two operators for this, one that has just one column with fixed rows, RGBA, and an operator on top, and for each, RGBA, you set the source channel. The other operator has 3 columns: Operand A, Operation, Operand B, and each of the 4 fixed rows you pick the two operand channels (or constants) and the operand. In Shake, they have a reorder node that lets you type into a text field the new ordering. So you type “GBAR” and you basically say R=G, G=B, B=A, A=R. Type “L” and you get a scalar which is the Luminance of the RGB components. For KCM, you might want something that makes more sense for the types of operations we do. In Nuke, they draw a matrix where the columns are inputs and the rows are outputs. You just check off how you want them moved.
If we DO end up with allowing multiple outputs, which I’m still not so sure about… Would it be possible to have a viewport/render switch on the outputs? I’m thinking that it might be helpful to output a vector as color for the viewport and normals for the render.
Bobo I figured a few of them would have been Helium limitations.
About the navigation, for me anyway I use it all the time almost subconsciously, even if you aren’t grabbing at it to navigate you do see you entire field. If we get have multiple outputs I image it to get even more cluttered. The linear nature of nodes being left to right, no matter how you try to organize them, gets a little frustrating trying to fit everything in view.
Sorry these may seem like youngster questions but:
Wouldn’t this destroy the niceties of stack evaluation? We would be able to arrange output orders right? Will we still be able to have multiple modifiers?
Another BLOP thought, could it be possible to “open” a BLOP in an expanded schematic window, so it remain closed in the current view but editable in another? I guess more like a Parent Child view type of thing. Something like this may work well for a multiple output scenario too, your master view with all off your outputs and the child views with all the nodes.
You can do it Box#3 style, which has benefits, especially if certain optimizations are made (like caching data for multiple outputs), but it DOES instantly add a opportunity for nuttiness. You’d need to set eval order, certainly.
Ah I see, I for some reason keep imagining a TP like structure/interface, I guess because of its nodality(hehe new word)/wiring is somewhat similar to Magma-Flows
Currently the output node is locked in the upper right corner.
When we add multiple outputs, they will be ordered from top to bottom on the right side (similar to how BLOP Connectors are ordered on the left side).
You will be able to reorder them to define the priorities, but our main goal is not to replace the modifier stack with a single flow, just to simplify the stack when the SAME value goes to multiple targets. For example, if you read the Z position and turn it into a Density value AND into a Color value, right now you need one KCM to do the calculation and write to the Density, then another KCM to read the Density and write to the Color. In a multi-output environment, you could do the math and the output to both channels in one KCM. The order wouldn’t matter in this case.
Now if you add two outputs and connect independent flows to each one of them, the order would matter, but it would be your problem if you overcrowded the flow that way, and you will still be able to copy the one sub-flow and paste it into a new KCM on top of the stack to simplify the setup. Or you could just drop two KCMs like in the past and do it correctly to start with
This is all WIP, we might have to impose limitations if things get messy. For example, in a RenderElement we might disallow multiple outputs for obvious reasons.
I don’t see a technical reason why we couldn’t do that for BLOP editing, but I will have to see how to manage these relationships. For example closing the master window should commit and close all child editors, too. I will be working on BLOP editing code this week and will explore these ideas.
Keep them coming!
But are we actually reducing the redundancy? Or is it just going to evaluate the flow once for density and once for color? Is Krakatoa caching or just hoping the CPU cache does the trick (assuming you process point by point, not channel by channel, which no CPU cache could hold)?
Why? Let’s say I have a “BRFD Eval BLOP” or something to do shading… I might want to edit that BLOP and see it’s affect on 8 different objects referencing that BLOP. If all of those 8+ KCM Editors had to be open, that would be weird.
Everything in Magma is cached, in its current and future form. All processing is done a particle at a time and each operation writes its output to a shared location before being used by the next operation. You should be able to see this caching behavior in every version of Magma already shipped.
I haven’t seen any downsides to this yet, and the only major tomfoolery I foresee with multiple outputs is:
[Flow]
Channel1 -> SomeOperation1 -> Output1
Channel1 -> SomeOperation2 -> Output2 (Where Output1 is writing to Channel1's channel)
You may not be reducing low-level redundancy but more user level redundancy. IE a KCM for Color a KCM for Emission, when both use the same color channel data. You would reduce stack evaluation by 1 to wouldn’t you?
Yes, you’d have to have a way of specifying the order in which the outputs were processed. But that should be it.
So with the caching, you could see a performance boost then, right? Or does the cache (currently) extend beyond the modifier? Do you share caches between KCM’s?
The cache is only within a specific KCM, hence why we see multiple outputs as a way to improve performance. Caching across KCMs would be a nightmare to figure out the correspondence of nodes and cached values.
