[1.1.2] Kerbin-Side (v1.1.0) & Supplements

[Sigma88]

1 minute ago, AlphaAsh said:

Alas no. The RefLatitude and RefLongitude in an instance are just that, references. Static placement relies on PQSCities, which uses radial positions.

Yeah but I know the math for how to switch from one to the other, so no issues there

Sadly it was confirmed to me that mm can't do sin/cosin so I cannot do it this way

I still want to check if there is a way to do it only using the position vector

[ShotgunNinja]

@Sigma88 You could approximate sin and cos using a Taylor serie.

But seriously, this is better done in code. You need a program that take the input data (.cfg files or whatever that is) and output the processed data. Then you just feed the processed data to the 6.4x version of the mod.

For reference and for fun, and because math is only hard until you look at it:

sin(x) = x - x^3 / 3! + x^5 / 5! - x^7 / 7! + ... (you can stop here, it is precise enough for the job)
cos(x) = 1 - x^2 / 2! + x^4 / 4! - x^6 / 6! + ... (same as above)

 

Edited May 12, 2016 by ShotgunNinja

[AlphaAsh]

4 minutes ago, ShotgunNinja said:

@Sigma88 You could approximate sin and cos using a Taylor serie.

Math hurts my brain.

It's not 100%, but most statics are grouped by Group. As for the center, KK does actually calculate a 'center' of a group for the purposes of determining whether a group should be cached/visible or not, to deal with the krakensbane (only statics in visible range are 'active').

However (there's always a however) I was lazy in the coding and use the first static of a group to determine the center, because hey, they're close enough, right?

Take a look in the KK project on GitHub and perhaps a good way to go is start pushing some code at it.

Edited May 12, 2016 by AlphaAsh

[Enceos]

If it's gonna be possible to calculate the relative positions of other statics to the position of the first static in the group, then it's gonna be possible to scale those values. It is simple substract/multiply math.

Edited May 12, 2016 by Enceos

[AlphaAsh]

2 minutes ago, Enceos said:

If it's gonna be possible to calculate the relative positions of other statics to the position of the first static in the group, then it's gonna be possible to scale those values.

True. Still, one other caveat. Not all statics origin's are necessarily 0,0,0. That's going to mess up the math when you have adjacent statics and no way of determining their dimensions.

You can see why I don't pursue the code side of this. Not trying to discourage but it's a mammoth coding challenge.

[Enceos]

2 minutes ago, AlphaAsh said:

True. Still, one other caveat. Not all statics origin's are necessarily 0,0,0. That's going to mess up the math when you have adjacent statics and no way of determining their dimensions.

You can see why I don't pursue the code side of this. Not trying to discourage but it's a mammoth coding challenge.

Would you define the 'origin' please?

[AlphaAsh]

Just now, Enceos said:

Would you define the 'origin' please?

Center of the model as set in Unity. So if you have code referencing that directly and then try to move an object by that point...

A position is a single point, remember. It has nothing to do with the space being filled.

Hope that made some sense.

[Enceos]

23 minutes ago, AlphaAsh said:

Center of the model as set in Unity. So if you have code referencing that directly and then try to move an object by that point...

A position is a single point, remember. It has nothing to do with the space being filled.

Hope that made some sense.

Yeah, but do we need an object origin? The origin in my calculation is the RadialPosition of the root static with three coordinates x,y,z. Then we calculate the relative positions of the other statics to the origin, each will have coordinates ΔX, ΔY, ΔZ (basically: ΔX = X origin - X static, etc). Then we multiply these values by n, which is the scaling multiple of the planet we get nΔX, nΔY, nΔZ, then we add these nΔ values to the coordinates of RadialPosition of the static. Resut: We get an original distance between the two statics as it was before scaling the planet. Assuming Z defines a horizontal position in PQSCities.

Edited May 12, 2016 by Enceos

[ShotgunNinja]

I wrote a function that rescale the points in a cluster. Feed this with a map of 'some_identifier'->point and will modify it in-place. Hope that help, cheers and good luck.

 

Spoiler

static class stuff
{
  static Vector3d to_polar(Vector3d euclidean)
  {
    double len = euclidean.magnitude;
    Vector3d tmp = euclidean / len;
    double xz_dist = Math.Sqrt(tmp.x * tmp.x + tmp.z * tmp.z);
    return new Vector3d
    (
      Math.Asin(tmp.y), // latitude
      Math.Atan2(tmp.x, tmp.z), // longitude
      xz_dist // xz distance
    );
  }
  
  static Vector3d to_euclidean(Vector3d polar)
  {
    double lat = polar.x;
    double lon = polar.y;
    return new Vector3d
    (
      Math.Cos(lat) * Math.Sin(lon),
      Math.Sin(lat),
      Math.Cos(lat) * Math.Cos(lon)
    );
  }  
  
  static void ScaleCluster<T>(ref Dictionary<T, Vector3d> cluster, double scale)
  {
    double avg_lat = 0.0;
    double avg_lon = 0.0;
    double avg_z = 0.0;
    
    // convert to polar coordinates, calculate average position
    foreach(var pair in cluster)
    {
      Vector3d p = pair.Value;
      p = to_polar(p);
      avg_lat += p.x;
      avg_lon += p.y;
      avg_z += p.z;
    }    
    
    // calculate center
    Vector3d center = new Vector3d(avg_lat, avg_lon, avg_z) / (double)cluster.Count;
    
    // rescale the points
    foreach(var pair in cluster)
    {
      Vector3d p = pair.Value;
      
      Vector3d q = p - center;
      q /= scale;
      p = q + center;
      p *= scale;     
      p = to_euclidean(p);
    }
    
    // that's it
  }
}

 

 

Edited May 12, 2016 by ShotgunNinja

[AlphaAsh]

52 minutes ago, Enceos said:

Yeah, but do we need an object origin? The origin in my calculation is the RadialPosition of the root static with three coordinates x,y,z. Then we calculate the relative positions of the other statics to the origin, each will have coordinates ΔX, ΔY, ΔZ (basically: ΔX = X origin - X static, etc). Then we multiply these values by n, which is the scaling multiple of the planet we get nΔX, nΔY, nΔZ, then we add these nΔ values to the coordinates of RadialPosition of the static. Resut: We get an original distance between the two statics as it was before scaling the planet. Assuming Z defines a horizontal position in PQSCities.

\o/ I don't doubt you. Math is not my thing.

27 minutes ago, ShotgunNinja said:

I wrote a function that rescale the points in a cluster. Feed this with a map of 'some_identifier'->point and will modify it in-place. Hope that help, cheers and good luck.

 

  Reveal hidden contents

static class stuff
{
  static Vector3d to_polar(Vector3d euclidean)
  {
    double len = euclidean.magnitude;
    Vector3d tmp = euclidean / len;
    double xz_dist = Math.Sqrt(tmp.x * tmp.x + tmp.z * tmp.z);
    return new Vector3d
    (
      Math.Asin(tmp.y), // latitude
      Math.Atan2(tmp.x, tmp.z), // longitude
      xz_dist // xz distance
    );
  }
  
  static Vector3d to_euclidean(Vector3d polar)
  {
    double lat = polar.x;
    double lon = polar.y;
    return new Vector3d
    (
      Math.Cos(lat) * Math.Sin(lon),
      Math.Sin(lat),
      Math.Cos(lat) * Math.Cos(lon)
    );
  }  
  
  static void ScaleCluster<T>(ref Dictionary<T, Vector3d> cluster, double scale)
  {
    double avg_lat = 0.0;
    double avg_lon = 0.0;
    double avg_z = 0.0;
    
    // convert to polar coordinates, calculate average position
    foreach(var pair in cluster)
    {
      Vector3d p = pair.Value;
      p = to_polar(p);
      avg_lat += p.x;
      avg_lon += p.y;
      avg_z += p.z;
    }    
    
    // calculate center
    Vector3d center = new Vector3d(avg_lat, avg_lon, avg_z) / (double)cluster.Count;
    
    // rescale the points
    foreach(var pair in cluster)
    {
      Vector3d p = pair.Value;
      
      Vector3d q = p - center;
      q /= scale;
      p = q + center;
      p *= scale;     
      p = to_euclidean(p);
    }
    
    // that's it
  }
}

 

 

Useful if I were inclined to actually plug it in to KK. I said it was on GitHub. If you want the feature, then there's more work than that and GitHub is thataway.

[ShotgunNinja]

@AlphaAsh Hey its okay. I don't actually want the feature, in fact I don't ever use this mod, nor I have ever seen it. I was just trying to help somebody that was wondering how to do it.

[Sigma88]

34 minutes ago, ShotgunNinja said:

@AlphaAsh Hey its okay. I don't actually want the feature, in fact I don't ever use this mod, nor I have ever seen it. I was just trying to help somebody that was wondering how to do it.

That looks like  very useful function.

As soon as I move SD to dll I'll definitely be interested in adding something like that

[Sigma88]

ok, I think I've figured out a way to get a rough approximation of how to change the positions.

I have yet to test it, so I cannot be 100% sure, but I feel pretty confident it will work

it will require an addition to the KK configs tho, so I'll have to see if @AlphaAsh is open to that

[Enceos]

30 minutes ago, Sigma88 said:

ok, I think I've figured out a way to get a rough approximation of how to change the positions.

I have yet to test it, so I cannot be 100% sure, but I feel pretty confident it will work

it will require an addition to the KK configs tho, so I'll have to see if @AlphaAsh is open to that

As long as you post a commit on github, he'll consider that :3

[AlphaAsh]

1 minute ago, Enceos said:

As long as you post a commit on github, he'll consider that :3

He makes a good case in his PM for a simple solution that requires little work. Of course, pushing code will get things done quicker than waiting for me to get to it. The latest Kerbin-Side pack won't make itself and Stellaris won't play itself

[Enceos]

1 minute ago, AlphaAsh said:

He makes a good case in his PM for a simple solution that requires little work. Of course, pushing code will get things done quicker than waiting for me to get to it. The latest Kerbin-Side pack won't make itself and Stellaris won't play itself

Haha, Stellaris ftw! )

[AlphaAsh]

@Sigma88 I should tell you that there have been a number of abandonments of this very thing in the past and that there is another similar attempt being made. Unless it's been abandoned too.

Might be worth comparing notes.

Edited May 12, 2016 by AlphaAsh

[Kerbal Dynamics]

20 hours ago, AlphaAsh said:

I'll have a look at Green Coast. What other mods do you use?

Because some are already/always open. If the light's green, click the base in the launchsite selector, then click set as launchsite in the base manager.

I use only BDA. I don't think that it affects the static objects here at all though

[AlphaAsh]

1 hour ago, Kerban Aircraft Industries said:

I use only BDA. I don't think that it affects the static objects here at all though

Ah ha! Cracked it. I suspect you don't have Kerbin-Side Complete, possibly just Skyways? You're missing a tower.

I'll get it sorted for the next versions.

[xx_mortekai_xx]

Holy excrements!  I came hoping to get some help with the math, and I check back to find that the entire issue has almost been sorted.

 

The only word I can use to describe this is "amazing".

 

Hopefully, you all hear this too often (i suspect not), but I appreciate what you all do, and that you spend your own time helping make the experience of others more enjoyable.

[Sigma88]

Just now, xx_mortekai_xx said:

Holy excrements!  I came hoping to get some help with the math, and I check back to find that the entire issue has almost been sorted.

 

The only word I can use to describe this is "amazing".

 

Hopefully, you all hear this too often (i suspect not), but I appreciate what you all do, and that you spend your own time helping make the experience of others more enjoyable.

I wouldn't celebrate just yet

[xx_mortekai_xx]

44 minutes ago, Sigma88 said:

I wouldn't celebrate just yet

Not celebrating a completion, just amazed at the speed by which the problem has been tackled and a possible solution produced.

 

Regardless, I still appreciate it immensely.  I have gone back and forth between configurations (swapping 64K for Kerbin Side and vice versa) probably 15 different times in the last week, simply because I cannot choose between the two.

Edited May 13, 2016 by xx_mortekai_xx

[Sigma88]

ok, so after a decent amount of testing I think I can make a list of issues that one will need to face when rescaling a planet in the presence of KK

I'm posting here since this discussion was started here, @AlphaAsh since it's a KK thing let me know if you rather bring that to the KK thread (or SD thread, I don't want to clutter your thread if you feel this is off topic)

let me start with a disclaimer: some of the issues I will list here can be solved only by changing KK. I am in no way saying that you should add this changes. I am just putting my thoughts out here in case you are interested.

I will divide the issues in 2 groups, issues with altitude and issues with RadialPosition.

Issues with altitude:

Spoiler

Altitude in KK is defined as the "distance from sea level" (where sea level is 1 planet radius from the center)

the issue is that the information included in the altitude value stored in the Statics contains 2 informations,

1. The distance between ground level and sea level
2. The additional offset required to make the building touch the ground

this happens because static models are moved using some kind of "barycenter" or "origin point", and when this point is not at the bottom of the model, you need to include this offset into the "altitude"

example:

In this example, the blue line is the altitude saved into the KK configs, the green line is the altitude of the terrain at that point, and the red line is the distance between the barycenter of the static and its bottom.

when rescaling kerbin 10x we need to multiply the green line by 10

the red line will need to reman the same size, and the blue line will need to be newB = newG + oldR = 10*oldG + oldR

(in this example the red line has a negative value, while both green and blue have a positive value)

this problem can be solved by specifying in the KK config either the green line or the red and blue lines.

 

Issues with RadialPosition:

Spoiler

Issues with radial position are multiple.

Let's start from the assumption we can change the position correctly.

If we choose not to change the radial position we have the issue that all the statics will be spread around, which doesn't look very pretty, but at least they are all at the correct altitude.

If we choose to change the radial position we run into some altitude issues. if the base in built on an uneven terrain, moving statics closer together might move them to a region with different altitude, hence bringing them inside the terrain (or hovering above it)

 

this issue can be solved only by manual editing each static, or by making sure each base is built on a flat terrain (and by flat I mean "always at the same distance from the center of the planet")

 

this doesn't even take into account the issues of moving the parts themselves, I have an idea on how to do that with only cfgs, but if that won't be possible I could always use a dll like it was suggested earlier by @ShotgunNinja

I'm currently looking for a base that is built on a flat terrain and that has all the red lines equal to zero, so that I can test if my RadialPosition math is correct. If you know of such a base, please ping me so that I can give it a try  

 

[AlphaAsh]

Good show. I thought the model origin had an impact on this.

I'm currently working on getting a group's middle radial pos output to instances in a cfg, so you'll have that soon.

These other issues you highlight are going to need some coding that I'm not up for right now. No offence intended but this isn't a feature I personally want or would use and I tend to burn my energies on those I do first. I also tend to prioritise features for the mainstream audience of the mod, after that, or rather whatever features tend to coincide.

Which does mean it goes on the bottom of my list of 'when I fancy mucking about with complicated code or get bribed to do it'.

Or someone else more invested dives in with some coding. That's why KK is open-source, afterall.

Edited May 13, 2016 by AlphaAsh

[Sigma88]

3 minutes ago, AlphaAsh said:

These other issues you highlight are going to need some coding that I'm not up for right now. No offence intended but this isn't a feature I personally want or would use and I tend to burn my energies on those I do first. I also tend to prioritise features for the mainstream audience of the mod, after that, or rather whatever features tend to coincide.

I don't think you could solve the RadialPosition issues in KK anyways

the issue is intrinsic with the concept of resizing the planet, for example, if you put a hangar inside a hill, with its front sticking out, when you rescale the planet 10x the hill will be 10x times bigger, and will inevitably bury your hangar.

and if you resize 0.1x the hill will be so tiny that the hangar itself will cover the hill

 

this will happen even assuming a 100% accurate reposition of the hangar itself

now that I think about it, if I can change the scale of the static's model, that should fix this issue. but I'm not sure that this is what a player who's playing a resized kerbin would want.

 

as I said, the solutions would require either

put all bases on a flat surface (this is up to who makes the base, and I wouldn't blame anyone for choosing not to. since it'll make it less interesting)

manual editing the bases, and here's where people like @Paul Kingtiger come into play. SigmaDimensions has the obvious limitation that it cannot reposition statics because it's built to work on whatever resize the player might want, and I built it this way on purpose to help people that make resize mods. Since those mods (64k, Kscale2, SRSS...) have chosen a specific scale, it's possible for those mods to include a patch that would fix the bases for that specific setup