Space Graphics Toolkit & Planets

Apparently removing it wasn't intended? https://issuetracker.unity3d.com/is...n-a-definition-for-setselectedwireframehidden

 

I just purchased this, am using Unity beta 5.5. When do you expect full 5.5 support in this asset? Is it fully working with 5.4 if I wanted to downgrade to that? If not working in 5.4 and/or 5.5 I might need to get a refund, we are on a very tight schedule and don't have time to wait for long. Thanks so much!!

 

As I said in the previous reply, the removal of this method was marked as a bug that will be fixed by Unity, so it's not an issue with this asset. For now you can just comment out those 3 lines, or wait for the next version from Unity.

 

I downloaded the Latest version of unity 5.5b7 also the issuetracker bug that you showed upabove has been fixed... Still getting the same errors as up above

 

Just comment out the lines until they release the version that includes the fix. Those lines just hide the scene view wireframes that can slow components down when selected (e.g. SgtTerrain).

 

Setting up Saturn with the 3.x ring system for the first time, and the the semi-circle on the far side of the sun has an odd dark tint. I adjusted the penumbra color on Saturn, but it persists. Any suggestions on how to fix that?

 

Do you see this issue in the 'Saturn' demo scene? If you're using just media that comes with SGT then can you upload the .unity scene file so I can replicate it?

 

Hi.
I think about how to generate via SgtProceduralSystem Planets and other objects. Right now I have 10k stars generated from XML file (120k in future) who give real directions of nearest stars in X,Y,Z. Question is how to connect that all to database (X,Y,Z and other parameters like for example Magnitude or Luminosity and LightTemperature [how to use]). Maybe someone have some idea for dynamic universe LOD?

 

You could easily render 120k stars using the SgtCustomStarfield (or via your own SgtStarfield), the challenge is finding which star you're nearest to and loading a high resolution star model and planets for it.

To do this you could use two coordinate systems, one for your galactic position, and one for your star system position. To find the nearest star you could store the star positions in a tree for fast searching, and if you're within a certain distance of a star you load the models for it. These models would then probably have to be positioned using some kind of origin shifting system.

 

Right but i thing I need 3 coordinate systems , 1. For galactic , 2. for stars and 3. for position on planet. For position on planet, asteroid ,etc. I thing about use Geographic coordinate system (Have some script). Regards

 

I've attached a basic project showing you how to create an origin shifting system using two coordinate systems with as many different scaled cameras you like. The code is pretty basic, but also fairly intricate, so I highly recommend you fully understand it before trying to modify it. This demo uses User Layer 8 = 1k, User Layer 9 = 1m, to match the camera names.

In the demo scene just press space and it will pick a random star generated by the SgtGalaxy starfield, and warp to it. When it gets within range, the SgtGalaxySpawner will spawn an SgtGalaxyStar at the star's location (it doesn't despawn it!). Although there are 3 cameras (1:1. 1:1000, 1:1000000), the galaxy is only rendered in the highest, and the stars you travel to are rendered in the middle. As an example I placed a star at the origin that uses all 3 LOD levels (though I doubt you can see the highest), and how the SgtSwapper component can be used to handle this LOD between multiple cameras.

As for the code, the SgtPosition struct stores the universal position of everything (e.g. main camera, stars). The struct is split into the Local and Global coordinates. The local coordinates use doubles and when any of them exceed the SgtCamera.CellSize they will inc/dec the global coordinates which are longs. By default CellSize is 1000, which means it can support positions += 974,883 lightyears with a very high accuracy (e.g. for local physics).

All objects in your scene should have the SgtSnappedObject component, which stores an SgtPosition as well as a reference to the camera that's rendering it. If any of the cameras snap their origin position then this GameObject's position will be updated, hence the name.

The SgtLocalCamera component is attached to the main camera, and any extra cameras have the SgtScaledCamera components. As the name implies, the scaled cameras will have their movement scaled relative to the SgtLocalCamera, but they don't actually scale anything in view, so you must make sure your GameObjects are scaled correctly, and have the right layer & culling mask. If any of these cameras exceed the CellSize position then their world space position will be reset and their global positions will be adjusted accordingly.

Both the SgtSnappedObject and SgtLocalCamera components monitor their world positions for changes and apply them correctly relative to their scale, so it should work fine with physics and most components that modify positions and things.

The most difficult thing about this code is getting the scale of your objects right in each camera, and making sure they're in the correct layer. If you make any mistake here then objects will look bad, easily end up flipping around the screen when you move the camera fast, or disappear with LOD. Also, since the stars are very far apart, the calculations required to get their positions is very delicate, and one mix up of floats and doubles can cause you to see nothing because you might be off by thousands of km, so be very careful about your data types.

Enjoy!

 

^ this was a good read but not sure if i understand it completely

 

Which part?

 

Darkcoder you are BIG. Greate code nice structure and good idea.

 

Hi folks, sharing my impressions with a test I did were Space Graphics Toolkit works together with the Granite texture streaming solution.
I've created 32kx16k color and normal maps and 8kx4k displace map and put the resulting material (using Granite's texture redirect feature) with the StandardShader on a Space Graphics Toolkit terrain as a stress test. For results and more detail (FPS and memory bearings and more detail on the setup) see the following video and its description.

It just works. It's amazing because this happens less than often in Unity.

 

Looks great, is that using just one texture and material? With a bit of extra code you could write an SgtTerrainModifier that makes new materials and loads separate textures, so you can have LOD textures, as well as streaming. Though I don't think the current SgtTerrainModifier code has a material changing setting.

 

And a question for you Carlos (being a space effects expert): Do you see a way to create a wormhole effect similar to the wormhole in the Interstellar movie? Basically it would have to be a 3D spherical portal if I get it right and as such, the render output of a reflection probe on the other side of the wormhole should be usable as a base for the effect. Am I right?
Any plans on adding this in the future?

 

Yes indeed, one texture for color and one texture for the normal map in one material that has the Granite's adaption of the Unity standard shader assigned.
Basically, the Granite solution allready kind of takes care of LOD because it only loads texture tiles based on visibility and distance. The only limit was the 32k texture tile map limit of the Indie version, otherwise I'd have gone for the full 232 meters per pixel texture. As I'll have a fixed camera path for approach in my project that will end in a single point on the surface, I'd go with a higher resolution terrain patch for the target area then.
I'm more thinking of also using the texture streaming on the SgtDisplace component, because the 8k texture limit of Unity for the height map is what bothers me the most right now. Should also work without problems, shouldn't it?

 

Nope :/ Just found that you're doing the displacement in the component, but Granite only works with shaders.

 

Do you mean the scrolling stars effect at this timestamp? www.youtube.com/watch?v=yTpbZ_Psbeo#t=1m15s

If so, I experimented with a feature that looks similar to this before, but never finished. I can try and finish it off this week though.

The benefit of using multiple textures and materials is that you can use less memory. With a 32x16k 24bit texture, you're looking at 1.5gigs of memory alone, even if you only load a small section of it. For the heightmap, I recommend you modify or make a new 'SgtTerrainDisplacer' component that doesn't require a Texture2D. If you look at that code, you can see it requests the height at a specific XYZ point, so you could replace the heightmap sampling with a different lookup that doesn't require a Texture2D.

 

Sorry, didn't make that clear enough. I meant the effect that can be seen before actually entering the wormhole at the beginning of the sequence. It's similar to looking at a portal in form of a half sphere with increasing distortion closer to the edges - well, sort of.

That's the automagic that comes with Granite, the two textures only take up a bit more than 200 MB on disk after processing and the RAM and GPU memory usage is equally as low because only the visible parts are streamed in, so the display resolution actually is the deciding factor. Couldn't believe it before I tried it out, but they really managed to achieve it. Almost no loading times at the beginning, no texture LOD (aka mipmap) popping, because it's all streamed and decompressed on the fly.

True, as easy as it is, I haven't thought of that alternative yet. Thanks for the food for thought.

 

The SgtSingulairty component does something like this, but because it's a camera effect you can see limitations when it tries to distort pixels that are outside the camera view. To do it properly the scene would have to be rendered as a cubemap I imagine, but this would have many limitations for actual games with objects in the scene so I don't think it would be usable.

Even when you're close to the planet? Sounds nice.

 

Darkcoder, Hello!
Your toolkit looks great!

I am thinking to buy it, mostly due the planet LOD and atmosphere scattering systems.
I am going to use it for landing on full scale procedural planets and I have a few questions:

1. About planet LOD. Is there is a limitation of maximum LOD level or I can generate as much LOD as I need? I mean depth 10 or 20. In order to increase detalization of 10000 km planet from space view to a couple of vertices per meter after landing.

2. About atmosphere scattering. Is it good enough to use it not only from low orbit around planet, but also right from planet surface (while character located on planet)? Or simply put, is this tool able to replace the default procedural skybox for "ground" FPS game? But while character will raise its altitude, the sky will slowly disappear and transform into "space"?

Simply put, can I use this tool in order to create planetary landing like in games: Space Engineers, Star Citizen, Kerbal Space Program?

Thanks!

 

There's no set limit, but all the calculations are done with floats, so you will eventually experience scaling issues depending on your scene settings. To counteract this you would have to implement a more advanced coordinate system, but this is a very game specific feature, so you would have to know some C# to add it.

It depends on your game. In order to fit the shader into Shader Model 2, certain sacrifices had to be made that make the atmosphere not look as good as say Unity 5's skybox, but since you can seamlessly travel to space with it, it's very useful for many games.

The LOD system is very similar to Kerbal's, but not quite as advanced. In the future I hope to make it as good as Kerbal's, but there's still quite a lot to do. Right now the terrain system is probably good for something along the lines of Spore.

 

Darkcoder, thanks for the quick reply!

Yes, I realize that implementation of full scale planets requires some special workarounds such as multi camera, scale adaptation, floating origin etc. Thanks for precaution.

I already implemented some of such approaches, but my implementation of LOD is not finished and quite slow.
So mostly I need just reliable mesh generator and atmosphere.
Seems like this exactly what I need, and I will try to figure out how it works and adapt the system. Thanks! : )

 

Hi I have the package installed in my project but not currently using it in any scene but during compiling to android I get these shader errors

 

Try selecting the SgtLight.cginc and SgtShadow.cginc files, right click -> Reimport. It looks like Unity doesn't correctly handle the scenario where you move cginc files, and since you moved the SGT install folder it broke that somehow.

 

thanks it worked

 

Hi Darkcoder!, do you think theres a way to add specific Motions to each star, based on real Proper Motion and Radial Velocity data to a CustomStarfield?

 

The easiest way to do this is to store the velocity of each star in the vertex data, and shift the star's position using this and the _Age property. The only downside is that eventually all the stars will fly away and disappear, so I don't think it's so useful for most projects.

To make the changes you can add a Velocity vector to SgtStarfieldStar.cs (or Proper Motion & Radial Velocity and calculate the velocity later), and write the vertex data in SgtStarfield.cs:BuildMesh. Velocity is a Vector3 though, and the only available vertex attributes are uv3 and uv4 both of which are Vector2, so you'd have to write the XYZ to the XY and X components of each, and in the vertex shader you can retrieve the velocity and multiply it by _Age, and add it to i.vertex before it's used.

 

Hi, do you have some date when you plan to update tool to unity 5.5 version?

 

I solve my problem by reimport all assets

 

Sir, your atmosphere is amazing! As good as the default Unity sky.
And planet LOD is also amazing and work very fast!

This is two main features for me. So if you thinking about what to improve, suggestions from me - Atmosphere and LOD.
Actually, LOD seems perfect, but Atmosphere maybe can be improved (however don't know how exactly), maybe better sunsets or something like this, You should know better : )


And one question.
By default, after PlanetPatch perform Split (), its children have subdivided UV. However I need to keep their UV "intact". I mean, each PlanetPatch should have UV from 0 to 1, not 0-0.5 or something like that.

I already found workaround - I just increased material tiling to 2, 4, 8 etc. But it is not very correct solution and 0-1 UV will be more preferable.
How can I do it?
If there is no such option, just give me a code and tell where I should insert it. If it is not bother you.

Thanks! : )

 

Indeed, the atmosphere does need some improvement. I have plans to make a new one (e.g. SgtAtmosphere2) that performs more complex and impressive looking scattering, but I will have to experiment around a lot before anything will be released.

The 0..1 UV data you describe is currently stored in the uv2/TEXCOORD1 channel. The shader used in the 'Terrain Debug' demo scene uses this, and is how the individual patches are highlighted. If you want to switch uv and uv2 then you can change the calculation for it, the code is in SgtTerrain_Patch.cs lines 223-224.

 

Sounds good! Take as much time as needed. If it will be improved - it will be amazing! : )


Made a changes in the code, now it works perfect! Thanks!
Also I found a little bug, after I swap those lines, UV turned out mirrored on X coordinate, but I am easily fixed it by little modifications:
currentCoord1 = new Vector2(-quadU+1, quadV);

And commented second UV coord to archive additional performance boost.
Very flexible!

Also I noticed that you are using vertical alignment in your code. Quite rare programmers use vertical alignment in their code.
Very clean code : )

 

Hi Darkcoder is there a way to reuplad teh solar sytem and the galaxy pack ...it seems to be broken for the current version of unity and SGT
thanks

 

Thanks, I hope so. My first idea was to replace the alpha blending of the corona and atmosphere components with additive blending, and use HDR + Tone mapping to level the brightness out. In theory this would allow for more realistic night skies where you can see the moon and stars in the sky just like you can in real life, but in practice the tone mapper looks poop when using such high brightness values, and causes bright things like stars to become incredibly dim up close, even with modest brightness values in the 5.0 range (5x 255). I'll experiment with doing the inverse where I just make the stars and such dimmer, but I suspect I won't be able to achieve the kind of results I was hoping for.

In any case, I'm currently working on some changes to the corona and atmosphere components that should make them look better and have less shader complexity. If successful, these would not require any replacement components, and would just make the current ones look better

I just made a new project in 5.5.0f3, imported SGT 3.2.4, imported SolarSystemPack, and notice no issues with any of the example scenes (besides the warnings which will be fixed soon). Maybe try reimporting the shaders and demo scene files? Or making a new project as I described, then copying the files over or something.

 

Hi Darkcoder. Is there a way to render obscuring dust when making a galaxy using the starfield components? I've tried changing rendering order and setting what is supposed to be dust to Background without luck. I'm trying to use far fading along with dust to mimic blocking out some light from the core when viewed edge on.

 

Starfields only use additive blending, so no they cannot obscure things like dust would. I experimented with subtractive blending in the past, but the results weren't so good.

The solution is to use alpha blending, but this requires sorting of the star/dust particles, which is difficult to do efficiently as it requires sorting the mesh data every frame (slow). However, Unity's built-in ParticleSystem has this feature, and it runs quite fast, so I recommend you use that.

 

Hi,

Someone could explain how can you use RTP materiel on sgt_terrain + sgt_displacer please ? Or a simple way for have high ground detail texture/normal map.

Thank you

 

Hey guys, here's a sneak peek of what I'm currently working on (open in separate tabs to easily compare):

Current corona/atmosphere:


New corona/atmosphere:


As you can see, the optical depth calculations are now much better looking. For the longest time I didn't like the current results, as they made the horizon look too linear and not like an actual thick cloud of atmosphere, so I rewrote how it works and I'm really happy with the results so far.

No idea, but the SgtTerrain and child SgtPatch components have a Material field which automatically propagates to child patches, so you would set it there. If RTP relies on vertex color data then you can use the SgtTerrainColor component to write that.

 

Hi Darkcoder,

I updated to the newest version of SGT but for some reason it broke my starfields. If I turn on and off the "Stretch To Observer" on my startfields using code, it doesn't seem to update them until the update calls UpdateMaterial. The combination of FollowCameras and set to false and StretchToObservers set to true works at first, but then inverting them by code doesn't yield the awaited result unless I force a call to BuildMaterial. This function seems to be called if I click in the inspector to change a setting like StretchToObservers. It was fine with the previous version, so I'm trying to figure out what you changed.

 

Hey,

I'm not sure which version you're updating from, but I changed the way materials and such get updated a while back. Basically, most settings are now associated with a specific 'Update___' method. If you look at the code for the SgtStarfield inspector, you can see how StretchToObservers is associated with UpdateMaterial:

Code (csharp):

1. DrawDefault("StretchToObservers", ref updateMaterial);

So to know which update method you must call after changing a setting, I recommend you look at the inspector for it (usually at the top of the associated class file). The reason why I don't just make properties to automatically call this is because changing multiple settings that require some Update___ method would waste a lot of CPU if that operation is expensive. I could work around this by using a system to mark it dirty and clean it later (as earlier versions of SGT did), but this makes the code rather complex. Additionally, Unity's inspector doesn't do properties by default, so this system made the most sense to me.

 

Thank you for the info! I had a much older version of SGT.

 

I upgraded to the 5.6 beta which gave a handful of warnings from SGT, which were pretty simple to fix except for one which I think I did properly but not 100% sure. Everything seems to be working properly so far, though I only just started.

The one thing I wasn't 100% sure on is in SgtHelper_Editor.cs, in the method MakeTextureTruecolor, the property 'textureFormat' is obsolete. I replaced it as such:

Code (CSharp):

1.                 if (importer.textureCompression != TextureImporterCompression.Uncompressed)
2.                 {
3.                     importer.textureCompression = TextureImporterCompression.Uncompressed;
4.                     ReimportAsset(importer.assetPath);
5.                 }
6.                 // This is obsolete
7.                 //if (importer.textureFormat != TextureImporterFormat.ARGB32 && importer.textureFormat != TextureImporterFormat.AutomaticTruecolor && importer.textureFormat != TextureImporterFormat.RGBA32)
8.                 //{
9.                 //    importer.textureFormat = TextureImporterFormat.AutomaticTruecolor;
10.              
11.                 //    ReimportAsset(importer.assetPath);
12.                 //}

 

I'm currently working on an update that addresses these issues, as well as upgrades many of the main components. Your changes there are the same as what i did on my end too, so it should work fine.

 

Any plans to have Cloudspheres project shadows onto an inner renderer? (if not, +1 reqest)

 

Possible minor performance improvement...

This is happening in the Atmosphere Outer shader:

Code (CSharp):

1. float4 shadowColor = ShadowColor(i.texcoord5);
2. lighting *= ShadowColor(i.texcoord5);

It looks like the contents of the shadowColor variable could be re-used here, instead of calling ShadowColor() again.

-----

Also, the opacity of the LightingLut is being discarded, so it looks like the back of the planets have a dark grey smog on them.

Instead of calculating the opacity of the LightingLut based on the grayscale of the LightingLut color, let the opacity be handled separately from color, using the alpha value of the lighting brightness gradient that is passed into the script.

 

No plans to do this, because the cloudsphere is mainly designed to look good from outside, and in this scenario you can just bake the shadows into the texture. I have plans to make it so this component spawns actual clouds as you approach though, which should allow for true shadows.

Thanks, though this shader (and corona, ring, jovian) has been rewritten for the next version of SGT to not only remove these issues, but be also simpler, look better, and use less instructions in most cases. It will hopefully be out this month.

 

Here's another sneak peek of the next version:



This shows the new SgtFlare component, which can be used to easily generate cool star effects. It also shows the new SgtRing detail map feature, which makes the rings look much more impressive up close. You can also see the improved SgtSphereShadow penumbra casting on the ring.