Jump to content

[Early development, 0.24] Kopernicus Planetary System Modifier

BryceSchroeder

By BryceSchroeder
in KSP1 Mod Development

 Share

Recommended Posts

biohazard15

biohazard15

Posted
Posted

Looking forward to this too. When Kopernicus will be released, we can finally bury PlanetFactory - it was a great mod for its time, but Krag didn't bother to fix all the bugs in the career mode.

One question, though: if compared to PF, how much memory Kopernicus need? PF was maybe the most memory-hungry mod out there.

Link to comment
Share on other sites
BryceSchroeder

BryceSchroeder

Posted
  • Author
Posted
Looking forward to this too. When Kopernicus will be released, we can finally bury PlanetFactory - it was a great mod for its time, but Krag didn't bother to fix all the bugs in the career mode.

One question, though: if compared to PF, how much memory Kopernicus need? PF was maybe the most memory-hungry mod out there.

Probably less, but memory usage will depend on what you do with Kopernicus.

PlanetFactory came with a substantial number of new planets, which I suspect is what caused its memory usage to be so high. Kopernicus is more a "mod that lets people add planets or replace the stock system entirely" than a "mod that adds planets." It'll probably come with various examples, but its memory usage will depend heavily on what set of planets you're using with it.

I haven't yet experimented with how various memory-saving plugins interact with Kopernicus. I would not anticipate any compatibility problems, though - when you create the planets by replacing the systemPrefab, as we've done, most ancillary things seem to just work.

Link to comment
Share on other sites
Teknoman117

Teknoman117

Posted
Posted (edited)

As far as memory saving plugins go (such as Active Texture Management), if we can't make Kopernicus directly compatible, we will provide texture compression settings for the mod. I believe (correct me if I am wrong), ActiveTextureManagement walks through the general textures paths (respecting the PluginData/ directory's non loading characteristic) and compresses all the textures which don't have some setting within ATM set otherwise.

Certain textures shouldn't be loaded into the standard game memory for Kopernicus due to the way PQS works. From experimentation, the only texture we can say certainly shouldn't be imported is the planet's height map. The life is very short, as it gets loaded to build an object called a MapSO (essentially is a texture wrapper which copies the data internally). After this object is constructed and passed to the PQS, the texture is no longer needed for the rest of the game. We can't compress height maps, but as they are only 1 channel, they aren't too big.

The color and detail textures can be compressed at the cost of some visual quality, but DXT still yields good results visually (http://blogs.msdn.com/blogfiles/shawnhar/WindowsLiveWriter/Texturecompression_DF7A/cat1.png - figure out which one is the compressed one). Aggressive compression can yield compression ratios as good as 6:1, so those big 8k by 4k textures from real solar system can get as small as ~16 MiB (versus the initial 96 MiB uncompressed). But as Bryce said previously and in our mission statement, neither of us are graphics artists and probably won't have much more than usage examples included with the plugin. Our test planet is Mars, because it's the only one of the planets with very detailed surface maps, and the features are very interesting (Valles Marineris and Olympus Mons for one) (I found some nice DEMs of surface features - http://www.uahirise.org/dtm/). It's up to the community to build planetary packs with this plugin. NathanKell is interested in using Kopernicus for RSS.

Again, as Bryce mentioned, the memory impact will be as small or as large as you want it to be. We will do everything we can to provide the tools to consume as little data as necessary.

Edited by Teknoman117
Link to comment
Share on other sites
_Augustus_

_Augustus_

Posted
Posted
I'm curious how hard would it be to port over a PF CE system over to kopernicus.

Yes. I really think Kopernicus and StarSystems should kind of merge, as Oven should keep working on improving the stars for now. And SOMEONE needs to release their planet maker soon!

Link to comment
Share on other sites
Dooz

Dooz

Posted
Posted
Yes. I really think Kopernicus and StarSystems should kind of merge, as Oven should keep working on improving the stars for now. And SOMEONE needs to release their planet maker soon!

How is this related to my quote?

Personally they should stay 2 mods.

Link to comment
Share on other sites
braininator

braininator

Posted
Posted

While I somewhat agree with augustus, having two separate parties develop two mods that are very similar(and since oven is working on planets as well) does seem... redundant... merging them may not be trivial.

side note: I can't really program... only one ap course, so I am not the best "expert opinion".

Link to comment
Share on other sites
_Augustus_

_Augustus_

Posted
Posted
While I somewhat agree with augustus, having two separate parties develop two mods that are very similar(and since oven is working on planets as well) does seem... redundant... merging them may not be trivial.

side note: I can't really program... only one ap course, so I am not the best "expert opinion".

I agree. It is redundant.

Link to comment
Share on other sites
BryceSchroeder

BryceSchroeder

Posted
  • Author
Posted
Hi guys, I see you are making some great progress :D might you guys be up for a chat some time? Seeing as you are working way faster than I am alone, I might have to reconsider the direction I'm taking my mod StarSystems to.

Can you email / gchat me? My address is [email protected]

Teknoman, NathanKell and I have been discussing the project via gchat.

Thanks!

Link to comment
Share on other sites
BryceSchroeder

BryceSchroeder

Posted
  • Author
Posted
How much ram willl this take? similar to planet factory?

As elaborated on here by Teknoman and me, that will depend on what set of planets you use with it. But if you only use it to add, say, one small planet, it will use much less RAM.

Progress update: Teknoman says he will be working on atmospheres today, and I am making a preliminary investigation of oceans.

If I finish first, I guess we're going to say that the oceans are made of vacuum pump lubricating oil :D

Link to comment
Share on other sites
BryceSchroeder

BryceSchroeder

Posted
  • Author
Posted
I'm curious how hard would it be to port over a PF CE system over to kopernicus.

I'm not sure. I think we'll have a better idea once the configuration system is solidly underway. Some features to support the PF CE paradigm of planet creation (clone and modify) are planned, although the planets produced will still be introduced into the game through systemPrefab injection as with other Kopernicus bodies.

Link to comment
Share on other sites
BryceSchroeder

BryceSchroeder

Posted
  • Author
Posted
Yes. I really think Kopernicus and StarSystems should kind of merge, as Oven should keep working on improving the stars for now. And SOMEONE needs to release their planet maker soon!

I think we'll probably be able to release a testing version next week, possibly for a sort of public beta. In the meantime, if you're super curious, anyone can visit the project's github page and compile it yourself. It's not too hard. (Email me at [email protected] if you can't find some of the image files it needs - Kopernicus currently depends, for testing purposes, on some image files from RealSolarSystem.)

Link to comment
Share on other sites
rbray89

rbray89

Posted
Posted
As far as memory saving plugins go (such as Active Texture Management), if we can't make Kopernicus directly compatible, we will provide texture compression settings for the mod. I believe (correct me if I am wrong), ActiveTextureManagement walks through the general textures paths (respecting the PluginData/ directory's non loading characteristic) and compresses all the textures which don't have some setting within ATM set otherwise.

Certain textures shouldn't be loaded into the standard game memory for Kopernicus due to the way PQS works. From experimentation, the only texture we can say certainly shouldn't be imported is the planet's height map. The life is very short, as it gets loaded to build an object called a MapSO (essentially is a texture wrapper which copies the data internally). After this object is constructed and passed to the PQS, the texture is no longer needed for the rest of the game. We can't compress height maps, but as they are only 1 channel, they aren't too big.

The color and detail textures can be compressed at the cost of some visual quality, but DXT still yields good results visually (http://blogs.msdn.com/blogfiles/shawnhar/WindowsLiveWriter/Texturecompression_DF7A/cat1.png - figure out which one is the compressed one). Aggressive compression can yield compression ratios as good as 6:1, so those big 8k by 4k textures from real solar system can get as small as ~16 MiB (versus the initial 96 MiB uncompressed). But as Bryce said previously and in our mission statement, neither of us are graphics artists and probably won't have much more than usage examples included with the plugin. Our test planet is Mars, because it's the only one of the planets with very detailed surface maps, and the features are very interesting (Valles Marineris and Olympus Mons for one) (I found some nice DEMs of surface features - http://www.uahirise.org/dtm/). It's up to the community to build planetary packs with this plugin. NathanKell is interested in using Kopernicus for RSS.

Again, as Bryce mentioned, the memory impact will be as small or as large as you want it to be. We will do everything we can to provide the tools to consume as little data as necessary.

That's precisely how ATM works. The GameDatabase texture list is used to process the textures. If it doesn't show up there, it won't be touched.

Link to comment
Share on other sites
Teknoman117

Teknoman117

Posted
Posted
Woot! Orbit color changing FTW

Yeah, orbit renderer literally has a field called "orbitColor." Simple enough.

 [FONT=Menlo][COLOR=#444444]body[/COLOR][COLOR=#444444].[/COLOR][COLOR=#444444]orbitRenderer[/COLOR][COLOR=#444444].[/COLOR][COLOR=#444444]orbitColor[/COLOR][COLOR=#444444] = [/COLOR][COLOR=#3363a4]Color[/COLOR][COLOR=#444444].[/COLOR][COLOR=#444444]magenta[/COLOR][COLOR=#444444];[/COLOR][/FONT]

I'm not sure. I think we'll have a better idea once the configuration system is solidly underway. Some features to support the PF CE paradigm of planet creation (clone and modify) are planned, although the planets produced will still be introduced into the game through systemPrefab injection as with other Kopernicus bodies.

It will actually be fairly easy to port PF planets. Just look at the configuration files - it is just a list of added or modified PQS Mods. Not too much hidden magic is happening. We won't have direct support for PF configs (I *may* write a handy little conversion script), partly to respect Krag's wishes of non distribution of PF's assets. For anyone thinking about making a Sentar expansion "Kopernicus" edition, I have a feeling that would count as redistributing PF, even if the textures in question don't belong to Krag, the idea of that solar system does.

Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...