-
Controlling a User Data Slider via Xpresso
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!
-
9 Replies
-
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
-
That mapper is set up as follows, as to make the output values match the slider values (0-20%):
-
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!!
-
edit: “0,20 input going to 0,20% output”
-
ah, there you are – input lower is fine at 0 but if input upper is 1 any input above that breaks it
-
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
-
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
-
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
-
Fascinating, thank you so much for elucidating such nuances! I would never have reasoned priority was passed in such a way. Along with fixing my problem, this really helps my understanding of C4D’s logical structure; couldn’t be more pleased 🙂
Reply to this Discussion! Login or Sign Up