Notifications
Clear all

[Closed] Expression controller character limits

Hey all,

I’ve got a system we’re using for receiving rigs from outsourcers which are authored in maya. They have a system which can convert all of thier rig mathematics into an xml which I then parse inside max and build expression controllers from.

This is a proven bit of tech that we have used through several projects, but this new rig is an order of magnitude more complex and I’m encountering a few issues.

When I generate my expression, I get no errors. All of my scalars are generated correctly and the .setExpression runs fine with no errors. The rig also does stuff when the driving objects are moved about (although the movements of the joints are not exactly right which is why I’m debugging this).

However, if i open one of the expression controllers to look at the expression itself (which is over 4000 characters long), I then get an error saying its having an ‘Error Parsing Expression’.

I’m wondering if maybe we are hitting a limit to the size of these expression strings inside max 2012? It is strange however that upon controller creation I did not get a parsing error.

Anyone ever encountered anything like this before or know of a limit ot the size of an expression?

10 Replies

i don’t think a script expression has any limitation by number of lines or symbols. my thought the problem is in your expression.

Looks like there is a character limit. If I shorten the names of my scalars then I get no error. Looks like it may be a 4096 character limit.

1 Reply
(@denist)
Joined: 11 months ago

Posts: 0

interesting… but i never in my many years practice wrote an expression for script or expression controller longer than 100 lines of code.

Yeah we have never needed to previously, but these rigs are insanely complex!

I ended up writing a modification to my original tool, which goes through and essentially hashes the names of all of my scalar variables and then replaces these much shorter names within the expression text. Now that I’ve done that, the expressions are working with no problems. I was worried that doing this would make the expressions hard to read, but they are so huge they were almost impossible to follow anyway!

i can show you some technique, and you will see why i never wrote any script for expression longer than 100 lines …

ca = attributes functionHolder
(
	fn makeMatrix3 p0 p1 p2 = 
	(
		front = normalize (p1 - p0)
		up = cross front (normalize (p2 - p0))
		side = cross up front
		matrix3 front side up p0
	)
)
delete objects
b = converttomesh (box isselected:on)
s = b.position.controller = position_script()
s.addobject "functions" (createinstance ca)
s.setexpression "(functions.makeMatrix3 [0,0,0] x_axis y_axis).pos" 

simple, isn’t it

if you want to ‘stick’ the attribute and controller use something like:

delete objects
b = converttomesh (box isselected:on)
s = b.position.controller = position_script()
custattributes.add s ca
s.setexpression "(this.functionHolder.makeMatrix3 [0,0,0] x_axis y_axis).pos"   

also you will be surprised to see how faster these solutions vs a code put into expression body

Yeah I know there are faster ways of writing these things, but unfortunately (or fortunately depending on how you look at it), we have a system that can run expressions at runtime inside our games, which means our footprint of keyed data is tiny. This uses a sligthly cut down version of the operators within the float_expression controllers, however we have to keep them as ‘simple’ float_expression controllers, without some of the more elegant things that can be done

Hi DenisT.
How would you do this but using “Positon_Expression” instead of “Position_Script”? Is it possible?

1 Reply
(@aaandres)
Joined: 11 months ago

Posts: 0

OK. Never mind. Really usefull!