[1.8.x-1.12.x]R-T-B's Kopernicus Unified "Bleeding Edge" Branch[REACTIVATED]

[OrbitalManeuvers]

For me with build 35, 1.9 version, Beyond Home, Armstrong shows the texture problem on both High and Ultra settings. Reloading through space center/tracking station does not help, on either setting. In fact, I'd say it's even worse after the reload.

That said, when Armstrong is lookin really borked, if I cheat directly to a low Rock orbit, it's perfect. And by really borked, I mean:

Spoiler

On a bad day you can even get dotted lines ...

 

 

[R-T-B]

18 minutes ago, OrbitalManeuvers said:

For me with build 35, 1.9 version, Beyond Home, Armstrong shows the texture problem on both High and Ultra settings. Reloading through space center/tracking station does not help, on either setting. In fact, I'd say it's even worse after the reload.

That said, when Armstrong is lookin really borked, if I cheat directly to a low Rock orbit, it's perfect. And by really borked, I mean:

  Hide contents

On a bad day you can even get dotted lines ...

 

 

Weird.  I may be barking up the wrong tree entirely with assuming it has anything to do with atlas.  I will look into this again very soon.

[R-T-B]

So, at present it appears any bodies not using at least the 1.8 shader exhibit problems with the tiling / farm patch bug.

I discourage use of the following templates until this is formerly fixed:

Val, Tylo, Bop, Pol, and Eeloo.

I'm working on this but obviously it's not easy, or I'd already be done.

Edited October 1, 2020 by R-T-B

[R-T-B]

Update to the above:  The templates are not broken, pack authors are just using them wrong!  I have found a fix and it involves a simple config change.  I will be advising relevant pack authors soon.  In the meantime, here's a "quick fix" for JNSQ for 1.9.1 and 1.10.1, respectively:

http://glacialsoftware.net/JNSQ_FIX/

Credit to team Galileo for their hard work, these are simple config fixes.  Grab the 1.9.1 or 1.10.1 version depending on your KSP, and Extract to your GameData and replace any files.  Simple.

Technical details, which I will be spreading around:

This is not a Kopernicus bug so much as an improper use of configs.  Most configs (JNSQ included) are using AtmosphericTriplanarZoomRotation as their PQS material.  This DOES NOT WORK on the following bodies as they don't implement that shader:  Laythe (1.9.1 only), Tylo, Bop, Pol, Eeloo.  You must use AtmosphericBasic/AtmosphericOptimized or Vacuum on these bodies or you will get the tile bug!  It's that simple!

@OrbitalManeuvers

Edited October 1, 2020 by R-T-B

[OrbitalManeuvers]

@R-T-B hey guess what?

Spoiler

You found it! I looked at the change in the configs, applied the same change to Armstrong in BH, and B I N G O. 

HOLY FRICKIN BINGO

 

[R-T-B]

34 minutes ago, OrbitalManeuvers said:

@R-T-B hey guess what?

  Hide contents

You found it! I looked at the change in the configs, applied the same change to Armstrong in BH, and B I N G O. 

HOLY FRICKIN BINGO

 

Lol your spoiler had me apprehensive.  I thought for sure it couldn't be good.

Yep, it's just a simple material change.  Moons of Jool + Eeloo cannot use AtmosphericTriplanarZoomRotation (the 1.8 shader) as their material.  Many packs have made this mistake, I have sent out notifications to those I can.  This probably will cease to be an issue when they get the 1.8+ shader in say, 1.11, but for now this is the fix.

Edited October 1, 2020 by R-T-B

[Poodmund]

Why are they getting that material shader applied to them?

Those stock bodies do not use that shader.

[R-T-B]

7 hours ago, Poodmund said:

Why are they getting that material shader applied to them?

Those stock bodies do not use that shader.

Beats me.  JNSQ apply it manually in their config and several others just followed suit, I guess?

If it hadn't been applied manually by several packs, it would've worked.  It's the pack authors fault.  Which is why I struggled to fix it so much.

Edited October 1, 2020 by R-T-B

[Poodmund]

So if I have Vanilla KSP and install Kopernicus BE, Jool's moons do not use that shader, correct? Kopernicus is not overriding stock behaviour. Specification/usage of that shader is fine on any PQS-based body, it just has to be utilised properly.

The plageurism (a bit strong but basically what it is) of configs has always been a big issue with Kopernicus based mods and issues get very widespread without any understanding.

[R-T-B]

1 hour ago, Poodmund said:

So if I have Vanilla KSP and install Kopernicus BE, Jool's moons do not use that shader, correct?

Correct.

1 hour ago, Poodmund said:

The plageurism (a bit strong but basically what it is) of configs has always been a big issue with Kopernicus based mods and issues get very widespread without any understanding.

I mean, I'm personally of the opinion configs are ok to borrow and modify ethically speaking as they are really just value pairs (unless explicitly forbidden, ofc).  The textures and such is more where I'd be bothered.  That being said, copying without understanding is the real issue, and it's going to happen, unfortunately.  Best approach to it is education.

[OrbitalManeuvers]

2 hours ago, Poodmund said:

The plageurism (a bit strong but basically what it is) of configs has always been a big issue with Kopernicus based mods and issues get very widespread without any understanding.

I think you'd be 100% justified to view it as imitation and therefore flattery. Some of the mods you've worked on (that I know of) are very established and highly creative, so people are going to look to your work for some of the very hard parts, and some of the very easy parts. 

[Hohmannson]

16 hours ago, OrbitalManeuvers said:

@R-T-B hey guess what?

  Reveal hidden contents

You found it! I looked at the change in the configs, applied the same change to Armstrong in BH, and B I N G O. 

HOLY FRICKIN BINGO

 

So you just change the "materialType" and everything is fine?

[OrbitalManeuvers]

2 minutes ago, Hohmannson said:

So you just change the "materialType" and everything is fine?

What I did on my machine was change Armstrong's materialType to Vaccum in the PQS section, and yes it fixed the patchwork textures.

[R-T-B]

8 minutes ago, Hohmannson said:

So you just change the "materialType" and everything is fine?

Pretty much.  Just make sure you are using one of the more basic material types and not AtmosphericTriplanarZoomRotation (the 1.8+ shader).

Alternatively, if you must use that shader, use a inner system body.

Edited October 1, 2020 by R-T-B

[Poodmund]

4 hours ago, R-T-B said:

I mean, I'm personally of the opinion configs are ok to borrow and modify ethically speaking as they are really just value pairs (unless explicitly forbidden, ofc).  The textures and such is more where I'd be bothered.  That being said, copying without understanding is the real issue, and it's going to happen, unfortunately.  Best approach to it is education.

4 hours ago, OrbitalManeuvers said:

I think you'd be 100% justified to view it as imitation and therefore flattery. Some of the mods you've worked on (that I know of) are very established and highly creative, so people are going to look to your work for some of the very hard parts, and some of the very easy parts. 

I wasn't saying that the act of copying the configs from an ethics standpoint is the issue... I was saying that the copying of configs with preexisting issues that then propagate down through to commonly copied configs/templates are the issue.

[R-T-B]

17 minutes ago, Poodmund said:

I wasn't saying that the act of copying the configs from an ethics standpoint is the issue... I was saying that the copying of configs with preexisting issues that then propagate down through to commonly copied configs/templates are the issue.

and I'm agreeing, I suppose.

By the way, new release.  This release adds the same functionality as "MyRocksAreBiggerThanYours" making that plugin obsolete (@Thomas P.'s contribution)  Full release notes follows:

Kopernicus R-T-B Unified "Bleeding Edge" Edition Release 36

R-T-B released this 3 hours ago

This is R-T-B's "Bleeding Edge" branch of Kopernicus, intended to support the latest features, KSP editions, and also the latest bugs. Please keep in mind this branch may be more buggy than Prestja's mainline Kopernicus branch, but it also supports more KSP versions and has more features implemented for testing reasons. Many features that make it into mainline Kopernicus are born, tested, and trialed by fire here.

This is release 36. It contains the following changes:

1.) We now support "Breaking Ground" anomalies out of the box, eliminating the need for "MyRocksAreBiggerThanYours."

2.) Material names have been simplified. You can still use the old ones, but there are simpler alternatives now. You can see Pull Request #28 for details, or simply wait for the wiki to update. Remember, the old names still work and we have no plans to change that, this is just for usability.

Known Bugs:

1.) The "enableComets" parameter is deprecated now and does not function. Set "cometPercentage" to 0 to get the same effect.

2.) Fogramp maybe doesn't work right, it's been very buggy in reports lately.

Please download the right output zip for your version. "191" zips are for 1.9.1, "1101" for 1.10.1, etc.

Thanks and as always, report bugs!

-RTB

Edited October 1, 2020 by R-T-B

[R-T-B]

Kopernicus R-T-B Unified "Bleeding Edge" Edition Release 37

R-T-B released this 1 minute ago

This is R-T-B's "Bleeding Edge" branch of Kopernicus, intended to support the latest features, KSP editions, and also the latest bugs. Please keep in mind this branch may be more buggy than Prestja's mainline Kopernicus branch, but it also supports more KSP versions and has more features implemented for testing reasons. Many features that make it into mainline Kopernicus are born, tested, and trialed by fire here.

This is release 37. It contains the following changes:

1.) This adds an experimental performance optimization to land scatters. In some extreme scatter-laden scenarios, double digit FPS improvements have been realized.  Please compare performance to the old builds with scatters enabled and report back! Also, do note any strange behavior with land scatters in particular as that may be caused by this update!  If it's bad we can revert!

Known Bugs:

1.) None known as of now, however that does not mean there is none! Report if you find any!

Please download the right output zip for your version. "191" zips are for 1.9.1, "1101" for 1.10.1, etc.

Thanks and as always, report bugs!

-RTB

Edited October 5, 2020 by R-T-B

[Gordon Dry]

@R-T-B darn - actually I got tanked fps (again) and have no clue where it comes from. No exception spamming or such.

So it could™ be the rls 37.

As I got lower fps in flight scene, SPC and in the Tracking Station (I'm used to 60 fps @VSync in SPC and Tracking Station) the issue must be a mod that affects all those scenes.

Last session yesterday, before I updated Kopernicus, I got a much better performance.

But I'm not 100% sure that Kopernicus is to blame because I also updated "Docking Port Alignment Indicator" and a test/debug .dll from "DockRotate" (no spam coming from that side and I was not docking or undocking this session).

I will boot up KSP again without the two "docking mods" and see how the performance will be.

Edit:

btw I got only scatterer (mainly because of the shadow flickering fix it provides) but no EVA (and no config for it).

@R-T-B I cannot blame Kopernicus - I tested over several boot ups with mods in and out and the fps did not change much.

I don't want to believe that having two vessels more in orbit plus a handful of debris tanks the fps - compared to yesterday.

Could be any mod and I just triggered it yesterday.

(I guess I loose the hope again and the next hiatus is in sight.)

Edited October 5, 2020 by Gordon Dry

[R-T-B]

3 hours ago, Gordon Dry said:

@R-T-B darn - actually I got tanked fps (again) and have no clue where it comes from. No exception spamming or such.

So it could™ be the rls 37.

As I got lower fps in flight scene, SPC and in the Tracking Station (I'm used to 60 fps @VSync in SPC and Tracking Station) the issue must be a mod that affects all those scenes.

Last session yesterday, before I updated Kopernicus, I got a much better performance.

But I'm not 100% sure that Kopernicus is to blame because I also updated "Docking Port Alignment Indicator" and a test/debug .dll from "DockRotate" (no spam coming from that side and I was not docking or undocking this session).

I will boot up KSP again without the two "docking mods" and see how the performance will be.

Edit:

btw I got only scatterer (mainly because of the shadow flickering fix it provides) but no EVA (and no config for it).

@R-T-B I cannot blame Kopernicus - I tested over several boot ups with mods in and out and the fps did not change much.

I don't want to believe that having two vessels more in orbit plus a handful of debris tanks the fps - compared to yesterday.

Could be any mod and I just triggered it yesterday.

(I guess I loose the hope again and the next hiatus is in sight.)

It's possible the optimization I just did hurts standard situations, as I only tested against synthetic examples with insane numbers of scatters.  Can you revert one version and confirm that?  If so, I will try a different approach to measuring and improving scatter performance.  I have several other ideas.

Edited October 5, 2020 by R-T-B

[Gordon Dry]

@R-T-B no matter how many mods I have or remove - what helps a lot in Map View and Tracking station is toggling off the orbits with that mod "TooManyOrbits".

And I only got 4 probes, 1 "station" (Agena target vehicle) and 6 relays total (Kerbin and Mun).
The 20x debris are hidden.

It seems that the vessels are not the issue, the rendering of the orbital lines seems to be the culprit.
At least in map and TS.

I still don't know what tanks the fps in flight mode.

Edited October 5, 2020 by Gordon Dry

[R-T-B]

@Gordon Dry, try this build with a more conservative optimization for land scatters, should be on CKAN-Bleeding edge as well:

Kopernicus R-T-B Unified "Bleeding Edge" Edition Release 38

R-T-B released this 7 minutes ago

This is R-T-B's "Bleeding Edge" branch of Kopernicus, intended to support the latest features, KSP editions, and also the latest bugs. Please keep in mind this branch may be more buggy than Prestja's mainline Kopernicus branch, but it also supports more KSP versions and has more features implemented for testing reasons. Many features that make it into mainline Kopernicus are born, tested, and trialed by fire here.

This is release 38. It contains the following changes:

1.) The previous performance optimizations only worked well in synthetic testing, and actually hurt FPS in many situations. More conservative ones have been applied that should work better globally.

2.) Corrections to the syntax of SolarPanels.cfg have been made, enabling better compatibility.

Known Bugs:

1.) None known as of now, however that does not mean there is none! Report if you find any!

Please download the right output zip for your version. "191" zips are for 1.9.1, "1101" for 1.10.1, etc.

Thanks and as always, report bugs!

-RTB

Edited October 5, 2020 by R-T-B

[StoneWolfPC]

Ok, after the last 2 updates you've made I've had a sudden issue with asteroids.  I was getting the normal amount of asteroids in the kerbin system, maybe slightly less?  Now, they're showing up............ but get this................... NOT in the kerbin system.  They're ONLY showing up in the Galaxies Unbound systems that were added!  Around each star to be precise!  Awesome, but......... now I can't complete 2 of my missions because they require me finding a class C and dragging it to dres, and an e to laythe.  lmao.  If I can't complete them I'm not worried, it's too much fun seeing that they suddenly show up in so many places when they were only showing up in Kerbin just prior to the last 2 performance enhanced updates.  lmao.  You did something right I think, while something else said f off.   I don't envy anyone who has that problem.  It's exactly why I could never get into coding anything!  Though QBasic was far less finiky back in the day it seems.  I got pretty good at that at one time.

[R-T-B]

1 hour ago, StoneWolfPC said:

Ok, after the last 2 updates you've made I've had a sudden issue with asteroids.  I was getting the normal amount of asteroids in the kerbin system, maybe slightly less?  Now, they're showing up............ but get this................... NOT in the kerbin system.  They're ONLY showing up in the Galaxies Unbound systems that were added!  Around each star to be precise!  Awesome, but......... now I can't complete 2 of my missions because they require me finding a class C and dragging it to dres, and an e to laythe.  lmao.  If I can't complete them I'm not worried, it's too much fun seeing that they suddenly show up in so many places when they were only showing up in Kerbin just prior to the last 2 performance enhanced updates.  lmao.  You did something right I think, while something else said f off.   I don't envy anyone who has that problem.  It's exactly why I could never get into coding anything!  Though QBasic was far less finiky back in the day it seems.  I got pretty good at that at one time.

Yeah, we switched to asteroid defined nodes, so Galaxies Unbound must be set up that way in it's config.  Before, it was only spawning around Kerbin/the homeworkd, which while convenient, was not technically correct behavior.  This would be up to the pack author to fix now.

[R-T-B]

Kopernicus R-T-B Unified "Bleeding Edge" Edition Release 39

R-T-B released this 7 minutes ago

This is R-T-B's "Bleeding Edge" branch of Kopernicus, intended to support the latest features, KSP editions, and also the latest bugs. Please keep in mind this branch may be more buggy than Prestja's mainline Kopernicus branch, but it also supports more KSP versions and has more features implemented for testing reasons. Many features that make it into mainline Kopernicus are born, tested, and trialed by fire here.

This is release 39. It contains the following changes:

1.) Contributions to SolarPanels.cfg from forum user hemeac to help avoid errors in third party packs.

Known Bugs:

1.) None known as of now, however that does not mean there is none! Report if you find any!

Please download the right output zip for your version. "191" zips are for 1.9.1, "1101" for 1.10.1, etc.

Thanks and as always, report bugs!

-RTB

[R-T-B]

Can people who are willing to test for me try a quick bench of the following?
Take bleeding edge latest release, and JNSQ.  Run with land scatters enabled scatters 100%.  You WILL lag.  See how bad (in FPS).  report.  Then compare with this old optimization release, Release 37 of the bleeding edge.

If you get a good result (net gain in FPS to Release 37), please compare then more standard packs with Release 37 vs the modern Bleeding Edge.  I'm trying to gauge whether or not reverting the optimizations in Release 37 was the correct thing to do.

Edited October 8, 2020 by R-T-B