Space Graphics Toolkit & Planets

Hey, I love the pack, but I just now got the most recent update and everything is now missing textures and every single one of your scripts no longer works. Is there something I did incorrectly with implementing the update. Please help!
ps. Errors are on just on the EditorGUI_Packer script.

 

You need to delete the old SpaceGraphicsToolkit directory, then install the latest version. Simply installing the latest version on-top of an older version won't work for most updates, because I usually change quite a few classes to add new features, etc.

 

Hi!
i've a problem with my eart atmosphere, when i scale the planet it look like this:

any idea to fix the problem?
thank you.

 

Yeah I can replicate this issue, I must have changed something in one of the updates to break this, because I'm pretty sure scaling used to work correctly. I'll see if I can get a fix out soon, thanks for bringing it to my attention!

 

thank you, i'm waiting for your fix.

 

Ok I've fixed the issue for the latest build, but it was caused by some optimizations I added in after submitting 2.6.1 (thus aren't available yet). Are you sure your planet has a uniform scale? i.e. the X, Y, and Z scale values are identical. Because I wasn't able to replicate this issue in an earlier build.

If your scale is uniform and you're still experiencing this issue then can you PM/e-mail/post the .unity scene file for this?

 

that's strange, i just change the planet radius from 40 to 100 and the problem apear.
My scale seems to be uniform.
is that a shader problem or other thing?

 

I have no idea, can you upload the scene?

 

i need to simplify the scene before send it.
It seems to be a sin/cos problem on the planet orientation to the sun because when i change the radius to 51 (the size where the problem start to appear) the bug is dependent of the planet orientation (it disappear periodically)...

 

Thank you! and It looks incredible, as usual.

 

i found the problem, i had a camera as child of the planet that create the bug (but i dont understand why...)
But i've the same problem during the scale of a planet:
for my application i need to scale dynamically the planet, for that i made a loop witch increase the planet scale gradually during 25 frames.
At the beginning and the end of the scale the planet look good but during the scale it doesn't work well (i've a similar render than in the picture above).
This problem occur for every planet with atmosphere and for the sun...

Have you a fix for that?
thank you.

 

Ah, then it's possible your scaling code is being run after the planet shader code.

Try going to: Edit -> Project Settings -> Script Execution Order

Then add SGT_Planet and your scaling script, and make sure SGT_Planet has a higher priority.

 

WOOT 2.7!!

I'm loving the new Infinite Dust Field component. Very beautiful.

 

Hi,

First, I am really liking the nebulae component; Great job and thank you !!

Now, I ran into a problem when I updated to the new version 2.7. In 2.7, the thruster shaders (BasicFlame,Flame,Flare) do not compile anymore and comes up as pink on my mac. In the previous version it was working; I can't remember if I was using the one right before 2.7 or an earlier one. I made sure I deleted everything before importing the new version.

The errors I am getting are :

Right-clicking on the thruster shaders and selecting reimport will make the errors appear in the console log.

 

Oops, I moved them and forgot to update the include paths, nice find! I'm submitting an update now.

If anyone needs the fix ASAP then just extract THIS zip on top of your 2.7 install directory.

 

Darkcoder, Thanks for the fix, the thrusters work again !

However, strangely I have another issue which I just noticed now (not sure if it was there before), but I can't create a star anymore.

When I add the script to an empty game object I get a bunch of null ref exception, which is okay I guess since its missing texture and mesh that I need to assign. However, even after I assign them, I still get null reference that keeps popping up; Also with everything assigned, the star model and textures don't appear/render on screen in scene view or game view.

Sometimes dropping the Star script on an empty game object will create a child of that object called "Oblateness" which contains two empty gameobjects called "Atmosphere" and "Surface".

The error I get which keep repeating over and over is the following:

 

You're right, I didn't test it because I didn't think I modified the class >_<, the same goes for the Asteroid Ring. I'll get a fix out in an hour or so.

[Edit] OK I've fixed the errors, but I had to modify quite a lot of source files so PM me if you want the fix. Or just wait until Unity approves them.

 

I think Rings are broken? i tried creating one for my planet and nothing even shows up, though i do get this in the log...

 

Yeah I unintentionally broke quite a few things with 2.7 due to poor testing. I PMed you the fixes, and I'm just waiting for Unity to approve my submission (why does it take so long to approve if they don't even test it?).

 

Hi DC,

I finally bought your excellent kit, and I'm starting to do some tests. One of the projects I'm working on is a VR demo for the Oculus Rift (which I've just received woohoo). The first thing I noticed is that all the effects that are based on billboards don't work with the Rift's camera controller, because the billboards match camera direction/rotation. The main issue is with rolling your head sideways which immediately kills the effect.

I am close to achieving a nice warp effect using the SGT_dust script, but of course as soon as you move your head it falls apart. Is there a way to lock rotation of the billboards to something other than the cameras? Maybe the camera controller which is the parent object for the two cameras, (one for each eye).

Thanks!

 

Yeah I did notice that. I'll wait until the 2.7 fixes have been accepted by the asset store before I submit anything else. In the mean time, I sent you a test build which contains code that should hopefully correct the dust cloud camera roll issue.

 

Amazingness! Will give it a test in a bit and report back.

EDIT: Works great!

 

Damn, I'm jealous!!


Is it "safe" to install what up on the Unity store now, or should I wait a bit longer?

Typically I've created new (test) projects with each new release since I don't mind start my testing over from scratch.


DarkCoder needs some Shore Leave! We're running him ragged with all the requests and features we're making him add - he needs a break so he can relax a bit!

...Nah, keep at it DC - all your work is looking too good to allow you to rest or sleep!


-Will



PS - I have to say I think it is eff'n ridiculous that when you go to the Asset Store and put in a search for "Space" this SGT addon doesn't even show up! (...and if it does, I got tired of scrolling down looking for it!)

Even when I select "My Stuff" I STILL have to scroll all the way to the bottom just to find the add-on so I can update it - THE most important addon I've purchased and it's pretty much a ghost in the system!


DC I'd say you should pull your product, and post it anew because obviously the keying / tagging for your add-on is all screwed up on the Asset Store database compared to all the other entries.

Even a sort by "popular" doesn't show it - what? I guess there's only five of us here that loves this package? Yeah right...

 

Yeah it should be safe to update now, Version 2.7.1 was accepted yesterday, and it fixes a few silly mistakes. But like with all software updates, you should backup your projects before updating!

I certainly could rebrand/rerelease SGT, but I'll leave such drastic measures until after I try everything (e.g. making YouTube videos).

I completely agree that it's ridiculous that SGT doesn't list for 'space'. I just tried it now, and on the 'popularity' tab, the #1 asset is something last updated in 2011, and doesn't have any reviews/ratings. In fact, almost all the assets in there don't have any reviews/ratings, so the search system is clearly completely broken/poorly designed.

 

^ EXACTLY!

-Will

 

Just updated, and it's looking good now. I even installed the Unity 4.1.3f3 update to double my risks.

I did encounter a situation where I had to update SGT twice, but that's because I am using a custom folder hierarchy. Once I did the second update, the new demos for dust and nebulas worked fine (they were black scenes on first update). Since I did not install fresh though, some things that existed previously are weird (ie the 3d thruster demo - the thrust fx texture is pink/missing). BUT - this is my experience in general with Unity using asset updates when you change the directories around. To prove this I did install SGT to a clean project and it works great:

Clean Install:


My custom directories after updates (unity weirdness with asset updates in custom locations, not SGT)


Great work, and amazingly useful asset Darkcoder!

PS: if you notice my post count, some customers simply dont post - but these threads are monitored and youtubes are followed - it's very useful to see the chatter, even when we dont participate

 

I just tried doing a fresh install of SGT in Unity 4.1.3f3 and those scenes seemed to work fine. I then created a few random subdirectories and dropped the whole SGT directory into it, and the scenes still work fine.

My guess would be that you didn't upgrade to SGT 2.7.1 (released 2-3 days ago) which includes a few fixes, including one for the thruster shaders.

If not, then you can look at the materials to see what wrong. They're in SpaceGraphicsToolkit/Examples/Materials/Thruster/Flame

 

quick question: for support questions do we ask here or is there somewhere else?

and if so, i'm in the middle of creating a 'Universe Generator' loosely based on the procedural example, however the intent of this goes much farther. it creates nebulae, galaxies, stars, planets, moons etc etc.. based on sizes and ranges specified.

anyway, my question is: how might one go about loading up a surface multi mesh properly? whenever I try to create one via a 'new' operator it returns null. I can load up a (Mesh) mesh fine, it's just getting it into a surface multi mesh or multi mesh that seems to be an issue.

 

You can ask here, by PM, or by e-mail. But asking here keeps this thread alive, and it might give other people ideas, so I prefer this

I intended to make it so that the Planet and Star classes automatically instanced an SGT_SurfaceMultiMesh where needed, but it seems I made a mistake with the SGT_Star class. In SGT_Star_Properties.cs, after line 107, add: if (surfaceMultiMesh == null) surfaceMultiMesh = new SGT_SurfaceMultiMesh(); and it should work. You now just have to read yourPlanet.SurfaceMesh or yourStar.SurfaceMesh and it should always return non-null. I made the property setter do nothing because I wanted to make it harder to break the state of these classes, perhaps I should have removed the setter altogether, but it's a design choice I made to keep the inspector code looking consistent.

 

that worked an absolute treat, thank you

 

Hellou.

I have a questions.

Can I put in something to a planet like tree or some station creatag in eg. terrain toolkit etc.?

And what about the cooperation SGT with other unity packages?

I see the planet terrain is generated from the textures , so terrain is a stable.
Is this pasible to change the terrain (change deformities) using terrain toolkit?

And what is better SGT or Etherea?


Please for reply.

 

I don't know what Terrain Toolkit is, but I'm pretty sure it's not compatible with SGT, because SGT planets don't use Unity terrains. If you want to place trees and stuff on your SGT planets, then you'll have to do that yourself in the editor, or write a script to spawn them. You can place them on the surface of your planet using the Snap To Surface component.

If you want to deform the terrain yourself then you'll have to either modify the height maps, or modify the planet meshes. If you want to modify the planet meshes then you can either create them yourself in Blender (or a similar program), or use a Unity modelling addon, like Game Draw.

They're completely different packages really. Etheria focuses on procedural planets, whereas SGT focuses on a wide range of space graphics, including planets. However, the planets in SGT aren't procedural, because they require source textures and height maps, so it depends what you're after.

 

I've started working with cube textures and cube spheres. One thing I noticed was small seams between the sections. I've checked my textures and they're fine. I suspect the meshes are positioned a pixel or 2 off from each other thus creating the seams. If you turn off the atmosphere on the earth cube map example you can see what i'm talking about.

I've looked into trying to modify it myself however there are several layers of extrapolation to go thru. SGT_Mesh, SGT_MultiMesh, SGT_SurfaceMultiMesh etc etc. plus the fact that I have to find what's hidden and not knowing what i'm looking for. I'm assuming that each mesh has it's own hidden gameobject? Something to give it a transform?

please advise

 

I checked the Earth scene using the cube textures, and I can see the seams between the cube faces, they indeed aren't apparent when looking at the textures themselves. However, the seams aren't caused by SGT, and it's not the fault of the meshes. The issue likes with the textures, and it's twofold:

- The textures are compressed by Unity, so the edges might not match up exactly in all cases.

- The textures use bilinear filtering, but each cube face is separated so there's no way for the filtering to apply across the cube borders.

The second point is the main reason why you see seams, and it's the same reason why you see texture seams in any game that uses multiple textures in different areas of the terrain. If you load up two adjacent cube textures (e.g. +Z -X) and align them in your image editing program, you'll see that the pixel colours on each texture edge differ, which will cause a seam when put into 3D. To fix this, you have to make sure the edge rows columns have matching pixels.

I don't have any experience with fixing this kind of texture issue, but I know that it's a problem faced by actual cube map textures, so I'm guessing that there are tools out there that can correct this. If not, then a script could be written to blend the edges together.

 

when I make the cube textures I first make a single seamless texture using various plugins (photoshop) namely redfield's seamless workshop plugin, from that I then generate the cube maps using flexify 2 (another plugin) and then import them into unity and finally apply them.

i'll see if I can delve a bit deeper into my source textures to rule them out absolutely. secondarily, I have some experience with texturing as I have collaborated and written a few 3d engines which used, dynamic texture splatting, normal mapping, terrain (ROAM, geo mipmapping, octrees) etc etc.

currently, i'm working on a 'universe generator' (using your most excellent sdk) that basically allows you to set a few parameters and textures and it will auto generate galaxies, nebulae, quasars, pulsars, black holes, asteroids, stars, planets and moons. having to create several thousand objects by hand is a little too daunting for this programmer

I've adjusted your SGT_SimpleOrbit, to negate the parent's rotation if you wish, thus allowing me to be able to orbit in any axis as well as self rotation in any other, while the parent can rotate in whatever axis and speed it likes. this allows you to still have the parenting relationship, but be able to pick and choose what you want to 'inherit' from it's parent. I know some folks would argue that if I don't want to inherit parent transforms that I shouldn't parent them, however I would argue that I personally don't like having to have a bunch of root objects that I have to then search and or maintain the relationships separately, potentially each frame..

Additionally, I've modified your SGT_SurfaceTexture class to be able to automatically parse a texture and obtain it's most used color, create a gradient from that, and then use it for coronas and atmosphere. I did this to be able to do a simple Euclidian distance color check against known star colors and more importantly their heat, mass and diameter ranges. all from reading the texture that the user wants to apply. I then have an 'Enforce Star Contraints' bool which, if enabled, will make sure the star is of the appropriate size and mass and will automagically resize the star as well as the corona, atmosphere heights etc to be within the limits of a star with that texture color..

Lastly, I did this to be able to approximately calculate habitable zones around different types of stars based on their heat indexes, thus to know what textures to apply to those planets etc closer in vs those that are farther out. (fun fact: there is no such thing as a 'green' star btw )

so for example, as i'm randomly selecting textures for a small planet close to a hot star, chances are that there is no atmosphere and certainly no liquid water due to the heat and lack of atmospheric pressure, possibly lava though, but mainly just a burnt out cratered cinder. so when I randomly choose a texture to use, I wouldn't use a blue (water-based) texture. the opposite would be true for planets further out. mainly ice, snow, gas giants and barren rock based textures with thin or no atmosphere. i'm also able to approximate orbital distances based on heat, mass and diameter.

all of that now becomes reasonably approximated due to simply checking the star's texture color.

so you can see why, after all of that, why I was a little chagrined to see the seams lol

there might be a few tricks we can use (ie: tiling) that might get better results. what class/object might contain that info? SGT_SurfaceTexture?

btw: i'm thinking of changing your inspector to allow a user to either use the 6 textures OR a premade cube map and get the appropriate textures that way. not sure yet, I haven't looked into the code that far, but it seems to me to be something that would be cool since I might want to reuse a cube map for something else. shrug

 

got it fixed actually

i'm not sure where the best place for this would be but:

if (Configuration == SGT_SurfaceConfiguration.Cube)
newTexture.wrapMode = TextureWrapMode.Clamp;

textures default to repeat. needs to be set to clamped if using cube textures..

 

I've got a scene set in Saturn's rings, and it looks fantastic...except I need something below the SGT ring object, showing the density of the ring looking "down". I've got an animated UV texture set up (see screenshot), but it just doesn't look good, it's obviously flat. I've tried adding more SGT objects but worried about performance on mobile. Any suggestions on how to make this look real?

 

haven't had a chance to play with the asteroids yet, in a day or so as I make my way thru the sdk, but mebbe some fog or smoke a particle emitter? not sure what that would look like though, something to show a bit of depth. just a suggestion

 

Unless you're using the Surface Tessellator there's no single place where you can implement tiling. But the best way would be to write the tiling in the planet surface shader and pass the tiling amount in the SGT_Planet.cs. Alternatively, you could modify the mesh UV data, in which case you'd want the SGT_SurfaceMultiMesh.cs

I originally made it so that you could set either a spherical texture, or an actual Unity cube map, but for some reason I found some limitation that caused me to revert to using separate textures for each face. I think the issue was that I couldn't easily separate the faces without making new textures, which would have a large performance penalty when changing textures, and it would also double the memory requirements. But if you still want cube maps then it shouldn't be too hard to implement, as I believe I used an enum along with many switch statements to choose between the surface texture types, so you'd just have to fill in a bit of code.

Your project sounds interesting though, keep us updated, especially if you post any juicy pics/videos/demos

Yeah that should work, though I'm not sure if it will persist. I believe you have to modify the settings from the Texture Asset Importer?

I'm also pretty sure all the planet textures that come with SGT have their Wrap Mode set to Clamp. I guess I should have checked that from the inspector and show a warning if they're not right.

One method would be to fade your ring plane out based on its angle to the camera, i.e. full alpha when the camera is top-down, and no alpha when you're side on. If you want to do this via code then you need to do something like:

Code (csharp):

1. var cameraDirection = (Camera.main.transform.position - ringGO.transform.position).normalized;
2.  
3. var alpha = 1.0f - Mathf.Abs(Vector3.Dot(ringGO.transform.up, cameraDirection));

To then get this to work, you'd pass alpha to some sort of transparent shader, e.g. Unlit/Transparent Cutout, Particles/Alpha Blended

Another way to show the density more clearly is to just use more SGT_AsteroidRing layers, but give each layer a different width and thickness, and to make sure they're using the Bates2 distribution.

 

I checked the texture set method and the new textures are indeed created with the default wrapping mode of repeat. I placed the clamp code in the set method and seems to persist and work quite nicely. seams are now gone

btw, I found something else that was bugging me. trying to size the rings. in my opinion, you should be able to set the inner ring and then the width from that, but after looking I found this:

Code (csharp):

1. public float RingRadiusInner
2.     {
3.         get
4.         {
5.             return -ringWidth * 0.5f;
6.         }
7.     }
8.    
9.     public float RingRadiusOuter
10.     {
11.         get
12.         {
13.             return ringRadius + ringWidth * 0.5f;
14.         }
15.     }

not sure what the * 0.5 is for, but after changing it to:

Code (csharp):

1. public float RingRadiusInner
2.     {
3.         get
4.         {
5.             return ringRadius;      }
6.     }
7.    
8.     public float RingRadiusOuter
9.     {
10.         get
11.         {
12.             return ringRadius + ringWidth;     
13. }
14.     }

it 'feels' much better. it doesn't resize the inner ring now when you resize the outer.

as far as pics? sure thing still sorting out a few assets etc before i'm ready to show stuff

 

All the rings in SGT used to be specified by [Radius .. Radius + Width] (as your modification shows). But in Version 2.5 I believe it was, I changed them to [Radius - Width/2 .. Radius +Width/2], so you can see where the * 0.5f comes in. The reason why I made this change was because when using SGT, to make interesting asteroid fields I often found myself having to duplicate rings to create additional layers. However, these layers needed to be tinner, but shrinking them consistently using the former range was very time consuming, so I changed it. There are other times when the new range makes more sense, for example if you want to plot a circular orbit using the SGT_Ring component you can just set the radius to the orbit radius of your planet, and freely tweak the ring width to whatever you like.

One solution to make everyone happy would be to just display the 3 obvious ways to define a ring's radius and thickness, but I believe this would clutter the inspector up too much. But if anyone else wants to go back to the old system, then just open up SGT_Ring_Properties.cs (lines 436-450) and SGT_AsteroidRing.Properties.cs (lines 256-264) and make the changes mentioned above.

 

got another question

i'm trying to add some noise to the stars by adding a perlin noise 4d shader. I have the shader and it's working etc, however i'm going through a few growing pains trying to actually get it to render properly in SGT. I see in lateupdate() you're hard coding the first one (variant/outer), any suggestions or advice to make my life a bit easier? <grin>

 

If you look at SGT_Star.cs lines 97-111, I build the shader string based on the star's current settings. The chosen shader is just a stub that sets various #defines, and you can find the actual shader code in SpaceGraphicsToolkit/Required/Shaders/CGInclude/StarSurface.cginc. You can implement your noise in there by modifying the shader.

If you want to make the noise optional then you'll have to add your own 'hasNoise' field to the Star class, and optionally append 'Noise' to the targetSurfaceTechnique string in SGT_Star.UpdateMaterial. You'd then duplicate all the StarSurface shader stubs in SpaceGraphicsToolkit/Required/Shaders/Resources/StarSurface, luckily there are only 4 for the star. Now just open the shaders up and append Noise to their names, add #define VARIANT_NOISE to each of the new shaders, and you should be good to go.

However, I personally don't make the shader stubs by hand. I've written an editor to easily churn them out, and you can get that tool from HERE, though there is no documentation for it.

 

thanks, i'll check it out

once I get them done, and if they look decent, i'll send them to you if you like

 

I have am trying to set up layerCullDistances for some planetary rings, so the distant areas of the rings are culled (they look too thick, not to scale), while the closer areas are rendered. But I think that layerCullDistances doesn't work on the SGT asteroid/ring component -- it's all or nothing, it won't cull just the portions beyond the culling distance. Any suggestions on how to get that to work?

thanks
Dave

 

You're right, I forgot to set the layer and tag for the ring slices.

To fix this, open up SpaceGraphicsToolkit/Required/Scripts/Player/SGT_Ring_Messages.cs, and after line 19, insert:

Code (csharp):

1. SGT_Helper.SetParent(ringGameObject, gameObject);
2. SGT_Helper.SetLayer(ringGameObject, gameObject.layer);
3. SGT_Helper.SetTag(ringGameObject, gameObject.tag);

I'll submit a fix for this very son, thanks for pointing it out!

 

Thanks for the code, but it's still not working. I've got it in the right place? the culling works on other objects, but not the rings -- even when I set the culling distance at 1, the entire ring is rendered.

 

After re-reading your original comment, I think I misunderstood the issue.

Unity's layer culling distances allow you to change the distance at which rendered meshes will get culled. However, Asteroid Rings in SGT essentially just use a single mesh, so they're either fully culled, or fully visible. This means that setting the cull range won't allow you to hide individual asteroids based on their distance to the camera.

If you want to do something like culling distances for the asteroids then you'll either have to modify the asteroid ring shader to hide/shrink asteroids based on their distance to the camera. Or, you could modify the asteroid texture mip-map alpha to fade out, this would give you a rather crude solution with no overhead.

Anyway, please correct me if I'm still misunderstanding your issue.

 

Ah, I see. Yes, that's what I want to do. So that will improve performance? Frustrum culling doesn't seem to affect performance of a dense asteroid ring on iPad...but hiding the asteroids based on distance to camera will effectively reduce the processing load?

 

If frustum culling doesn't change anything then the bottleneck is the vertex shader, which will always be run for every asteroid as long as any part of the asteroid ring is inside the view frustum. If you disable asteroid spinning then you can gain some speed, and disabling ring shadows will speed it up even more. But the only other way to speed it up is to use less asteroids (you could then make them bigger to compensate).

Yes, hiding the asteroid ring will speed it up a lot. Obviously you don't want the whole ring to appear/vanish instantly, so you might want to make your asterid ring up from multiple GameObjects, but give each one a different culling distance so you only see all the asteroids when you're up close, just keep in mind that each asteroid ring is a separate draw call, so you don't get too crazy.