The Viewport Maxscript Editor - NEW

Become a member of the CGSociety

Connect, Share, and Learn with our Large Growing CG Art Community. It's Free!

THREAD CLOSED
 
Thread Tools Search this Thread Display Modes
  02 February 2011
The Viewport Maxscript Editor - NEW

Here ya go:

The Viewport Maxscript Editor Version1.2c - released 2011.03.26
Download and extract .zip contents, run .ms file.

Prior releases:
The Viewport Maxscript Editor Version1.2b - released 2011.03.11
Download and extract .zip contents, run light or dark .ms file.
The Viewport Maxscript Editor Version 1.2 (with Lite and Dark skins) - released 2011.03.06
Download and extract .zip contents, run .ms file.
The Viewport Maxscript Editor Version 1.1 - released 2011.02.27
The Viewport Maxscript Editor Version 1.0 - released 2011.02.23

I'm happy to release a new script that allows you to create scripts using objects in max's viewport.
I call it "The Viewport Maxscript Editor", and it's existence is the direct result of this post.

It was written with the idea that it could replace the long outdated and basically useless "Visual Maxscript Editor" - it's even named the same acronym.

Enough talk. Here's a demo of how it might save you time.

Here's the process to get started using it:


This is a version 1 release, so if people like it/use it/have feedback, then I'll be happy to update it.

Use it, break it, dig thru it, tell me how it can be made better.

--
Quote: j83:
I would suggest never use the Visual Maxscript editor, it creates messy code, spaghetti-like UI controls, and hard-codes all UI positions which makes it very time consuming to manage and add new functionality. The Visual Maxscript editor was abandoned by Autodesk a long time ago and I don't think they're going to finish it.

This comment was used like a guide. I've tried to format the code the script writes in a simple and straight forward manner, and the script itself was created to allow additional UI elements to be added later on, as well as groups/presets of UI elements. Unfortunately, for this release, I've hard-coded the UI positions - but I plan on adding a checkbox to toggle between writing offset: instead of pos:. Default events would be easy to write as well, so that may be an update. Here's the code from the above .gif image:

global Rectangle001
       try destroyDialog Rectangle001 catch()
       rollout Rectangle001 " Rectangle001"
       (
           --UI ELEMENTS
           button Rectangle002 "caption" pos:[100.0,135.0] width:100.0 height:30.0
       )--close rollout
       createDialog Rectangle001 300 300 250 100 lockWidth:true lockHeight:true style:#(#style_toolwindow, #style_sysmenu, #style_resizing)


Hope people find it useful!
__________________


Last edited by TheGrak : 03 March 2011 at 06:55 PM.
 
  02 February 2011
Nice one, thanks for sharing.
 
  02 February 2011
TheGrak, looks awesome. Thanks a lot for releasing it and sharing with us!
__________________
The Lady and the Reaper, Oscar-nominated animated short, here
 
  02 February 2011
flowCode idea

@scrimski, 48design, and IkerCLoN: I'm happy to help! Let me know if you guys use it/want any changes to it.

I brainstormed more on my way to work (long commute).
Here's some crazy ideas based on writing scripts with objects in the viewport:

With this image, I've taken Euclid's 'Greatest Common Denominator' algorithm and displayed it as a flowchart and as code. Then I merged the two ideas to create node-based coding, which is tentatively named "FlowCode" for now. Here's my inspiration for doing this. You may notice that I put a function inside the main function. That's to simulate recursion, but still allows the function to accept parameters. I'm not sure if the code would work that way, thats just how I've written it out.

The idea behind this 'flow code' was to bridge the worlds of visual design and code design. Using nodes, you can define relationships using links or lines. The nodes are evaluated according to their links, just like a script is evaluated top to bottom, left to right.

Now I'm not saying this way of coding is better or even possible, but... I can foresee the ability to drag a variable node into a function node and (based on node distance) link the variable into the function automatically. This would save my hands from copying + pasting variable names into functions. This could also be extended to statements like 'if/then' or 'fileIn()'. It's objective tasks like these that I am certain can be automated or simplified. If nothing else, it's just a different perspective on writing code.

These ideas are scattered for sure, but I hope to build a working example of 'FlowCode' before the end of Feb, so Max users can start to play around with it.
__________________

 
  02 February 2011
Thanks for sharing this with us. I like your ideas on node based scripting. I think that might make it a little more approachable by users with less scripting experiance. I think autodesk should be thinking about adding somthin like this in XBR.
 
  02 February 2011
Quote: Viro: I think autodesk should be thinking about adding somthin like this in XBR.


That's one of the big motivators for why I'm doing this.
If I can write something that people actually use and it helps them in their day to day tasks, then I'm happy. If it ships with 2012, then that makes me happier. If it gets more people into writing code, then I'm even happier. And I'm not looking to sell this idea, Autodesk can just have it... no strings attached. Or hire me as a 'conceptual developer' - whatever that is.
__________________

 
  02 February 2011
You're actually describing here FSM's or finite state machines. Basically states controlled by conditions triggered by inputs.

a = 10

if a > 20 : greater condition - input 20

then a == 20 - branch off
__________________
Disclaimer: My opinions are not those of my employer.



Last edited by eek : 02 February 2011 at 10:44 PM.
 
  02 February 2011
Much respect Eek! I'll be absorbing some concepts from Finite State Machines.
Do you see value in this approach (writing code using objects)?
__________________

 
  02 February 2011
Just updated the script. You can download it from the first post of this thread.

VME can now build (rough) clones of itself, via a drop down item.


I also forgot to illustrate how VME can manipulate the actual size of the UI elements:


And a stress test:


Also cleaned up the code a bit with a new function.
I think I'm just going to develop 'FlowCode' into this script after the UI elements are polished a bit more.
__________________

 
  02 February 2011
Originally Posted by TheGrak: Much respect Eek! I'll be absorbing some concepts from Finite State Machines.
Do you see value in this approach (writing code using objects)?


It makes it incredibly modular, its one reason node based workflows catch on so well - take ICE, Houdini or Shake for example. In terms of complexity though things can get very hair raising and complicated very quickly and you can tend to blow out the system for systems sake i.e you add a state just for the flow to keep working - when a custom piece of logic does a better job.

Essentially you want the best of both worlds - one that motionbuilder does nice with the relation constraint. It's a controller powered by nodes, states, switches etc by that can have scripted input i.e custom python input for a node.

I.e you want base logic to be easy to create but that can wrap custom logic - i.e like ICE compounds. Its one reason i LOVE the script controller in max - i use it for everything thing - it would be neat to wrap that into a nodal work flow.
__________________
Disclaimer: My opinions are not those of my employer.


 
  02 February 2011
@ Eek, thanks for the thoughts. Very motivating.

I've been thinking more about flowCode. Here are ten examples of how I'm seeing various nodes working:



1. illustrates a variable node. the VME IDs would exist as custom parameters on the line object. the VME IDs would describe the properties of that variable, for example: type = string, value = "myString".
2. illustrates 'code canvases', which are essentially representations of sets of brackets. these sets of brackets can be of type: function(), rollout(), or just a pair (). I'm sure there are more types. these canvases contain statements and variables, and also help to illustrate...
3. variable scope in a very intuitive manner. Variables 1 and 2 are parameters of Function A, variable 3 is in the scope of Function A, variables 4 and 5 are in the scope of Function B, and variable 6 exists in global scope.




Let's move on to statement nodes, starting with the fileIn() node.



4. illustrates the fileIn() nodes VME IDs, consisting of an editText value you can enter, or a pickButton that lets you select a node. When a value or node is entered/selected, the object updates itself with a small triangle to visually indicate that it is linked.
5. illustrates a string variable linked to a fileIn() node. I envision extra data being displayed in the viewport when an object is selected, for example clicking on the fileIn node would popup the data "fileIn()" then underneath it the values assigned to it's parameters... in this case it's just a string variable, since fileIn() only accepts a single value and it must be a string.
6. illustrates running a file from the scripts directory, based on a fileName variable. these nodes are placed within a bracket canvas, and you might notice the "+" node adds the string variable to the getDir node string.
7. illustrates a new kind of user-interaction based on this layer of nodal abstraction. here I'm dragging a different variable string into the bracket canvas, and based on proximity (a circle object representing a 'weld' tolerance value), max recognizes that I want to replace the variable and prompts me with a yes/no messagebox. now I can drag and drop variables into brackets without copying and pasting, or even typing. Coding with the stylus






Moving on, lets check out if/then/else and case of statements:



8. illustrates the VME IDs of an if/then/else node. notice that 'else' is controlled by a check box, enabling the user to toggle between if/then and if/then/else states. The outgoing links are labeled A and B, referring to then() and else() respectively.
9. illustrates a if(...)then(fileIn(...))else(print ...) statement in 'flowCode' form. Notice the print node has text input or pickNode VME Ids.
10. illustrates a case statement. the bold node is the case node, which evaluates to the connected nodes. there can also be a default node. it has a spinner to set the number of case statements. while this particular concept is functional, it is also inherently limiting and I'm not totally happy with it so far.

I plan on building functional variable nodes within a few days, then move into building basic logic nodes, assignment nodes, and also figuring out how to link nodes in the viewport based on proximity. I'm also planning to update the UI of the VME script to separate UI elements from nodes, so you don't have a dropDown with 2,000 items. In addition to all that, I'd like for the VMeditor to be able to build a fully functional copy of itself with just a click. This will pave the way for building preset UI elements, with nodes, in groups, so you could save UI elements and code (node sets) as presets.

This will eventually lead to: A C# compiler node. A XML reader node. etc... possibilities are endless... even more far fetched: a Python installer node... or a node that would compile a string into a frozen python binary, allowing the user to visually write python .exes in maxscript. many ideas...
__________________

 
  02 February 2011
Nice one Be sure to take a look at impure in case you haven't done so already.
__________________
Scripts :: linkedin
 
  02 February 2011
@Swordslayer: Thanks! Impure is inspiring.

I figured out a more elegant way to represent if/then/else, case of, and fileIn() statements. This idea is built on top of the assumption that any set of brackets would be represented in the viewport with a bracket canvas. This also allows me to 'name' the rectangles based on what they represent.



This simplifies the visuals a bit. Notice the default statement on the 'case of'. I think this approach is much closer to representing the actual code. There's a lot more to be developed.

A couple of fun things:
1. To save a script's UI that you are developing, just save the .max file.
2. Since each Custom Attribute stays with the object, you can merge and xref UI elements.

I also had the far-fetched idea of writing a .PSD import node - allowing a user to build the UI as layers in Photoshop. Then based on layer name, example: "PickButton", the VMeditor could load in the .PSD, parse the layers to UI elements (compare layer string name to library of strings), then load in the appropriate bitmaps (assuming you've already sliced up the elements and saved them as images). I think this type of node would let users customize their scripts UI very quickly and professionally. This idea is a variation on the PSDtoCSS web service available here. It's also similar to how Adobe Encore can import .PSDs to build DVD menus based on layer name. Food for thought.
__________________

 
  02 February 2011
Originally Posted by TheGrak: @Swordslayer: Thanks! Impure is inspiring.

I figured out a more elegant way to represent if/then/else, case of, and fileIn() statements. This idea is built on top of the assumption that any set of brackets would be represented in the viewport with a bracket canvas. This also allows me to 'name' the rectangles based on what they represent.



This simplifies the visuals a bit. Notice the default statement on the 'case of'. I think this approach is much closer to representing the actual code. There's a lot more to be developed.

A couple of fun things:
1. To save a script's UI that you are developing, just save the .max file.
2. Since each Custom Attribute stays with the object, you can merge and xref UI elements.

I also had the far-fetched idea of writing a .PSD import node - allowing a user to build the UI as layers in Photoshop. Then based on layer name, example: "PickButton", the VMeditor could load in the .PSD, parse the layers to UI elements (compare layer string name to library of strings), then load in the appropriate bitmaps (assuming you've already sliced up the elements and saved them as images). I think this type of node would let users customize their scripts UI very quickly and professionally. This idea is a variation on the PSDtoCSS web service available here. It's also similar to how Adobe Encore can import .PSDs to build DVD menus based on layer name. Food for thought.



I think you need to sort out base logic first:

if/then/else
continue/exit
while/for
try/catch/throw
case of

One thing your'll have to start thinking about is combining different logic, i.e the result of a case statement driving a if statement etc - nodes handle this with a line connecting them.

What you'r actually depicting is actually a circuit diagram i think - with hints of state flow code logic.
__________________
Disclaimer: My opinions are not those of my employer.


 
Thread Closed share thread



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
CGSociety
Society of Digital Artists
www.cgsociety.org

Powered by vBulletin
Copyright 2000 - 2006,
Jelsoft Enterprises Ltd.
Minimize Ads
Forum Jump
Miscellaneous

All times are GMT. The time now is 12:15 AM.


Powered by vBulletin
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.