-
arcionek
2022-10-04 04:45:42 UTC Due to confusion as to what “rigging” would be, refer to the gif below.
(just a few main examples of utility, still up to debate)Round 2
- 42%
- 58%
26 votesLog in to vote!
Stick Nodes®
A stickfigure animation app created for mobile devices!
Create your own stickman animations on your Android or iOS device!
What stuff would you guys make if you had either of these
smart polyfills
no bitches meme around
This is really cool
I probably wouldn’t be smart enough to make anything with this but I bet some talented people could make amazing things
okay if that’s what you mean by rigging please please use a different word
i think that’s part of the reason i’m being patrick.jpg is your terminology lol
(similarly, with max-inverse, what you mean is “pingpong” (as LibGDX calls it), inverse would imply going the opposite direction completely)
also in general your “max” slide is more of a modifier of the “X:1 ratio” behavior, for length, rather than a whole class of behavior as you’re kinda presenting it here
same with “inverse”, its a modifier, so:
[nodeA scale] = 2:1 of [nodeB] (simple, standard statement)
[nodeA length] = 1:1 of [nodeB] (with max of 100) <- optional
[nodeA length] = 1:1 of [nodeB] (with pingpong effect) <- optional
[nodeA angle] = 2:1 of [nodeB] (inverted) <- optional, go in opposite direction
what this implies is you NEED 4 things for a "nodegramming statement"
1 target node, 2 controller node, 3 what property is being affected, 4 ratio
(optional parameters of setting min/max, inverted, pingpong, etc)
– – – – –
"rigging" to me = using a skeleton and giving it different skins basically, basically nothing to do with nodegramming
this is just nodegramming in general imo, nodes behaving a certain way through programming
– – – – –
say the target node is non-static and is being modified by a controller node
can the user interact with the node? what happens if the controller node is moved again, does it snap the target node back to where it “should” be?
Silence , old man
you’re like 20
that’s 40 in zoomer years
I’m barely 17
i said you’re 20
It’s fine officer, I told them they’re 20.
okay if that’s what you mean by rigging
I don’t know what to call it atm, so I just go with whatever name as for now because I suck at naming and never got any suggestions. Lmao.similarly, with max-inverse, what you mean is “pingpong”
This one is kinda funny, let’s say we have 1:1 mirror of length. Segment A is the controller, segment B is controlled by A, segment B has max of 200. Both segments start with length of 100.Now if we stretch A, after passing 200 length, segment B would start going backwards. For example reasons the numbers are (A, B):
(150, 150), (200, 200), (250,150), (300,100), (400,0), (500,100)
With the last number, this is what I meant by “ping-pong”, as B would end up oscillating between 0 and 200. Would be neat if it could be somehow transformed into a sin/cos motion, but I’m keeping this example simple for now.
what this implies is you NEED 4 things for a “nodegramming statement”
Nerd, I already went through this.We get a controller segment, then create a variable that is one of the controller’s properties (length, angle, scale etc.), then we get a target segment, set it so one of it’s will match the variables number at 2.00 (user customised) scale.
So if we stick with variable and target both reading and applying the numbers to angle, and their controller-target starting angles would be (0,90) then:
(45,90+90), (90,90+180), (180,90+360).
last part question
This is why I said the rigging thing should only work with non-static segments to avoid headaches. Especially since they break smart-stretch continuity, but can start one themselves.If a segment is being “target”, it can’t be interacted with in animation mode. Simple as that.
Where you should be worried about is what if controller is attached to target. Mathematically would be “simple”, but will be totally broken ui wise lmao. (spoiler alert, the app would just give nah son).
Anyway, the reason why variables would exist is to allow for better way to handle it UI wise, as well as give option for user to switch between variables and properties without breaking fuck all.
Will give mockups on how everything will look, don’t worry about that lmao.
yeah i was kinda reiterating what you said in a different way
but if you can present your ideas like that it’d help
almost like you’re writing up the documentation for an API
specifically name the “functions” and parameters, and any optional modifiers, etc
just helps with the understanding
see like now i finally get what you mean by “create a variable”, i think i can reword that as “pick a property to modify”?
you’re not really “creating” something right?
(and now i read the end bit of your post and your talking about variables and properties as different things and i’m back to patrick.jpg)
in my head this seems pretty much all we need right now and as you said, static nodes only (making sure there’s no death-loops is already done with joining, its not terribly difficult to prevent that)
almost like you’re writing up the documentation for an API
Never wrote one, don’t know how even writing one looks like. Thus, reason why we’re failing to communicate properly lmfao.as you said, static nodes only
u mean non-static lol.I had similar idea for the window for it lmao, just didn’t want to have clutter of 300 different segments being put into one window.
Also very rough draft for the rigging mode.
Emphasis on having multiple figures in the same Rigging mode, not just one stick. I basically was designing this for stuff like “if variable X is equal Y, then Stick1 switches to Stick2 at Z angle” when the target is the main node. And variables would also provide data between segments, it would get confusing if we get 2 of #69 segments.
I had a bunch of stuff in mind when it comes to rigging, on top of what we discussed, but that’s like more or less later-development shit. I know how it could be handled, just wanted to set a place for it.
are you getting static and non-static mixed up or what lol?
these target nodes can’t be used by the user to drag around like normal, so they’d have to be static
y or n
– – – – –
so variable = method of controlling the node?
it can be controlled by a segment, or in the sidebar by a checkbox, input, slider, etc
however i don’t see the point in anything other than a segment, else you’re just changing the length via the sidebar aka you can already do that
oh wait
i just had brainblast
so you make a “poopybutt” variable, and it is applied to the stickfigure
when you select the stickfigure, this “poopybutt” appears in the sidebar
if you change the value of “poopybutt”, every node using this variable changes
k cool
now for the sad part
i don’t think i will dabble with variables or anything that messes with the UI/sidebar for the app, at least anytime soon
that’s a whoooole mess of work with new modes and menus and shit and you know what i’m tryna do with my schedule
sticknodespctease.jpg
right now gonna just do everything else minus the variable stuff
yeah it’ll be inconvenient for those trying to go into maximum overdrive, but it’s better than nothing and is still doable
are you getting static and non-static mixed up or what lol?
Nah, the reason why is, like i said, I want to put it in separate rigging mode. Which would hide the static Nodes becauseA) it’s a whole lot of ass having so many segments packed onto screen. I know “hide static Nodes” exist but
B) I wanted to be able to put multiple figs in a rig.
i don’t think i will dabble with variables or anything that messes with the UI/sidebar for the app, at least anytime soon
Oh yea no prob with the sidebar ui shit, I knew it would be a problem but I put this out as to show why variables to begin with.But you should still add variables, just for segment wise, grey out the other options. Variables will make this sorta easier for rigging and also make sure shits won’t break if you decide to work on the UI part lmao.
If you think the multiple figs in one mode would be too much ass rn, and would get to it one day, i could also suggest to have the rigging in Creation Mode as a toggle between the two, until it gets developed enough to be more of standalone thing with multiple figs. I’d say putting it onto separate file to save would make it also less stress inducing lmao.
well then my question is still a question
what if a user moves a node that is being controlled by another node, or is it not moveable
– – –
as for variables, i can probably still do a variable like you said just for segments, so many target nodes can easily look to one controller node
similarly i wanted to add as many “Color” properties to a stickfigure that a user wants, so they can change many different aspects of a color in a figure
anyway that’s for a problem for future ralph
– – –
for the SN app, rigging will all be done in creation mode as you’re making/editing a stickfigure yeah
it’s not gonna be as robust as you want but we both know why that is and what i’m aiming for why are we doing this in public lmao
what if a user moves a node that is being controlled by another node, or is it not moveable
Putting this part up again.If a segment is being “target”, it can’t be interacted with in animation mode. Simple as that.
color
Oh yea I keep forgetting to include mentioning that whenever I get to making mockups or writing about it. Will prob make smth about it later.for the SN app, rigging will all be done in creation mode as you’re making/editing a stickfigure yeah
Butt damn it’s gonna be ass. As a full-time rigger node limit is bane of my existence. That’s why I insisted on multiple fig variable shit lmao.why are we doing this in public lmao
To hold u accountable lmfao.Btw, when are you gonna add that thing where it connects two separately branched segments?
oh i thought you were implying it was static by saying that, thus my stupidity
Btw, when are you gonna add that thing where it connects two separately branched segments?
also can we talk about how dangerous the word rigger is
honestly lol’ing at the idea of this being the intro to like, a sitcom or something, and its cycling through quick shots of all the characters
captioned “Arcionek”
ps i deicded the Rigger Update will be 5.0.0 and will be quickly following 4.0.0 (and the subsequent quick fix/minor versions)
don’t wanna introduce 2 game-changers in 1 update
Yeah figured out so. It’s too much for sprite update lmao.
i just realized that was loss i was too overwhelmed with all the other shit lmao
both dont seem that useful to me so its still a hard choice
this stuff would essentially allow you to build functional machines
like pull a lever (a segment) and doors open/close
of course people will take it to maximum insane-o levels and build like redstone type of shit
I already made working calculator with just smart stretch so…