Tweak of grandfather clock 'anim'

[SneaksieDave]

Not really a model animation I guess, but I'm not sure where else to put this. I made a tweak to the old pendulum movement to try to make it more like a real one ( e.g.

) which move in a much smaller arc and slower. Vid shows original movement compared to new. Let me know if you think it's good enough to commit to SVN.

 

video

[Springheel]

Fine with me. Did you create a new table for it? I'd like to keep the old one for use with gauges.

[SneaksieDave]

Good catch, didn't think of that. I'll use a new, and keep the old.

[SneaksieDave]

Okay committed with both tables intact.

 

Is there a way to adjust the time? I didn't deduce one from looking at the mtr file. It appears the clock always starts at about 6:37 pm which is probably not ideal for thieving missions.

 

"Mum, did ye hear something?"

"'Twas just the wind. Pass the rolls and gravy please?"

[Springheel]

I think you have to rotate the images manually.

[SneaksieDave]

If that's the case, then I'd be inclined to say that the UV map needs to be changed in the clock face itself, because otherwise any other model which currently uses the clock arms (I'm assuming there are more... maybe machinery?) will get screwed up with a change. I'd give it a shot but it looks like while Blender can import an LWO, it cannot get the UVs on one.

[Springheel]

Hmm, that should work. Can you make a tracker entry and assign it to me so I don't forget?

[SneaksieDave]

Okay done: http://bugs.angua.at/view.php?id=1761

[Dram]

If the texture is round, then you can do the time via shaderparms.

 

The back layer would be a simple background (white with numbers), then on that would be a minute hand layer, and then an hour hand layer. These could be adjusted to automatically spin over a set period of time constantly (so for the hour hand it would rotate 0.00833 degrees per second, equaling 360 degrees over twelve hours.

 

The default rotation offset would be tweaked via shaderparm, which would specify the hour and minute.

 

Just needs for the minute hand and hour hand to be separate images, as well as the background.

 

I don't think a second hand would be necessary (afaik most grandfather clocks don't have minute hands?).

 

Would be awesome to return to a room and find the time really does change.

[Springheel]

These could be adjusted to automatically spin over a set period of time constantly (so for the hour hand it would rotate 0.00833 degrees per second, equaling 360 degrees over twelve hours.

 

That part is already done.

 

The default rotation offset would be tweaked via shaderparm, which would specify the hour and minute.

 

How is that done?

[Dram]

How is that done?

 

Looking into the TDM folders I see the clock animation is done via model, rather then material. If it were done via material, then you could add the following to make it turn over the set period of time:

 

textures/darkmod/tessssting
{
   noSelfShadow
   noShadows
   twosided

   // Hour hand
   {
       blend diffusemap
       map models/md5/props/gfclock/gfclock_d
       clamp
       rotate (8.333 * (time * 0.0001)) + (Parm7 * 0.00833)
   }
}

 

Set shaderParm7 on the entity that uses the texture equal to the hours that it should start at.

 

Of course this would require tweaking, but it is possible.

[Springheel]

There is a version that does it with models, but we're talking about the one that uses animated textures.

 

Set shaderParm7 on the entity that uses the texture equal to the hours that it should start at.

 

So shaderParm7 is just some universal variable? What does it default to?

[Dram]

So shaderParm7 is just some universal variable? What does it default to?

 

It is a shader parameter that can be set in scripts, on entities etc, and thus used to affect the materials of that particular entity. On the other hand you have global shader parameters, which are adjusted globally and affect all materials using the globalparms. For example the texture ambient method uses this. Our colored lamps use shaderParm 0, 1 and 2 for color. ShaderParm7 is nothing special, I just chose 7 because I use it for the particle leaves.

 

ShaderParm7 defaults to 0.

[Springheel]

So you set shaderparm7 on a entity by entity basis?

[Dram]

Yes, so you can have one clock set to show 8 while the other 10 etc, as long as that shaderParm (be it whichever number you choose to use in the material file) is set on the entity which uses the material. The shaderParm you set on the entity itself.

 

You could also set up a third shaderParm which controls the scale of time passing (for weird missions), so you could have it show time passing at faster then life rates etc etc etc.

[OrbWeaver]

I'd give it a shot but it looks like while Blender can import an LWO, it cannot get the UVs on one.

 

I have definitely imported an LWO with UVs into Blender before, but I have a feeling you need to download a separate import script rather than using the one packaged with Blender.

[SneaksieDave]

I think you're right, that does ring a bell. I was only trying the native import support so far. It's great that they got that in, even if it's not yet complete; and full ASE support is native finally! Yay. Blender has really impressed me in this re-visit. OSS is one of the world's greatest things.

 

Anyone want to try Dram's suggestions above? I'm really curious about this. It'd be excellent if mappers could actually set the time for the clock in a mission.

[SneaksieDave]

@Dram: any further suggestions on this? When you said tweaking, you really meant it...

 

I took the original equation and started mucking with the numbers to see what does what, and so far this is where it's at:

 

rotate (2.8 * (time * 0.0001)) + (shaderparm7 * .0833)

 

The first parens create the slow movement. 2.8 was borrowed from the original numbers in the shader, and seem to be as close to proper minute movement as we're going to get. I did blind tests with a straightedge on the monitor and a stopwatch and got: 58 sec, and 1min 1sec. So it's really close. Where did 8.333 come from, I'm wondering?

 

The second parens create proper 5-minute separations. They are not the correct time, meaning setting it to 11 might give you some value near 7:30, but at least whole numbers are 5 minutes apart. Was it .00833 for any necessary reason?

 

Working:

* Proper minute motion

* Proper 5 minute spacing by whole numbers on shaderparm7

 

Not working:

* Proper hand placement for the minute time. Yes, they're 5 mins apart, but not at the correct times. Need some math person for that I think, or a lot of trial and error. I assume it will have another set of parens.

* Any work on the hour hand at all (none attempted yet)

* Would the hour hand use a different shaderparm?

 

[Dram]

To explain, the example I gave above was for the hour hand, where if you put a value of 3 into shaderparm7 then it would start at 3 o'clock.

 

0.0083333 is:

 

360 degrees over 12 hours || 30 degrees per hour || 0.5 degrees per minute || 0.00833333333333333 degrees per second

 

Since the rotate function is done per second, then you use 0.00833333, but for some reason it doesn't work right when put there like that, so I did 8.3 * (time * 0.0001) to compensate.

[Dram]

To clarify what I said above, basically when I put 0.008333 for rotate degrees it did something more like 1, so it seems to only take integers. I'll mess around with this and see what I can come up with.

[Springheel]

That's not necessary...Fidcal already set the values to work according to real time. The only thing we need is the part that tells the hands where to start.

[Dram]

That's not necessary...Fidcal already set the values to work according to real time. The only thing we need is the part that tells the hands where to start.

 

Presuming that is for the texture hands version, then you only need to add the + (parm7 * 0.008333) to the end of the rotate function. That will mean that adding +1 to parm7 would add one hour (or 5 minutes etc).

[SneaksieDave]

Thinking about it, I guess that the reason it's off from expected is based on two things: 1.), whatever alignment is on the texture, and 2.), whatever UV alignment of that texture is, on the model. For this to work correctly, it needs to be calibrated correctly. The textures themselves must point exactly up, and the UV map must then align them exactly up. After that, 0 (or 12 or 24) will be midnight. Correct? If so, we need to worry about those first.

[Dram]

Pretty much sums it up. I'm not sure if we have a second hand, but it is possible to have that too. Might be a little pointless though.

[Springheel]

I've modified the hour and minute hands to point straight up (in the texture). However, I recall being somewhat confused when setting them up because they didn't start at the same position as the texture. Maybe that will be fixed by adding Dram's shaderparm line.