[Closed] passing to and returning arguments

I see only one case where has sense to assign value to function argument (from inside) –

fn foo inArg &outArg = (
	outArg = inArg - pi -- assign val to outArg
	outArg > 0 -- return result from the func.
)
 

Maybe someone with more patience can translate this for you.

I guess my question is, why do I have have to turn theBB into another variable to get it to work?

If I understand you correctly, you don’t need to do this.

You can assign the results of a function to another variable, as long as the function ‘returns’ the value you want. So, for example:

fn myFN =
 (
 --does some stuff
 return "complete"
 )
 myFNresult = myFN()
 print myFNresult

This will print “complete”.

So, for your boundingBox function I would suggest:

fn getBBounds theObject = 
 (	
 	local c = snapshot theObject
 	c.transform = matrix3 1
 	local myBB = c.max - c.min
 	delete c
 	return myBB
 )
 myFnBB = getBBounds $
 print myFnBB

Hope this helps!

Thank you, TheGrak, it does.

I was under the impression that using “return” was somewhat frowned upon so I was trying to avoid it. Perhaps I am misunderstanding it’s use. Time to read up on that.

Thanks!

so would this be the optimal way to execute getting the bb x,y,and z?

 fn getBBounds theObject = 
  (	
 	 local c = snapshot theObject
 	 c.transform = matrix3 1
 	 local myBB = c.max - c.min
 	 delete c
 	 return myBB
  )
  
  fn xBounds bb =
  (
 	local x = bb[1]
 	return x
  )
   fn yBounds bb =
  (
 	local y = bb[2]
 	return y
  )
   fn zBounds bb =
  (
 	local z = bb[3]
 	return z
  )
 
  myFnBB = getBBounds $
 x = xBounds myFnBB
 y = yBounds myFnBB
 z = zBounds myFnBB
 

 so would this be the optimal way to execute getting the bb x,y,and z?

“Optimal” is a very subjective term. If it works for you, then it’s as optimal as it needs to be. I’m sure Bobo or denisT could optimize this code further, so there are many ways to do what you’re referring to.

I was under the impression that using “return” was somewhat frowned upon so I was trying to avoid it. Perhaps I am misunderstanding it’s use. Time to read up on that.

I’ve read using return slows down functions a little bit, but the function you are working on isn’t time sensitive so I don’t see why using return would be problematic or frowned upon. You also don’t need to type “return something”. You can just type “something”, and the fn will return it automatically.

For example, you don’t need return:

fn getBBounds theObject = 
 (	
 	local c = snapshot theObject
 	c.transform = matrix3 1
 	local myBB = c.max - c.min
 	delete c
 	myBB
 )
 myFnBB = getBBounds $
 print myFnBB

Works the same as above code.
I’ll attempt to optimize your code and post that in a second.

Here is an attempt at optimizing that code:

 fn getBBounds theObject = 
   (	
 	  local c = snapshot theObject
 	  c.transform = matrix3 1
 	  local myBB = c.max - c.min
 	  delete c
 	  return myBB
   ) 
 myFnBB = getBBounds $
 myx = myFnBB[1]
 myy = myFnBB[2]
 myz = myFnBB[3]

The boundingBox values that are returned are returned in a 3 element array (a point3). you can access an element in the myFnBB array by it’s index. you don’t need a function to do this.

Hope that helps!

One of the advise in maxscript reference is not to use return because it is slow. I don’t know how slow it is, but…
So, instead return you can use this:

 
 fn getBBounds theObject =    (	 	  local c = snapshot theObject 	  c.transform = matrix3 1 	  local myBB = c.max - c.min 	  delete c 	  myBB   )  myFnBB = getBBounds $ myx = myFnBB[1] myy = myFnBB[2] myz = myFnBB[3]

The function will return the last expression.

Awesome dude, thanks for the explanation on the return – I really appreciate it!

I can’t understand why the code is so … unreadable formated.