The White Guardian

kool

make it work for 1gb crappy GPUs pls xD

Pardon? It should work fine, it's not that resource intensive. Can you confirm that a clean install plus KS3P causes a severe frame drop?

I'll test today. Also can you give me the status on the visual pack? 

Tag me!

well im excited.

@Galileo nope, it's a fully standalone mod.

Ahhh even better...

Now this is the content I followed for.

even better!

i remember my first post (?) on evolution and im still looking forward to it! and still cringing to death because of that post)

cool

GG!

gj

kewl

That actually is genius.

I think I get it. Like a texture that you can use to offset the terrain?

That's already possible through VertexHeightMap though. Internally VHM does this:

'data.vertHeight += map.GetPixelFloat(data.u, data.v) * deformity + offset;'

In English: the altitude at this position (data.vertHeight) becomes equal to the altitude at this position (+=), plus the lightness of the height map at this location(map.GetPixelFloat(data.u, data.v)) times the deformity, plus the value of offset.

So, you could just add a secondary heightmap, make the oceans white, and invert the altitude to push the terrain down. This way you can even smooth the effect by blurring the ocean edges. Lastly you can use offset to raise or lower the terrain to make the coastline match perfectly.

@Gameslinx I could do that easily. In fact lemme write it out rq.

using System;
using UnityEngine;

public class PQSMod_FlattenMap : PQSMod
{
	public MapSO map;
	public double flattenTo;
	Color dark = new Color(0,0,0,1);
	
	double finalAltitude;

	public override void OnSetup()
	{
		finalAltitude = flattenTo + sphere.radius;
	}

	public override void OnVertexBuildHeight(PQS.VertexBuildData data)
	{
		if (map.GetPixelFloat(data.u, data.v) == dark)
		{
			data.vertHeight = finalAltitude;
		}
	}
}

Here is a rough, poorly optimized draft. Currently it will set the altitude of any black pixel on the map to the value of flattenTo (relative to sea level). Currently it checks the value of the map countless times however, which is probably not a good idea. I'll have to create a smart lerp method for this.

I should also probably make a thread for this...

I've made a thread to move this discussion to.

thanks @The White Guardian

oh.

now im very sad

@GenesisPlayz So am I, it should work just fine.

I'll just rewrite the code from scratch and see what happens.

Nevermind. I rewrote the code three times, every time the same result. Or a lack of a result to be more precise.

I even tried ruling out other causes:

- Maybe the directory for the dll was invalid?

- Maybe Kopernicus' OnDemand loader hates jpg?

- Maybe if I ignore OnDemandLoading?

Et cetera. I'm giving this thing one last shot - recompiling using Visual Studio 2015 rather than 2017. if that does it, then it's Microsoft's fault.

@The White Guardian dude no Kerbol Origins on the list?

@amarius1 Kerbol Origins doesn't count as 'my mod'. I left collaborations out of this.

Not to worry, I'm still working on Kerbol Origins.

@UranianBlue because I was under the impression that people enjoyed Arkas more than Cyran... besides that, Arkas is smaller, thus easier to update.

Ayy thank you man  glad to see we're not losing a team member. I should REEEEEALLY start doing the sketches for the new parts  

As for how MapArray works: it's exactly the same as VertexHeightMap, but swap out 'VertexHeightMap' for 'MapArray' in your config.

Next, swap out 'map' for 'array' and link to your MapArray texture.

Then, add another line of code reading 'channel = x', where x is either 0, 1 or 2. That depends on the color channel you want to take data from.

0 = Red, 1 = Green, 0 = Blue

Can we see a planet made with MapArray?

@UranianBlue It would be exactly the same. Only 3 heightmaps are stored in the same space as one. However I imagine with the wrong format (I'm looking at .DDS files) heightmaps can be 'contaminated' across all channels.

So for 3 planets you can use the MapArray to target 1 file and separate the heightmaps based on their colour values.

Gets hyped (?)

When will you post a link? I thought of doing one but got bored

@UranianBlue I'm not making tutorials on Space Engine because it's the cheap way out. If I'd teach people how to grab textures from a program in which all planets resemble each other, then the forums will be flooded with planets that look similar.

The difference in generation speed is because of the engine - Unity was not designed to export textures. I prefer the long waiting method of KSP though, SE easily floods the GPU so that it stops responding if asked to export textures of a resolution that is too great for it to swiftly handle. KittopiaTech exports the map pixel-by-pixel, meaning that the computer does not freeze while working. It's a longer but safer method, and the result is much more worth it.

Besides - if people wanted to see SE planets they'd open up Space Engine, they're completely different art styles, and merging them is not a good idea. I do get your thought pattern though, but there are better ways of making textures.

@The White Guardian You can fix the freezing easily.

https://www.reddit.com/r/spaceengine/comments/52gov2/is_there_a_way_to_export_high_quality_planet/

Also, there are so many objects in Space Engine and so many ways to randomize textures that the resemblance is negligible.

I would like to see some more in-depth tutorials on Landcontrol and positioning craters of different sizes at specified locations, not just randomized terrain based on a seed and then a HeightColorMap.

I agree with @The White Guardian, Texture style in SE look very similar to each other and I've played around with it long enough (I used SE to world-build a Solar System for my fictional alien race) that no matter how much you change it up, from afar and even up close sometimes, They all look almost similar to me. It wouldn't be fun to have many planet packs looking like they ripped off from each other. Don't do a No Man's Sky and go overboard. And knowing people, they would be too lazy to go into the coding and make their own textures anyway. Also, there usually is a problem with the height maps even when converted where the terrain won't look smooth but rather blocky when applied to a KSP Planet.

I like KittopiaTech because it allows full procedural generation of a KSP-like planet but if you do it well enough, you can end up having something unique from other planet packs. It gives an easier idea of what your getting, you can change image size and you can do easy in game editing without having to go into SE and doing copying and pasting from one game to another and having to load KSP up millions of times just to simply see what the texture would look like.

(Don't mind me, just tagging @Disparia Books real quick...)

...new features... hmm...?

Correct. Placing everything perfectly is going to be a challenge, but in the end, I think it'll be worth it.

Im looking forward to them!

Be careful though. Some popular mods don't work with 1.3, like Interstellar Ext. and BD Amory.

@UranianBlue thanks for the heads-up! No worries, I already have Cerillion working in 1.3 save for Scatterer, but that's only because I have to fix a 'Module Manager syntax'.

Perhaps there could be a community DLL pack, similarly to the CTTP project, where people can code and add their own DLLs for Kopernicus PQS mods?

It would be cool, assuming you can point Kopernicus to a DLL rather than replacing the whole thing

Damn this will certainly be useful for my future projects, friend!

Too bad I can't use it in Kerbol Origins as it is already mostly complete but it will certainly featured in my next pack. 

Good job! Looks very impressive.

Great job!

Sounds Awesome! I hope it works! Would it be possible to somehow use that to generate some terrain above it to make a cave though?

With regards to transporting Space Engine stuff into KSP.

The main problem that importing Space Engine stuff into KSP is generally the simple fact that unless you add noise on top of them, you end up with mushy or blocky (or both!) height. This is also a problem for color maps (Especially with ocean worlds. Look at @Galileo Planet Pack, for instance, and you'll see bits of blue on the shore. If that's been fiixed since I last looked at it I do apologize) but it's less of a big deal because they can be at a lower resolution without losing important details, sometimes. The problem is if you add noise on top of a fully finished heightmap, you get too much noise and the whole thing becomes a mess.

So I would recommend that to put a SE world into KSP, try to remove all small scale procedural detail from the SE world, and do your best to replicate a similar look with PQSMods. Alternatively, export the map and then manually iron out the small scale noise from the map and add some with PQSMods.

Note that this doesn't just apply to Space Engine worlds. It also applies to Real Solar System worlds, and worlds that use real world detail. (SSRSS, RSS, Galileo, to name a few)

Now there are some super-ninja tricks to get less blockiness out of heightmaps, but it works best for hand-painted ones instead of things like SE or RSS maps. The trick is to have lower resolution maps for higher scale things, and work your way up and down respectively to add details.

For instance, imagine you have a large lobed asteroid that you want to add, but you also want really fine detail. If you tried to implement it without using any noise, you would end up with a pixelated effect on the terrain. If you use a lower resolution heightmap, the pixelation goes down because KSP blurs it out better. But then you lose small details like craters and cliffs and such.

The solution is to use a low resolution (512x256) map for the lobes of the asteroid, and then put the mountains and cliffs and craters on a higher resolution map. (depending on the scale, 1024x or 2048x) The technique can also be applied to large bodies. Use a 1024x map for large scale topology, and put small scale details on a higher resolution map. Now the smaller details will still be mushy and/or blocky to some extent (Not obviously so, but still noticeable), but the terrain in general won't.

Now, @The White Guardian, that volcanic crater looking thing in the picture would be a shame to leave mushy, but it would also be a shame to have the whole terrain look blocky. Try using a low definition heightmap for much of the planet, erasing some of the important high detail land formations, and then copying them onto a high definition map.

This method is a lot of work, but it gets good results, especially in conjunction with procedural PQSMods.

There's a neat nifty trick to try and remove some noise 'errors' in heightmaps without manually smoothing them by setting 

PQS
{
	minLevel = 2
	maxLevel = 8
}

to this:

PQS
{
	minLevel = 2
	maxLevel = 6
}

That actually reduces the quality of the heightmap in relation to the terrain (It has the same effect. I don't really know how to describe it... It lowers the octaves of the entire terrain, if you know what I mean). It's good for smoothing out jagged areas, and generally keeps the rest of the detail relatively well...

Level changing is tricky, to be sure. First of all, it decreases the definition of all terrain on the planet, including procedural. Second of all, under certain conditions having too high or too low a Level can result in the planet being partially intangible.

Note: this spreadsheet is only for personal use. Maybe I'll edit it in the future for public use but right now it's tailored to work with a very specific mod.

I am pretty sure it is still being updated, based off the fact that KilAshley still gives the links out when you pm, and when I got it, it said it was updated recently, but idk... I don't make planets as much now as when I was just beginning

Wait, nvm there are only three curves... Ignore the message above

I presume the three curves are pressureCurve, temperatureCurve, and temperatureSunMultCurve?  Those curves are all important, but it's incomplete.  At a minimum there should also be temperatureLatitudeBiasCurve and temperatureLatitudeSunMultCurve.  These additional curves define the latitudinal and diurnal temperature variations of the planet.  By not providing these curves, the curves of the template are used by default.

And even if KillAshley does keep his spreadsheet complete and up to date, there's no harm in having another one.  There is certainly more than one way to automate this process.  A planet developer can choose which spreadsheet he likes better.

Yeah, I know, at the bottom at the last message I realized that there where only 3 and I said nvm, lel

Don't give up

Pull only up

And never stop

(oh wow i made it in 4 seconds)

I've given up on the mod. The outcome is that adding terrain scatter to a mod is such an insane amount of effort that it'd take a C# newbie like me years to get it working.

Fortunately, Thomas will be adding a new mod in the next update of Kopernicus, which can add scatter to an entire planet using a map where the whiter the color the greater the concentration.

That serves as a good replacement.