As some of you know, I have been working on creating some documentation for the MoI Javascript API. While still incomplete, there's enough useful information there now that I plan on releasing a beta of this documentation later this week or next.

Over the last few days I have also been busy "consuming" the new documentation, using it to create a Javascript library for procedurally generating geometry in MoI. The following is a screenshot of a little tool I have been playing around with that allows you to use this library to create new geometry in MoI by interactively writing and running scripts:



This is still a very early WIP, but I thought it might start the creative juices flowing for some of the more technically oriented MoI users out there about what's possible once the Javascript API is available.

For those not very Javascript savvy, the script I wrote in the window on the right basically says:

- Create some number, n, of concentric circles centered around the origin.
- Extrude the collection of circles to form a roughly "square" set of nested pipes (part1).
- Create a 90 degree rotated copy of the nested pipes (part2).
- Compute the intersection of the two sets of pipes (part1 and part2) and add that to the MoI scene.

That is an invualable work!!!
And show what a true gem of "apparent simplicity" is the system ;)

Hello Dave

Looks really exciting. Im not yet into scripting but this makes me want to learn. You say there will be a beta release will this include the tool you show? what is your plan in then end? will you make a commercial product from it?

lots of questions I know. Look forward to seeing how it all progresses.

Jamie

Wow, this is gonna be amazing!!!
Creating 3d content by scripting has always been my passion, so looking forward to see it working!!

Mark

Here's another sample. I've merged the script with the perspective view just to save some space:



Each line in this one generates a "stream" of random spheres oriented along each of the x, y and z-axes...

> Looks really exciting. Im not yet into scripting but this makes me want to learn.
> You say there will be a beta release will this include the tool you show?

No, the two are completely decoupled. The "tool" is only a day or so old, and is being used to help me develop the procedural library and do some testing. So it's nowhere near being complete at this point. The documentation is just that: documentation. There's no code associated with it at all.

> what is your plan in then end? will you make a commercial product from it?

I'm not sure yet what direction this ought to take. I'm still pondering this question...

Wow, amazing Oo

What about a procedural nodal interface ? :)

Very cool Dave, it looks like you have been putting your script documentation to very good use already!! :)

I'm looking forward to seeing what you will do with all these pieces!

- Michael

"What about a procedural nodal interface ? :) "

Yes, that's the million dollar question! and probably not a simple answer...

Intellisense!

Nice work! Especially if you can come up with lots of "canned" routines.

I think the random function will have lots of applications.

For example, I would like to make a model of a ring with a hammered finish. For a close up render I would like the finish to be geometry rather than use a texture & bump map.

My first thought was to make a solid ring and another solid object in the shape of the hammer head (basically just an egg-shaped solid). Then boolean diff the hammer in lots of random spots around the ring.

A procedure could make short work of that.

Ed

Hi Dave,

Great work you're doing there, I have one question, bear with me as I haven't done any programming since college and that was the 'BASIC' programming language.

Just to get this in it's basic form, correct me if I'm wrong, you write a script and you execute it to produce an object in MoI, if that's the case can it work in reverse, where if we model something can it 'record' what you've done in script form so we can make a sort of macro for repetitive tasks, or is that a completely different thing altogether ?

Cheers

I think thats where he would want the abilty to tie into MoI's Com interface. Thats later...Maybe.

This is great, Dave :)

Very good idea, and will be an invaluable tool to any advanced MoI user.

> What about a procedural nodal interface ? :)

Interesting question. With what's there today, it would not be easily doable. But I have some things in mind for future work that could change that picture quite a bit. We'll just have to see what evolves...

> My first thought was to make a solid ring and another solid object in the shape of the hammer head
> (basically just an egg-shaped solid). Then boolean diff the hammer in lots of random spots around the ring.

> A procedure could make short work of that.

It would, but it might require a lot of analytic math to correctly position the "hammer" before each "blow". I haven't delved into every nook and cranny of the Javascript API yet enough to know if those kinds of interfaces are being exposed in the API. If not, then a PhD in Math is going to come in might handy in addition to some Javascript programming chops ;-)

> Just to get this in it's basic form, correct me if I'm wrong, you write a script and you
> execute it to produce an object in MoI, if that's the case can it work in reverse, where
> if we model something can it 'record' what you've done in script form so we can make a
> sort of macro for repetitive tasks, or is that a completely different thing altogether ?

It's probably doable, but would almost certainly require instrumenting all of the current MoI interface code to "capture" the necessary information. It's probably not something a 3rd party would want to attempt, since its effect would be so widespread within the MoI UI files...

Hi Dave - re: instrumenting UI to capture/record stuff.

Actually there is one kind of recording mechanism already in place, which is used by MoI's current history function.

When a geometry factory produces its objects, the factory name and all of its inputs are converted to a chunk of text and stored on the output objects. This is what is then used during history updates, like when you do an Loft for example and then edit the curves that were inputs into the Loft and then the Loft updates.

That kind of recording is happening all the time when you just do any modeling in MoI.


So there's kind of one ingredient of that in place, but that does not really mean that it would be at all easy to make a macro recorder though, it would probably need to have some additional stuff for reconstituting factories and analyzing inputs on history data and stuff like that set up.

There are plenty of other confusing issues involving recording macros, like when you select an object while the macro is running, do you intend for that particular object to be used when the macro is replayed (say as a cutting object in a boolean), or would you want to be able to pick objects to use at that point, stuff like that. There's probably enough issues that it would be more properly part of a larger and deeper history mechanism that had various mechanisms set up for modifying parameters on a sequence of operations.

- Michael

> Actually there is one kind of recording mechanism already in place, which is
> used by MoI's current history function.

> When a geometry factory produces its objects, the factory name and all of
> its inputs are converted to a chunk of text and stored on the output objects.
> This is what is then used during history updates, like when you do an Loft for
> example and then edit the curves that were inputs into the Loft and then the
> Loft updates.

> That kind of recording is happening all the time when you just do any modeling in MoI.

OK, that's really good stuff to know. Thanks!

> So there's kind of one ingredient of that in place, but that does not really mean that
> it would be at all easy to make a macro recorder though, it would probably need to
> have some additional stuff for reconstituting factories and analyzing inputs on history data
> and stuff like that set up.

Sure, but as long as the information is available through the API, the problem moves from being "impractical" to "doable", which at least means it is still worth thinking about.

> There are plenty of other confusing issues involving recording macros, like when you
> select an object while the macro is running, do you intend for that particular object to
> be used when the macro is replayed (say as a cutting object in a boolean), or would you
> want to be able to pick objects to use at that point, stuff like that. There's probably enough
> issues that it would be more properly part of a larger and deeper history mechanism that
> had various mechanisms set up for modifying parameters on a sequence of operations.

Maybe. But these issues always exist in every macro recording system I've seen. For simple tasks like "clone the current selection and move it +8 feet along the x-axis", then the recorder is just the ticket. For more complex tasks, the recorder is just the beginning.

Usually the user takes the output script from the recorder and tweaks it by hand to create a reusable, parameterized result. Having running code in front of them is usually a huge positive for a user. They can see how the steps they need to do translate into code, and from there it's usually not too big a leap for them to abstract out the parameters from the constants, or introduce loops, etc., provided they've got some guidance or examples about what needs to be done. We're all much better at "copy and paste" than we are at RTFM :-)

For example, as I recall, in XSI you don't have to explicitly record a macro. You just do something, then open up the command history and copy the last few lines worth of stuff you did into a new macro and start tweaking.

So, I'm sure it's still a fair amount of work to do, but I don't think a macro recorder facility has to handle everything itself. Just converting user actions to code is a huge first step...

Hi Dave,

> For example, as I recall, in XSI you don't have to explicitly
> record a macro. You just do something, then open up the
> command history and copy the last few lines worth of stuff
> you did into a new macro and start tweaking.

Yeah, something along those lines I think would be good.

That's kind of more what I was getting at when I was talking about a deeper history mechanism.

It would be nice if there was a way for you to switch on a "history view" that showed the sequence of operations that were used to generate the currently selected object.

Probably the main purpose of that would be so that you could alter some of the parameters that were used and have the object recalculated. But that could also be a good place to capture some steps as a macro as well.

If you were able to more visually edit different parameters with different UI controls for each one that kind of interface would probably be possibly usable by a wider set of people.

- Michael