Space Graphics Toolkit & Planets

Wow that sounds awesome.

 

Tried using SGT with the new HD rendering pipeline system, but apparently the atmosphere doesn't show and not sure why, without the pipeline it works.

 

That's supposed to happen, pipeline mean rework the shader

 

When it becomes stable and part of a major Unity release I'll look into it.

 

Hi Darkcoder,

Using the SGTHeightmap on large-scale worlds means at ground-level, the pixels are kilometers wide. So I'm trying to figure out if I can use a heightmap to drive the Amplitude of the SGTTerrainSimplex component on a per-pixel basis. This seems like a simple solution but I can't seem to add any code that works in the SGTTerrainSimplex (not even a public variable shows up in the inspector).
Do you think it is possible to achieve this effect?

 

The terrain height modifying components can be stacked, so you can use heightmaps with simplex. If you need to combine their behaviours in some way then you should do it in one component like you describe. Sll SGT components use a custom inspector defined at the top (inside #if UNITY_EDITOR #endif), so you can modify that to include your new values, or delete that block entirely to use Unity's default inspector.

 

Or just add DrawDefaultInspector (); so you get the custom + the default

 

Is there a release date for the floating origin stuff? Also is this going to be added to the main asset for free or do we have to pay for it? Just wondering.

 

It will be at least 2 weeks before anything is released, and it will be released for free.

A few higher priority things came up so I haven't been able to send out any test builds yet, but they will come soon.

 

Hi! Loving this asset. I'm really impressed by the variety and quality found in the toolkit.
Running into a minor bug in the editor and test builds, attached below. This is an untouched demo scene for "simple belt".

As you can see, the stars in the background are being rendered through the planet and all shadows. The stars are set to "background" in their render queue and the blend mode is set to "default".

I am using deferred rendering in my project. When I switch to forward, this fixes the problem. Is there any special settings I need to change to make SGT work with deferred rendering?

Thanks!

 

I sent you a private message with updated shaders that should fix this.

 

Here's a sneak peak at the next version of SGT!

​

It demonstrates stars placed at realistic (lightyear) distances, planets orbiting at realistic (AU) distances, and with orbiting asteroids. This is all made possible using the new origin shifting system, which supports universes over 50 billion lightyears (i.e. it can scale to our universe). Since loading all the universe at once isn't possible, this is all handled using a procedural spawning system. There's still a few things left to do, but the most difficult things are done!

 

The asset has source code? I want to use it as documentation and example to do the same with my custom gameplay and world!

 

This is awesome.

Did you envision making your floating origin system open source (MIT license) on github ? Just the code, with just one demo scene with a cube ship and spheres planets.

For you:

• this would generate new sales of SGT / your other assets (good marketing !)
• you would get feedback, enhancement, fixes, if you want to spend the time reviewing / merging the pull requests, or you delegate that or just let others handle this in their forks.
• and integrations / variations of the code (like a u2018 specific version for example)
• maybe feel good

For asset store publishers

• it would be a base framework for their new assets, so compatible with SGT
• SGT is a big player, so assets publishers will want to advertise "SGT compatibility"
• more links to SGT / your other assets, more sales for you !

For game devs :

• it would make it a breeze to use multiple assets that are "SGTFloating compatible"
• make the system rock solid (because open source means more eyes on the code)
• Faster access to versions / fixes / bleeding edge features
• ensure it won't become abandonware (because of github's easy fork system to make a new version, like shaderforge for example is now community maintained, there is a u2018 fork)

Infinite universe / floating origin is a very specific use case that goes out of the normal way to use unity, it's hard to do properly as you know and requires to adapt all the game entities to the way transforms are reset, so having a community of devs using that would be really useful I think.

 

Yes, all C# source code is available in the package.

Your list of benefits is indeed good, but you also have to consider the downsides and unknowns:

• It's not clear what the overlap between github users and paying asset customers is. Even the most popular github Unity projects (e.g. xLua, UnitRx) only have a few thousand downloads over the past few years. In my experience these kinds of numbers are easy to achieve for free asset store assets, and mine aren't even close to being the most popular. Asset store assets also have the huge advantage of directly being connected to the asset store and thus my paid products.
• It makes project management more difficult. Currently all of SGT is in the same repository, and putting just the origin shifting stuff on github would complicate things. It also complicates the code since all SGT components use the same helper and inspector classes, which would be too bloated for just a stripped down origin shifting repository, and separating this code to avoid that would make my job more difficult.

In theory it would be nice to do, but I'm not convinced the time spent doing and maintaining this would translate to enough extra sales to justify. I think the best argument for it is that other asset developers could use it in their assets, but this doesn't stop assets like Playmaker getting support from many assets despite having no freely available build users can bundle, and if I put myself in the shoes of another developer I would be hesitant to include such a thing. I plan to submit the first version of this new build next week so we'll see how it goes, I can always change my mind. Thanks for your thoughts!

 

Yeah, I see your point of view and it makes sense !

Note you can still sell the asset store version of a free github asset, like Xnode does.

And if you feel like building a "closed source community" gitlabs has free private repositories for unlimited amount of users, but you would have to invite your verified customers to the repo.

I wish unity would do that : https://feedback.unity3d.com/suggestions/integrated-source-control-for-assets-in-the-store ( please vote for it if you agree ! )

 

I have a question, for the spiral starfield, I am having some trouble understanding the code. I see the starfieldstar class is stored in a list in the starfield group script. i was wondering, is there a way to access this via clicking on one of the stars in-game. how would i go about doing that? the thing is i would like to use this to procedurally create a map and perhaps have each star procedurally create a solar system within the starfieldstar class. it seems like all the pieces to do this are here they are just not connected. any ideas on how I would do this?

 

The only starfield class that stores a list of star positions is the SgtCustomStarfield, because otherwise every starfield would take up a lot of memory. If you click the context menu (gear icon) for the SgtSpiralStarfield then you can see the option to "Make Editable Copy", which will create an SgtCustomStarfield from it. You can then use the Stars list inside this class to access the SgtPointStar data, which includes the local position of a particular star. To pick one on the screen you then have to loop through them all, transform them to screen space, and compare against your click location.

 

Can you help me understand the starfieldmodel script? does this draw a punch of quads and map them to the star texture? also how does it get the star positional data? does this update everyframe to have the stars face the camera?

 

Yes.

When the SgtQuads.UpdateMeshesAndModels method is called (e.g. OnEnable or when you adjust an inspector setting), it first calls the virtual BeginQuads method inside each starfield class to find the amount of quads that will be generated, and based on this number an amount of SgtQuadModels will be created, and each of these will get the virtual BuildMesh method called on them, to build the quads for that specific model. This is because in the past and currently on some platforms there is a limit of 65k vertices, so for large starfields it must be split up.

The camera facing direction is calculated in the vertex shader, which is why runtime performance of this component is very fast.

 

I ain't been following this as closely as I did once (yay college life) but now that it's summer, I'm poking all me old haunts once more. :3 I love the new additions in the works, especially the floating origin and realistic distance!

I do have a question. A hundred bucks is a big squeak for a small hobby-developer like myself; I think your asset is easily worth it for sure, but I am curious how often it goes on sale? I'd probably nab it up real quick whenever that happens next :3 A lot of my projects are space based and would benefit heavily from this asset. Save me hundreds of hours of work.

Thanks mate c:
--IronDuke

 

Questions before purchasing.
1: does this work with 2018 with zero issues?
2: is the realistic process possible with the way it is currently from the pics it seems like you can recreate all these stages:
https://en.m.wikipedia.org/wiki/Stellar_evolution#/media/File:Star_Life_Cycle_Chart.jpg
^ chart on part of steller evolution. This could be an extremely vital part to my game!

 

It goes on sale maybe once a year, the last time being last month. If you're mostly interested in the origin shifting system then you may get a pleasant surprise in a week or two when the asset store team reviews my submissions

1 - As far as I know, yes.
2 - You can recreate most of these states with SGT to varying degrees of accuracy. The nebulas are the hardest, and require a lot of tweaking to the source images, and the pulsar + x-ray emission astrophysical jets could be done using a particle system since there is no SGT component to make those yet. The only one of those that can't be done is the Roche lobes of the binary stars.

 

Hello, I have to make a Solar System for a VR project. SGT have all the planets of our solar system out of the box? Sorry for the newbie question.

 

After you purchase SGT you can download the 'Solar System Pack' which is available at the top of the first post in this thread, or on the SGT webpage.

 

More on my second question. The most important part is actually before the neutron star becomes a pulsar. So thermal x-ray and gamma radiation should not be needed. Maybe as a failure for the last mission as a cool effect or something. My main goal is to create a galaxy around a neutron star. Mostly lifeless as it should be and some black holes. I basically want to make my world map out of this system. I guess that's a more detailed question. That should be possible right? For example, I should be able to do a lot of distortion effects with black holes and not make the gravity pull as strong as it should be/turn it off completely right?

 

If you can find a reference video or something for the effect you're looking for then I can give you a better answer. I'm currently working on a major update to SGT to improve the code, feature set, and visual quality, and also plan to add lots more demo scenes in the near future for pulsars and such, so the more reference material I have the better.

The black hole effect is purely visual/post processes, so it has no impact on the physics, that's a separate component and completely independent.

 

It sounds like what I want to do is more than possible I think. It's just now I gotta wait for some sale $100 is steep. I know how hard it was to make this though so I kinda understand. Serious math+art going on here good job on that.

I'm actually finding 0 videos on neutron stars

 

on the custom starfield script, how can i call the regenerate function from another script? what is it called?

 

@Darkcoder - Got a request for a tool for space graphics toolkit.

Would it be possible to get a tool that allows us to create solar systems using the new floating origin system?

Example

 

It's called UpdateMeshesAndModels().

The Universe feature comes with the SgtFloatingOrbit component, which allows you to make custom orbits. It doesn't have as nice editor integration as that video, but the inspector settings to get something like that are very simple and easy to use though.

 

​

 

*squee intensifies*

Thank you so much for this, man! You are da boss!

--IronDuke

 

Tried the new update, looks pretty good. I notice that I can fly inside the planet, their arent any more colliders? Was something changed or is this broken?

 

There's no collision in any of the demo scenes currently. I plan to add some more advanced components for things like collision, orientation to planet surface, spaceship controls, etc. But first I want to finish making demo scenes for all the features, update the website & first post, etc.

 

Ohh, Alright. Yeah I've noticed in the version previous of this one. I've added a character controller and stuff to a basic model and it was clipping some parts of the planet. Is this going to be fixed with the new collision stuff?

 

It depends on your character controller. To add colliders to the SgtTerrain you just set MaxColliderDepth as always, or use the SgtTerrainPlane, and for the new planets and asteroids you can just add a Sphere/MeshCollider. The only thing that changed is the camera movement component no longer slows down and eventually collides with SgtTerrains even if they have no colliders.

 

I bought this something like 7 years ago and have looked at it off an on. I've only just started actually diving into it now so I apologize if these questions are just a result of my own ignorance with the project.

1. The infinite starfield. The stars stutter and don't update smoothly between frames. For example, I have a test scene where I'm moving the camera to the left Translate(Vector3.left * Time.deltaTime * 50f) and I can see what looks like double vision and stuttering every few seconds. The framerate isn't the issue as its well above 60fps. Also, I'm not moving the camera with physics so it isn't the physics not syncing with the framerate. I removed the floating point origin and anything that resets the stars position just as a sanity test and it still stutters. I think it's something fundamental to how it works.

2. Minimum star sizes. I like to have small stars but too small and the blink in and out. If I raise the minimum star size, this fixes the blinking, but now the stars are a little too large when moving through them. So instead of just a global minimum and maximum, it would be nice to have a maximum star size up close. This way I can keep the stars just above flicker level in the background and not too large in the foreground. If I set the minimum and maximum to the same value above the blinking threshold, they're too large up close. So maybe some kind of maximum screen size ratio like a particle?

3. Floating point origin. This is something I've written many times on my own and I've always wondered a few things. Typically I would keep the player at Vector3.zero and parent the rest of the world under a single GameObject. Then I offset just the parent by they player's movement delta every frame. This makes floating point origin extremely simple and easy to use. However, it looks like your implementation is using a few components and has a lot of glue logic. Plus you only reset to origin after the player has moved a certain distance. Did you find that just parenting the world separate to the player and offsetting non-performant for some reason? I would always reset the player every frame and just offset the world by whatever they moved in that frame. This simplifies the code but I never knew if resetting every frame was a poor choice and if I should only do it every X distance?

Thanks!

 

1 - Are you sure you're not updating the movement in FixedUpdate?

If I add the following component to the Main Camera in the 'Infinite Warp' demo scene, I notice no issues:

Code (csharp):

1. using UnityEngine;
2.  
3. public class Move : MonoBehaviour
4. {
5.     public float Speed = 10.0f;
6.  
7.     void Update ()
8.     {
9.         transform.Translate(Vector3.right * Speed * Time.deltaTime);
10.     }
11. }

2 - I plan to add a minimum size to stop them flickering, but I think a maximum size would look weird. Unity's particle system has the ability to set a maximum size and I think it looks strange when you get close. Perhaps a better solution is to make the size change based on distance similar to the billboards. I'll have to experiment with this.

3 - I made it this way simply because moving everything has a performance cost, and doing that every Update would be a waste of performance since the visual quality between the camera being at 0,0,0 and 100,0,0 is basically going to be the same. Moving normal 3D objects has minimal impact, but if they have colliders it's a bit more, if they have scripts that need custom values to be updated/offset then it's even more, etc, so there's basically no reason to not have it work this way.

 

Thanks for the reply.

1 - You're right. I found it works fine when I use the example too. So please disregard that. It must have been something with the way I re-created the scene.

2 - Sure, that sounds good. It's not a big deal but might look nicer.

3 - Yes that's a good point that moving only the player would have better performance than everything every frame. But I wonder if it is offset by the fact that things under a parent don't need any special consideration at all. They all move around locally and everything just works. They don't need to know or consider they're using a floating point system at all. Obviously, this isn't a complaint. Just curious how others approached this problem.

Thanks for continuing to support the asset after all this time!

 

It only 'just works' for simple objects. If you have any components that store world coordinates then they will break without updating those coordinates every frame. Also keep in mind shifting the origin like this loses positional precision, especially for distant objects. One of the key features of the SGT implementation is the SgtFloatingPoint, which stores a high precision coordinate that remains as accurate at 0,0,0 as it does at the edge of the observable universe. If you origin shift a galaxy or any smaller objects that far it will totally break. If you've tried moving spaceships and stuff past 10,000 units you'll know they start to shake, and if you're shifting planets and players in the millions of units suddenly your once accurate positions will degrade into +- 1km accuracy positions.

No problem, it's a lot of fun!

 

Hey man, just downloaded 3.5 (love it!) but there doesn't seem to be the option to cube-map a texture anymore? Nothing in the settings-cog but reset.

 

I sent you a private message with the file. I'll include it in the next version.

 

Hi Darkcoder,
I've managed to adjust the RidgedSimplex component to accept a heightmap and derive its height from that map and it works well.


I want to delay the rebuilding of the mesh if the camera's velocity is above a certain amount (to see if that helps with the lag spikes when re-calculating the mesh). Is there a function to delay the rebuild I can use?

 

If you rebuild the terrain then it's designed to go through the whole hierarchy and update the mesh of every child, and changing that behaviour would require some changes to the code. It sounds like you may just want to limit how many children are spawned per frame though, which can be done by modifying the SgtTerrainFace.UpdateStates method. You could add some kind of counter to the terrain that gets reset every frame, and inside UpdateStates you only allow the SplitNow method to run if it's been run less than a certain amount of times.

 

Hello again,

Is there a way to use the SGT Terrain Cube Materials with a normal map and get the edges to match up?

 

Yes, the example 'Terrain' demo scene even uses normals without seams. The most important setting is SgtTerrain.Normals = Normalized. Your screenshot looks quite wrong though, are you sure you didn't get the wrong texture on that face?

 

I thought it might be something to do with the wrong texture but the geometry matches up and the shadows don't. Strangely, changing my normal maps texture type to default fixes the odd lighting issues (?) but the seams are still visible, as they are in the Terrain demo scene (not all the seams, just a couple).

 

I can see a slight seam at the light/dark transition, but nothing as bad as your picture. Which version of Unity are you using? Also, did you enable anything like HDR or Deferred rendering?

 

2017.3 and no HDR. Looks the same in deferred or forward rendering.