Hmmm...semlar what happens if one wants multiple rings per segment? (Like mana and life)
They both need their own spinner right? Is overlaying a problem?

From my work with orbs I can tell that frame stacking is a pain in the but. In the system that is working with only two scrollframes (two halfrings) one can position multiple textures inside the scrollchild. Textures can be stacked amazingly well thanks to texture drawLayer.

To get frame stacking right on my orbs I have to parent each frame after another.

*Sidenote*
Just to save it from dying. I recoverd my blogpost from elitistjerks from 2009 and brought it to github.
https://github.com/zorker/rothui/tre...chive/rRingMod
https://web.archive.org/web/20110208.../362-ring.html

We might need to create another scroll frame that covers the spinner and parent the 4 background textures to its scroll child to keep them on the same level as the wedge texture.

I want each spinner to be treated as one unit and separate from any other spinners that you create.

I want to play around with semlars function this week. Currently collecting some ideas and links.

http://wowwiki.wikia.com/wiki/SetTex...ransformations
https://github.com/tomrus88/Blizzard...L/Util.lua#L31

I have not grasped how it is possible to rotate the wedge texture via animation rotation and correct that rotation via SetTexCoord.

Like you rotate it to the right by 45° but then you call SetTexCoord to rotate it left by -45°. How is it keeping the clipping?

Oh. It is the other way around isn't it? You do SetTexCoord first and then rotate.

The order of the rotations is irrelevant, they're rotated in opposite directions to keep the picture level while the animation creates the desired angle. I thought of all of this immediately after seeing this image in your original post:



The yellow square is the slice/wedge texture; its corner is attached to the center of the image and an animation widget is being used to rotate it around in a circle to create the (green) angle that we want.

I'll make some illustrations to hopefully clarify what's going on. Here's what we're starting with:



First, we rotate our image using an animation. This gives us our angle, but of course it also rotates the image.



We'll apply a rotation in the opposite direction to correct its orientation using SetTexCoord.



It's upright, but not quite the effect we're going for, so let's shift it to the left (actually halfway down and halfway to the right, we want it to be centered on one of its corners so it lines up with the image). This translation is done along with the rotation in one matrix transformation to generate the coordinates for SetTexCoord, but I'm showing both steps separately here.



Finally, we'll put it in a scrollframe to clip anything outside of the quarter of the image we actually want to be displayed.



That's it, the rest of the image is just 3 copies of the original texture shifted halfway to the center to make up each quarter.



Here's our final product:

Thanks a ton. What blew me is that you can adjust the SetTexCoord of a texture and keep the clipping that is set by the animation rotation.

Basically the texture is clipped twice. By the animationgroup and by the scrollframe.

There are huge benefits being able to do it this way because the ring texture can be of any shape.

Is the outcome any different when using this instead of the animationgroup?
http://wowprogramming.com/docs/widge...re/SetRotation

A few weeks ago semlar allowed me to use the code he posted to use it in an addon.
Its far from finished, here are the first results.

First picture is Health and mana with red and blue Spinners (called so because thats the word semlar used in his example :) )
There is an animation there below the spinner but of course that isn't visible in this picture :rolleyes:



Second picture is the health Spinner in action.



Third and fourth pictures are the same as the first two but have different textures applied.
Also the "eye" in the middle is animated.





Early january I got the inspiration for an animated heath/mana bar.
Found Zork's addon called Diso Kugel 2.
But couldn''t get the result I wanted :mad:
Then came semlar's post.
Spinners (name for the addon I am using) is a combination of the code semlar posted and the inspiration I got after seeing Disco Kugel 2 :D

Might be a few weeks before I will release a Beta version (progress is limited by time and skill).
But so far I am happy with it.

Any suggestions for improvements are most welcome.

Texture:SetRotation() reuses the C code for Texture:SetTexCoord() using a rotation matrix (and shrinks the image by √2), so they overwrite each other.

The animation isn't clipping the texture. The only thing the animation does is physically rotate the entire texture widget, which is extremely important because SetTexCoord is only capable of moving the texture within the boundaries of its (square) dimensions.



Since the animation rotates the entire physical texture object, it means SetTexCoord is no longer limited to cutting off the texture at 90 degree angles (the sides of the texture), because now the side of the texture is at whatever angle we rotated it to.

You can think of a texture object like a scroll frame. You can move its contents around using SetTexCoord, but you can only ever "clip" it at its edges, which are always 90 degrees.

Now imagine that you could apply a rotation animation to a scroll frame. You're no longer limited to 90 degree angles because the edges aren't straight up and down, they're at the angle you set the rotation to.

The animation still isn't clipping anything in that example, the scroll frame is, it's just changing the angle that the scroll frame is clipping its contents at.

Hmmm. When working with textures that use an aspect of 1 (square), is the following condensed Transform function correct?

Yeah, if you're only manipulating square textures it looks like that does the same thing as calling Transform(-0.5, -0.5, angle, 1) with the function I wrote.

If you'd rather work with degrees instead of radians, I believe the blizzard functions sin and cos are degree-based instead of the radian-based math.sin and math.cos, so you don't even have to convert between them if you use those instead.

Not sure if you noticed it. The wierd bug that you fixed in the demo with a OnUpdate function that you call onPlay and disable it thereafter can be fixed by just calling :Pause() after :Play().

What cannot be removed though is the delay. No clue why it does not animate without it.

The delay makes sure you have some time before the animation ends. Otherwise, the animation stops and snaps back to the original position before you get a chance to pause it. I'm not entirely sure if AnimationGroup:SetLooping("REPEAT") would crash the game with a zero duration or if it would apply at all, but that might be a possibility.

SDPhantom the thing is that we never need that delay. If we do not set it the API will not rotate the texture.

I sat down and wrote myself a small test addon for the ring. Super cool indeed. That the new technique allows texture stretching makes it even better.

http://imgur.com/a/fGZpG

https://github.com/zorker/rothui/tre.../wow6.0/rRingo

What is missing is the ability to select another start segment and to pick the number of frames to be used.

So many use cases. You could use it to create small squares that emulate a cooldown spiral.


By far the coolest thing in a long time.

I would not use the animation system later on for smooth animation progress. What oUF_Smooth does is more than fine. All one needs is a SmoothBar module for all the value updates. Sth like this: https://github.com/zorker/rothui/blo...oUF_Smooth.lua

"Needing" it is subjective. Do we need a full 1 sec end delay? No. In fact, it could be far less. As long as it keeps the animation running long enough so we can pause it. The problem with running a zero duration animation is it never plays. This can either be a check in C code to not start or the animation ends before AnimationGroup:Play() even returns. Either way produces the same result as when an animation finishes, everything snaps back to their original layout.

Your own testing provides this answer, I'm just explaining it so you can understand what might be going on and why.

Thanks. Maybe it is just me but I find it wierd that the animation has to be played and then paused to be able to use :SetRadians().

On top of that you cannot play/pause the animation itself. It has to be the group.

Hello

Thanks Zork to point me there.

It is a very nice concept from semlar.

Cheers
Sigg

What bothers me are the numerous bugs still in the animation system. For example, rotation animations don't reposition the frame's children, they just rotate them in place on the same origin point. Also, setting a particular animation's target only works in XML, the Lua API for it does nothing (always runs on the AnimationGroup's parent no matter what you set the target to).

Would it be possible to create animated pie charts with this method with relatively small cost?
I'm looking for something like that in the future.

I actually wrote this specifically to be used as an option for progress textures in weak auras, so it will be used to create animations there.

Most of the processing is from performing the matrix transformation for the texture coordinates which requires a decent number of math operations, but even doing this with a number of different textures probably isn't going to cause a noticeable impact on most, if any, computers capable of running the game in the first place.

edit: I tested 1200 spinners (all using the same texture) and went from 100 fps to around 80-85, animating them OnUpdate.

I was actually more interested in data relating to the additional impact of having paused animations continuously rendering. An earlier version of my custom flight HUD used a bounce looping method on rotating textures and paused whenever the loop state changed. I scrapped the method since it not only had its own problems to deal with, but the entire addon as a whole was eating up a considerable chunk of processing power when the game really needed it. It wasn't the worst part of the old code, but I did consider it to be contributing factor.