Hi there,
Today I have some free time for R&D and I’m passing through most of the MXScript’s documentation and I up until now, I found this page, so I wanted to check the performance differences between what I normally do and this method and the differences seems to be huge!
code:
resetMaxFile()
time01 = 0
time02 = 0
loops = 10
for i=1 to loops do (
myObj = teapot()
addModifier myObj (turbosmooth iterations:4)
addModifier myObj (edit_normals())
myMod = myObj.modifiers[1]
myMethod = myMod.getNormal
start = timeStamp()
for i = 1 to myObj.baseObject.mesh.verts.count do (
myMod.getNormal i
)
time01 += (timeStamp() - start)*.001
start = timeStamp()
for i = 1 to myObj.baseObject.mesh.verts.count do (
myMethod i
)
time02 += (timeStamp() - start)*.001
delete myObj
)
clearListener()
format "method 01: %
method 02: %
" (time01/loops) (time02/loops)
result:
method 01: 0.0172
method 02: 0.0037
You are not looping over the turbosmoothed vertex count , but the base object (basic teapot ) vertex count ( because you use *.baseobject, better use myObj.mesh.verts.count )
After that change , the time difference really matters …
haha yeah, stupid me! I was testing it with multiple scenes and I forgot to remove it.
In any case, the difference again it’s pretty dramatic.
I tried it again with your fix and I got the following results:
method 01: 5.3022
method 02: 0.7135
It’s about 7.5 times faster! I wonder why I haven’t seen it by anyone else before.
everything is wrong in both your methods. you are ‘weighting’ the air.
the Edit Normals modifier to be working has to be open as current object in the Modifier panel.
i’ve modified your code to match the condition… now you can get the numbers:
resetMaxFile #noPrompt
myObj = teapot isselected:on
(
max modify mode
addModifier myObj (turbosmooth iterations:4)
addModifier myObj (edit_normals())
myMod = myObj.modifiers[1]
myMethod = myMod.getNormal
local loops = 1, nn
start01 = timeStamp()
for k=1 to loops do
(
nn = for i=1 to myObj.baseObject.mesh.verts.count collect myMod.getNormal i
)
time01 = (timeStamp() - start01)*.001
gc()
start02 = timeStamp()
for k=1 to loops do
(
for i=1 to myObj.baseObject.mesh.verts.count do myMethod i
)
time02 = (timeStamp() - start02)*.001
format "method 01 >> % time:% method 02 >> %
" nn.count (time01/loops) (time02/loops)
)
but as i said: both your methods are wrong. the rigth one is ~10 times faster
in both your methods you iterates through only verts that were before “turbosmooth” which amount is ~250 times less than current mesh.
only me was showed several times on this forum this technique and explained the difference
Hi Denis,
I’m not sure if you’ve read the previous comments, but spacefrog mentioned about the baseobject problem and I replied to that.
I’m also not sure if check the link I’ve posted. I’m not trying to find the fastest way to get the normals! I was just experimenting about the fastest way of calling the same method multiple times. Is there any faster way of doing that? According to MXS doc there isn’t.
in two words… the main difference between :
<node>.edit_normals.getnormal 1
and
(
getnormal = <node>.edit_normals.getnormal
getnormal 1
)
is
in the first case you say to the system to create the interface first and after that use a pointer to the function
in the second case you store the pointer first, and pass only the pointer to function after without creating a new instance of the interface.
yeah, I understand that. I can’t see why you said that these are both wrong.
you call getnormal function in situation when it does do nothing because the edit normals modifier is not a current object in modifier panel.
if you don’t care about real edit_normals performance you can just compare:
n = Edit_Normals()
for k=1 to 100000 do n.getnormal
vs
n = Edit_Normals()
f = n.getnormal
for k=1 to 100000 do f
which makes more sense