Tweak of grandfather clock 'anim'

[SneaksieDave]

I'm assuming any remaining angle would be from the UV alignment, no?

[Springheel]

I don't know...I may be misremembering, but I thought I noticed that the hand start position changed if I added the rotation line, which would suggest it isn't the uvmap. If you like I can just rotate each hand 90 degrees and see what happens.

[SneaksieDave]

Hm. I'm not exactly sure how it works, but my assumption is that as long as in the modeler, the UV map is set up such that the arms on the modified textures (I haven't checked these) point straight up, we should be good to start tweaking the equations. Unless that's not what you mean. I dunno. We just need to calibrate to 12:00 and then we can get it working much easier.

[Springheel]

Well, you can test this very easily...just make a square brush in a map and put the decal texture on it. Then see if it starts at 12 oclock. If it doesn't, then the rotation value is somehow affecting the start angle. If it does, then there's obviously a uv problem with the clock and I'll fix it.

[SneaksieDave]

Yep, progress. Both hands point to exactly 6 now. So either the UV needs 180 deg rotation, or the images (probably easiest?), or we use a hacky offset in the rotation instruction.

 

One thing I'm not sure is a problem or not (it didn't seem to be, which is confusing): it looks like the alpha wasn't rotated:

[Springheel]

I've adjusted the clock mesh, see how it works now.

[SneaksieDave]

We have achieved midnight. Now we should be able to figure out the proper equations.

I imagine the texture adjustment probably throws off any existing gauge definition(s).

[Springheel]

I imagine the texture adjustment probably throws off any existing gauge definition(s).

 

I don't think it will...the hands were already pointing at 11'oclock, so I didn't have to move them much.

[SneaksieDave]

Okay this is now working and up on SVN. User sets shaderparm7 for hours and shaderparm8 for minutes. For example, the result of adding the following fields to a gfclock entity in a map is shown in the image:

 

"shaderparm7" "5"

"shaderparm8" "3"

[Dram]

Cool, cheers Sneaks.

 

Speaking of which, that grandfather clock could use a reskin. The strong white on the wood looks a tad cartoony. Also the wood texture is so-so.

[Komag]

old thread, but the first post mentions "I made a tweak to the old pendulum movement to try to make it more like a real one ... which move in a much smaller arc and slower".

 

Did this only affect the grandfather clock object, or was this an effect on func_pendulums?

 

I'm trying to work with a large func_pendulum and adjust it's speed, but there doesn't seem to be any way to do that. the "speed" property is more a matter of swinging degrees and not actually speed at all.

 

Plus, I can't seem to get any reaction out of adjusting the "phase" property either, am I doing something wrong?

[Komag]

... I finally found some answers from another older thread

 

jdude, on Aug 24 2008, 07:24 AM, said:

I think this pendulum function needs some fixing up. The angle parameter isn't listed in the list of it's parameters and it probably should be for convenience sake. Also speed adjusts how far the distance is from the left sway to the right sway, not the actual speed of the pendulum. I am unsure yet what the speed parameter is for this function.

 

greebo said:

The frequency of a mathematical pendulum depends only on the length of the "rope" and on gravity. That's why the "freq" spawnarg is in there, use this to make it faster.

 

The "speed" spawnarg controls how far the pendulum is swinging from one end to the other end. It should probably be called "operating angles" or something, but combine the angles with the frequency and you get a certain speed as result.

 

--------------------

 

I first played around with the "freq" setting and found that with my current "speed", a "freq" of .05 nearly matched it. Then I was able to double both "speed" and "freq" and in effect move the pendulum twice as fast but at the same distance and angles as before. Works great!

[Komag]

Still wondering about that "Phase" setting though, doesn't seem to affect anything

 

 

EDIT - messed with more, found that using number far outside 0.0-1.0 made a difference, such as -20 or -6 (the positive numbers like 4 or 12 just caused a delay for me but no starting angle change)

[Tels]

Still wondering about that "Phase" setting though, doesn't seem to affect anything

 

It should affect the "start" of the movement. E.g. if you have 10 entities moving in a cycle of 1 second, all would move perfectly in sync. With the "phase" you can make all of them start at different times, so they are not in sync. (Not sure in what unit it is, probably in seconds or milliseconds).

[Komag]

crosspost!

 

Yes, I see how it works now. The positive numbers appear to be seconds of delay, because I actually timed it with a stopwatch! The negative numbers might be something like seconds, but actually start the pendulum at that point in the swing in progress right from the map start, instead of just making a delay