Space Graphics Toolkit & Planets

Hi, I liked the package a lot. I am stuck on one thing:

I am able to fly into a planet's atmosphere, able to land on the surface by using SgtSnapToTerrain, and able to walk around. The problem comes out with the collisions. When I collide with rocks or anything else while walking on the surface, the character gets high rotational forces and also it's localPosition changes. The character is parented under the planet while walking on the surface. The planet orbits around its star, and it orbits around itself. The rigidbody constraints are frozen when on the surface (it helps a bit for the position, but not that much for the rotation).

Is this way of implementation of character movement on the surface right choice; if not, what would you recommend? If nothing wrong with the implementation, what further manipulation would you suggest to demonstrate normal collision results for the character while walking on the surface?

Thanks.

 

Physics systems generally don't work well when dealing with very complex scenarios like you describe, where the planet is moving with physics and the things on the planet are also expected to behave properly locally. The usual solution is to simulate these things separately using their own stable local world. For example, your planet would orbit as it does now, but things on the planet would be simulated using a separate 'static' planet, and using multiple cameras or similar you would combine them to give the illusion it's all one big simulation. This can be very tricky to set up correctly though, especially when dealing with planet to space transitions, but it sounds like you have some system like this, so you may be able to modify it.

 

Thank you for your answer. Actually I could make it work a bit. Thanks to your SgtSnapToTerrain script. But I had to remove rigidbody from the planets, and write my own script to organize the planetary motion. Also freezing rotations on the character is needed. I was even able to apply a low and high gravity demonstration on the surface by changing the damp value on the script. I was even able to apply gravitational force on the character while on the surface. This setup works like a charm in editor. However, I checked with the build yesterday, it seems that there is a problem with updating the position of empty game objects (if I am right) (which is an entirely different problem happened also in another project). So far, it is what I needed in editor, a system with not real world planets but not so small as well. And didn’t modify a bit of your code. Very very good job you did with this toolkit. Thanks again.

And thanks for the advice. I really want to go into that since it will bring some additional possibilities. I want to keep the planets orbiting everytime, I need to search how planetary motion is observed on Earth surface and how those motion patterns are transformed into real orbital motion, which requires time for some physics research.

Meanwhile, I will deal with the wierd behaviour of empty game objects in build. I may not just need them to apply gravity, even not the center of the planet: I have all the background in the script, just didn’t see this possibility before. I will try.

 

I'm trying to use SGT's Elliptical Starfield at the same time as a skybox and running into a problem. As soon as I turn on the skybox my stars stop rendering. If I set the star fields's render queue to Geometry Last with Offset of 1 the stars show up again... however they are now rendering in front of all the geometry. It is my understanding that the Skybox will render at Queue depth 0, not 2500... Is there a path to remedy this? Thanks.

 

Thanks for pointing this out. The issue is that I made additive blending switch to ZTest = Always, which probably doesn't make sense. If you open SgtQuads.cs and find the BuildAdditive method on line 266, you can replace the CompareFunction.Always with CompareFunction.LessEqual to fix it. You may have to switch your starfield's 'Blending Mode' to something else then back again for the changes to apply.

 

That was the Culprit! I got around it late last night by just creating another camera for the skybox and setting the culling mask to "Nothing". Since I'm developing in VR, this was less than idea.

FYI: changing the blending back and forth did nothing for me.. I had to recreate the Elliptical Stars object to get it to work.

 

How many stars can I get away with before noticing issues? Will 100,000 stars or 1,000,000 stars be an issue? Any optimizations you can recommend if so?

 

In the next version I've completely removed that code and set LEqual in the shader, so it shouldn't be an issue.

The amount of stars is pretty much only constrained by the vertex shader speed of the target device, or fillrate if the stars are taking up many pixels. To optimize things you can disable Pulse, FadeNear/Far, and use the SgtStaticStarfield if possible. This feature is incredibly efficient though, so 100k stars or more should be no issue on most devices.

 

@Darkcoder Thanks for all the fast replies! The commitment to customer support really shows.

Another question: Is it possible to not have the stars rotate? I'm interested in creating an 8-bit graphics vibe like the one pictured here:

 

Good afternoon, I develop an application - a model of the solar system for androids using arcore. Tell me, can I use the Space Graphics Toolkit in my androyd project, will I lose performance?

 

Compared to what? You will lose performance when adding anything graphical to your scene. All graphical SGT features are designed to be very efficient at rendering what they do though.

 

Can you make a tutorial and a scene exemple for use the component Sgt Procedural System because I have some problem like all is white because the buffer of amosphere doesn't create automatic and for jovian is transparent because don't generate the meshe else when I open for each the mesh onglet. Also, there aren't gravity create automaticly.
Anyone have this problem ?

Thanks in advance.

 

I am very interested in creating a scene where the player can fly from orbit around a planet to landing on the surface. Can anyone comment or provide an example of how this asset behaves when you get down to the surface of the planet? The web demo and youtube videos didn't show this.
Also, does SGT contain any kind of code to help with very large scale space? I want to have realistic planet sizes and distances.

 

I sent you a private message with an updated build that fixes this.

SGT will eventually include an origin shifting system to handle very large scenes, but having realistic sized planets and having the detail be high is unrealistic.

 

Thanks, I will tested this.

 

Hi, @Darkcoder / Carlos!
I'm still enjoying SGT -- thanks!
That said, I'm really hating the GetTransformInfoExpectUpToDate() error spam. I'm using still (2017.03) with SGT version 3.4.0. Are these fixed in 3.4.2? If not, any chance you could contact someone at Unity to get it fixed, please? I'm sure all the SGT users would be willing to add votes on an issue you get logged!
Thanks!

 

I believe I found a workaround in 3.4.2 since I can't see the error now, but apparently failed to include it in the change log. You can backup or duplicate your project and update to the latest version of SGT to check.

 

Oh that's awesome! Thanks!

EDIT: Never mind -- fixed it! Something to do with scaling and hierarchy! I'll reply below just so a notification goes to you.

So, erm, since you're here, are you aware of issues with gas giants misplacing their textures when you get too close to them?

 

Whoops, never mind -- fixed it! Something to do with scaling and hierarchy! Thanks and sorry to bother you!

 

Never noticed this before. Are you sure the 'Mesh Radius' setting is correct?

The spheres that come with SGT have a radius of 1, but if you're using Unity's built-in ones, then it needs to be 0.5.

 

Hi Darkcoder, great asset! A couple of noob questions for you.

The Terrain Color pdf suggests to use this component to color the vertices of an sgtTerrain but TerrainColor script doesn't seem to exist in my scripts folder. The terrain example scenes have this components functionality but for the life of me I can't find where or what it is.
I'm using Unity 2017.3.1f1 and have the same issue in Unity 5.5.

EDIT: Found it! Unity materials (obviously)...

 

Actually, this is a component I removed from the main build. The SgtTerrain shader (and material using it) does the same thing that this component does when the 'Fragment Blending' setting is disabled, except it's more fiddly to use, and it's slower because it's calculated on the CPU. I then added the 'Fragment Blending' setting which produces smoother results than any vertex color based approach, so I didn't really see a reason to keep it in, but forgot to remove the documentation file. Thanks for pointing this out!

 

Thanks DC.
I've read most of this forum and understand some of the limitations of SGT when it comes to large planets but I have a couple of questions...
I have scaled up the game object containing the sgtTerrain (1000, 1000, 1000) and this level of polygon detail is perfectly acceptable for my purposes. Should I scale the planet this way or by increasing the radius? If I increase the radius by more than about 20 my capsule collider passes through the ground but if I scale it up the collisions work (although there are still some "cracks" it can fall through).
Is it possible to have a planet of that size be fall-proof?
What other problems could it create?

 

This is all down to how the physics system works. Smaller position values are best, but not too small. Since SgtTerrain meshes all use the center of the planet as the origin, you can't avoid large position values with large planets, so you should try scaling down the rest of your scene and experimenting to find where the perfect balance between all these factors is.

 

I'm having some serious issues - even on the example planet scenes with no alterations and Max collider depth set to distances size a simple capsule with a collider and rigidbody falls straight through the mesh. Unity project settings are default.
Also, if I scale the planet with the radius setting the LOD system seems to stop working.

 

I don't see any issues with capsules on the demo scene terrains + colliders. Keep in mind they use non-convex MeshColliders, so any object moving too fast will pass through them since they're paper thin. You can set the Collision Detection on your Rigidbody to Continuous to improve this, or limit your object's velocity, or decrease the fixed time step, or increase the physics substeps.

I also don't notice any issues with the LOD when scaling the planet. Keep in mind the LOD distances are relative to the size of the planet, so if you scale it to 10% then the distances will also be 10% their previous distances.

 

It seems counter-intuitive but is it right that the highest LOD mesh has no mesh collider when the Max Collider Depth is set to the same as the LOD amount? Adding one more to the Max Collider Depth adds a collider to the highest LOD level but the field turns red. Even so, with or without colliders at the highest level, my gameobject just refuses to collide with some meshes but does collide with others. This doesn't seem like a problem anyone else has had so maybe it's my system? This is a major headache and is preventing me from exploring more of the features of SGT. Would you be able to provide me with a simple scene that has working collisions on your system so I can check if my system isn't the problem?

 

Hey, @Darkcoder

I just fixed a per-frame allocation I was getting from SGT. SgtHelper.WriteShadowsNonSerialized() is doing string concats which were resulting in 0.6KB per frame for me (on mobile). It looks like all the calls cap it at 2 shadows so I added this:

    private static readonly int[] ShadowMaterialIds = {

        Shader.PropertyToID("_Shadow1Matrix"),

        Shader.PropertyToID("_Shadow2Matrix"),

    };

then swapped the SetMatrix() call to this:

SetMatrix(ShadowMaterialIds[shadowCount++], matrix);

and made an overload of SetMatrix() that takes int for key (which works with no further changes).
I can supply a diff if that'd help.

 

The Max Collider Depth field turns red if it's higher than the amount of LOD levels, to make sure you're not doing anything wrong, but it will still work. I notice no issues with the colliders though.

I've attached an example scene that has 3 terrains with 3/4/5 LOD levels, and notice no issues with collisions.

Thanks for finding those, I'll fix it in the next version

 

Thanks DarkCoder...it was my system. Reinstall fixed it. Sorry about that.

On another note...any idea why I might be getting dark artifacting on my atmosphere?

 

Do you have a screenshot of this artifacting?

 

It only seems to happen when I rotate the camera quickly which makes holding windows and print screen with one hand and flailing the mouse with the other. This is the only image I could capture. Hope it's enough.

 

It looks like some pixels of the atmosphere mesh are going out of the view frustum. Does the issue go away if you increase your camera's far clipping plane?

If you can describe the exact steps required to reproduce this in one of the example scenes then I can see if I can replicate the issue, or attach some scene that uses the example media and scripts.

 

Hi Darkcoder.
It look's pretty good.
Regards.

 

I am just checking back on this comment and see if you have started working on this yet. I know you have a lot to do, so im not trying to come down on anyone, im just curious.

I just saw another version of Planetary terrain and i was wondering if something like that would ever be applied to this package. I know if you did, it would not be an abandoned project like the previous version of planetary terrain. This new asset claims he can scale earth 1:1.
Do you have any thoughts on this?

 

I have no immediate plans to work on this feature. Besides fixing bugs I'm currently focusing on improving demo scene polish and optimizing all my existing assets. The main way to improve terrain performance is by making it multithreaded, and the new job system coming to Unity 2018 may make this easier, so I'll wait until I begin any experiments.

Are you referring to THIS asset? Anyway, as I've said before the terrain system isn't a main focus of this asset because people's imaginations run too wild and make such a system impractical for anyone to develop, leaving behind a lot of abandoned assets due to how much upkeep they require. The same thing happens to most voxel world assets.

 

Good day, I really would like to buy this asset. I am very very new to unity and I am looking for an "infinite Universe" asset!
would SGT do that ?? Would you know such an asset?

Thank you,
lolo.

 

(I am just an owner of the package)

SGT is a graphics package at its core giving additional scripts to easily add these graphical components to a scene. An infinite universe however, is a different matter: you need a very well thought out procedural generation system (I doubt there is an asset for this). To visualize your generated data you could then use SGT.

 

Thank you so much for answering. I will definitely buy this asset once I know how to use it.
Have a good day, Lolo.

 

HI Darkcoder,

The mesh colliders don't seem to work in Unity 5.6.3 and above? Is this part of the asset not compatible (everything else seems to work fine)?

 

Mesh colliders for what? Please describe the steps required to replicate the issue.

 

The colliders on the sgtTerrain. They work fine in 5.5 but don't work in 5.6.3 or above with exactly the same settings. Even with the package you sent me (to show working colliders) they simply will not work in 5.6.3 or above.

 

It seems like later versions of Unity 5.6.X change the MeshCollider code, causing this issue. I've sent you a script that should fix it.

 

Any information on some new updates? Like procedural clouds, etc.

 

I'm currently working on the origin shifting system and many things related to it.

 

Very juicy, I would have to say.

 

What kind of stuff that's going to be added to the floating origin? Any information you could share on it?

 

In the Documenation/Components folder there are a bunch of PDFs for each of the scripts that exist. Is there a consolidated Index that summarizes the entire asset?

 

Right now the system is designed to support a universe of +- 1,000,000 lightyears on each axis, and can be rendered using any number of cameras. Each camera can be configured to render a different object scale (e.g. 1:1, 1:1000), and there are components that seamlessly handle the switching of your GameObjects between these different scales, as well as loading and unloading of prefabs based on distance. There's also the ability to pick distant objects on the screen and smoothly warp to them.

This system works well and is ready for release, but I want to update the other components to have better compatibility with it. For example, the shadow and light system in the current SGT build works well for standalone scenes that you manually set up like the demo scenes, but these settings can be fiddly for a dynamic universe that has things loading and unloading all the time, so I need to develop systems to make that easier. I also have new ideas for code optimizations and improvements that I want to experiment with, so it will take a few weeks at least before it's all ready. I'll send you some builds soon!

Not in the form of documentation. The store page description and screenshots are the only places where the main features are listed. Inside the asset you can right click the Hierarchy and see them under 'Space Graphics Toolkit', or see all components under 'Component/Space Graphics Toolkit'. A lot of the smaller components (e.g. used to bind demo scenes) don't have documentation, but have brief comments in the code, or tooltips.

 

Sweet! Would love to test this.