Wooden Crank

[shartte]

Added a model for the wooden crank, item model, and a TESR that makes use of it.

A FastTESR could possibly work using some of the vertex rotator magic we're currently using. But personally I don't think it's worth it since you can't use wooden cranks for decoration :P Initially I thought about using a block model when the crank is "at rest" and a TESR for when its rotating. But since the crank doesn't actually return to its original position when the cranking stops, this also doesn't seem to offer any benefit.

Visual Result:

[shartte]

There might be a possible solution using the Forge animation system as well. Might look into that.

[Elix-x]

Yeah of course probably definetly. I'll accept TESRs only when it's impossible with models.

[shartte]

You realize that triggering a visual chunk rebuild for every animation tick will kill performance more than using a TESR, right? The general consensus seems to be that animated models -> TESR. Even the Forge animation system comes with a TESR helper class. It's still a TESR, it just might be less code, really. Only advantage I can see is using the Fast TESR system, but still. It's a TESR :P

Side note: I am currently also working on the meteorite compass. And even though I have a working TESR solution, I will have to go models because animated in-hand TESRs are not really supported by Forge anymore (The hook is there, but it's marked for removal).

[Elix-x]

As i said, fast TESR is for far te rendering (and should have been called far TESR really). So it won't help much.

And yes, i know that forge animation system relays on TESR internally, but why not use it? It will be less code for us.

[shartte]

@elix-x Are you sure about FastTESRs? My understanding was that it was for batching draw calls and improving performance if multiple instances of the same TESR are on screen. Regarding the animation system: I can check it out, but I'd rather have it as an issue for further improvement than holding up this PR. I am not even sure the animation system is easily usable for us because of our custom caching rotating model.

[Elix-x]

Look into FAMS and if it is that difficult to use it, we will see.

[shartte]

Allright that's fair enough. I need to check it out for the compass anyway.

[dpeter99]

Can I merge this? @elix-x

[Elix-x]

@dpeter99 not yet.

[shartte]

@elix-x Okay I checked out the FAMS and it's extremely complicated (and undocumented). I'd rather not use it for something like this, since it'll still be based on a TESR even when we use the animation system.

[Elix-x]

Nope. You & @JosephRymer will have to learn it anyways, as all animated blocks should use it.

[shartte]

Yeah no thanks, someone else will have to do it then. It's a waste of time.

[Elix-x]

Well, with more complicated it blocks it will get a lot more complicated to use TESRs and jsons at same time.