Deluxe Ski Jump Forum

So, I have decided to remove my answer to sneze2r's post and to systematize all information about my propositions to include for hills profiles. In my opinion, hillmakers should have much more freedom in preparing desirable hill profiles than currently. How it should look? First of all, let's start with inrun.

• Generating startgates spacing. Currently it is based on 'step' parameter which can be measured horizontally. My idea is to combine two parameters: es and number of startgates. The equation used for that could be es/max (max - number of startgates) and everything would be generated in inrun line.
• Generating r1 parameter. First of all, I would like to ask: what kind of curve is used to generate this parameter? The change of curve type is dependent on what answer to this question I will get. If it is cubic equation, then there is nothing to change in that case; if other, then it should be changed into cubic. Also, on a few hills certificates we can see that r1 parameter has two values - the reason is that at beginning of curve is different radius than at the end of it. Example is Vikersundbakken, where r1 has at its beginning 142 meters radius, and at the end 100 meters radius. In that case, two methods could be used alternately, so using - it is my proposal to name that parameters - r1a and r1b would work normally when just r1 is not defined.

Now there are my ideas for landing zone.

• P-point used alternately with l1. Currently l1 is not generated too accurately (mostly it is related with h and n parameters, so I am going to suggest using just P parameter to define concretely a length, where blue sheets start and where landing zone arrives to moment defined with beta-p.
• Bigger priority for rL in situation, when hillmaker don't want to define beta-L. It could be used alternately as well. Sometimes beta-L parameter is not measured correctly, so prioritize rL parameter would be a nice variety.
• Adding r2L parameter as an optional. It should work like that: if r2L is not defined, it won't cause not loading the hill by the game - then r2 will generate as an one curve (defining potential r2L=r2). Currently r2L is required in newest hills since 2008, when JUMP-08 standards became announced by FIS.
• Another option which could diversify creating more realistic lower dhill curvers: defining a length where U-point is situated. In that case, there won't be any need to use r2L, r2, r2x and r2y.
• Options to choose curve type. Currently I know that the r2 and r2x with r2y are generated as a cubic parabola, and FIS requires in hill projecting standards to use quadratic parabel. So I would like to suggest some types of curves as a parameter 'curve' connected with r2L, r2 and with U-point location: 'quadratic', 'cubic', 'clothoid', 'circular', etc. It should be connected with U-point position, if r2L, r2, r2x and r2y are used, the curve equation should be changed from cubic to quadratic, according to FIS standards.
• Beta-U also as an optional parameter. When it is not defined, it should be automatically generated as a 0 degrees. If it is defined, my proposition is to define it in values 0≤x≤10 (what is your suggestion about maximal available beta-U?). After U-point, it should go smoothly into 0 degrees depending on 'ar' parameter.

Some ideas for me look like easy to implement, some difficult, but it doesn't matter. As I write at the beginning, hillmakers in my opinion should have much more freedom with generating hill profiles, so chances with creating realistic profile could be much bigger than nowadays.

Start gates: I think that the 'es' parameter didn't match to reality on most of the hills, so I decided use custom step to define the start gates. This could be changed, so that the step is automatically calculated from 'es' if no step is given.

Inrun radius: I am using cubic equation for the inrun curve, so the radius of curvature changes smoothly along the curve.

The changes that you proposed for the landing zone require a bit more thinking...

Ability to define two inrun gammas and r1s
In hills like retro Holmenkollen, Odnes or even Squaw Valley http://www.skisprungschanzen.com/EN/Ski ... lley/0578/ it would be very useful in accurately representing their inrun profiles. The first gamma could both be larger or smaller than the second since in the past the inruns didn't necessarily get less steep the closer to the takeoff you got.

Ability to place K and HS points in 0.5m interval
Useful for hills like Bílá K47,5 or Eisenerz K63,5 HS70.

Maciejo-96 wrote: ↑29 May 2021, 19:28 [*]Beta-U also as an optional parameter. When it is not defined, it should be automatically generated as a 0 degrees. If it is defined, my proposition is to define it in values 0≤x≤10 (what is your suggestion about maximal available beta-U?).

I think there is no point in artifically restricting Beta-U range, since hills with crazy Beta-U wouldnt get verified anyway and I'm all for letting hillmakers make even more crazy experimental profiles

I had a chat with Maciejo-96 and the conclusion was that possibility to define absolute positions (x,y) of P and L points instead of defining rL / r2L and l1 / l2 would make it possible to create wider range of (realistic) landing profiles.

I also noticed that in my current implementation the radius of curvature rl is not used (or required) for anything when generating the landing profile. So, the shape is currently based only on values of beta-p, beta, beta-l, l1 and l2.

Xinitiao wrote: ↑31 May 2021, 12:19 Ability to place K and HS points in 0.5m interval
Useful for hills like Bílá K47,5 or Eisenerz K63,5 HS70.

I just discovered that in the past there were even crazier FIS-homologated hills, such as this K53,6 gem http://www.skisprungschanzen.com/PL/Sko ... iedingtal/ so I guess this proposal needs to be changed to 0.1m interval

[low priority suggestion]

More control over the outrun profile
Currently creating outrun is very unintuitive, and in my opinion hillmakers would benefit with more control over how its created, for example the flat part of the outrun can currently only be placed in the beginning of the outrun, and curves after, but not the other way and we have no control over the angle of a, so the outruns of hills like Willingen cant be properly modelled

Jussi Koskela wrote: ↑01 Jun 2021, 08:22 I had a chat with Maciejo-96 and the conclusion was that possibility to define absolute positions (x,y) of P and L points instead of defining rL / r2L and l1 / l2 would make it possible to create wider range of (realistic) landing profiles.

I also noticed that in my current implementation the radius of curvature rl is not used (or required) for anything when generating the landing profile. So, the shape is currently based only on values of beta-p, beta, beta-l, l1 and l2.

This is now implemented for the next update.

Xinitiao wrote: ↑31 May 2021, 12:19 Ability to define two inrun gammas and r1s
In hills like retro Holmenkollen, Odnes or even Squaw Valley http://www.skisprungschanzen.com/EN/Ski ... lley/0578/ it would be very useful in accurately representing their inrun profiles. The first gamma could both be larger or smaller than the second since in the past the inruns didn't necessarily get less steep the closer to the takeoff you got.

After consideration in the commitee, we think it would be even better if we could create inrun profile with a custom definiable profile, like currently you can with inrun-extension (using lines, arcs, polynoms). (The inrun-extension inrun profiles are currently constrained by fixed startgate position to inrun-top and constrained from the bottom by the actual profile-inrun profile. This feature is necessary for good recreation of real hills too i.e. Oberhof HS140.

Very interesting idea, it could give more control on creating more realistic inrun profiles. Also it could be nice to see more options of curves in profiles [f.e. conic (quadratic), circular...]

And... hmm... what about preparing the same method for dhill? I forgot to suggest that it could work better than only coordinates

Completely custom inrun and dhill (top, left, right) profiles might be doable but not for the next version. There are some assumptions in the code with regards to them.

Currently it's okay to redefine inrun-left, inrun-right, inrun-left-guard and inrun-right-guard, but redefining others will break things up.

Okay, we'll be waiting with more unusual hills for future versions then