Space Graphics Toolkit & Planets

I uploaded the first of the tutorial videos video earlier, you can view it HERE. Once I finish uploading the first set then I'll properly announce it.

You can already make thrusters roll you ship, I just ran out of default Unity control axes to set. If you look at line 39 of SGT_3DSpaceshipController.cs then you can see I've written the code for roll, I just didn't have anything to map it to.

Shields effects will come soon! I'll begin with Stargate style shields, because I've already made them before so I know what to do and I have the media for it.

You can kind of do laser beams using thrusters, but yeah I will be writing a dedicated component to do this.

 

Great tutorial! Well made and concise. Thanks.

 

hey sweet, thanks man.

 

Excellent video! Been spending a lot of time with the toolkit this weekend, everything is great so far

 

I'm setting up my solar system after upgrading to 2.5, and I miss the Rotation on the star -- so trying to use the Chaos Transform to get the Corona to rotate, but it's not working. If I put that component on a Star+Corona, then the star spins around, but the corona doesn't move. If I put it on a Corona-only GO, then nothing happens. Am I missing a step?

 

I removed the rotation in the star/planet components because it was duplicate functionality, and it meant that there was no obvious way to place objects on planet surfaces (because you can't directly read the rotation data). However, I did enhance the SGT_SimpleOrbit (Component → Space Graphics Toolkit → Simple Orbit) component to now have the optional Rotation setting, this will allow you rotate Planets/Stars/Anything

If you put your corona is a separate GO and rotations don't affect it, then your corona's Mesh → Alignment must be set to Billboard. If you change it to Random then it should rotate as expected.

 

Thanks for the quick reply, and, yes, if I change Alignment to Random, the corona does rotate now. But as the camera moves, portions of the corona disappear -- see attached. I can reduce this by increasing the Plane Count enormously, but that wasn't necessary before, and it still happens even with Plane Count over 100. Is there something else I can do to replicate how it used to work?

 

It looks like something's going wrong with the Cull Near option. Are you using an orthographic camera? If not, could you try removing the Corona component and creating it again? If that still doesn't fix it, could you upload/post/pm/e-mail me the scene file and anything else required to test the scene?

 

Ah, thanks for the tip. The Cull Near setting were default, and way too small. I've cranked them up and now it's good again. Thanks!

 

So how goes the work?

 

I submitted version 2.5.5 a few days ago, but it hasn't been accepted just yet. It includes a bunch of bug fixes and a few new features + scenes

 

​

Version 2.5.5 has now been accepted and can be downloaded from the asset store!

• Added the Debris Spawner component.
• Added the Shaders In Build window.
• Added the ‘Spaceship On Surface’ example scene.
• Added the ‘Infinite Asteroids’ example scene.
• Fixed a bunch of small bugs.

​

Before upgrading, I highly suggest you back-up your projects.

While this update shouldn't break anything, it's still a good idea to do this.

​

Debris Spawner Component

This component allows you to randomly spawn debris around the camera. If the camera moves away from the debris then it gets respawned in front of the camera, creating an infinite field of debris. This update comes with a texture asteroid model along with an infinite asteroid field example scene showing you how to use it.

Unlike the Asteroid Ring component, these debris objects use separate GameObjects, so you can add colliders and rigid bodies to them and have your spaceship mine them, etc.


Shaders In Build Window

You can access this from Component/Space Graphics Toolkit/Shaders In Build. It allows you to manually include/exclude SGT shaders from your final builds. This is useful on mobile devices if you want to keep your file size down, and loading times down.


Snap To Surface Component

I also included this example component, it allows you to lock objects to the surface of your planet. This is very useful if you want a character to walk on the surface of your planets. I also included a demo scene showing you how to create spaceship controls where the spaceship is locked to the surface of a star.




Anyway, have fun with the new update! Now that I'm happy with most of the SGT code I should hopefully be able to add new features more easily, and I'll try and get round to making more tutorial videos!

 

I updated but now get several shader errors on all shaders. it cannot open include files. Unrecognized profile specifiers. Token errors, etc.

Unity 4.1.2f1.

 

In the latest version I moved the shader files around, so to upgrade SGT you should first delete the whole 'Assets/Space Graphics Toolkit' directory, then do a fresh install. Could you try this?

I just tried installing the package in Unity 4.1.2f1, and all the scenes work fine (no warnings or errors, and everything looks good). If you still get the error then I can try uploading the package elsewhere.

 

I've been away playing with other software upgrades - it's great to come back and see another update, especially support for massive asteroid fields!

As always, great work DarkCoder!

I will be digging into this for the weekend!


...And folks, please remember unless it's a "small" update of a few files, as DC has recommended several time's it's best to totally remove SGT before installing a newer version!



-Will

 

Excellent!!

Debris Spawner : This is fantastic. Finally a decent way to generate space dust to give that feeling of motion.

Snap To Surface Component : I think i drove around the surface of the star for about 10 min straight. This will be very useful indeed. It would be cool if you could catch some air. wink wink

Truly awesome work Darkcoder

 

Yeah, there is some good stuff in this update.. nice work!

 

Hello again,

I am currently in the latest Unity4.1.2.

I have attached a copy of the project I recreated to show the error. If you open the Debug scene and then use the menu item 'DEBUG/Color Field Error' you will get an EditorWindow with a drag window inside. When you click the color field to edit the color it throws an exception. I have seen this in a similar format with CurveField as well.

I have this in a larger project and it won't even save the color information back to the color variable.

Any insight you might have will be very helpful!

Thanks,

 

I've had problems like this before. In my case, I tried to run my inspector code through a function called via reflection. This seemed to work great, except opening colour fields would throw an exception, just like your code. I would guess that your issue is the same thing, where opening the ColorField inside that function causes it to break, because it's not directly called through OnGUI. However, it doesn't look like you can work around this issue, because the Window function doesn't exactly give you any flexibility. Unity's GUI system is riddled with lots of these really obscure bugs, and I doubt they're going to get fixed anytime soon. If all else fails, then your best bet might be to make your own colour picker window. Just be warned that creating a window that edits a field in another window/inspector is a massive chore, so many things can cause it to break... I'm pretty sure I spent many many hours getting the colour gradient field in SGT to work properly across Windows and Mac.

 

If you believe this is an issue with Unity, you should (probably both of you) make sure you submit a bug report with reproducible issues.

If this is a known issue, I'm sure it's being worked on, if not, it's best to make sure that someone in development knows about the issue!

Find it? Report it! We'll stomp it.

 

Finally got through this amazing thread, and boy am I excited. Truly epic stuff so first and foremost, thank you DC for the work so far.

I read on the first page that you've added Gravity Source Gravity Receiver components, and was wondering if I could use these to allow players to walk inside ships. Didn't see anything specific in the thread as far as moving players with ships but this is one of the main features I need to implement.

 

I just bought this it looks great. The main draw for me was the snap to surface component, though the rest of it is also impressive. I'm trying to figure out the thrusters, but I'm having trouble getting them to work. I've looked at the documentation and the example scenes, but I don't understand how to assign inputs to the thruster controls.

Is there a way to define an input to control a specific thruster? I'd like to be able to something like add a thruster to a ship and assign a key to activate it.

 

No, you can't directly bind thrusters to keys. The current system works by sending the SGT_ThrusterController a request to turn around an axis, or to move linearly in some direction, and then the code will automatically determine which thrusters need to be activated to perform that action.

If you want to have full control over which thrusters get activated when you press various keys, then you'll have to write your own thruster controller.

For example:

Code (csharp):

1. public class MyThrusterController : MonoBehaviour
2. {
3.     public SGT_Thruster[] MainThrusters;
4.     public SGT_Thruster LeftThruster;
5.     public SGT_Thruster RightThruster;
6.    
7.     void Update()
8.     {
9.         if (MainThrusters != null)
10.         {
11.             foreach (var thruster in MainThrusters)
12.             {
13.                 MainThruster.ThrusterThrottle = Input.GetKey(KeyCode.UpArrow) ? 1.0f : 0.0f;
14.             }
15.         }
16.        
17.         if (LeftThruster != null)
18.         {
19.             LeftThruster.ThrusterThrottle = Input.GetKey(KeyCode.LeftArrow) ? 1.0f : 0.0f;
20.         }
21.        
22.         if (RightThruster != null)
23.         {
24.             RightThruster.ThrusterThrottle = Input.GetKey(KeyCode.RightArrow) ? 1.0f : 0.0f;
25.         }
26.     }
27. }

Just drop this code onto your spaceship and in the inspector you can assign thrusters into the MainThrusters array, and assign left/right thrusters. Adding your own thrusters and keys to this should be pretty easy.

You could also modify the existing thruster controller, but it would be far much more work, because of the custom inspector, and because I decoupled the thruster controller from the actual user inputs. Let me know if you have any more questions about this.

 

I'll try it out. Thanks!

 

Really very interested in purchasing this package, where can I read up on what exact functions are provided for working with gravity? I'd love to have ships affected by planetary gravity, as well as setting up artificial gravity on ships that can be turned on and off.

 

The gravity components are pretty simple. The Gravity Receiver component just looks for nearby gravity sources and applies forces to the rigid body. The Gravity Source component allows you to specify the min/max radii of the gravity well, and the falloff model between these distances (i.e. how powerful gravity is depending on where in the well you are). This isn't realistic (e.g. it doesn't use rigid body mass, and the gravity has a finite range), but it allows you to tweak the gravity much more easily.

There's currently no way to create in-ship gravity because I didn't even think about it, but I imagine it's not too difficult to do on its own. The main problem is that things inside the ship (e.g. characters and boxes) would need to be locked to the spaceship. If you don't do this then linear/rotational acceleration will cause everything inside to fly around and hit walls, even with ship gravity. Locking stuff to the spaceship's changes in velocity is probably fairly easy to do, but I highly suspect you'd still end up up with issues with floating point precision. I'll have a play around and see if it's doable.

 

I thought the 'static dummy' approach of having a ship outside the scene with normal gravity and no movement controlling a 'dummy' player on the actual moving ship might work. Problem is how to transition from the inside of the ship to the outside (space or planet). Walking the ship's hull is also an important feature for me... so all in all quite a few bits to figure out!

 

Can anyone recommend a tool or process to create appealing planet texture maps in appropriate projections to use with this kit?

 

This is such an incredible art pack, but after using it for a month, I've started having trouble with layers. I've got several cameras with culling masks, so they render different Earth spheres (based on distance from the surface). This worked fine for a couple of weeks, but now the Earth GOs seem to be losing their layer assignment. They still show the correct layer in the layer pulldown, but the cameras do not respect those layers -- they render none or the wrong Earth GO. For awhile, I could fix it by re-assigning the layer to each one, but now even that doesn't work. I'm using Unity 4.1 (and come to think of it, the problem started after I upgraded from 4.01). Any suggestions?

 

Oops, you're right. I don't actually seem to be setting the layer for the planet objects >_<

I just submitted the fix to the asset store, but if you can't wait then replace the SGT_Mesh.cs file with THIS.

 

Thanks for the fix! But now I get this error on all those planet (and starfield) objects:

UnityException: GameObject has undefined tag!
SGT_Mesh.Update () (at Assets/SpaceGraphicsToolkit/Required/Scripts/Library/SGT_Mesh.cs:225)
SGT_MultiMesh.Update () (at Assets/SpaceGraphicsToolkit/Required/Scripts/Library/SGT_MultiMesh.cs:314)
SGT_Starfield.LateUpdate () (at Assets/SpaceGraphicsToolkit/Required/Scripts/Player/SGT_Starfield_Messages.cs:47)


I tried assigning a tag, but the errors still appear.

 

Does this error still occur if you update SGT to the latest version? If you just replace SGT_mesh.cs then it's likely your object's tags will be set to null (something I didn't think about, sorry) thus causing this error.

 

Thanks, that got rid of the error.

But now, with the update, SGT_Planet.LateUpdate is taking up huge percentages of the CPU. How can I stop that?

 

These CPU issues weren't there with the previous update? I don't imagine the new additions would cause that much of a change :/

Also, could you upload the image to imgur or somewhere? The forum attachments are terrible at best.

 

It was at 60% of CPU during one run-through; now it's more like 20%. I tried a pre-upgrade copy of the project, and it's the same there. I guess I just hadn't noticed until it spiked. But it's using this CPU even when the camera is not rendering the planet (due to culling layers). Is there a way to prevent that, without disabling the planet?

 

Possibly, but it depends which part of the planet class is eating up the CPU. Can you give more details about your scene? e.g. how many planets do you have? Are they using the sphere or cube configuration? Are they using the surface tessellator component? Do they have colliders? Have you run your game using the profiler (especially with deep profiling enabled)?

My guess is that the slowdown comes from the state checking I do inside of LateUpdate. If so, it might be possible to eliminate most of that code.

 

I actually have three Earths in the scene -- each positioned a bit differently for different cameras during a rocket launch sequence. All three use cube configuration (but only textures on a couple cubes, to reduce overall filesize). No surface tesselation, and none have colliders (at least as far as I know.)

Here is a screenshot of the deep profiler. (When I disable two of the Earths, the LateUpdate CPU usage drops to about 22% -- more than that Earth was using when the other two were enabled.)

 

Interesting, there are quite a lot of things in these functions that can be optimized. But it's getting a bit late here, so I'll see what I can come up with tomorrow.

 

That'd be terrific -- and not a huge rush, just glad to know it can be improved soon.

 

I'm also having trouble with starfield layers and camera culling -- should that be working in this update?

 

Yeah it should be working, I just checked the code and I don't see anything wrong with it. Make sure you set the starfield's Observer field to the camera that's currently rendering it, because the starfield mesh will be stretched to the far culling distance of the selected camera. If it's still broken then can you package/describe a scene that shows a situation where it would break?

 

Never mind. I had not changed the camera's Clear Flags to Solid Color. Works now!

 

Darkcoder: was just wondering when you plan on putting out V3? no rush or anything..

 

I'm not sure, but I'll probably just focus on adding lots of smaller features in lots of small updates, rather than lots of features in one large update (like Version 2).

The main reason why I haven't announced/released many new features is because I'm working on my next asset store product, which should be ready fairly soon. However, any bugs/issues with SGT will always have a higher priority.

Is there any feature in particular that you really want to see?

 

I know the question was directed towards Xsnip3rX, but for me, I want to say that what I'd really like to see are some nebulas, but I'm not in a hurry or anything !

 

Yeah, nebulae and i would LOVE a galaxy generator (just stars, not planets or anything like that).

 

Ok I've put nebulas next on the feature list. I've already thought up a possible way to generate fairly nice ones without too much user work, so I'll see how they pan out.

What kind of galaxy? You can already generate an elliptical galaxy using the starfield component. I guess I could add some code to allow you to generate spiral galaxies, though I'm not sure how good they'd look without dust clouds.

 

Well, i'd Love to see the dedicated beam weapon system and the shields, it would actually help me finish my game lol.

 

Elliptical / Spiral / Barred Spiral I haven't tried using the system with the starfield component, I will look into it for sure! I think if you get the nebula component working, it wont' be hard to add that to the spiral galaxies on the users side!

 

Working lasers, pulse lasers, energy beams, and space "explosions" would all be great.

And the spiral galaxy mentioned.