A Unity ID allows you to buy and/or subscribe to Unity products and services, shop in the Asset Store and participate
in the Unity community.
Introducing the new Universal Render Pipeline and High Definition Render Pipeline subforums!
Unity 2019.3 Beta is out now.
Discussion in 'Assets and Asset Store' started by Darkcoder, Aug 18, 2012.
I'll look into it. I imagine the tangents are incorrectly oriented or something.
Hello Guys ! I'm planing to by the asset, just one question Is real time Constellation available in that asset?
Nope, maybe in a future version.
Version 3.5.1 Out Now!
- Improved PS4 shader compatibility.
- Added Extract Cubemap feature.
- Added SgtShadowLayer to the Bonus Pack.
First and foremost, Im sorry if this information is posted here already, I was unable to find it using the search function.
I am interested in purchasing this but have a couple questions.
1. Are you able to provide documentation before purchasing? (Would help me decide if this asset is appropriate for my project)
2. As the code base sits currently am I able to define "planet types/properties" in json and use your toolkit to generate the planets, stars, etc?
1 - You can view the component documentation HERE.
2 - As long as you write the code to read this JSON data and create the SGT GameObjects/Components from it yes. The code required would be almost identical to just setting the parameters like you would in the inspector (and in the documentation above). The only difference being you have to also call methods like UpdateMaterial(), UpdateMesh(), etc to apply the changes. These methods are automatically called from the inspector when you edit values, but to prevent performance loss or excessive modification checking in Update I separated them, but you can easily see which methods to call by looking at the inspector code, or just calling all the Update__ methods after generation.
Nice! Wonder where the extract cubemap went there for a bit. Just checking in on something, hows the roadmap for procedural clouds?
I'm getting strange jittering effect on my texture on planet surface when i move the camera. The problem seem to get worse on larger planets and bigger texture tiling. I'm currently working on mars with scale of 6 779 000 units and the jittering is quite noticeable.
Also, do I always need to update terrain colliders on runtime for them to work?
edit: I fixed this. My solution was to add the Floating Object component to my second camera, with Monitor Position selected. I'm not sure if that's exactly right, but it's working so far!
First, I can't thank you enough for releasing the basic free version of your SGT. I've been exploring it for a couple days now, and it's really beautifully done. After reviewing the samples and the documentation, I'm still struggling with a couple of concepts.
First: I'm trying to select objects RTS style, with a second camera rendering the object close up on the UI. It's basically working, but I'm seeing the object snapping:
in the above gif, you can see what I mean. The bottom camera is the one I added, and when I click on the planet it positions itself above the object, that way you can be anywhere on the map and still see / act on your selection.
I found this in the documentation on basic camera setup:
NOTE: This snapping causes the camera’s Transform.position to change, which may cause unusual behaviour with certain camera control
components. To fix them, you must hook into the LeanFloatingCamera.OnPositionChanged event, and update the required values.
However I'm not really sure exactly what that means. I searched the scripts for examples of it, but couldn't decipher exactly what I needed to do. Is there something simple I'm missing? Here's the code controlling the camera:
Thanks for your work, and I appreciate you taking the time to read this!
Sorry for the late replies, I was on holiday and wasn't able to reply to everything in my inbox.
I haven't decided how it would be implemented yet, so I can't say. It will probably come when I get around to expanding the terrain pack, which will be a little while.
The terrain system isn't integrated into the floating origin system yet, so it's not possible to make such large planets without visual artefacts. I added it to my to-do list, so I'll get around to it soon!
Glad you found a solution. Making floating origin systems work with everything is indeed quite difficult.
Currently running Unity 2018.2.4f1.
In a normal 3D project, the free pack works perfectly. However, in a project using the new fancypants HD Render Pipeline, there are a lot of issues:
Floating origin is completely broken
The materials on planets and asteroids are busted, showing only as horrific Barbie-pink
Star flares are frozen in their original orientation and don't follow the camera
Movement works. Procedural object spawns work. Orbiting works, as do the orbit lines. (They're ugly due to precision issues from broken floating origin.) As far as I can tell, only those three items in the bullet list are not working.
I have no clue how just using a different render pipeline breaks the floating origin system. :/ The other two make sense.
I'd poke it more, but I've run out of time for the day. I understand if you're not gonna work on preview package compatibility: that's a huge can of ugly mutated worms. Just thought I'd bring this to your attention! :3
There's currently no SRP support, which is why 2 doesn't work. 1 & 3 are broken due to a bug or API change where cameras no longer call the Camera render events. Someone mentioned this in the beta thread and a Unity member mentioned looking into it, but I guess they forgot vv. When these new features get properly implemented I'll take a look, but I don't like changing things to account for bugs that may only be present in a few versions of Unity.
No problem! I only use the HDRP to get familiar with it before it's properly released, and my project is gonna stay in regular 3D for now.
Thanks again for offering the free pack! :3 I do plan to buy the full version in a couple years or so, if it's still there.
I was already using version 3.4, just tried to switch to 3.5 recently: it has amazing properties. I am very excited about this. There are two things that I couldn't handle:
1- In order to land on the surface of a planet, you have to make your player a child of the planet so that they will share the same rotational velocity (since, the planet is also orbiting around its y axis as well as the sun). Normally, I prefer to do so at a safe distance before landing finishes. But, floating point does not allow the player approach the surface any closer when the player becomes child of the planet. I have a plan B solution to this but I would like to ask if I can do anything to make this work to see the performance, first, and then decide to implement plan B or not.
2- When I copy the planets with atmosphere from the example scenes (terrain examples) and paste into my own scene, the atmosphere does not render when "Lit" option is checked. Actually, it seems to be rendered as black - transparent-black. Creating an atmosphere from scratch also produces the same result. I am using Unity 2018.2, but I also have 2017 on the other computer, haven't checked there, yet, though.
Thanks again for your work. This is an awesome asset.
1 - If both the player and the planet use the floating origin system then it may not work when you parent it like this. Even if it did, the coordinates would be very high and you would lose floating precision, thus defeating the purpose of using the system. The correct way to achieve this is by manually calculating the rotation and positional changes required to keep the player on the planet, without touching the parenting.
2 - Make sure the lights in your scene have the SgtLight component attached. I should really add an inspector warning if none are found. If this didn't fix it then let me know.
Thank you for the fast reply. Suggestion on atmosphere worked great.
How do you suggest to implement manually calculating rotation and position changes? The first thing I can formulate is: apply gravitational force on player + set player position to rotation * transform(localPosition). But, do you think this kind of approach work while climbing up/down hills; is it possible for the player end inside the planet object? Another formula I can think of is the SgtSnapToTerrain script in the older version. Do you think adapting that script to this version from earlier one is a better way of achieving this? It seems to be doing the same thing but much more gently.
You can do the same thing the parenting was doing. Basically, you need to copy+paste the UnityEngine.Quaternion class using double instead of float. Then whenever the planet moves or rotates you need to calculate the local rotation & local position of your player relative to the planet using an inverse rotation, then you update your planet orientation, and calculate your player's new data my rotating the local values by the new orientation.
Hay I know this is fairly new but is there a way to have different colors/textures on the planets given that using the new floating point system?
Like for instance, I added a color material on one planet and of course all the other planets are the same, is this not in yet? Without having to code anything.
But very awesome update- Couldn't wait for this update and more...
What do you mean? You can adjust the planet colors any way you like. The example only contains one planet prefab though, so you must add more to the SgtFloatingSpawner__ components if you want different ones to appear.
Hi, i'm interested in your asset, it's perfect for your game.
But i noticed that this extension requires one license per seat, i'm working with an friend in my organization, that means that i have to buy the asset 2 times ? The price: 99.95 USD converted to BRL it's 405,76. If we buy two times it's almost 1 thousand , it's too much for our budget, can we have an deal ?
And it's possible generate all the planets and stuff in runtime, i already made my procedural terrain generation but i'm interested in apply all this atmosphere and cloud effects in your planets !
I've been using your plugin for a while but since Unity introduced the new assembly definition file, I'm having issues defining an assembly/separate project for SGT. The reason for that is that your editor code is in the same file as your scripts. Can you split your editor code and your game script code in separate files please? It will make things much easier now and in the future. Thanks.
N.B. I manually split your code but it's very annoying because integration takes a long time every time there's an update to SGT.
No discounts. If you're only interested in planets and atmospheres then in the coming weeks I will release something you may be interested in. All editor features of SGT are available through the almost identical C# code, so yes you can make everything procedurally.
Thanks, I'll take a look. Keeping it all in the same file saves me a lot of time, but I guess Unity breaking things is nothing new. Hopefully there's some way to keep the current system by forcing the normal Editor assembly to load first.
Great plugin, I've recently been trying to integrate it into a simple project I'm working on but have come across an issue when trying to export for Android (Oculus Go in particular). My builds are failing due to a shader error, I've attached a screenshot below. Is this a known issue or could I have changed something without realising, it's unlikely I've changed something as I'm using objects copy/pasted from the examples but never rule out user error
Thanks for pointing this out. I've sent you a PM with an updated shader.
Hello, I've been using the asset for about a week now, and things are pretty awesome. I've even gone as far as to write some extra features for the base terrain shader to allow for some subtle texture variations
The problem I'm running into right now is LOD. It seems there's not really a lot of options when it comes to that. Specifically far LOD. I'm wondering if it's possible to set a minimum level of detail on my terrain, since I'm working with some fairly large distances here, and a terrain that looks like this:
from far away is not really ideal for me. I'd much rather have it something like this:
Is there already a way to implement this? Like maybe some snapshot thing that applies a fake texture to the terrain when far away? Anyways, thanks! Hope you can get back to me
I think, I see what you mean. You mean an orbit texture, what you would see from space, and then a ground texture. I'd also like to have this, cause If I make a grass texture super small, then its weird looking from space. +1
I actually had a pretty good idea for this using the terrain shader.
1. Generate a heightmap after the terrain height has been set.
2. Instantiate a geosphere to work as the LOD model, and copy the material from the terrain to the geosphere.
3. Using the terrain shader on the geosphere, add a toggle that lets you switch between an "LOD Mode" and the regular shader logic.
4. Pass the heightmap into the geosphere's material and toggle the LOD mode. LOD mode will use the heightmap color value (with some added variables for saturation based on terrain radius and stuff) to draw the textures, same as the terrain (just using a heightmap instead).
5. Based on the distance to the terrain toggle between the geosphere and the terrain.
I'm gonna try this and see how far I get.
You can already do this by adjusting the LOD distances, simply increase the first few until it's split at the distance you want.
The problem with making some kind of fake texture LOD is that unlike most of the other components, SGT doesn't control the surface material/shader. Instead, this is specified by you from the inspector's Material setting, so this kind of feature would have to be part of the shader you pick. It could fairly easily be implemented as a cube map lookup using the local vertex position, and faded using the fragment distance in world space, but making the texture look the same as the normal surface would be difficult, and I don't think most people would bother doing this.
Hi, i've experienced some bugs with mesh colliders of SGT Terrain
In some cases, the colliders are overllapping another ones, and in another cases they were not even created. There is a single hole in the meshs, and my character just fall.
I send some prints, some of this mistakes happen in your procedural terrain example scene.
This is a bug or i'm doing something wrong ?
Having issues with the solar system pack, using the latest SGT (full) asset and when importing the example pack I cannot load any of the example scenes, they all have errors (most null reference).
I'll do some tests now.
You can get the latest packs from HERE, where the 3_5_0 ones are the latest and should work. I'll organize the files better and update the links later today.
Colliders on SgtTerrain don't generate until I choose "Update Colliders" on context menu on runtime. That might be the reason for allakazan5555's player's fall. Then, in SgtTerrain.cs I set DelayUpdateColliders to true on line 169, everything worked great. Maybe this helps.
@SinDeSiecle Thanks, i set the variable and the colliders stop to be overlapping, but still with the holes in play mode.
You know where this "Update Colliders" button stay ? I can't find it
Btw, this error just occurs in play mode, in edit mode they are generating correctly
Keep in mind doing 'DelayUpdateColliders = true;' will cause the colliders to get updated every frame, which may be slow.
I sent allakazan5555 some updated scripts which should fix the issue.
Also keep in mind that when the collider depth matches the current LOD depth, the visual mesh and collision mesh will overlap exactly, which can make them impossible to see in the scene view depending on your rendering settings. You can click on the terrain to select a terrain face and disable the Mesh Renderer to see the collider, and also see the collider state in the MeshCollider to confirm it's enabled and has a valid mesh. The actual active collider may be in a parent though depending on your LOD state and collider settings.
Very interesting asset! Tempted to buy straight away for the shadow features, I gotta ask though, is it mainly for viewing planets from far away?
Our game has people walking on the planets, and the planets aren't super big. We are using a single directional light, so the other side of the planet is not lit very well and it generates some bad lightning.
Your shadowsphere should be the obvious choice here, yeah?
The shadow system works for any distance, but each shadow caster is calculated separately in the shader, so it's not suitable for lots of casters. In fact, the built-in shaders are only designed to handle up to 2 active shadows at a time, because this keeps the shader complexity down, and most space scenes only need this (e.g. one ring shadow constantly on the planet, and one major moon shadow on the planet at a time). The built-in SgtShadowLayer component allows you to stack as many casters as you want to opaque geometry, but since it adds more draw calls it's not recommended for your scenario.
If you want to cast lots of small shadows then I recommend you use some type of decal system.
So even with a single shadow caster, what results would that give? Any different to having a single directional light?
Unity's directional light uses shadow mapping, where it renders the whole scene once for each cascade to a render texture, and when rendering the objects with shadows it projects each pixel against the render texture depth to see how much shadow it should get. This works well for complex shapes and lots of objects, but the render texture has a fixed resolution so it can only work over a relatively small area.
Whereas the SGT shadow system simply stores the shadow caster data (e.g. position, radius) in a few shader variables, and when rendering the objects it projects each pixel against the shadow data to see how much shadow it receives. This means the shadow is incredibly high resolution, fast to calculate, and can work across vast scene scales, but it also means each shadow is visually limited to simple geometric shapes like spheres or rings. These shapes are of course visually enhanced using baked textures (e.g. penumbra, ring lines), but they won't be able to handle a rotating asteroid and accurately depict the surface bumps or something. This technique is very similar to how spotlights with cookie textures work.
Interesting, thank you very much for your reply. I'm having quite a lot of enviromental movement, so realtime lightning is needed. Still a very interesting package with all the other modules, now that I won't be using lightning.
- On your website, I didn't find any contact information, but I have a topic I would like to discuss with you regarding LeanPool, shall I PM you here?
Sure, you can PM me, or email. My email is listed on my publisher page, or in the Read Me.pdf of any of my assets.
Hi, i've been interessed in your Terrain Spawner script.
You have any example or tutorial of how to use it ? I tried to put the scripts together in a gameobject but nothing happened
I'm working on some terrain-tools for SGT terrains (for example, I am trying to combine the heightmap and simplex noise without pixel effect - bi-cubic interpolation?) and I'm wondering if you're working on any similar tools for the next update?
Sorry for the late reply. There's no example scene for this currently, I will add one when I get around to updating that part of the asset which will be after I update the planets and stars. To get it to work you need to add the SgtTerrainSpawner to your terrain, and add the SgtTerrainObject to your planet object prefabs. You can then drag and drop the prefabs into the spawner's 'Prefabs' list. You then need to adjust the spawner settings, for example the Depth should match the LOD split depth you want these prefabs to spawn on, and the Height Min/Max correspond to the SgtTerrain.Radius + heightmap/simplex displacement, to stop objects spawning under water or something. You should also increase the Spawn Count Max + Probability, so something can actually spawn.
Sounds good. I'm currently working on updating the planet features, and won't be touching the terrain stuff for a while.
Updated recently and SgtBoxStarfield is now removed. How can I replicate this using the new system?
If you were using it for infinite starfields/clouds/warp/dust, then the new SgtStarfieldInfinite component should be used instead.
If you were using it for an actual box of stars placed in the 3D scene like normal then there's no longer a component for that unless you use the custom starfield with stars distributed in a box. If you were using it for this scenario then I can quickly make a new version of it?
Yes, we was using it for distributing stars within a box, would be good to get that back.
I sent you a package via private message.
Hi @Darkcoder, i want to implement your floating point system, but my camera are inside a gameobject, and when the camera move i need to the object move too.
I tried to move the floating origin and floating camera to my main object, but when i do this, the object keep the same position on the screen, and the planet don't move.
You can help me with this ?
Your SgtFloatingCamera.Scale is set to 1000, which probably doesn't correspond to any objects in your scene, so their positions aren't updated. I'm not sure why I set 1000 as the default, but changing this to 1 probably fixes the issue. I've attached a demo scene demonstrating the "Floating Camera" scene modified for third person view.
@Darkcoder Thanks !
The floating system worked as well, but there's a problem.
I copied your cube example to my scene and everything work fine.
But when i set a rotation for the camera transform, the parent Cube object started spinning like a hell.
There's another trick to set a camera rotation or this is a bug ?
PS: I made a gif to exemplify my problem