MAXON CINEMA 4D: Cinema 4D Forum Adobe After Effects Forum

# Controlling a User Data Slider via Xpresso

VIEW ALL
 Controlling a User Data Slider via Xpresso on Jul 27, 2018 at 6:45:20 pm

Hi - I've currently got a Master slider (created using User Data in Xpresso) that's controlling 10 other sliders (linked to some motion of a group of objects). I want to then vary the value of this Master slider via a random number generator, but when I link this together how I logically understand it, the slider is unchanged (pic attached). Within this pic, you'll also see I've attempted converted from integer to percent (the two results shown) but to no avail. I'm guessing I'm missing an intermediate step within the last connection between the random percent and null object containing the slider; does anyone have any ideas?

Thanks so much for taking a look!

 Re: Controlling a User Data Slider via Xpressoon Jul 27, 2018 at 7:33:32 pm

given the result of the random integer and the range mapper are both 8 - what is it doing? Just clamping values? In any case percent won't be an integer it will be a number between 0 and 1 i.e.. 50% = 0.5

 Re: Controlling a User Data Slider via Xpressoon Jul 27, 2018 at 7:44:31 pm

That mapper is set up as follows, as to make the output values match the slider values (0-20%):

 Re: Controlling a User Data Slider via Xpressoon Jul 27, 2018 at 7:51:17 pm

Never mind, your logical perturbation led me to the answer - I've changed the mapper from 0,20 input to 0,20% and that worked! Thank you!!

 Re: Controlling a User Data Slider via Xpressoon Jul 27, 2018 at 7:52:07 pm

edit: "0,20 input going to 0,20% output"

 Re: Controlling a User Data Slider via Xpressoon Jul 27, 2018 at 7:57:20 pm

ah, there you are - input lower is fine at 0 but if input upper is 1 any input above that breaks it

 Re: Controlling a User Data Slider via Xpressoon Jul 27, 2018 at 8:50:46 pm

Actually I'm still getting a weird result... my object is taking on random values supplied (between 0->20), but not the actual random numbers shown in the slider (also between 0->20). For example, the slider goes 0->20 with the object as open as possible at 20 and as closed as possible at 0. The slider will show a new value on each new frame, but this value does not match the actual width of the opening seen. Easy to see, hard to explain - so I've attached my scene file in hopes that someone knows whats going on here.

The reason I need this to be consistent is that I'll eventually need the actual random numbers used over the shown frames printed to a list, and if I take the ones currently being shown, they won't match the actual geometry changes happening in the scene.

12584_eo1decoupledforum.c4d.zip

 Re: Controlling a User Data Slider via Xpressoon Jul 28, 2018 at 5:07:03 am

I've only had a short bit to look at it but why the extra xpresso - why an xpresso on each inner cloner and not just direct control of the inner cloner in the main xpresso on Mouth? Parts of xpresso like that can be a good way to organize but you start having to think about the expression priority... and for that matter perhaps you need to get the expression priority higher (lower?) than the cloner's priority (which is Generators 100 or something, have to look it up tomorrow). Just some thoughts for starters

 Re: Controlling a User Data Slider via Xpressoon Jul 28, 2018 at 9:13:06 pm

okay here's a file back at you.
I put a text spline in to get direct feedback about the random integer, not worrying about trying to follow the values in the xpresso window or the OM.
Changed the Matrix to Axis Distribution from Vertex for fewer particles generated just to speed it up for the test and most importantly dropped the Matrix to after (underneath) the Cloners. Since the Cloners and the Matrix are generators and (I think) the same internal priority and that priority is not settable then the order in the OM takes precedence. So this way the matrix generates it's particles in the position where the cloners have moved to for the frame and not before the move as was happening originally. I think that's what was causing the extra stuff in the display and would have been delaying (always a frame behind) the pyrocluster puffs in a render.

12591_eo1decoupledforum2.c4d.zip