yea i agree the fact that there is no real time feedback is a problem…
what i imagine right now is using the regular morpher + joystick to control the rotation of the head , and some other way to “snap” between textures based on the joystick position…
that keep sounding to me like material ID behavior
i didn’t play with the Morpher Material idea. My only guess that it might work. The HW shader can probably help to preview the material.
I agree that working with animated textures without real-time feedback sucks.
Another solution might be a SimpleMod that sets vert uv coordinates based on some animatable parameter.
Wait… we have planes(sprites), don’t we? The animatable UVW Map gizmo is much cleaner solution.
So the UV gizmo position wired to some ‘sprite index’ controller value sounds very promising for me.
There is no way to animate ID… No… I’m wrong, there is. There is the MaterialModifier.
Sounds cool for me! I like MAX. So many cool solutions!
I had a few extra minutes so I made a test file using this sprite sheet I found on Google. It’s max 2011 so hopefully you can open it (see attachment). It’s basically the same thing I used in the earlier example but it’s using a joystick instead of a single axis slider.
hmm… the set of walking does look complete for me. we have full rotation cycle, but all front, back, left, and right walking cycles are incomplete. sad… it could be a nice mini-challenge for anyone who likes to make his own puppet.
That’s because there’s only 8 “walk” images on the sprite sheet, so it’s actually only one step instead of a full two-step loop. :shrug:
With a more complete sprite sheet you’d see the full walk.
its a very nice proof of concept
it works well i think , i really need to put this to test on the setup i was going for
ill post it once its done ( im much slower the you guys on that department )
i agree with denis , the amount of possibilities is really exciting …
there are so meany ways to approach this
what i find really fascinating is trying to get a 3d program to do stuff that are not “3d” in nature
or more stylized
its really interesting the way people approach these problems
now … the question is , what is the most effective/stable/pipeline friendly way ?
also in coding and memory consumption and in general time saving setup way
any way ill try to finish my test and post it before Sunday
i think you shouldn’t care about efficiency of the method. the first is you have to make it work anyhow.
so i made a quick test
and the X exis works fine…
but it doesn’t look like the combined diagonals will work the way they i intended
probably because the texture is set up incorrectly , i just tried to do it in a friendly way for correction ( the texture )
Yeah, you’re going to need four more drawings for this texture to work I think. Move the top corners in toward the center drawing so the remaining drawings will be of “look up” and “look down” as seen from a side view instead of 3/4. Should work perfect!
It’s kinda fun to play around with So I went ahead and hooked up both the X and Y and changed the expression so you can resize the joystick with out breaking the math. Once the extra drawings are in there I think it’ll work pretty good!
I think this is definitely the way to go regarding methodology. The only thing worth changing is the implementation of the script controller. What would you do if you had a 64X64 sprite sheet? 64 if/then/else clauses?
A little math and this could be a one-liner.
looks like its working…
but i agree about the methodology
will i need to create a way to input for the script how many rows and columns are in the sprite sheet , the divide that along the limits of the controller ?
lo your saying you think the setup can be done with much less “coding” every time the sprite sheet tile numbers change ? and the controller ? 1 point ,2 point , 3 point
I know writing them all out is super inefficient. What’s a good way to condense something like this down to one line? I’ve never been very mathematically inclined