If the output nodes all “float” to the top, meaning that if you have one output, it is in the upper right, and if you have 5 outputs, one of them is in the upper right; wouldn’t it make more sense to read bottom to top? So the one that is easiest to find/read (from the human side) is the last one evaluated and most likely the important one?
So lets say I start a KCM, and I know I want to read in the normals, perturb them, and write out normals. So I set the only output from color to normal. Cool. Now I think, “how will I perturb these normals?” Ah ha! I will read in a map, but sample it with offsets (yay!) and do central differences to generate new normals! But wait! How do I read in the map? I need UVW’s! So I add a UVW output. But now that will displace my normals output. But the UVW output is only there to get the normals output anyway, so why should it go “on top”?
I want the output that is the primary intent to always be at the top, so you can very easily find it.
Regarding the rest, the swizzle is interesting. I was thinking something simpler, but I might like the way you have it now. More flexibility to add intermediate operations, so you could negate a component, or clamp it inbetween.
Plaintext copy/paste is exciting, but looks really verbose. Do you need to include stuff that can be assumed as default?
I am not following completely. Why do you add a UVW Output? The InputTexture has its own input socket to feed any UVW data you want, there is no need to output UVWs in a channel via an Output node.
The reason I went with top to bottom is that 99% of the time, the flow looks like Magma 1.x. I just felt that a second output should go below. No real reason. I know Max Stack goes bottom to top. But each time you add a new Output, the existing Outputs (and thus everything connected to them) would have to slide down. So if you started ordering your flow from top to bottom and right to left, you would have to deal with the shift. Right now, you just keep on adding more nodes in the empty space below the existing nodes. (The only sorting mode in Magma 2 right now does a flow that is similar to the row sorting in 1.x)
I am querying all properties (node’s internal properties and MagmaFlow custom properties) and dumping them all, because I am using this code for Undo/Redo and Save/Load. I could skip some stuff, but then info like Positions, Collapsed and Selected state etc. would be lost. What properties from the example I posted would you skip?
Chad I see your point, what you request is much the same eval methodology as the stack.
BUT it seems a 1000x more natural to use a top down here IMO.
Besides now you have a navigator! Which is something I meant to ask earlier, does the field save its location when you close the Magma editor and re-open it?
Not sure what you mean with “field”.
As in Magma 1.x, Pan, Zoom and node positions are stored in the modifier’s MagmaHolder ReferenceTarget object. I still have to add some other properties I feel should be sticky per editor as opposed to sticky per session, e.g. the state of the Reorder toggle. But closing an editor, saving the Max file, closing Max, opening it again a week later and opening the editor will restore everything as you left it. The Navigator just reflects/affects the Pan and Zoom values of the Helium control.
Sorry the “Field” meaning where you drop the nodes, not the navigator.
It doesn’t happen very often, when you have multiple KCMs it seems to sometimes get confused where the last “Field” position was. So in other words the last “Field” position from the last closed MagmaEd is the position for the next re-opened MagmaEd. Got me. In fact it hasn’t happened in quite some time, so maybe I have just lost my marbles.
Maybe I’m confused. So in my case (ignoring the fact that you don’t need the mapping output in 2.0) why would the ordering change the fact that your flow will have to be reorganized? If my mapping output was added on top, all the connections to the normals output would move. So the only time the nodes/connections would line up is if you created the outputs and the nodes in the correct order from the beginning. Which I suppose might happen sometimes.
If Collapsed defaults to false, then you would be able to skip all those lines.
If Enabled defaults to true, then you would be able to skip all those lines.
And Selected will probably always be true if you copy/paste. How else would you tell the Magmaflow what tool you wanted to copy?
The channelType could also be assumed unless it is non-default for the channelName, right?
And I assume the NumNodeInputs and NumNodeOutputs is actually defined by the node type, right?
I don’t know what the OrderX and OrderY are.
Oh wait, you don’t have name or notes… So those are assumed to be default then, right?
LOL, you are right, Notes and Names are not initialized unless the user entered something in them.
*I could skip the Collapsed and Enabled states if they are true. The Collapsed property is a custom property that is not native to the internal representation of the node, so it was a side effect of me exporting all custom properties (since these are in flux and I didn’t want to add custom handling for properties). But I can look into that. The Enabled property is an internal one and I could indeed skip it if it is true.
*The Selected property could be false if you are using File>Save instead of Ctrl+C. But I don’t want to add special handling depending on what is calling the MXS generator code, so if all your nodes are selected, you will probably have that in your output. It is also a custom property. I could add special handling to only save it if it is true.
*The number of Inputs and Outputs can be dynamic in a number of nodes including BLOPs and some new Query nodes we introduced. The reason I want to save them always is that if the DLR adds a new type of node that has dynamic sockets counts, I don’t want the scripted UI to fail because it doesn’t have special handling. The alternative would be to add an IF to skip that info for any nodes we know have a fixed number of sockets, or introduce more metadata into the DLR to give me a hint whether I should be saving that or not. So I will probably keep on saving those out…
*The OrderX and OrderY should not have been exported, they are used internally for the custom reordering. Same applies probably to Position2 which is the result of the Reorder. More IFs, but it would be worth it. I will rename all these extra internal properties to start with _ and then skip any such properties when exporting… So _OrderX would not be saved, while “OrderX” would. EDIT: Turns out underscore in the beginning of a property name is not supported, so I went with “Internal_OrderX” etc. These are not exported anymore.
*I don’t want to make assumptions what a “default” channel could be, since a custom channel on the list in Krakatoa could have one format on my machine and another on yours. So for important stuff like that, I’d rather spell it out explicitly.
*EDIT: Another thing that could be optimized is the declaration and setting of custom properties. Right now it takes two lines to declare the property and set its value. We could either change the DeclareExtensionProperty() method to accept a default value, or implement a scripted utility function to do the two operations in one line.
Thanks for the feedback!
Will do another round of optimizations and post the results here.
I’d like to see more overloading. I want to Floor or Sqrt or Mod a vector.
Just double checking, there’s nothing that lets you replace a component of a vector, right? I have to break out the vector and then convert the floats back to a vector?
Finally, BLOPs don’t let you add inputs to the BLOP “Properties and Actions”, right? So if I wanted to make a Swizzale BLOP, I can’t?
Compared to the hoops you had to jump through in the old Magma, a pair of a Breakout and a ToVector to swizzle plus a Float InputValue to replace a component isn’t that bad. But I know you are never satisfied.
Not at the moment, but I think it is a good idea to support Input Defaults in BLOPs. Maybe in the next point release…
I added it to the Wishlist.
While we have licensed the code, we haven’t really modified it in any way, so the shadows are the way they were in the original Helium.
If you are using Max with the Dark Scheme, your shadows might be too light for it.
Do yourself a favor and use a light background in the MagmaFlow Editor.
The only access to shadows I have is to turn them on and off. It was exposed back in MagmaFlow 1.x, will reexpose it in 2.0 so you can get rid of them.
Also, I made the stupid decision to change the background of the MagmaFlow to match the background of Max (e.g. Dark Scheme makes MFE dark).
I will probably remove that.
*Node Shadows are OFF by default (so if you are running the default Dark Scheme of 3ds Max, you should be ok)
*Node Shadows can be turned on from the Display Options rollout in the MagmaFlow Editor - the change applies to the current modifier only.
*The option has a >> button with the option to Get Default, Set Default and Reset Default like for the other values, so one can make shadows ON by default if desired.
Thanks for the feedback! I constantly forget Autodesk ships with that impossibly ugly dark scheme as default…
