[RELEASED] SPACE UNITY - Space Scene Construction Kit

No rush from me as it turns out. I finally bit the bullet on Pro and I didn't realize that there's a built-in function to render skyboxes from a scene. So I've been able to "bake" skyboxes from the construction kit generated scenes. Works great!

I end up disabling Spaceship, SpaceFog, and SpaceParticles. And I have to turn off the SU_SpaceSceneCamera script on SpaceCamera (messes up the FOV or something). I do have to render the cubemaps while a game is running, otherwise the local star doesn't draw. I also found a script online that dumps a cubemap into individual PNG files, which can be handy.

The reason I don't need realtime generation at the moment is that I'm planning on using Skyshop for image-based lighting. Those can take quite a long time to bake (over an hour in some cases), so real-time isn't an option if I go that route. So far it's working surprisingly well for ambient lighting, especially when there's lots of colorful nebulas (nebulae?).

 

Any eta on the major update? I would really like to fly between planets for a project I'm working on.

 

Hi - challenges with my day-job and complications with our house has delayed the update but the good news is that I will by the end of next month step down to 50% in my normal job and will therefore be able to develop SPACE at a much higher pace instead of the odd hours during nights.

I don't have an ETA on the layered coordinate system yet and my apologies for the delay of the update. I'm really eager to soon be able to dedicate proper time to bring SPACE to the next level!

I'd also like to give a huge thanks to those of you who have purchased this asset and for the positive feedback it has received.

 

Hi, I've build a small game using Space as the background and an other asset. Instead of really "flying" my ship through this space I've a ship that moves on an horizontal and vertical axis and asteroids flying towards the ship that I shoot. I exchanged the stars that were in the asset to your space background, added the SpaceFog, SpaceParticles and the SU_CameraFollow Script. Everything seems to work fine, except the Fog and Particles. As the Fog and Particles do appear in other demos, but only while flying, I think that's the Problem. My Ship isn't really moving. Is there a way to change the Fog and particles to work all the time? My ship virtually flies all the time.

Hope you can help,
George

 

You're welcome.

 

The SpaceFog and SpaceParticles scripts individually control all particles so they spawn in the distance around a ship so you always appear to be travel through something.

Since your ship is static at 0,0,0 and movement is simulated (and if your ship is flying all the time) I suggest creating new particle systems using Unity's component where you set the speed of particles. Unity's own GUI-configured particle systems are good when it comes to particle movement and you can keep the particle system stationary at 0,0,0 along with your ship. You can re-use the particle materials that comes with SPACE for Unity. I suggest creating a box emitter in the distance and pre-warm the particle system so the particles have reached your ship.

One limitation with the method above is that if you do stop your ship (it will still remain at 0,0,0) the particles will keep flying...

Alternatively, it could be possible to customize the particle script that comes with SPACE and feed your direction and virtual speed to move the individual particles. They should then re-spawn appropriately as they disappear out of range. Let me know if you need assistance with such a modification.

 

It is a simple shooter where your ship always flies at the same pace, so a hint how to change your script to always emmit the particles should be all I need. It works with your cam follows ship script so I guess the particles should work right out of the box too. So basically what I need is this. A hint where to change the script to always work the way it works when you fly full throttle in your demos. My guess is that this would be enough to sell the effect.

 

In my demos the particles are always stationary since you fly through them.

You could try to modify SU_SpaceParticles.cs (in the scripts folder) and change the Update() function. It loops through all particles in a for loop and you can change the _velocity vector there from random drift to a set Vector3, e.g. modify row 115 and set the particles to move backwards (the multiplier could be any number to suit your game, just picked 100 out of thin air =):

Code (csharp):

1. Vector3 _velocity = -Vector3.forward * 100 * Time.deltaTime;

I haven't tested it yet, but that should hopefully work and as the particles go out of range they should spawn again.

Saying this, I think for your purpose you'd be best off with a Unity particle system at 0.0.0 that just moves the particles with direction and speed suitable to your game. You'd get better performance and control this way becuase the SpaceParticles scripts is designed for when you want a large space to appear to be filled with particles to fly through, something the particle systems by default isn't very good at.

 

Ahh, okay, I see. Will try the particles then. Thanks a lot.

 

Hello everyone.

Just two quick notes regarding a couple of issues in Unity 4.2 which I'll address with an update (meanwhile there are workarounds

* Asteroids not rendering in build:
It seems like when doing a Build in 4.2 with asteroids results in no asteroids being rendered if they are configured to fade in/out. It works in the editor, but compile will keep opacity at 0. For the time being, this can be worked around by disabling Fading asteroids on the AsteroidField prefab.

* Planets may flicker in certain angles:
This has to do with range of the Point Light of local stars. You can manually fix this by changing the range of the point light of local stars and lower it from 100000 to 20000. On my rig it takes away any issues. It's odd because going from 3.5.x to 4.0 I had to reduce the distance from "Infinity" to 100000 - and with 4.2 it seems like it needs reducing further. Hopefully it's not a trend that continues =)

 

This looks pretty awesome and promising, purchased for sure

 

Thanks =)

 

Hello, I'm working with some stuff for the asset and I though I'd ask you guys for some input... It's a bit technical so only continue to read if this sort of stuff interests you =)

In the current version there are 80 seamless textures that are used for static star backgrounds with different color variations. These are 4096x4096 textures that occupy a large portion of the asset (205 MB.) Since the same texture is seamlessly tiled in any rotation (so called 8-sided texture) it's used on all six sides of a traditional Unity skybox on the "SpaceCamera" which utilizes 6 draw calls which is very unnecessary since it's the same texture.

By using a procedurally generated inverted cube mesh and a custom shader this is now reduced to 1 draw call. So far all good, but there are two ways forward from here:

Alternative 1:
Using a custom shader it's possible to combine the star texture with a tinted base nebula texture to achieve the same visual result as before.
Benefits:
+ Only 1 draw call
+ 191 MB is freed up in the asset
+ The reduced size will speed up working with the asset (when conversion of textures are necessary)
+ The reduced size will allow me to add more textures (nebulas, planets, asteroids) since it's no longer at the size limit of 500 MB
+ Distributions will be smaller in size if scenes use different star backgrounds
Disadvantages
- Tinted star backgrounds will combine two textures and perform color tinting which impact performance somewhat

Alternative 2:
Using a plain unlit shader and keep all the previous 80 star textures:
Benefits:
+ Only 1 draw call
+ Maximum performance on all platforms since it's a single non-tinted texture
Disadvantages
- No additional textures (nebulas, planets, asteroids) content can be since the asset is at the size limit
- Performance is sluggish when e.g. switching platforms since textures are re-imported/converted
- Distribution size will be larger if scenes use different star backgrounds

Performance
"Overkill" stresstest on PC with 100 simultaneous skyboxes, 1 draw call:
Alternative 1: 120 FPS
Alternative 2: 100 FPS

"Overkill" stresstest on Android Samsung Galaxy S3 with 20 simultaneous skyboxes, 1 draw call:
Alternative 1: 60 FPS
Alternative 2: 30 FPS

Other methods to benefit from both alternatives?
Win/win would be if it's possible to combine and tint textures ONCE upon scene load becuase dynamic tinting and blending changes are not necessary. Unfortunately I only think shaders can perform this in the "Pass" and not to create a new texture. I hope I am wrong? Also, combining textures using Get/SetPixels is slow (3-4 seconds on a PC) so that's not a good option.

The shader I'm using in Alternative 1 is:

Code (csharp):

1.  
2. Shader "SpaceUnity/SU_SkyboxTint" {
3.     Properties {
4.         _Color ("Color", Color) = (0.5,0.5,0.5,1)
5.         _MainTex ("Stars", 2D) = ""
6.         _NebulaTex ("Nebula", 2D) = ""    
7.     }
8.      
9.     SubShader {
10.         Tags {"Queue"="Background" "IgnoreProjector"="True"}
11.         ZWrite Off
12.         Blend One One
13.         Pass {
14.             SetTexture[_NebulaTex] {
15.                 constantColor [_Color]
16.                 Combine constant +- texture
17.             }      
18.    
19.             SetTexture[_MainTex] {
20.                 Combine previous + texture
21.             }
22.         }
23.     }    
24. }
25.  

Any input or feedback on this is most welcome.

Also, if someone knows how to combine textures in a shader before render passes, I'd gladly implement that instead since that would be ideal

Edit: I guess I could implement "RenderToTexture" for Unity Pro users to achieve win/win, but it would be nice to find a solution for all of you with the free version of Unity.

 

Hello!

I'm considering dropping Unity 3.x support for the version 1.1 update of SPACE for Unity. Are there any of you still running 3.x it would be great to know.

Thanks =)

 

Fine for me, but please keep supporting Unity Free (no rendertotexture).

 

Hello. I just purchased this package and I loved the demos on youtube, but I am not able to generate the star skybox. No matter what settings I select (only stars, no nebula, galaxies, etc.) I always get the sphere with the nebula, a planet, galaxies, and no stars skybox. I am generating a new project now thinking maybe somehow my project was corrupted, but I was just wondering if anyone else here has experienced these problems with Space Scene Construction Kit. I am using the newest Unity free. Thanks for any info.

[Update]: I just generated a new project, then generated a space scene with only stars (random) selected. I got no skybox at all.

 

Yes, Unity 3.x !!!!!!!!!!!!!!!!!!!!!!!!!!!!!
6R

 

Hi - you should use the included \_Scenes\Template scene as a base scene before you use the editor window to create a scene - is this what you are doing because it sounds like you may be using it from a new/blank scene which does not consider the camera setup?

Also be sure to check the included manual in the _Documentation folder. If you still have problems, please let me know and so you'll get it running.

It works for 4.x as well with some minor issues described in a recent post, but I'm working on the update.

/ Stefan

 

I was starting with a blank scene. I was able to add all of the items manually, but I will try with the template scene and see if that resolves the issue. Automation is always nice. I am messing around with the ship prefab you provided with the package now. Kind of learning how to make things tiny to give the illusion of giant space without running into the floating point issues. Thanks for the advice.

 

The floating point issue is a bit of a pain. I'm on my second rewrite for a solution for it and working on that particular issue as I write. Just out of curiosity, how large do you need your environment to be? How many stars to visit? How many planets? Real size distances or is it arcade style short distance? =)

 

I am wanting to emulate the X series mainly, possibly Eve Online. I am an experienced programmer (though my math skills leave a lot to be desired), but I am new to world building. I am trying to learn different techniques to simulate a galaxy sized environment via smooth transitioning between areas. Right now I am just working with an area surrounding a planet (like in the X series) and a gate system to get to other planets. I am guessing I would handle gateless travel to other planets/systems the way I think Eve Online does. I would probably have the star in each system be the parent for that system, then attach and detach the ship to the system parent or even to the planets (for orbiting) and only render those system entities that would be within flying distance. Somehow I would try to attach each system as it is spawned (when the player is flying from system to system) to the world 0,0,0. The transition for the ship would probably be an animation attached to the camera, then black and silence, then an explosion type of effect coming out of warp. Traveling from planet to planet manually without warp or gates would take too long, so I would probably just let the player wander into noman's land at that point, until he figured out he is going to be flying forever. Maybe have some invisible nodes spawn at 0,0,0 and attach the player to it when he gets too far from a planet or star.

All sorts of ideas. My main focus for the game will be trade, combat, exploration (like StarTrek style exploration), story driven, and Bridge central game play.

 

I just figured out that many of the problems I am having is because I had a previous version of monodeveloper installed from way back when and didn't remember. There were all sorts of problems occurring. Now maybe I can debug things and see what's happening to my stars.

 

Yeah baby! I'm all fixed now. Not sure how the previous mono, and runtimes were affecting this, but after removing everything and fresh install of unity and mono, and reimport the unity space, everything is fine. I can load the template, and add stars. Thanks. My biggest hangup was not using the template as you said. I saw that in the readme file. My other issues were not related to unity space. This is an awesome tool and I look forward to creating many star systems with it. I haven't read license info yet, but are we allowed to give you credit in our game?

I am curious as to why the asteroid field is attached to the ship instead of an empty entity. I attached it to an empty entity so that no matter how many ships are in the area, it will be world relative rather than ship relative.

 

ah I see, "infinite asteroid field". More difficult to be infinite unless the ship is the parent node.

 

I changed the flight a bit on the ship. Made it mouse controlled and only when the left mouse button is pressed. Also added targeting of any object under the reticle with the 'T' key. I think I am going to look into the asteroid generation logic and make them resource containers (ore, crystal, ice, etc.) and spawn them based on kind of a nav plane mesh where the vertexes represent the position of an asteroid. That way I can place the asteroids in systems that host specific resources (iron rich, etc.). http://www.derikwilson.com/files/videos/UnityTargetSelecting.mp4

 

Awesome. Awesome. Awesome.

 

I'm considering purchasing this - but there's one feature I must have.

I want there to be a star map (this is not for you to solve, it's just so you understand what I'm achieving) and when someone clicks on a destination, then the scene with this construction kit would load - I would need to:

Create the background during the load screen.
Recreate the same background (maybe using a seed) every time they go to the same destination.

Does the project support this type of generation?

Thanks!

 

From what I have seen, this project is a creator extension. However, you could preconfigure your scenes and store information about the assets in a database or just store the paths to the assets somewhere so you can get to it quickly at runtime. When the player clicks on a point on the starmap, load that scene, or load the individual assets and plop them down at 0,0,0 (though you will still have to use the template scene as it seems dependent on its functionality). You could also use the same assets to randomly generate a scene at runtime. That's just my take on it. For example, I will probably end up using the template in the space scene construction kit, then generate planet locations, asteroids, etc. at runtime based on information from the universe database that I will be creating. I may preconfigure the scenes if I can store info about the planets and other objects so that the user can target and scan them, mine them, etc.

 

Hi Guys - thanks for keeping the discussion going regarding how to approach using the asset for different purposes.

As DerikGW mentions, SPACE was more designed to use the editor tool to create and customize individual space scenes which are then switched between in a game. The reason why the kit was not designed to use seeded generation at runtime is because it would require all textures to be included in the distribution of a game resulting gigabytes of textures when in reality maybe only very few of the textures are used depending on the size of your game. Saying this, the asset can be modified for such a use by looking at the included editor scripts to see how assets are located and instantiated - but it requires some coding.

I understand that since the release of the asset it is much desired to cater for large universes where it isn't feasible to manually create hundreds or thousands of scenes individually. I am addressing most things but it's taking a considerable amount of time as I want to get it right. The path I'm heading is that SPACE for Unity will continue to be a custom painted texture driven scene creation but with two use scenarios:

1. Individual scenes will still be handled as before, they can be custom made and tweaked mainly suitable for action games, RTS games, sim games with less interstellar travel.

2. The tool is being extended to allow creation X amount of planetary systems within an intergalactic coordinate system so you can travel between the systems and also within the planetary systems. These type of space scenes have a centrally positioned star and a custom amount of orbiting planets and asteroid fields. The very distant stars and nebulas will be static for the planetary system as you would never see much movement with them being so far away. The planets and stars should, on the other hand, behave according to distance and scale within the planetary system. Bookmarks in the coordinate system should allow jumping between planets and you can fly past the star in the process, etc. Jumping to a different system would be handled by a warp effect and new nebulas, stars, and planets are instatiated as you arrive in the system. Instead of the editor creating a bunch of instantiated planets, the editor will instead show the star and planet hierarchy with drawn gizmos and as you click on a star, for example, you configure the color, the radius compared to the sun and when you enter play mode the star will be instantiated in the game instead of as a prefab in the hierarchy.

I still have restricted amount of time that I can allocate to development but in January 2014 I will finally step down to 50% in my day-job so I can focus more time and effort on the asset to speed up development. I appreciate the patience of those who are waiting for the update and thank you once again for buying the product which is enabling me to spend more time on it!

 

I know many of you would slap me for this, but if you add all that you said in the previous post, I would imagine many folks would pay a good deal (say $500 per license) for the final product as long as it supports Unity Free. I only mention that amount as a rough guess considering Unity Pro costs twice that, and you are saving us a heck of a lot of time, and providing very nice art as well!

 

This sounds great. If I am reading it correctly then this is exactly the space portion of our game. We plan on a star map like in SWG with worp gates to travel to and fro. I will read up on this asset more and I think it may help make a third of our game play.

 

Imphy, let me know if you need anything, testing, etc. I love your product and I am willing to provide any help required as time permits (free of charge).

 

I've also bought SPACE, but haven't opened it yet as I'll be using it on my next project. I was hoping to be able to use it for the case sort of like what you just mentioned... some way to create different background scenes in a random generated galaxy, where based on the type of star (or multi-star) system, number of planets etc. you'd be able to generate the background and save it for that location.

I didn't realize it didn't have that capability yet, but it's good to know you're planning on adding something like that. Considering I've already bought SPACE and will most likely buy the planet add-on (or any other add-on as this asset really looks good), I wouldn't want to have to pay another large amount like $500!

Can't wait to play around with this soon...

 

Nah I just mentioned the $500 as a rough estimate of what I would pay for the additional art and functionality. If you paid artists for the art and programmers to write and test the scripts, you'd be paying a lot more than $500. Seriously it takes a lot of time.

 

I watched the tutorials and I'm still not sure if those scenes can be scaled in size. Are they all the same area? Can I make smaller or larger scenes?

I wanted some smaller space areas and some much larger. Our game will be scaled for single player and multi-player.

 

You render with one camera - that's your scene as you think of it in terms of objects laid out in reference to each other with distances between etc.

That camera is set to ignore a layer called "Deep Space".

Another camera is set to render only the deep space layer and ignore everything else.

The first camera you will script and move around like you expect.

The second camera never moves. It just rotates. Thus, you never exceed the boundary of "space".

 

Currently the space scene is rendered using a separate background camera so if you move at "normal" speeds you wouldn't see much movement of planets or stars even if flying straight for hours. You can also configure it to get some movement to simulate faster speeds, but in the current version there is a limitation that you'll reach the star too fast compared to the planet, and you'll also approach nebulas which doesn't make sense and this is being addressed in the update. As for actual size of game play in real meters, you are still bound to Unity's floating point precision issues so if you have 1 unit being 1 meter, you can't really have a play area larger than 10km x 10km x 10km without starting to have position jitter.

In the coming big version update (this is not available yet), my current approach to this is to have one "Central Player Object" and everything else is positioned relative to the player. As the player reaches 10km in any direction he/she is snapped back to 0 and all surrounding objects including camera are moved back too so it's not noticeable but you get rid of the precision issue. Also I'm using a double vector3 class to represent actual positioning within a planetary system which gives a precision of centimeters out to a distance of 100 astromomical units (14959787100 km) from a star. In the update, the local star and planets are then positioned and scaled relative to the player so you'll be able to get a real "play field" of an entire planetary system. Then behind that I'm using a long vector3 to represent positioning of a planetary system within the universe and moving between planetary system is probably best dealt with using some type of a warp or jump effect (which should be included), but the direction of the warp will be correct. This makes the size of the potential Universe much larger than the currently known universe which should be plenty =)

I don't have an ETA on the update yet but I'm working on it every night more or less so thanks for supporting the asset meanwhile.

 

Awesome. That's everything I needed to know. Thank you for responding so quickly.

 

They would work perfectly for single player but for multiplayer, I don't think the "snap back" feature would work considering it would have to display the other players at their locations relative to the main player, a well as the other heavenly entities. I guess as long as every player tracked every moving object, and snapped them into the relative positions...that may be very tricky.

 

This is one of the painful challenges, to represent so many different scales (local, planetary, interplanetary, stellar, interstellar, and intergalactic) in a single coordinate system limited to float precision.

The snap back should work for multiplayer too, that is a main design goal for the update. Since every player has their own view then they will always be the "Central Object" and everything will be positioned and scaled according to their own view. The real position in the planetary system is represented by the double Vector3 so the actual position is correct for everyone, it's just the perceived positions of all other objects that are unique to each player. Also, the planets, stars, and other large scale space objects are not snapped because their position is calculated from the true double vector position.

 

I was planning to write a lengthy update to describe some of my recent work but I decided to put together a little video to showcase some of the stuff instead:

It shows some new stuff like:
* New custom optical flare for stars (1 draw call, GPU vertex+fragment animation - visible even when source is off screen - blocking is still be be done)
* New warp speed visual effect (in this case travelling at 5000 million km/h) in the new much larger universe, look will be tweakable for release.
* New scene view for editing planetary systems in the editor
* New procedural planets (save tons of space and create millions of unique planets for the coming enlarged space environments, seeded/random water levels, desert coverage, mountain coverage, polar caps, craters, land/ice/water textures, animated clouds with shadows) - 1 draw call for the planet and 1 draw call for the volumetric atmosphere
* New procedural nebulas (only a few kilobytes in size with tons of tweakable features such as dark matter, glow, hue, color, shape, etc.)

The stuff is still work in progress and will not represent the final release or how it will be released.

If you like the music in the video you can also buy some of my albums to listen to while you develop games, that would help fund development of assets too =) http://music.imphenzia.com/albums.html

 

Awesome and I am excited to see the new multiplayer function working with all these other new features.

 

Most excellent news! I can't begin to describe how awesome those new features sound and look, according to that video. Can't wait to try these things myself in the Unity editor though. This might just be the little push I need to motivate myself to go back to work in my project. Some time ago I came across an asset for procedural planets, but then it stopped getting updated not long after I suggested it was one of the few missing things from this package, can't help but think that was not a coincidence ... I any case, awesome stuff imphy.

 

I have not seen it listed so I requested an addon for playmaker support in the playmaker forums.

 

Question about your scene editor planetary system view, is that only for a system in the same scene? I was planning on making larger scenes for each planetary area in a system to have more play areas.

I would however love to see a universe map generated from your total scenes. I have my universes mapped out but do not have a good map for the whole thing. I might however use your system with a whole system in one scene if the area could be large enough.


P.S.
He added your kit to the playmaker to do list.

 

Hi - glad you like the video.

Glad you found some inspiration Nandus, hope you get your project going again =)

I haven't looked at Playmaker yet and it will be after the update before I get any chance to look at supporting it.

The editor and management of planetary system is currently my biggest headache because it needs to support many different types of games, it should be very simple to use for small scale games yet complex enough to handle games with thousands of systems. The route I'm heading is to enable you to create x amount of systems automatically (where x can be thousands) and it will generate a universe with a hierarchy of systems, stars, planets, moons with different attributes. The hierarchy of systems should be serializable so it can be saved to disk or a web server. For small scale games you should be able to edit systems individually, selecting them from a list so you can get the editor view to tweak planet positions etc. As for large games with thousands of systems, I'm not sure yet - maybe it's better to offer tweaking capability for settings when generating the universe rather than offer the ability to edit each system in detail.... Still thinking about this, A LOT =)

 

Awesome!!
I think letting us edit for smaller systems would be good. I cannot speak about someone making a game with thousands of systems. Maybe it would be doable with making system by system and linking and organizing them in an editor. The serializable hierarchy is one feature I would have asked for anyway. Good work.

 

As if this kit wasn't already super cool looking enough, you're blowing us away with that video. The planetary solar system thing looks pretty awesome and I was actually doing something like that myself already. It would be pretty cool if you were to get the update done and I wouldn't have to mess with doing it myself but my use-case is a solar map inside a ship (sort of like ME series) so I'm not sure how that might fit in with this. Is this supposed to be a real-scale sort of thing that lets you map out the system and fly between planets? Are you planning a price change with the update? Rough idea on time for pushing the update out?

The planet procedural painter thing looks gorgeous, gonna save me a lot of time making textures.

 

I think we can all agree that the ideal would be to have both, but I my case I have to go with the ability to edit each system in detail, settings for generating the universe are great and all; but it's something we devs can take care from our side. Because there are so many types of games that can use this asset, I think that having complete control over a system is more important that generating a universe, many of these games won't even need the latter; but most certainly most will need the first to some degree.

 

All I can so is wow on the list of updates great work cant wait to play with the new editor.