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]( http://forums.cgsociety.org/showthread.php?f=98&t=955342).
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.]( http://www.youtube.com/watch?v=qA_-wU8khiE)
Here's the process to get started using it:
[img] http://www.garrickcampsey.com/media/VMEhowTo.gif [/img]
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.
--
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! :)
Nice one, thanks for sharing.
Great, thanks! :buttrock:
TheGrak, looks awesome. Thanks a lot for releasing it and sharing with us!
@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.
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.
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.
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
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.
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.