Space Graphics Toolkit & Planets

I just purchased SGT after eyeing it for a while. I know I will not be able to dedicate myself to the related project anytime soon, but I'll be at least playing with it and I really wanted to support this asset. I like the way and expertize Darkcoder handled it until now so consider this my vote of confidence to motivate you and keep working on it as planned (v1.1 and beyond). You have a great asset hopefully you'll be able to push it further.

My project involves creating dynamic (procedural) universe and planet generation, hopefully I'll have more time to experiment with it and provide more of a useful feedback/questions.
Keep on the great work!

 

I see. Many thanks for the info !

I agree. Darkcoder has done an amazing job and support is great too. Bravo !

 

Quick question. I need to make some more SkySpheres for use with the SkySphere component.

How did you create those SkySpheres?

 

The ones that aren't from NASA are made in Photoshop. Basically I created several layers of clouds and blended them together and tweaked the colours. Then I distorted the image to a cylindrical (equirectangular) projection. I'm not sure if I did this within Photoshop, or if I used my friend's tool for it. You can grab his tool from HERE, basically you drop a normal image into it and it will spit out a skybox or a skysphere image, it's very useful!

 

Brilliant

Thank you. An awesome tool and I'm really looking forward to V2.

 

Any news on when V2 might be availailable?

 

Just picked this up and am looking forward to the next update already. This is really a fantastic piece of work. If I can be so bold to make two requests.. The first, Id like the echo the request a long time ago for nebula. This is something really hard to find, particularly where you can mix dark clouds around the edge of the inner lit clouds for that nice effect. Second, Id really like to be able to put a comet in the scene which tail is already extended by a certain amount on scene start instead of the standard tron tail solution that you often see. I love the fact that these work on mobile! Once again I just want to express my gratitude for such a beautiful piece of work.

 

I can't say for sure. I just came back from holiday, so there should be a lot more progress. But, some users have pointed out some compatibility issues with certain post processing effects, as well as with substance shaders. So I will have to test and hopefully get these issues resolved before the release.

Thanks. I haven't forgotten about adding nebulas, once Version 2 is out I'll probably start work on them right away, because working on these same old components all day long is pretty boring! I know what you mean about the dark clouds and how nice it can look (e.g. Infinity implementation), hopefully SGT nebulas will look half as nice.

As for the comets, that's a really good suggestion and something I didn't think of. I've added it to the list for Version 3!

 

Hello,
Does your addon supports Linear Lighting?

 

I don't know if the lighting is rendered correctly, but it seems most of the components work fine. One exception is the ring shadows, it seems the colours get inverted or something. I'll try and fix that for Version 2's release.

 

Actually if you are looking for any other ideas for v3 I would also suggest a black hole. Like a swirling vortex of cloud and debris with a burst of light shooting out from the center. Maybe this is more of an idea of a wormhole but I think you know what I mean.

 

Might be better done as a post-processing shader effect, given its theoretically lensing properties

 

Yeah, it's planned! My reference picture directory contains these images: One, Two, Three. So hopefully it will end up looking something like these.

I may make this in a future version, but there are quite a few reasons why I won't in V3, such as: I don't have Unity Pro (and this one feature doesn't really justify upgrading), this feature wouldn't work on mobiles, and I don't think many projects would find a use for this as opposed to the more artistic black holes shown above.

 

Yeah your 3rd pic is exaclty what I was thinking of. You could easily add the existing asteroid belt effect to the gass swirl and it'd look pretty epic.

 

All look awesome. Regarding the lensing, if anyone with unity pro wanted to try it, just use the post-processing shaders from MadFingers free project. Bonus- they work on mobile.

 

​

That's right, the long overdue update is finally live on the asset store. This update fixes a lot of limitations with the initial release, fixes a few bugs, and adds a few new features!

​

• Added Surface Tessellator (dynamic LOD) component.
• Added Volumetric Probe component.
• Added atmosphere meshes for better depth sorting.
• Added cube map support for planets stars.
• Added prefab support for all components.
• Added planet LUT size options.
• Added randomise button to all seed fields.
• Improved atmosphere colour blending.
• Improved substance material support.
• Fixed planet/star atmosphere mesh orientation.
• Fixed per-pixel specular on planets.
• Fixed Direct3D 11 shader warnings.
• All classes are now prefixed with SGT_.
• All class fields now match inspector field names.
• All documentation rewritten.

​

Due to the massive component class changes, your SGT Version 1 scenes will NOT Be Compatible with Version 2. This means that you will have to delete your existing game objects that use SGT components, and make them again.

If you don't want to delete the whole object, then I advise you delete the SGT components before you upgrade, upgrade, then add them again. If you delete the components after you upgrade, then it's very likely you will end up with planet surface meshes that don't get removed from the scene and are invisible (because by default, SGT hides the game objects it creates). If you do happen to do this, then you need to use a script to unhide them, such as this:

ExposeHierarchy.cs

Code (csharp):

1.  
2. // Create and put this in ExposeHierarchy.cs
3. using UnityEngine;
4. using UnityEditor;
5.  
6. public class ExposeHierarchy : EditorWindow
7. {
8.     [MenuItem("GameObject/Expose Hierarchy")]
9.     public static void ExposeSelection()
10.     {
11.         var root = Selection.activeGameObject;
12.        
13.         if (root != null)
14.         {
15.             Expose(root);
16.            
17.             root.BroadcastMessage("Update", SendMessageOptions.DontRequireReceiver);
18.             root.BroadcastMessage("LateUpdate", SendMessageOptions.DontRequireReceiver);
19.         }
20.     }
21.    
22.     private static void Expose(GameObject go)
23.     {
24.         go.hideFlags = 0;
25.        
26.         foreach (Transform child in go.transform)
27.         {
28.             Expose(child.gameObject);
29.         }
30.     }
31. }

To use this, just select a game object that has dangling invisible game objects, and from your menu select GameObject → Expose Hierarchy, you should now be able to see them. So delete anything with a name like Atmosphere, Surface, Clouds, Ring, etc.

Sorry for any inconvenience this may have caused!

​

Prefab Support

I think this was the biggest issue with version 1 of SGT. But I've now mostly fixed it. You can now create planets and other components, drag them into your projects directory and drag them into different scenes and stuff!


Surface Tessellator

This component gives your planet and star surfaces dynamic LOD, which means the mesh detail will automatically increase as the camera approaches the surface. I also included a Surface Tessellator Collider component, which will sit alongside the Surface Tessellator and generate Mesh Colliders for your planets and stars. I guess all that's left is a component that spawns trees and stuff on the surface?




Volumetric Probe

It may not be obvious from its name, but the Volumetric probe component is one fairly major thing I didn't have time to write for version 1. It allows your spaceships and other objects to enter gas giants and be visually affected by the atmosphere. You can just drop it onto any object and it should just work, regardless of the materials used. But keep in mind that it only takes one sample, so it probably won't look very good if your object is very large compared to the gas giant, and the gas giant has a complex texture. But for more realistic sized gas giants it should be great.




Cube Map Support

This feature means your planets stars no longer have to suffer from polar distortion. The Surface Tessellator component also has full support for these.




Unity 4 Support

I think it was always supported, but I've now fixed the shader warnings you get, so it should be fully supported.


Substance Shader Support

It's not completely supported, but I've modified most of the texture fields to now accept Texture, rather than requiring Texture2D. So you can now drag procedural textures from the substance into SGT fields. I'd really appreciate some feedback on it, because I don't know if this is enough for them to work properly.

​

You may notice in the documentation I mentioned and included a link to my new YouTube channel for SGT. If you have any tutorial requests, then please post here or e-mail me!

 

So very Awesome! Looks fantastic and well worth the wait Darkcoder!

 

Excellent news!

I'll do a few experiments after work today and let you know about the procedural textures.

 

​

So soon? Yep! I've been wanting to make a space combat simulator for quite a while, and now that the core of SGT is pretty solid, I can begin work on one. Any new graphical components I write for it will be included in SGT.

The first new component is the Thruster, which gives your thrusters a nice flame effect with a small lens flare.

​

Space stuff

• Dust/Debris around the camera to give a sense of speed (would also allow for 2D/2.5D starfields)
• Nebulas
• Comet Trails
• Black Holes

Spaceship stuff

• Ship lights that can blink in sequence
• Phaser style beams
• Shield impact effects

​

The version 3 feature list hasn't been set in stone, so let me know what you want!

 

What I want?

I wanna hug you for your excellent work!

 

Hey there,

If you could add an ice shader for ice asteriod fields that'd be awesome...
http://joejesus.deviantart.com/gallery/?offset=72#/d20vlq6

Might go hand in hand with debris produced by a comet. Only other thing I can think of is a galaxy that looks somewhat convincing that'd run on mobile. I dont mean render every single star but a model that could be used as a background for a map or a distant decor object.
http://joejesus.deviantart.com/gallery/?offset=48#/d2wu2f8

The ability to give the gas ring a whispy corona kind of like what is around the sun. Here is an example..
http://midado.deviantart.com/favourites/#/d1xibpo

Besides that, that honestly exhausts my ideas lol. Any of what you mentioned would be awesome. Especially nebula.

 

Great work DarkCoder! I can't wait to play around with this over the holidays!

I'm still hoping you come up with a starfield generator so we can get those Star Trek'esk color shifted stars wizzing by at high velocities! (That Star Wars jump to lightspeed effect would be hella hott also!)

-Will

 

Thanks! I'm glad you're happy with it

Here's a cropped version of that walpaper:



It just looks like a chrome effect, which could be replicated using a cubemap or a spheremap. I'll add it to the next version!

Right now you could create something like that using a plane with a galaxy texture like THIS, then use the starfield component with the In Circle distribution, and mark it to not be in the background.

But yeah, I plan to add in support for custom starfield distributions for things like galaxies. I could also maybe write some sort of shader + component to give spiral galaxies volume.

That kind of effect is probably best suited to the built in particle system. When you say gas ring, do you mean around a gas giant, or not?

Yep, this will be one of the first new components I write for Version 3. I didn't think about colour shifting the particles though, that'll be fun to add in!

 

I mean the ring that is in a plane being projected from the ball. Basically like the ring around saturn except instead of being perfectly flat it'd be a bit more messy kind of like gravity hasn't quite put in a perfect plane yet. But as you suggested maybe can achieve something similar with the particle system.

 

Thanks, DarkCoder - where would my project be without your great assistance!

Can't wait!

-Will

PS - Playing around this afternoon - great stuff!

I having opened the scripts (yet) but I'm seeing a bunch of stuff there's no documentation for - the camera items (I was looking to see if there was a quick and dirty "spaceship" movement script using the keyboard or mouse etc.) the various "Broadcasters"?, the new Surface items etc., Orbit stuff, Shoot object?

Any info on this stuff would be appreciated!

 

So like a Protoplanetary Disk? I'll see what I can do. Maybe the upcoming nebula component will be able to create something like you want. After all, some Planetary Nebulas look kind of like your reference image.

Yeah I didn't really document any of the scripts in /Examples, I guess it's a good time to make some videos showing how they're used!

As for the ship movement, there isn't anything in the current build for that, but the next release will contain some of the scripts made for my spaceship demo. This will include a thruster component, and code you can use to fire whichever thrusters are required to get your ship to move in some direction (maybe that's a bit overkill for what you want?).



And just a heads up: I won't have much free time for the next week, so I may not be able to reply to stuff that fast.

 

This really looks like a fantastic package, but... the stars... I suggest you give them some love. The star fields look very... unnatural. Contrasts sharply with the amazing planets.

 

Thanks for the feedback. But can you elaborate about what makes them look unnatural? Perhaps: The star distribution is too uniform? There are no dust clouds/spiral arms visible? There are no globular clusters/nebulas/etc to spice it up? The star visible brightness/magnitudes seem too consistent? There isn't enough variation in colour?

Reference images would also be very appreciated.

 

The star distribution is uniform, yes. The stars also all seem to be of the same size (just some seem to have less glow than others), same brightness, and are too big. In a more natural sky there would be more smaller stars of varying brightness and size, less evenly distributed. Dust clouds / nebulas would certainly make it look amazing as well. Spiral arms... that would be more for a galaxy view. http://files.myopera.com/sudiep/albums/605663/NASA Space Wallpaper 0018.jpg

Your planets are amazing, I'm sure a couple algorithmic tweaks would make your star fields look fantastic as well.

 

The more I dive into this tool set the more I am impressed with the way you have stuff set up. It's making it fun to learn about programming as I see how you have things laid out. I did noticed that the planets and the sun disappear when you get a certain distance away. I'm guessing this has something to do with performance or camera limits. It does seem a little odd to see the sun totally vanish.

I was wondering if instead of them just vanishing from sight if there was a way that you could add them to the Starfield some how or maybe a second sphere (like the Starfield) where at a certain distance they could get added and continue to get smaller.

I'm still on my first cup of coffee of my day so I'm not totally convinced that this idea isn't as far out there as the disappearing sun is. Either way I'm really enjoying SGT and thanks for the recent updated, Looks awesome!

 

One thing though re the stars, the sort of pulse/twinkle. Perhaps your suggestions would improve it, but you need to see it on a device to see how much better than average background starfields it actually looks!

 

Thanks! The main reason why there aren't many smaller stars is because the star sizes are based on world units rather than screen pixels. Thus small stars tend to flicker a lot when the camera rotates on a device with a low screen resolution, so I made them larger to avoid this. I guess the more correct solution would be to set a minimum screen size and fade them out, because right now their brightness doesn't change at all. I'll see what I can do about the dust clouds, maybe they could made made using the nebula component.

There's nothing in the code that hides planets/stars based on distance, that must be the camera draw distance. But obviously you can't keep increasing that to accommodate a larger universe, because eventually you will run into floating point precision related issues. The solution to this is to move objects that are far away closer to the camera, and to also scale them down by this same amount every Update (but still store the original positions).

This will solve the depth buffer flickering issues, but you will still get floating point precision issues as your player/camera moves far away from the world origin (transform.position 0, 0, 0). The solution to this is to move everything around the player, or the camera, so the player/camera is always at the world origin (transform.position 0, 0, 0). Doing this every frame is inefficient so many games split the world up into cells, so if the player/camera leaves the centre cell, you will shift every object in the scene (including the player/camera) so that it's currently inside it again. For example: If the cell size is 1000x1000x1000 world units and the player/camera leaves the cell on the +X axis (i.e. the transform.position.x is more than 1000), you move every object in the scene by -1000 units on the X axis, or -2000 if the player/camera somehow managed to get to +2000 on the X axis (maybe if you teleport?).

This would seem to solve your positional floating point issues and you might be able to simulate a fairly large solar system to some some degree. However, because all the objects in your universe are positioned using floats, objects very very far away from the camera will lose a lot of precision, and thus their position data will begin degrading/changing. The solution to this is to use a different coordinate system for objects far away. One method is to store the current cell your object is in (using the same cell sizes as before), and to store the position of your object relative to the cell. Now, every time the player/camera leaves the cell, your objects are placed at: (spaceObject.gridCell - cameraObject.gridCell) * gridCellWorldSize + spaceObject.gridCellRelativePosition (assuming gridCell is an integer vector that supports subtraction like that).

This feature may be included in a future version of SGT, but the last step is very game dependant and difficult to implement. For example: right now every object in the universe would be active/updating all the time, which would lead to a lot of slowdown if you populate the universe with many things. How would you handle saving/loading of these objects in a generic way? What if an object is orbiting another, how do you handle updating its orbit when it's not loaded, or when the object it's orbiting is removed before it? etc etc,

 

Actually you can solve the flickering issue by just putting anisotropic filtering to bilinear on the actual star texture and also setting mip-maps. With both, the flickering will diminish significantly. You also have to check your quality settings to make sure the texture changes you're making are actually being shown when you're in the editor.

 

True, though using anisotropic filtering may not be desirable on all devices or graphics settings. Either way, I've now implemented the minimum star size setting, so anything below a certain size will just cause the star to fade out.

 

Please can I know if it is compatible with Unity 4?

 

I'm using this with v4, Zozo without any probs so far (PC target only so far).


Not to detract from any updates you might look into for ArenMook, I'm actually happy with the star fields.

The only thing "special" I need for my games is repeatable star patterns in different "sections" in space.

In Wing Commander Privateer, depending on where you jumped, the Star patterns were very memorable; an off in the distance galaxy, certain colors and sizes to particular stars, an off in the distance planet (that you could never travel to) etc.

I was pretty much thinking I'd accomplish this using textured billboards with my special stars etc., within the differing levels in my game.

Or if not that, perhaps another star dome "under" SGT star dome that only displays my special stars etc., while still showing SGT pulsating stars in the background.

In the past I've created tilesets with the special stars, galaxies, nebulae etc., but that was when I was working with DirectX and later XNA...

I haven't tried, but perhaps I can get away with simplying adding Unity's cube map with what I want to see for the front, back, sides, etc., set the rendering so that SGT's star maps still display (or using a 2nd camera)?

Would it be feasible to add say 6 slots to the Starfield renderer that would let you drop in transparent PNGs for the front, back, sides, top and bottom and have those displayed in front of the generated starfield? (Actually if black could be ignored though screen, add or multiply modes, transparency could be optional...)


Off for some testing...

-Will

PS - Great discussion DC on the problems with precision and level sizes.

 

Yes, the latest build has been tested on Windows and Mac. The new webplayer demos were built using Unity 4 pro trial.

The SGT starfields have a seed field, and unless I'm mistaken, Unity's Random class is consistent across all devices so you could just use a specific seed for each star system.

If you play with the render queue settings then you should be able to get SGT starfields drawing in front or behind of Unity skyboxes. But I could always write a skybox component to make setting the ender queue and blend modes easier, if that's what you're asking?

 

Hi DC, yes, I can appreciate using the Seed which will always create the same pattern for each number entered.

I haven't checked yet, but I don't believe the variations will be significant enough to be memorable to the player?

I want the sectors of space within my game to be a "major character" as well.

If your skybox component will allow me to easily layer in my unique and memorable star patterns, nebula and galaxies etc., then that would be great especially if it automatically overlays and removes the black background - that would make it easier!

Here's some examples from Wing Commander Privateer (from YouTube videos):



Not one of the best examples, but notice the three blue stars surrounding the nebula, and the nebula itself. That pattern of stars and the nebula become very memorable as you revisit that sector of space.

Other examples:





Admittedly WC Privateer had way less stars in its various systems; it used variations in color and size, so it was I guess EASY to remember the different patterns, especially when compared to the number that can be generated with your toolkit!

I'll experiment with lowering the star count way down and up the size variations to see if I can achieve similar using just the seed.



But being able layer in cool looking stuff in front of your star fields should fit the bill for me - whether it's using a skybox component textured with my unique images, or something similar, would be a nice addition!

-Will

 

Thanks for the detailed description! Perhaps it would be difficult to create interesting star patterns using the seed alone, because you'd probably have to go through and verify hundreds of seeds before you find a good one. One way to fix this would be to allow you to manually modify the position/size etc data for each star after they've been generated. I'll include this in the next release.

As for the background nebulas/galaxies; Layering skyboxes would definitely be very inefficient in terms of fillrate, but I could also create a component that allows you to place images in the background (e.g. a galaxy image) and specify the size. This would save on fillrate and be much easier to do, I'll include this in the next version as well.

 

First want to say that this resource is fantastic. You have done an amazing job.

http://s1.postimage.org/wj7nlt7wf/prob3.png
I'm running into a problem with the wrap on a texture for a gas giant. as you can see from the image, I'm using the high resoultion texture that comes with the toolkit. After following the instructions pdf exactly I am getting this problem. That line which appears at the texture seam. Any idea what this is and how to fix it?

 

Thanks!

Are you sure you disabled mip-map generation in your texture import settings? (You must set Texture Type to Advanced to see this option)

In a future version I will include cube-map support for gas giants, this will allow mip-maps.

 

Ahh, turns out I missed that setting. Thanks.

 

Wow, DC - thanks for your support with this admittedly anal request of mine!


Actually having the capability to go back and edit each star seems amazing to me - not sure how you've implemented your star fields but that seems like an amazing feat for sure!

Just to be clear and not steer you down a path of hard coding, in WC Privateer, (it's hard to tell from those scaled images), the stars actually had various gradient patterns which is what made them memorable as well.

Thanks to this conversation, I pulled out my OLD hard drive from back in my DirectX dev days (oh the pain! The files are dated 1998!), and grabbed one of my 16x16 background tile sets (for a closer look, load this PNG into your image editor, zoom to 800% or so and set the grid to 16x16):



The goal was to design my levels using this (and a bunch of other) tile sets by placing the monochrome, colored and gradient stars along with the special items .

Of course back then, the target resolution was really low (~640x480) so by today's standards, these are pretty low-res (well except for mobile perhaps...)

Near the end of the tile set, you can see my special objects; the "gradient stars" (white center fanning out to red, yellow, blue, etc.,) similar to WC Priv's and some galaxies, nebulae and planets.

If / when you create nebula objects that can be individually placed within the scene, that will knock out a good majority of what I'm looking to do.

Considering how I like to draw my unique stars, it may be easier to just add say a starfield billboard object that always faces the camera and can be textured with individual 16x16 (or 32x32 etc.,) images similar to those tiles above that can be placed around the scene instead of editing your stars?


Looking again at the sets of stars you provided (2x4 etc.,) I guess I could create similar sets using my unique pixel art and then use the new placement features you're talking about?

If that's the case I'd imagine I'd need to be able to specify the tile offset within the image to use and its position within the star field as parameters?

Is SGT flexible enough to let me use say a 16x16 AND 32x32 set of star tiles together?

Maybe instead of a single texture slot, how about an array ("Add Star Texture" button) where I could then specify my different star tile sets and have SGT randomly select within them, AND if desired, also let me edit some individually?


Hopefully I've been clear with all of this - either way, it'll be interesting to see what you come up with!

-Will

PS - Just ran across the finished set of star tiles that show off all of the gradient stars (in the middle) I was referring to in my previous posts:

 

I'm continually impressed with this kit - it's really upped the visuals of my game with only a modest time investment. The update to include prefab support fixed my one minor complaint.

However, I'm having a bit of trouble trying to make a prefab of a planet with a surface displacement. When designing, the surface displacement script overwrites the planet's mesh, but the prefab instance is created without any mesh. Any advice on how to handle this?

Also, and this is really minor, it seems like I get really weird and inconsistent results if I try to copy an SGT component and paste the values into a matching component on another object. It's really easy to work around, but since so many fields are not copy/paste friendly (sliders and color gradients, for example), it tends to increase the amount of grunt work required. Ultimately, not that big a deal, though.

Thanks again for the amazing work!

 

It's probably best (in terms of draw call performance and usability) to put the special object images into a tile sheet and create a separate starfield component for them. Then using the new starfield editing options you could place/size/rotate/whatever them however you like.

Right now each starfield is limited to a single tile sheet where each tile is the same size, and 16k stars (index buffer limitation). I can remove the star count limitation fairly easily, but allowing different sized stars is slightly trickier because I have to first write a texture packing routine.

Those last two features can wait a bit. But I will release Version 2.1 fairly soon which in addition to some bug fixes, will include the layerable skybox component, the 'place images in the background' component, editable stars in the starfield, and the thruster component.

I think the hardest part about developing this pack is naming all of these features.

You right, I didn't test that case and it appears to break. I'll try and fix it now, sorry for the inconvenience! One way to force the mesh to get regenerated is to modify a setting and set it back, for example you can toggle the DisplacementClamp property twice (in inspector: Displacement --> Clamp).

 

In regards to star fields... I suggest you "hack" it. Background texture with small fine-grained stars, and on top of it your current sparse star field. You can get much better looking cosmos with a fraction of the stars you have right now.

http://www.starnetblog.com/tileable/seamless-cloudy-star-field-textures/ <-- tileable star field textures

 

Hi, well I must say again, I appreciate all the consideration you offered toward helping me out with these suggestions! V2.1 already sounds like it's going to be awesome - especially with editable stars - I can't wait to see what that's all about!


When you say texture packing - are you referring to a Texture Atlas? I have the great atlas maker in ex2D, if you're saying it would be more performant to pass in an atlas instead of individual textures?

Hi ArenMook - if you're referring to my posts. I actually need to reduce my star count way down (~50 - 100 stars tops) if I actually want to match the sparse starfields from Wing Commander Privateer.

Again, those tile sets I posted were examples from way yester-year when I was attempting to write my game using DirectX. If anything, all I'll be using now are the gradient stars and the larger special items (I have way better tools now for creating that artwork compared to back then!)

I could see myself maybe using some of the colored star tiles but SGT starfield already creates that look nicely and they also pulsate! I just need a way to sprinkle say 16 unique items tops in each of my scenes to make each location memorable.

I always found it cool when traveling between systems in Privateer - Pender's Star, the Junction System, a lot of those star systems strangely enough would actually feel like "home" from constantly seeing their recognizable star patterns - especially coming from the dangerous outer quadrants into the more heavily populated Junction or New Constantinople systems.





-Will

 

Those are nice textures, but using them as a background in a 3D game isn't so straightforward. The biggest issue is that they're only seamless on the horizontal or vertical axis. This means that if you apply them to a cube map, 6 of the horizontal edges will lay against 6 of the vertical edges, which will create 6 seams (the 4 vertical edges, and two of the top ones). Even if the texture accounted for that, you'd still end up with texture distortion at the corners of the cube because of the increased texel density. But at this point your texture would no longer be tileable, so you'd need a massive texture for each cube face to create high quality stars, but this isn't practical for memory usage/loading times/etc.

Yeah I'm talking texture atlases. If I just used separate images for each star then that would be a t least one draw call for every variety of background star/wormhole/galaxy etc. I want this toolkit to be as accessible as possible, so I won't have any (optional) dependencies on third party texture packers. Besides, writing a basic texture packer shouldn't be that difficult (though I've never written one).

 

After looking at your star tiles again, and reading the star field docs, just for a test, I figured I'd try my newly rediscovered tile set with SGT - I loaded that complete tile sheet I posted above and set the tiling to 16x16.



Initially it was a hoot because I still had the pulsing turned on LOL!

Instead of the star patterns twinkling like with yours, they would zoom in and out and look like fingers spreading open and closed since there were multiple stars per tile!

I didn't really pay attention as to how you were doing the pulsing - I thought it was though transparency modulation or perhaps even a grayscale "grunge" image you slide back in forth in front of the stars (but I guess with that you'd have grunge images exposed somewhere not to mention that's more resource intensive...)

Anyway after turning off the pulsing by setting it to 0, and playing around with the seed, I got pretty much exactly what I was attempting to accomplish way back in the day.

Upon approach to this planet coming out of the jump gate, this particular pattern will become memorable over time similar to the systems in Privateer...

With Unity and though the use of your tools, I've been able to accomplish stuff in hours that was taking me weeks and months to code, setup and test back in the day.

The planets look awesome now thanks to SGT - something that would have taken me a great amount of time to figure out with my limited time after work.

Now I just have to pin down a reliable workflow to make my planet textures - I do have LunarCell so I'm hoping this will work nicely with SGT. I may try to see what I can accomplish with Substance Designer as well...

Thanks again for such a great Unity add-on, and Happy New Year!

-Will

 

Substances can really be a blast when it comes to procedural planet surface textures. Yet they can be a real pain in the ass to get right (especially earth like planets). It really boggles my mind why there are no ready to use planet surface Substances in the Allegorithmic database.

Also, if you want to use the cube mapping approach DC has recently added, you'll have to find or think of an algorithm to convert the rectangular output texture(s) of the Substance to a cubemap. This really bloats your scene's load times when done at runtime.