Hi all,
I am planning a script-project that should act as a kind of productconfigurator.
I would like it to work like the AEC – foliage objects. except that the objects are not created runtime, but merged into a kind of ‘parentobject’ in the scene – from a modellibrary.
(so i will end up having an object called f.ex. ‘machine_type-A’ that consists of a lot of merged parts).
I think it would be nice if a allready defined machine could later be adjusted via the modifypanel – just like all other maxobjects. This is where my problems begin:
How do i create the ‘modifypanelenabled’ object that holds all of the merged parts, and handles updates according to the changes the user makes in the modifypanel.
Any ideas / approaches are very welcome.
Thanks.
Jan Fjordside
Jan,
there are examples for scripted Simple Object-Plugins in the Maxscript Reference.
Just do a search for ‘Developing Scripted Plug-ins’.
Scripted Plugins have a drwaback, you need to install the script that ‘installs’ them on every machine, you want them to render. But thats the same witrh every plugin.
Sometimes I think its more flexible to have a controller object with Custom Attributes that controlls a ‘group/assembly’ of default objects. Custom Controlls are saved with the scene.
Here is a preview for a scripted plugin I once wrote:
rdg::simpleHouse
Georg
Hi Georg,
Thankyou for the script example – liked it very much :-)…
Thanks for your input, wich has given birth to two new questions
1:
I have been through the script-ref’s Scripted Plug-ins section, and i have a fair idea of how it works. But i cant figure out how to replace the buildmesh function with a ‘merge-and-changematerials’ function that gets called everytime the user makes adjustments in the modifypanel.
2:
In your custom attributes approach – would it be possible to connect the assemblies/groups to the modifypanel for later modification.
Thanks
/Jan
glad you liked it
1: I am not sure what you mean, but I would do it that way.
I sounds very ‘unresponsive’ to me.
2: The customAttributes for the ‘assembly’ (not the build-in one) would be in the modify panel.
-> some more ideas/thoughts:
Maybe you should consider some abstraction layer, like a embeded flash active-x to compose your machine/assembly. this could give you a more responsive way to combine the various parts of the machine. a click on the generate button then merges all the needed parts to scene. store the ‘assembly-definiton’ in a customattribute, so it can be send to the abstraction layer anytime for redefinition. a ‘rebuild’ would delete all parts and merge the new one.
the assembly can have customattributes to change materials and stuff. I can post you my ‘very important – show me the environment color in the scene box’ if you want to.
I would be to affixed to the modify panel. it has it pro’s and con’s. Sometimes a floater with good designed interface and sophistacated functions is more helpful than a must-be-in-the-modifing-panel tool. But this depends on your task.
Georg
Please do
Do you mean that i should have a ‘edit’ button in the rollout, with wich i can pick allready inserted assemblies, for modification?
First off i think that the abstractionlayer will be some standard rollout content – to keep it as standard as possible. But great idea, flash opens great opportunities. I guess that html and js would be good also. Perhaps it would be possible to have the configurationoptions in a seperate xmlfile, for easy access when its time for updates… (lots of loose ends – lots of fun )
/Jan
yes, I would go the ‘pick assembly’ route. Sure you can have callbacks that watch selection changes and enable/disable your menues.
Here is the rdg::envColorHelper.
Georg