does it mean you send a file of this format?
This wouldn’t be really a file. It’s just text in the clipboard that is being pasted on the Unreal 3 Viewport. It contains all the relevant data. It references an asset in the asset library and all sorts of different properties. Unreal then knows what to do with the pasted text.
So you can basically select an object in a Unreal scene copy and paste it in notepad. And do any kind of changes to it, (not to the geometry obviously), but you can change values such as the transformation values.
This is what I’m basically doing with the script. I really don’t think that the creation of the text file is the bottleneck. (Besides the possible memory leaking you guys mentioned.) But in terms of speed, it only took around 0.05 seconds to create the output text (30 objects).
My main concern was the “when construct” that is definitely slowing things down. But as Pjanssen suggested, I could simply start and stop the timer in the when construct. And then let the timer do the parsing and creation of the output text when it gets enough time. In other words, when the objects have stopped moving.
Ok quick update! Pjanssen’s idea about stopping and starting the timer in the when construct worked very well! It is exactly what I was looking for.
However it was still lagging a bit. I did a little test where I printed the objects position in the when construct and I realized that a position is always printed twice. So I “optimized” the when construct a bit.
global tick = 1
when transform selection changes id:#UDK_TRANSFORM_TRACKER do
(
if tick == 1 then
(
tick = 2
)
else
(
UDK_theTimer.stop()
UDK_theTimer.start()
tick = 1
)
)
This seems to do the trick and the lag is now completly gone. Oh, and I’m already noticing how the memory is leaking… :banghead:
[QUOTE=Norman3D
This seems to do the trick and the lag is now completly gone. Oh, and I’m already noticing how the memory is leaking… :banghead:
i’m telling you again… when construct is not an issue. i know the sdk code. when construct is fast. it’s faster than any general callback.
Ok, so then there must be something wrong with the Timer. All I’m doing in the Timer is stopping and starting it. Could this be enough to cause the lagging?
How can this…
when transform selection changes id:#UDK_TRANSFORM_TRACKER do
(
UDK_theTimer.stop()
UDK_theTimer.start()
)
cause any lagging? :shrug:
When I move one object there is no lag at all. If I move 300 I get a lot of lag. It can’t be the function that the Timer runs, because it doesn’t have time to actually run it, right?
EDIT: ok, strange. There must be something with the Timer slowing things down. This runs super fast:
deleteAllChangeHandlers id:#UDK_TRANSFORM_TRACKER
con = dotNetClass "system.windows.Forms.Control"
UDK_theTimer = dotNetObject "System.Windows.Forms.Timer"
fn fn_timer =
(
UDK_theTimer.stop()
print "start function"
)
dotnet.addEventHandler UDK_theTimer "tick" fn_timer
UDK_theTimer.interval = 200
when transform selection changes id:#UDK_TRANSFORM_TRACKER do
(
UDK_theTimer.stop()
UDK_theTimer.start()
)
But I don’t see why the function of the timer is relevant! It should not be a problem. It will essentially run after the transformation has stopped.
Edit 2: I just tested the code above again, and it’s not running fast anymore. What is going on?
This may not be causing the issue, but try using the System.Timers.Timer instead of Windows.Forms.Timer:
http://msdn.microsoft.com/en-us/library/0tcs6ww8.aspx
http://msdn.microsoft.com/en-us/magazine/cc164015.aspx
No luck. Still lagging…
UDK_theTimer = dotNetObject "System.Timers.Timer"
fn fn_timer =
(
UDK_theTimer.stop()
print "start function"
)
dotnet.addEventHandler UDK_theTimer "Elapsed" fn_timer
UDK_theTimer.interval = 200
when transform selection changes id:#UDK_TRANSFORM_TRACKER do
(
UDK_theTimer.stop()
UDK_theTimer.start()
)
Next idea for optimization, cache the start/stop function calls. I’d be surprised if this would solve the problem as well, but its worth a try.
This might sound like a stupid question, but you are running
deleteAllChangeHandlers id:#UDK_TRANSFORM_TRACKER
between each test, right?
Otherwise the when callbacks multiply and slow things down.
Your code isn’t slow for me with several hundred objects unless I run it a few times and don’t delete the callbacks.
yes, yes I’m making sure to delete the change handlers every time. I’m beginning to suspect there is something wrong with my machine. Even when I start 3dsMax run the script once and attempt to move 300 objects it’s lagging.
Strange, works very fast for me. What max version are you on?
Tried it here on 2009/64 and 2011/64 and both were fast.
Perhaps check if there are other callbacks running on your machine using callbacks.show()
Nope, it’s not the case.
I just tested on 4 different 3dsMax versions.
-3dsMax 2009 – 64bit, the code runs fast, no lag.
-3dsMax 2010 – 64bit, the code runs fast, no lag.
-3dsMax 2011 – 64bit, lag!
-3dsMax 2012 – 64bit, lag!
Except 2011, all the others are clean installs, no scripts installed at all.
lo, since the when construct works on the current selection, did you make sure you had 300 objects selected when you ran the script?
Here are the steps to reproduce the issue, perhaps others can try it.
- Create 300 boxes.
- Select all of them.
- Run this script
deleteAllChangeHandlers id:#UDK_TRANSFORM_TRACKER
UDK_theTimer = dotNetObject "System.Timers.Timer"
fn fn_timer =
(
UDK_theTimer.stop()
print "start function"
)
dotnet.addEventHandler UDK_theTimer "Elapsed" fn_timer
UDK_theTimer.interval = 200
when transform selection changes id:#UDK_TRANSFORM_TRACKER do
(
UDK_theTimer.stop()
UDK_theTimer.start()
)
- Move all 300 boxes.
- Lag or no lag?