|02 February 2012||#1|
Speeding a script controller as much as possible
All right guys, I need your help. I've been delaying this post for long now trying to solve the problems on my own but I progress too slow and hence at this rate I'm going to give up. Something I don't want to. And before I forget, I'm using Max 2012 x64.
I don't know about the code of my helper plugin. Never coded a scripted plugin before and it took me some time to figure out how not to create the mesh all the time. It was slow as hell before, now feels ok for me. But still, I think the line "meshop.autoEdge effectorMesh #All 0.1" could be replaced with something faster. Although maybe it's not needed since the mesh is created only at specific cases. Either way any feedback is very welcome. Here it is:
Ok, so let's get to the questions:
1: As my main concern here is speed, THIS topic was really interesting. Unfortunately soon the talk got too "deep" and I could not follow it anymore. However, as shown in there, script controllers seem to be a bottleneck speed and memory wise. But I don't know how to achieve the same I'm doing without them. I was planning to make some functions (like different falloff modes maybe) inside the falloff object and call them from the script controllers, but I can't do that with expression or wire. Does weak references help speeding things up here?
Well, I don't know if it's possible through maxscript only, but I wanted to be able to have a workable feedback (8-10fps?!) with at least 1k objects. Am I asking too much from a scripted solution?
Test scene (must run the scripted plugin above first!):
2: I'm doing this tool to control arbitrary parameters, essentially float controllers. I want to have dynamic UI controls so the user can add/remove new ranges to link to different things. The approach I'm experimenting with is through custom attributes and redefining it as I add/remove stuff. But I don't like the UI blinking it causes. Is it possible to avoid that? Is there a more correct/elegant way of doing this?
3: How to access the node itself from inside the scripted plugin? I tried using "this" with no luck. Can't find anything in maxscript help. This is a problem for me since I'm adding the custom attribute to the node by using the "$" which is fine if the user explicitly creates the object. But if I try to create it via script it of course fails.
4: As the affected objects hold a script controller, deleting the effector will make a mess. I was thinking in storing the affected controllers in the effector node. So I can revert them before deleting the effector. Does the #maxObjectTab support controller values? The best way for dealing with this is with a #nodePreDelete callback, right?
Forgive me if some questions are too noob, but my coding skills are waaaaayyyy outdated. So I'm completely opened to any tip, suggestion or anything to improve.
|02 February 2012||#2|
Senior Technical Artist
Join Date: Jun 2005
Have you tried using the on <param> set <arg> do () and on <param> get <arg> do ( <arg> ) handlers within your param blocks? This would dispense entirely with the need for any external controllers as the paramblock parameters would have their own sub-anim tracks (assuming you have set them to animatable:true).
Edit: A quick hack of your code yeilds this... Link your sphere object to the helper using the pick button on the UI then the UI properties will change the radius of the sphere:
if you want the sphere to update when the helper is moved then you can use the when construct to add a change handler, something like this:
You can add as many handlers as you need to the same id, then when you're done you can remove them with the delete change handler functions (check the reference for details).
Hope that helps!
Last edited by Moosley : 02 February 2012 at 01:45 PM.
|02 February 2012||#3|
Join Date: Sep 2003
Thread automatically closed
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.
Note that as CGTalk Members, you agree to the terms and conditions of using this website.
|Thread Closed share thread|