This project is a further advancement on the earlier saw palmetto concepts. By advancing further into Maya's scripting interface, we explore more possibilities and uses in the ReadArchive functions where numerous effects and controls can be used to generate much more complex effects and animations.
Notes!
This project may differ from the initial assignment writeup written for Professor Malcolm Kesson. It would have been edited to also reflect my later experiences, clearer tutorial techniques/codes and also later advancements made to the projects as well.
RIB Replacement
Continuing from our previous assignment where we learnt to place objects onto the vertices of a polygon, we proceed further to placing more complex objects into the scene. This method using Renderman's Pre-Shape Node... which exist as a insertable renderman attribute onto any shape object. The concept is that once executed in Prman, the engine will read this attached node and perform any MEL action as requested by the user.
The RIB_MEL Files
To facilitate this action, we begin the exploration of three file types - the UI melscript, the UI rman file and the RI melscript. Though extremely unconventional in my own opinions, these three files work together in the RIB_MEL folder of the maya project space to faciliate the proxy rendering.
Bearing in mind that this is a renderman process, it is inevitablity limited by that very aspect. A possiblity of which can still be considerably imitated strictly by Melscript probably in the added render functions included in Maya itself. Carrying onto the topic. The UI melscript creates a renderman based User interface which allows users to manipulate any options as they so desire. To simply put - when modified using Professor Malcolm's Cutter interface, it provides an extremely easy alternative towards Maya's own user interface creation... albeit with one fatal flaw - that the attributes are actually defined by the use of the Rman file which behaves like a fixed procedure, requiring a Maya restart inorder for it to incorporate any chances. Still, in my own preferences, I still very much prefer the addAttr of which Maya provides.
Continuing on, it was pre-decided that the attributes used for this part of the exercise were to include several functions such as:-
► Radius - this will determine the radius of the RiSpheres on the vertices.
► Scale - this will determine the scale of the ReadArchive RIB files on the vertices.
► Jitter - this will offset the positions of the proxys on the vertices, thus creating a positional noise
► Seed - this crucial attribute locks the randomness of the rand command.
► ArchiveName - this determines the path of the RIB file.
► UseArchive - this boolean trigger activates between RiSpheres and RIB files upon rendering.
Next, the concept of this is relatively simple! The UI Melscript adds all the renderman attributes to a selected object. It also places a Pre-Shape Node which calls out the procedure addSpheresToMeshRI which is essentially the RI Melscript which will run the required actions.
The addSpheresToMeshRI Procedure
Similar to the earlier script performed in the Vertice Tricks chapter, this script too calls on the same attribute, with only one crucial difference. That would be the use of Renderman Languages in the Melscripting platform. Anyone familiar with the RIB language will immediately remember a few features about such code. Essentially any RIB code could be used in the Melscript environment provided that the Renderman plugin is loaded and that the header "Ri" is added.
Other useful notes would be the use of "headers" such as TranformBegin and TranformEnd. This is the way by which a RIB file remembers spatial manipulation and should be used to contain any tranformations or rather "translations" on the rib objects. The essential code below tells renderman to either render a RiSphere or RIB archive file through the activation of the $useArchive switch.
The results of which, after carefully adding on RIB attributes such as RiSurface, RiScale etc can be seen as below:-
The Swarm of Invaders
Inspired by the comment of the Professor, I have decided to embark on my own kind of Matrix action. Using the pixel classic form of space invaders! Using the earlier experimented ghosting and incoporating new elements, I hope to create a similar sentinel swarm movement of space invaders.
However, there are many limitation when it comes to the use of Renderman Pre-Shape nodes compared to the flexibility of Melscripting that we have earlier discovered. For some odd reason, the arrays could not be ideally stored in Maya's memory when it was being executed during renderman's render. Also considering that the use will be unable to display the full effects of the ghosting and therefore be unable to judge his configurations.
The MAYA > MEL > RENDERMAN Solution
So what can I do to preserve the user's ability to preview his options? while still allowing the high numbers of high poly invaders to be rendered in Renderman? My solution came down to this header's title. By breaking up the two systems apart and allowing Maya and the Mel language to evaluate the effects of the ghosting parameters while allowing renderman to handle the rendering.
Thus the script and user interface was broken up into 2 parts:-
Since it was obvious that we wanted the entire ghosting process to be controlled by Maya rather than Renderman's process, it was obvious that the two interfaces be seperated apart. The earlier ghosting process now reduced with a lesser interface since Scalar controls were no longer part of its jurisdiction. While the main Renderman attributes remains the same as with the earlier introduction.
What my intentions for this script is that Maya will process all information with regards to the object's rotation and position in relative to the ghosting trajectory and will output these data into two arrays of which Renderman will use to place the "Invaders"
Using similar concepts, the ghosting code was rewritten to compensate for this action required by this new format. Null Locators was also created to display the position of the objects. Using the aimY procedure from www.fundza.com which uses pythogorean theorem to caculate the cartescian angles. The same linear format was created for each objects targeted aim as they progress through the arrays of position which comprises of the object's trajectory.
And thus, we are able to see a preview of all user actions in the viewport while the Ghosting information is constantly being updated by Maya's expression editor. Data of which is then outputed vis $outposition and $outrotation towards Renderman which will then place the proxies for render.
Thus completes this part of the assignment. However, as there are still a few scalar glitches, work will still continue to progress for this section until I can finally match a scene to recreate an invasion.
Errors which was observed was the way positional information greatly varied from the Renderman environment and Maya space. Thus creating a significant variance in scale, rotation and position which poses a significant problem at this moment. A desperate altlernative woul be to write 2 seperate script to do positioning procedures to place the objects in Maya and in Renderman seperately. Of course this would inherently create more issues especially when ghosting is concerned.
The Positioning Issue Examined
So what was the problem? After several extremely complex tests and trying to recreate means to solve the problem from scratch over and over and over, PRman was determined to tell me that its positioning coordinate system was different! A simple screen shot showed how a simple position in renderman such as 5,5,5 could become a complex floating point number of 2.6088356~
It was evident that this number could not be possibly compensated at this point. So I was forced to discard this effective method of presenting this scripted effect. Thus I began testing the two environment for its differences and hopefully began to solve its inexplicable issues.... Changing my eventual preview system to a duplicate geometry which presented the less desirable but similar result!
But Finally, after hours and hours of testing and going through 8 different techniques to achieving the same result, the problem was finally solved! The issue?
The Maya and Renderman Conversation
Well the animation tells it all. It seems that PRman cannot received attributes with regards to translation directly from Maya. This inexplicable part was tested and tested and tested to no avail. However, the oddity of it was how it related its position from the object containing the Pre Shape Mel!! Yes , this meant that if I can isolate any transformational movement to the object containing the node, the solution coud find itself. Thus, I have seperated the MEL and PRman part into a greater division. The mel script exist as an expression on the actualy object itself, while it duplicated the "hero" object and than placed all its vertices in a ghosting environment in Maya. Next, the Pre Shape Mel simply queried the position of the duplcated vertices with relation to its Pre Shape Mel Node and everything was solved! Finally. With that resolved, the invaders animation now march on again!!
Right below, you can see an example of an baked animation preview of what the inMaya preview will look like for its users as they attempt to control the positional values to manipulate the ghosting and wobbles.
dave kin chang wei - visual effects artist / technical director - davekcw@yahoo.com.sg - www.kamid.net
home
