Space Graphics Toolkit & Planets

First, there is definitely a prefab. It's a ship with thrusters. The "SpaceshipThrusters3D" demo.

Second, you haven't taken proper English into account. My statement was "amount of prerequisites and bugs" (since "bugs" is prepositional to follow the actual action verb "amount of prerequisites", the preposition "bugs" becomes non-plural).

If you'll dissect the actual statement, you'll also see that the third phrase references the first phrase, which describes why it's not mobile ready for non-programmers; the fact that its only set up for PC controls and takes more advanced knowledge of C# to understand how to get a joystick object variable to appear in the inspector. That's the part that's not mobile ready.

I will admit, after editing the custom inspectors and editors to accommodate a joystick, I too am quite happy with the asset. I think I was expecting it to be drag and drop ready for mobile. I should make an edit on my earlier comment as well that the other kit doesn't have the Gravity, Orbit, etc. that this one supplies, nor the graphics quality, so we can assume my previous post to be moot.

Edit2:
Removing the previous version prefab from the demo scene and reimporting solved the errors. The problem was sharedassets metadata I assume. It was creating a Flame and Flare child under each Thruster Parent at runtime which 2.7.5 does not.
Thanks for the support.

 

Seriously? .. seems your trying to be difficult..

I could never get the thrusters to work...sort of put it on the back burner for a bit while I work on other things..

 

The demo scenes that come with SGT are mainly there just to show you what graphical effects can be achieved using the components. As such, the support components (e.g. controls) weren't designed to be used in any actual game, which is why they don't have any advanced settings, don't listen to touch inputs, etc. But core components (i.e. all the graphical stuff) were designed to work well with mobile devices, and to my knowledge they all do.

If you take a look at the 3D thruster control script for example, I believe I laid it out incredibly simply:

Code (csharp):

1.     public void Update()
2.     {
3.         if (ThrusterController != null)
4.         {
5.             // You must call this before applying a new burn
6.             ThrusterController.ResetAllThrusters();
7.            
8.             // Move Forwards
9.             ThrusterController.ThrusterLinearBurn(Vector3.forward, Input.GetAxis("Jump"), Space.Self);
10.            
11.             // Yaw
12.             ThrusterController.ThrusterAngularBurn(Vector3.up, Input.GetAxis("Horizontal"), Space.Self);
13.            
14.             // Pitch
15.             ThrusterController.ThrusterAngularBurn(Vector3.right, Input.GetAxis("Vertical"), Space.Self);
16.            
17.             // Roll
18.             //ThrusterController.ThrusterAngularBurn(Vector3.forward, Input.GetAxis("Some Other Axis"), Space.Self);
19.         }
20.     }

As you can see, I designed it so that the user can easily modify this to get the control setup they want. I wouldn't really call this advanced C#, but if adding touch controls to such a script is difficult, then maybe they could get a touch gesture script/asset that should hopefully be rather trivial to use (i.e. just replacing the Input.GetAxis("...") with whatever they need.

Start by adding a child GameObject called 'Thruster' to your main spaceship, add the SGT_Thruster component to it, and follow the pdf documentation for how to set it up (make sure you slide the Throttle value so you can see it working). Then copy paste the thruster around your ship until you're happy. Then add the SGT_ThrusterController component to your spaceship and click the 'Find In Children' button, or manually drag and drop all your thrusters into that component (you can hit the Min/Max throttle buttons to check if they're working). Now you just need to bind some controls to the Thruster Controller, for example the SGT_3DSpaceshipController script and you're good to go.

The SpaceshipThrusters3D scene shows you what you'd end up with if you correctly did what I just described.

 

Is this part of a script from Star Trek. Sounds like something that Mr. Spock would say.

 

I was wondering if there might be a technique someone could suggest to create a volumetric "dust" effect within a planetary ring? The idea being that you'd have asteroids (I know that's not the correct astronomical term for rocks orbiting a planet, but please bear with me here) in the rings, but to give it some real "body", also have a sort of volumetric dust effect in the same area. I envision rendering similar to what we see with the gas giant. It would fall off above and below the plane of the ring, and could have stripes of different colors running through it in concentric rings. This would give a major visual quality boost to planetary rings, especially if your perspective is inside of one. I tried oblating a gas giant down really, really flat, then expanded its radius to occupy the rings, and it looked pretty close to what I had in mind (of course, it didn't have a hole in the middle, so that's a problem). So I was just wondering if something like this is possible by either using some kind of volume fog shader, or by perhaps re-purposing the gas giant rendering technique to apply to a sort of ring? Any ideas?

 

Making an effect like this would require a lot of changes to the ring component and its shader, but I imagine the code would look similar to the gas giant code. The real challenge is finding the optical depth/thickness between the ring vertex and the camera position. For a sphere (e.g. gas giant) this isn't too difficult, but for a torus or tube it's considerably harder, and packing it efficiently into a shader is even more challenging. There might be an approximation that gives good enough results, but it'd probably require a lot of research and testing, so I'll leave it until I've finished off the core features of Version 3 before I attempt this.

One workaround that's fairly easy to implement though is to find the position of the camera relative to the ring, and if it's inside then you could spawn in dust/fog to give the illusion of being inside the ring. This would also be considerably more efficient than any 'correct' solution.

 

Does anyone have performance problems with SGT_Dust component on mobile?
I tried to use one from the example (Orange bits) and it works very good - constantly locked on 30FPS.
When I add second dust component (Green clouds) - everything falls down below 10 FPS. Tested on very good Android and iOS devices.
It seems strange, as both of those components are similar, settings are the same (range, count etc.) and the difference is huge.
Any clue what may be wrong?

 

These components are very expensive in terms of fillrate. If you replace the dust texture with a white square then you can see how much of the screen the particles are taking up, so if you have many particles that take up the whole screen you will encounter fillrate issues depending on the GPU. The dust example scenes were designed for desktop devices so I bumped up the particle sizes so it looks good on very high resolution displays. On mobile devices you will have to reduce the particle size, reduce the particle count, or space them out more to reduce the fillrate hit until the performance is what you're after. The fillrate performance of every GPU differs widely so it's hard to say what kind of settings you'd need, but if you use a white particle texture then you should generally be able to see the fillrate usage and tweak the settings until you don't get too much layering of large particles.

Right now the dust particles are positioned randomly, so one optimization would be to place them more uniformly. This would help to reduce the fillrate hit by keeping it more consistent. If you're familiar with C# then you can find the code at line 355-367 of SGT_Dust.cs. Right now it picks a random spot between 0..1 on all 3 axes. A simple way to make it uniform would be to make 3 separate loops for each axis and plot the dust particle in the grid cell, perhaps adding some noise to break the uniformity a bit.

 

Hello again,

I'm really curious how I can create custom nebulas within my scene ( I Currently have a starfield going on ) but it is too simple for my game, I need nebulas (and pretty please add the option for galaxies?)
So my question is how can I add nebulas, also what should be the max (this is for mobile ios + android)
As well as, pretty please add galaxies ? so we can truly make a cool looking space scenary.

Also, how bad will it be to have planets within the mobile game, will mobiles still handle it ?

thanks appreciated.

 

In the latest version I added nebulas and the elliptical galaxy starfield pattern. You can combine these to create a fairly convincing galaxy (just look at the picture on the first post).

To set up a nebula you should first look at the 'Nebulae' example scene that comes with SGT and see how I set up the 'Spike Galaxy' GameObject. As you can see, the Nebula Texture field contains a texture that looks like a galaxy, and if you play around with the nebula settings then you can get the particles looking as high/low detail as you want. I then set up a starfield on the same GameObject with similar radius settings, but I make sure to set the Distribution to Elliptical Galaxy, and leave In Background unchecked.

 

Oh i didnt even realize you updated this asset !

Awesome thanks,

another question is;

how come when I make the radius on the starfield higher than 150 my camera does no longer render it,

I basically need the stars to be there constantly , but also the player not to reach it (so i was trying to up the radius)

thanks

i got the other space tool and was wondering if you have any experience with it, I'm just curious in the way he does the nebulas / galaxies with the navmeshes, is it more efficient or less?

 

Maybe you need to increase your camera's Far Clipping Plane? Also, if you check the In Background setting in the starfield then you shouldn't have to play with the radius, as it will always be unreachable. Quite a few of the example scenes feature background stars so you could just take a look at their settings if you can't get it to work.

Also, I missed your earlier question about mobiles: Planets should work fine, I optimized it so that you can get one close up planet with atmospheric scattering working nicely on 3GS/4S+, so if your game has planets that don't take up the whole screen then it should run even faster.

 

Amazing,

thank you very much ! If I could rate you on the asset store I would do so again,

simply amazing.

This is a must buy asset even for those who wont use it

Thanks for the answers, I will be sure to play around with the new update now and create an awesome space scene looking

1 last question hopefully for this week is, if I wanted to have multiple spaces, for example going from 1 "space" to another, by player reaching / advancing in the level, and having a smooth transformation from space 1 to space 2, (background stuff) such as starfield, nebulas and galaxies, how would I achieve this?

thanks again.

v2.7.5 is the latest?

 

The easiest way to do this is to load the next level in a different place in the same scene and 'warp' the camera to the new area, then delete the old area. However, none of the example scenes do this, so I can't point you to an example. It shouldn't be too hard to do, but it would require some scripting to handle the load/unload and transition.

Yes, 2.7.5 is the latest.

 

Thanks a lot for the answers,

okay so now here's a bump im running into;

I'm trying to use the nebulas (from the space unity asset) that i've purchased with the scripts you have (so i change the nebula texture to advanced read + write etc.) however unity gives me a bunch of errors and it doesn't work,

can you please explain how we can create our own nebulas (from other textures) as I read the documentation and it jut explains of all the options etc.

maybe I am just doing something wrong,

let me know if I should remove the other asset's name ? or if it doesn't bother you I will use that as a reference.

I'm trying to accomplish an awesome space scene with many nebulas (about 7 - 12 to populate the whole scene...) / galaxies (not necessarily as few, just for eye candy) and ( a sun) + a starfield...

thank you

 

What kind of errors does it give? As long as you enable read/write and set the format to something that can be read from (e.g. Automatic Truecolor) then it should work fine. What happens if you just replace the texture on one of the example nebulas? Also keep in mind that setting the nebula resolution values too high will give some errors. I'll fix this in a future version.

 

Thats what I do, i actually used your example nebulas and just dragged the textures from the mention above,

and unity basically freezes

and gives many errors;

(21:37:16.7603)
Error:
Unsupported texture format - needs to be ARGB32, RGBA32, BGRA32, RGB24, Alpha8 or DXT

StackTrace:
UnityEngine.Texture2D.GetPixelBilinear()
None: line 0
SGT_Nebula.Regenerate()
SpaceGraphicsToolkit/Required/Scripts/Player/SGT_Nebula.cs: line 539
SGT_Nebula.LateUpdate()
SpaceGraphicsToolkit/Required/Scripts/Player/SGT_Nebula.cs: line 483

 

Did you try changing the texture format to one mentioned by the error?

 

Ah i see, thanks

well, I'm not sure maybe its just me but I cannot get nice nebulas going on... hopefully in the future this part improves or if you can create a short video tutorial of the process that would be great.

thanks, keep up the good work, amazing asset.

 

Hi Darkcoder. I'm really enjoying using this asset-- amazing work. It is stunning to be able to do things like orbit past the Earth, watch it go dark, then have the sun burst out from the other side!

A couple of questions:
1) The stas and nebula look great but I notice that the skysphere backdrops look noticeably pixelated. I tried the high res assets and highest poly skysphere, but I'm wondering if this is just the way it is or if I've somehow set it up wrong.

2) About the SGT_Surface Tesselator: Is there a way to increase the granularity of planet terrain so that there's more variation in mesh topography? I'm experimenting with a 50,000 unit size cubic planet, resolution 8, LOD 15, 10k vertices per mesh, but still getting really angular, artificial looking mountains.

3) Can trees and foliage shaders be used on the planet? Or anything like Relief Terrain Pack?

4) Can you suggest any direction to go in terms of trying to add more realistic oceans? Right now it looks good from space but flying down to the planet you see patches of ocean painted up the sides of mountains. I was thinking something similar to how you do the clouds but of course saw z-fighting issues when I experimented with pulling the clouds into the terrain just to watch how it renders. I read that the Planetary Terrain package uses a sphere with a separate camera, but I'm not versed enough yet in Unity to get how that might work and think I read that SGT can only use 1 camera.

5) About varying the planets: Since the Surface Tesselator and SGT Planet require bitmaps I was wondering if you could suggest anything in the direction of creating randomized planets. I have Numberflow and am experimenting with procedural textures, but I think this might be too slow. I was also thinking about something like Bitmap2Material, which can generate the normal, specular, etc. and maybe trying to feed SGT the image stuff at runtime, but this might be way off base.

6) It's probably way beyond the scope of the kit, but I was wondering if you had any idea of the best way to try to spawn game objects (like enemies or animals) on the terrain as it's created. I'm not sure where to even start, but I imagine you'd have to somehow define zones that would be activated and deactivated, then somehow account for placing the objects on the terrain. I was considering whether something like SECTR might help here.

Thanks for any thoughts on these. I'm mostly curious about how to approximate large, randomized planets but I see from reading previous pages in the thread and following posts from others here that there are significant factors to consider, like scaling and floating point precision. It may be smarter to fake large planets by stitching terrains together and use SGT where it's probably the strongest-- in space!

 

The skysphere component was something I just wrote for fun, because out of the box Unity only does skybox rendering. If you're noticing pixelation then either the skysphere texture isn't high enough resolution, or you're noticing the extreme polar distortion. In a serious project I wouldn't really advise using sky spheres/boxes for much other than things like nebulas that don't require much graphical detail, because you will notice the pixelation at any resolution. If you need some high detail stuff in the back then I suggest you just stick that particular thing (e.g. a galaxy texture) on a quad.

You could add more LOD levels to remove the jaggedness, but this would only smooth out your terrain. The reason why it does this is because there's no extra detail to sample from. In a future version I plan to expand this component, perhaps this extra detail could be read from a detail map, or some sort of procedural generation, but right now there isn't too much you can do without editing the component yourself.

I have no idea how the Relief Terrain Pack works, but if you want to snap something to the surface of a planet or star then you can use the SGT_SnapToSurface component, which will calculate the required height at a specific point. You can see how this might be used in the 'SpaceshipOnSurface' example scene, though you might want to tweak the component so it only positions your trees once, to avoid the overhead of doing it every frame.

Drawing water on a planet is probably one of the trickiest challenges with planet rendering, which is why I haven't gotten around to doing a more complete component for it (e.g. Spore like oceans). If you place a sphere with a water shader on top of your planet then you can get good ocean going, but as you will soon notice there are many issues with this, like z-fighting, no shores, no ocean depth based colours, etc. But if your scene only has a few planets then you might be able to essentially hand build each of these elements. I will explore this more in version 3 of SGT, because it's something I really want to write.

It's possible to procedurally generate the planet textures and then feed them to SGT, but indeed there would be some delay while the planet textures are generated. If you can somehow hide the generation delay behind a loading screen, or warp sequence, then you should be able to do it. While I haven't experimented with procedural planet texture generation myself, I have seen many articles and such with lots of info on it. I would personally begin with 3D simplex noise samples and spend ages finding good ways to combine them together to make something usable. But from what I've seen, you need some really heavy duty algorithms to get planets that don't look like they're from a 1970's sci-fi film.

One way I might do it is to create a spawn map (basically a heightmap, but each pixel represents a thing to spawn), then find the player's height above ground level (check out SGT_SnapToSurface.cs to see how this can be done), and if it's below a certain value then I know I must spawn stuff. I then find the spawn map's UV coordinate below the player (again can be found in that script) and read the colour. If the colour is something say RGB1,0,0, then I know I have to spawn some trees, or whatever.

That's the most efficient and simple way I can think of off the top of my head, but it would require a lot of tweaking to get it working right.

Yes, it's easy to forget that engines like Space Engine/Infinity/etc were written from scratch with planetary rendering in mind, whereas Unity wasn't, so emulating some of the stuff they do is incredibly tricky without full knowledge of all the consequences. But in the future I do hope to expand on many of the things you mentioned. I hope I helped

 

I have come to this conclusion too....pretty much..

Use SGT planets or planetary terrain planets or Etherea1 planets or atmospheric scattering or some other planet shader ... fake atmospheric transition(trigger map switch after entering the atmosphere) from space to the ground of an unlimited terrain map..

Seems to be the best way with Unity Engine..

Sure I can get characters to walk on a planet surface with SGT planets, Planetary Terrain planets, and Etherea1 Planets but getting things working on those planet surfaces PROPERLY without issues seems to be a challenge..

Like a weather system/cycle, building placement,trees,grass,rocks,rivers, enemy NPC's, animals ETC..

 

Hi there, probably a stupid question but i cannot see any mention on the asset store or in your opening post re API usage.

I mostly would want to use this to generate random solar systems, all from code using seed numbers, is this something that is possible with your toolkit?

is there an abstracted API layer or would i have to loop through generating planets and assigning everything at the game object component level?


cheers!

 

A really big thanks Darkcoder, your reply was immeasurably valuable in helping me pick a direction. I'm starting to realize what a truly MASSIVE amount of work planets are. I could dig into the SGT Planet code and maybe with a lot of study get a little better than the 70s planets (haha), but I'm honestly a lot more interested in working on the interactivity of the environment. I think I'll explore more in terms of passably varying the planets from space, maybe seeing if it's possible to merge hand drawn continent textures at runtime and feed these to SGT, then cutscene to terrains for the surface.

I'd be very interested in what you come up with for 3.0. Honestly, given the amount of work, it'd be more than fair to maybe have a separate SGT Planets kit. I'd definitely be in line to buy it if I could get the planets big enough. (Considering all the issues with how floating point precision limits scale, what do you think about some system where the player controller at the zero origin and the planet rotates beneath them?)

 

Hey BES. Thanks for the feedback, I've actually seen a lot of your posts on this subject. I think we're both aiming for similar game experiences, namely with huge or unlimited terrains. Your challenges with things like voxel terrain and water with the PT kit helped spare me from stumbling down some blind alleys, as I really want to focus on the whole planetary adventure element and interacting with the environment.

I'm now looking at stitching together terrains at runtime, but my main concern would be variation. I'd hate to see the same mountain or canyon planet after planet. Deforming terrain is possible, but would potentially be slow. A friend suggested the idea of mixing and matching smaller chunks of terrain, sort of like terrain tiles in a 2D game, but I'd have to investigate how evil that would be in terms of combinatorics (2D can get ugly, but maybe 3D might be easier with good stitching and height blending at the edges, though I'm still finding my legs with Unity and can't say for sure).

Have you tried anything like this in the direction of infinite terrain? I've done it with endless 2d maps by keeping the player at the zero origin. Maybe something similar (or warping the player as they cross zones) would work so that your coordinates don't get too high.

 

Not really, but Currently I am attempting to use "Real World Terrain" with "
Sectr Complete" to "link" terrain pieces together for an unlimited terrain..

If that don't work I will try "Terrain Composer" ... terrain composer is cool ..but it seems overly complicated .. so I have been avoiding using it.

The last one I will try is "World Composer" it is pretty much the same as "Real World Terrain" but a different publisher(same publisher of Terrain Composer, but I bet you knew that already)..

After I figure out what terrain method I will use that works well enough and looks realistic enough to be used for my purposes I will attempt to take a top view screenshot of that terrain ..as far out as possible so I can use it with an SGT Planet... so the terrain matches with how the planet looks from space..

 

Sorry, didn't notice this comment earlier.

To procedurally generate stuff in SGT you have to copy all of the steps you would normally take in the inspector, but instead do it from code. Most of the property and method names should be very similar/identical to the ones in the inspector, so it should be easy enough to use. I also include a demo scene showing you how you might set up a star system completely from code. Just keep in mind that there are no features to automatically generate planet/ring/nebula/etc textures, the settings are basically for the materials, GameObject positions, scales, etc, which get calculated within the components.

The majority of the changes for Version 3 are updating the library to make better use of Unity's new features. For example: Unity 4.2 introduced property drawers, which will make the inspector code 1000x easier for me to manage. But property drawers only work on serialized fields, so to take advantage of this I have to redesign the components to not be hidden behind so many properties. Also, right now the atmosphere code is set up so the surface uses a custom planet surface shader with atmosphere. This great for performance on mobile devices, but it means you can't easily switch the surface shader to something more complex.

This may work fine for small demo scenes, but as soon as you add mesh colliders and physics, you have big issues. I believe the best method is to just shift the scene around the camera based on a grid, so if the camera goes outside of a 10km or whatever box then everything snaps in the opposite direction. But even this would cause massive issues with any script that stores world positions, and for really large scenes you would have to store a separate coordinate system for every object so that their position doesn't degrade if the camera moves too far away. So ultimately maintaining a system like this would require both programming skill, and a good idea of how the system works. If a user has both of these then they could just implement the system themselves.

 

thanks for the response!

cheers mate

 

I think I am going to use streaming to fix this...

Pretty much stream scenes together, loading screens will be gone, each scene will be small, but big enough to at least have 1 planet(20,000-30,000ish in size) with a few moons and other tidbits..make sure each scene is saved before moving to the next..

Flying through space should be simple too using the same setup.

 

That's an very interesting approach as it seems you'd get a nice correspondence between the visual look of the planet in space and being able to visit specific features. It seems like a huge amount of work, though, unless you can screenshot just points of interest and blend these into more generic environments (say, a water planet with several islands, or any other monolithic environment like desert or grass)

 

Yeah I was reading up a bit more on this, seeing that games like Kerbal Space Program uses their own relative coordinate system to manage object positions along with dedicated cameras to show distance objects. It's a lot of work.

If I can figure out how to get varied textures onto SGT Planets I think I'm content with using it just for space. I was hopeful that I could use the cubic meshes and generate textures but whether I try noise or combine hand drawn parts of continents at runtime it's going to be slow. So far I don't see another way, so the trade off may be really nice looking planets from satellite or hand drawn images which don't vary much (not good for an open universe game) or somehow hiding the load times.

 

Well I did mention that you could try streaming... something like this: https://www.assetstore.unity3d.com/#/content/15356

Basically it breaks down everything in the whole scene into stream-able objects to reduce or get rid of all loading screens ...I am going to try to use it for planets and space travel to stream all the scenes together..

Right now though I am trying it with some terrain maps...after World Composer is done making the tiles..

 

I am loving the look of this kit and the potential is amazing but I am having difficulty just making a spaceship prefab fly through my environment!!

I am finding the thrusters too complicated to implement and too cumbersome to use.

I feel there really must be a better way.... a compromise between real space physics, ease of implementation and fun playability would be awesome.

Can you give me some advice on having a system, based to some extent on physics but one that doesn't take dozens of careful manoeuvres with thrusters to actually travel around the beautiful environment you have made it possible for me to build.

I don't want just a total airplane type experience but something not quite as realistically simulated and hard to implement as your thrusters would make this kit just so incredibly awesome to produce fun games with.... just a simple starship controller that would drift and bank and move fluidly and easily where a player was wanting to go would be an amazing companion to this kit.

I am hoping that I get some real advice and not just get shot down over this. I am very new to Unity but quite eager to learn more about it and to start producing some fun and playable projects.

Many thanks
MangeyD

 

SGT Thrusters are made to simulate (more or less) the behaviour of space vehicle in vacuum and no gravity. And they do it very well. I agree that they are a bit hard to use, but this is a minor problem.
If you want to simplify it a bit, I'd recommend adding some drag/angular drag to your rigidbody - you'll avoid the behaviour of constant movement and rotation (just like in atmosphere). But tuning force and drag you may achieve quite a natural look with a bit of "arcade" feel. And it would be a little easier to steer.

 

If you don't want realistic physics then you need to disable the force aspect of the SGT thrusters so that they only provide visual feedback, then you need to write a spaceship controller that directly sets the spaceship's rotation and velocity. This can be done very easily, for example:

Code (csharp):

1. using UnityEngine;
2.  
3. public class SimpleSpaceshipController : MonoBehaviour
4. {
5.     public Rigidbody Spaceship;
6.    
7.     public float TurnSpeed = 100.0f;
8.    
9.     public float MoveSpeed = 100.0f;
10.    
11.     protected virtual void FixedUpdate()
12.     {
13.         if (Spaceship != null)
14.         {
15.             Spaceship.AddRelativeTorque(0.0f, Input.GetAxis("Horizontal") * TurnSpeed * Time.fixedDeltaTime, 0.0f);
16.            
17.             Spaceship.AddRelativeTorque(Input.GetAxis("Vertical") * TurnSpeed * Time.fixedDeltaTime, 0.0f, 0.0f);
18.            
19.             Spaceship.AddRelativeForce(0.0f, 0.0f, Input.GetAxis("Jump") * MoveSpeed * Time.fixedDeltaTime);
20.         }
21.     }
22. }

If you apply this script to a spaceship with Drag values of 3.0 or so, and adjust the speed to suit your game scale, you end up with a very easy to control spaceship. If you couple this with a SGT_ThrusterController and do the appropriate burns (as seen in SGT_3DSpaceshipController.cs) then you can also get the visual thrusters firing nicely.

 

Thanks so much for the two replies above. It is late here now so I won't get to play with this until tomorrow but hopefully I can get something going when I do.

thanks for such a quick response.

 

The tips on changing drag and angular drag settings have actually made enough of a difference to the way he thrusters handle so I thnk I will keep them. I have pasted the controller and spaceship from the demo into my environment and that is going well... so now all I need to do is use my ship and tweak the thrusters around and it should be good.

Thanks again for the timely responses.

 

I am still having trouble with the thrusters.

I can make the spaceship from the 3D thrusters demo handle well, however when I substitute other spaceship models the main thrusters do not do what they should. All of the other thrusters appear to work as they do with the demo model, however I get a variety of different results with other models.

2 models I have used both have other thrusters engage when I use the space bar and they rotate horizontally instead of moving forward.... and the main thrusters appear to be rotated but changing their rotation setting does not help.

I am hoping you have some tips for how to apply the thrusters to a spaceship model and hopefully you may also know what I need to do to have other models behaving like the demo model does.

Thanks

 

The way the thruster firing works is by checking if the thruster points more-or-less (within 30~ degrees) in the direction you want to go.

For example: If your thruster points downwards (i.e. a local direction of 0,-1,0), then calling

Code (csharp):

1. ThrusterController.ThrusterLinearBurn(Vector3.up, 1.0f, Space.Self);

will not do anything, because the burn direction is 180 degrees out from the thruster, but if you use:

Code (csharp):

1. ThrusterController.ThrusterLinearBurn( - Vector3.up, 1.0f, Space.Self);

then the thruster will fire, because the burn lines up with the thrusters.

The same thing happens with angular burns, except instead of just comparing directions, it checks to see if the thruster is pointing in the right direction relative to where it's placed on the spaceship. For example:



Here we have the front view of a spaceship, so we can see the XY plane. If we want to roll the ship, then we need to apply a burn along the Z axis (XY plane), so I use a simple torque calculation to find which thrusters are pointing in the right direction for the burn we want.

The downside to using such a simple calculation is that it may not work well for complex spaceship designs (e.g. asymmetrical ones). There's also no code in there to balance the thruster power, so it's quite easy to produce burns that cause the ship to spiral out of control.

If the provided Thruster Controller isn't working well for you, then perhaps it would be better to write a custom one that fires the exact thrusters you want. Writing your own thruster controller is very simple, because all it does is set the Throttle value of all the thrusters between 0..1, but writing a more advanced one will probably be more difficult.

 

I'm having an odd problem where my corona flashes as my star rotates. I set it up pretty much like one of the example files, and I tried playing with most of the settings to see if anything affected it, but can't figure it out. This is what I'm seeing (as I spin it back and forth to show the flash and when it happens):

 

Nice find, it seems there's a small bug in the corona offset code. If you open SpaceGraphicsToolkit/Required/Scripts/Player/SGT_Corona.cs and find line 70:

Code (csharp):

1. SGT_Helper.SetLocalPosition(coronaGameObject.transform, observerDirection * coronaOffset);

and replace it with:

Code (csharp):

1. SGT_Helper.SetPosition(coronaGameObject.transform, observerDirection * coronaOffset);

it should work as expected. Basically it's flickering because Unity's changing the draw order between these two transparent objects. I added the Offset setting to the SGT_Corona component so you can force the corona to draw in front or behind the atmosphere, but I was setting the offset in the wrong coordinate space.

 

That worked! Thanks!

 

Please help fix Errors in console

Assets/SpaceGraphicsToolkit/Required/Scripts/Player/SGT_Skysphere_Messages.cs(39,87): warning CS0618: `UnityEngine.Camera.far' is obsolete: `use Camera.farClipPlane instead.'

Assets/SpaceGraphicsToolkit/Required/Scripts/Player/SGT_Starfield.cs(60,101): warning CS0618: `UnityEngine.Camera.far' is obsolete: `use Camera.farClipPlane instead.'

Assets/SpaceGraphicsToolkit/Required/Scripts/Editor/SGT_Inspector.cs(86,30): warning CS0618: `UnityEditor.Undo.SetSnapshotTarget(UnityEngine.Object[], string)' is obsolete: `Use Undo.RecordObject instead'

Assets/SpaceGraphicsToolkit/Required/Scripts/Editor/SGT_Inspector.cs(87,30): warning CS0618: `UnityEditor.Undo.CreateSnapshot()' is obsolete: `Use Undo.RecordObject instead'

Assets/SpaceGraphicsToolkit/Required/Scripts/Editor/SGT_Inspector.cs(100,38): warning CS0618: `UnityEditor.Undo.RegisterSnapshot()' is obsolete: `Use Undo.RecordObject instead'

 

Are you using the latest version of SGT? Also, what version of Unity are you using?

 

I`m using modified version 2.7.2 unity 4.3.4

 

There are inconsistent line endings in the 'Assets/SpaceGraphicsToolkit/Required/Scripts/Player/SGT_Skysphere_Messages.cs' script. Some are Mac OS X (UNIX) and some are Windows.
This might lead to incorrect line numbers in stacktraces and compiler errors. Many text editors can fix this using Convert Line Endings menu commands.

 

I'm pretty sure I fixed these errors in 2.7.4. Perhaps you could separately download the latest version and copy the relevant code until it works, or diff the changes.

All the code was developed in monodevelop in Windows so the line endings should be consistent, but monodevelop is a bit crap so perhaps I messed up on some of the files.

 

Hi DarkCoder,

My project requires me to upgrade to take advantage of Unity 4.5.0's features and bugfixes. However, I've run into a snag. I use SGT 2.0/2.5 code and shaders and Unity 4.5's new shader compiler doesn't like them. If Unity could tell me what errors are preventing compilation that would be great, but it merely gives me malloc errors on every shader (after being stuck for a very long time with several UnityShaderCompiler processes open). This is true whether I upgrade from a 4.3.4 project or import a fresh SGT into an empty 4.5.0 project (although with a fresh project, the errors don't manifest themselves until a build is attempted, for Windows standalone in this case). However, SGT 2.7.5 works just fine.

It's a bit scary to me to think I need to upgrade to the latest SGT when so much has been built around it, but I am curious if you had any insight into the differences between the shaders of the older SGT version and the latest one, and why Unity 4.5 would have a problem with it? If not, that's fine. I know it's an old version.

Thanks!

 

Strange, I'm pretty sure I haven't touched some of the shaders since the first few version 2 releases. I'll check it out tomorrow after I get back.

 

I had the same issue, shaders from an older version of SGT (about a year old, not sure?). It was odd, the shaders would fail to build and take ~1 hour+ trying to build with only malloc errors to go on at the end of it. I'm pleased to say that for me too the latest version of Space Graphics Toolkit works fine with Unity 4.5. All good now.