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.
New Unity Live Help updates. Check them out here!
Discussion in 'Assets and Asset Store' started by Darkcoder, Aug 18, 2012.
Do your shaders support camera-relative rendering described hier?
Fantastic work! Hopefully someone here can help you out with the project
Interesting. Assuming Unity modifies the input matrices automatically then it may work, but I haven't tested it. I wonder if this feature merely adjusts the positions, or also changes the depth to be logarithmic or similar. If so, that would be very nice.
Hi, thanks for the amazing graphics toolkit.
I'm having a problem with Infinite Warp: the Starfield with "stretch" property is flickering a lot when the object moving through it has a Rigidbody and there's some force acting on it. This happens both on Unity 2019.3.1f1 and 2019.2.9f1. Using Floating Origin makes no difference.
Steps to reproduce:
1. Import SGT to a new project
2. Open a copy of scene "33 Infinite Floating Origin"
3. Select "Main Camera" and add a Rigidbody component with default configuration (mass: 1, drag: 0, angular drag: 0.05, use gravity: yes, interpolate: none, collision detection: discrete)
4a. Set a non-zero gravity in Project Settings -> Physics and make sure that "Use gravity" is checked on the Rigidbody
4b. Add a simple script that does GetComponent<Rigidbody>().AddForce(...) in FixedUpdate
5. Hit play
The stretched Starfield should flicker like mad as soon as your object starts moving. By "flicker" I mean alternate rapidly between being drawn and not being drawn. Stretching itself seems to match camera movement correctly. The other Starfield (without Stretch) is not affected by this problem.
Setting "Interpolate" to either "Interpolate" or "Extrapolate" on the Rigidbody makes it slightly better, but the Starfield is still flickering if I try to rotate the object or move it with default controls that are set up in the scene. The flickering happens no matter whether I'm in Editor's play mode or using the standalone player. It's reproducible both on Windows and Linux. My graphics card is Nvidia GTX 1060 with fairly recent drivers.
Has anyone else seen this problem?
The issue is that the physics update in FixedUpdate, whereas the stretching updates in Update. Changing Rigidbody.Interpolate to Interpolate fixes this, because now the positions are being written in Update. However, the demo controls still directly adjust the Transform.position values in Update, and these new values aren't registered by the physics system until the next FixedUpdate. This means the interpolation is still working with the old values, and thus there's a positional dispairty that causes the flicker.
I'll send you an updated build shortly.
Hi Darkcoder, just wondering how the planet tech is coming along.
I've been working on it quite a bit this week, and good progress has been made. I'm mostly focusing on simplifying the code, and optimizing it right now. I'll hopefully have a video or something very soon
Alright, here's a video of the current state of progress:
This is a 1:1 sized Earth with 19 LOD levels, and it takes just over 3 seconds to fully generate from a cold start.
Each triangle at this depth is around 1x1 meter, and while it's possible to add more levels, you run into noise generation artefacts if you go deeper. These artefacts are due to Unity.Mathematics using single precision noise functions, so it's not something I can easily fix. However, I'm satisfied with this level of detail so I don't really care to investigate workarounds to this. If you use a moon sized planet instead, then you can get much higher detail without running into these issues.
I decided to go back to the tessellation style LOD blending I experimented with earlier, as I think the seamless look without popping is quite nice. This approach also allows me to simplify the code a lot, which makes optimization much easier. I also came up with some clever ways to pack the mesh data, so the vertex data transfer required is fairly low.
More to come soon
This is amazing.
Why you can't use an external noise lib like this one?
Because Unity's mathematics library is specifically designed for burst, and it's insanely fast. I tested the FastNoise Simplex noise before, and even with burst it's much slower than Unity's version. Perhaps there's some noise library out there that is of comparable speed, but I don't want to deal with third party licenses (can't use GPL). The planet data itself is all doubles, so if someone really wants higher resolution and/or planets bigger than Earth, then they can replace the code with their own. Also, the terrain heights are only one part of the puzzle, actually spawning grass, trees, etc on the surface to even suit the current resolution threshold is going to be a challenge.
I see. Another possibility would be to ask the Unity mathmatics team if they could implement doubles.
I have made a short video with the new SGT terrain component. It's an early preview, but it shows how impressive it is. You really feel the height of the mountains at this large scale if you fly around them. The planet is ~6300 Km in diameter. The planet is made without using height maps, it's all procedural math.
Will it support smooth transitions from space to surface? Also will you be supporting vegetation? If not will it be compatible with options such as vegetration studio pro or cpuinstancer?
thanks, can't wait for this update to be released.
Holy crap, this puts my example demo scenes to shame
Also, you can increase the atmosphere's Occlusion setting to make the scattering not draw though the planet.
Yes, it already supports seamless space to surface travel.
Yes, I will add some kind of glass/tree/rock/etc placement system.
Keep in mind the features seen in that video will be part of a new asset, as this took a lot of work to develop, and this adds many new (especially procedural) features. I may replace the current SgtTerrain component with a cut down version of this though, we'll see.
I wanted to show how incredible this new asset is, even in this early stage of development. You did a fantastic job.
Increasing the atmosphere's Occlusion works, thanks.
ooh, can i try it <3
Yes, I'll send you a build soon!
I'm currently still doing a lot of experimenting with the terrain generation code itself. Once it's a bit more finalized I'll have some easier to use components for everyone to test
Looking forward to it, looks amazing great work!
I want to share some new testing screenshots made in the latest version of the new SGT Terrain component. This time I tested texturing with three 8K slope textures (Compression: high resolution / 85 MB each) and one main texture (Compression: high resolution / 85 MB). I also used mipmap streaming and mipmap fading on all normal maps, because it is not necessary to see them from distance.
I could not see any texture flickering or other issues and it looks pretty awesome.
@Darkcode: Fantastic work!
Whoa, that looks so good I don't believe it's the same set of components I gave you
When you say three slope textures, I assume you modified the shader to layer them in? Looks great! I will soon implement a much more flexible texturing system to make this easier. I'll use your images as a reference. Those results look incredible for such a small change though!
The past few days I've been experimenting with foliage placement, and it's been pretty interesting. I thought instanced mesh drawing would be the obvious solution, but Unity makes this kind of tedious to do for a number of reasons. Most importantly, SRP Shader Graph shaders don't support instance specific values like color... so there's no way to make each one have a unique look besides scale+rotation+position. Secondly, you draw them using a list of matrices, and updating a list with so many instances can be slow, and this must be done quite a lot since this planet uses a floating origin system. You would normally be able to just handle this shift using a single matrix in the shader, but of course you can't do that with surface shaders (and maybe Shader Graph? haven't tested), because the vertex output must be in object space. Finally, I decided to benchmark mesh instancing (with cached matrices) vs manual mesh batching, and it turns out manually batching is so much faster that it's not even close. Perhaps each instance is frustum culled, thus eating up a lot of CPU time. Either way, results so far are promising.
Yes, it is the same set of components.
Yes, I added 2 more textures to the shader. Each textures has it's own tiling, normal scale, sharpness and slope angle. That's all I modified for this result.
Here is a (low quality) video of the work I've done on SGT's terrain system. It's unfinished and thrown together but I hope it shows the possibility of using layered masks to create decent visuals from space to the surface.
I'm only using one biome here. It's made with satellite height data of Colorado, run through World Machine to create higher detail and RGB masks. It's tiled twelve times over a 2000km radius planet. The detail heights and maps are then tiled 500 times and use the main biomes mask for height and placement. A couple of detail normals add another level of detail.
My plan was to have three biomes that have the broader features you see from space. Each biome would only be able to use the three detail maps with this method as Unity's shader only allows up to 16 texture samples (1 main mask, 3 biome masks and their 3 normals, 3 detail masks and their 3 normals and 3 detail textures). Then I was going to make a system to enable me to paint the biomes onto the planet (should be quite simple?).
But it's time to move onto the next version!
Darkcoder, would this approach work with your new system? Could the procedural terrain work with masks and blend with heightmaps? Could the shader be extended with another pass to increase the variety?
Looks great. If you want to use DX 11 you can use up to 128 texture with 16 sampler. In DX 11 you can reuse sampler.
Awesome! Thanks dude.
Hello! I just purchased this asset and it's awesome.
I do have a question about the Infinite Warp effect. Where in the code can I change it so that the stretch is based on the movement of another game object as opposed to the main camera. I'm not seeing it anywhere. Any help is appreciated. Thanks!
Wow, impressive to see how far you've taken the terrain system! Real height data also looks so much better than procedural data, at least from a distance.
The new system would indeed allow you to use texture masks to define where different terrain types appear, as well as a fully procedural approach, or some combination. Now that I see these great results with real elevation data I might make some kind of component to include these without relying on tiling.
After you enable the Stretch setting for the warp effect, you can see the Stretch Vector, Stretch Scale, and Stretch Limit settings. You can disable the automatic stretching based on camera velocity by changing Stretch Scale to 0, you can then manually specify your own with the Stretch Vector value.
Would you be able to help me fix the planet textures? I have a new Unity scene 2019.3.2f1 and have URP installed. I downloaded SGT and opened the Aurora scene. The planet has the hot pink color of a shader that isn't processing correctly in URP. Thank you, Matt
Did you follow the steps in the documentation HERE?
Brilliant, Thank you Carlos! I've bookmarked the documentation page.
Would this asset be able to take NASAs dem/terrain data and make a a planet?
Not sure what format you're referring to, but SGT uses heightmap data encoded in the alpha channel (SgtTerrain + SgtMeshDisplacer), and red+green (SgtMeshDisplacer) of a texture.
I am talking about this file, specifically - https://astrogeology.usgs.gov/searc...MOLA/Mars_MGS_MOLA_DEM_mosaic_global_463m/cub
The smaller jpg could be used, but the tif file there is way too big for Unity to handle, not to mention the data is probably stored in a 16 or 24 bit channel which Unity also couldn't handle. You would have to convert this into a separate format (i.e. not an image), and write your own code to sample it. The next version of SGT (coming out soon) comes with a new terrain system that will be easier to modify, so rendering this kind of file wouldn't be too difficult. Converting that tif to an array of float for example would probably be the most challenging part.
Yes, it is stored in 16bit (2Byte) array. My other problem though, is that it is equirectangular projected onto the "canvas" so that it can be easily wrapped onto a sphere (looks great before all programs that I use crash trying to render it). So my goal is to convert it to tiled terrain data to be used in Unity. The secondary issue being that tiling the image is easy, I've done it a few times... however because it is equirectangular projection the tiled information slightly past the centered equator loses accuracy the further it gets away (because it is being stretched). So I was kind of hoping your toolset could handle some of these issues?
edited to add- the data set is quite easy to work with honestly, its just the conversion part thats killing me (equirectangular - to tiling) so that it can be rendered without crashing. This is afterall close to a 1/500th scale of a planet using meters.
This is a very project specific requirement, so there is no tool in SGT to do this. It shouldn't be too difficult to do though. This is how I would do it:
1 - Create a rotation+scale matrix that defines a cube that intersects the planet sphere (or just store a point and right+up vectors).
2 - Loop through every x*y pixel of your final image, and get the 0..1 UV of it.
3 - Multiply this UV by the matrix (or get the point + right*u + up*v), and you will get a 3D point, which you normalize.
4 - Convert this point to polar coordinates (atan2(x, z), asin(y)), and scale to 0..1 UV.
5 - You can now sample the DEM at this UV, and write it to your current x/y pixel.
6 - Repeat for every pixel.
Keep in mind this will still give you a distorted texture, since there's no way to map a sphere to a plane without distortion. The amount of distortion will be proportional to the size of the sampled area though, so smaller areas will look good.
I've been working on this over the last 24 hrs (not your method though, because... (atan2(x,y), asin(y)) - Foreign language stuff )
I was able to convert it over to a cube map using tools from another developer that came with a game that I bought... but... for some reason when I import them into my other program, it mirrors them, almost like its being put onto the culled side of a plane and inverted in the other direction? Dont know, it is confusing. I am going to work on it some more today.
I bought a few things lately so my wife has forbidden me from the asset store, but Im watching your tools
btw... using your method... how difficult would it be to have a script mesh the entire planet out (from center to calculated location of pixe), and then run another script that uses the 0,0,0 (center of the planet) to create projected slicing tool to create 4096 tile cuts (remesh from the larger object into smaller objects of 4096 tile sizes) - that way, you can keep the curvature? (maybe even skipping the whole creating a mesh first so that you can load and unload the "tiles" as they are generated). Really hoping unity considers investing in projection method terrains also... because... its reality.
Edited to add:
Was thinking about this too. The tiling could be calculated easily because Geotif already know Max Height, Min Height, Avg Height, Radius of the planet and then could in theory calculate at that distance the matrix (spherical?) and collect the information in said matrix and make a mesh with those boundaries.
Try the attached package
Thanks for the link. I will play with it a bit more. Couldnt get it to do what I needed (100,000 x 50,000 W/H Image - Unity hates the file) so... but interesting for sure. Thanks for the link. I think you meant that one because of all the built in functionality? Anyways... I appreciate it.
Wait... so how do you do this...
This is sort of what I am after (as an end result) Can it only be generated with procedural or can I use a variation of heightmaps with Space Graphics Toolkit etc? Any tutorials for generating the meshes necessary for "landing" on a planet? If I can make something like this with my files then Id definitely get the package. It doesnt have to be "Unity Terrain" as much as it just needs to actually have a mesh structure where objects can be placed and there can be good quality graphics (like say real world scales - and the planet isnt only 1km wide.
It's just an example of most of the code required. To sample your huge image you obviously can't use Texture2D's GetPixelBilinear, and you would have to replace it with your own. That part should be much simpler than the spherical coordinate stuff though.
This is using the SgtTerrain component (soon to be upgraded ), which is available in the current version of Space Graphics Toolkit. It procedurally generates this mesh and increases the detail based on camera distance using a heightmap you specify. That's just a test using Unity's wireframe shader, but you can also use the SGT Planet shader that has more things that you can also customize.
Do you really want to manually place objects on a planet that is "real world scale"? Let's say you spend all day manually placing objects in a 1x1 km area. You now have to repeat this process a mere 510,100,000+ times to cover the whole surface. Seems silly.
So to answer your last question, yes and no. I have 2 potential uses.
1) requires full scale, as I have worked for land survey companies in the past and could potentially use such a tool to provide extra work from(get)/to them in various areas and I have a general need for it based on a Design. Also another part of this requires actually mapping out entire spheroid bodies that exist and matching the terrain data within a 1/3 of a meter accuracy which is possible with some of the data for some bodies and will be possible in the next 4 years as more data is analyzed and release.
2) Not really. I guess in reality, since there isnt enough data anyways, the dimensions could be whatever, just as long as the planet seems big, and I can fix certain features to the planet (models will stay in place even with LOD changes and wont fall thru the planet (how do you handle floats/doubles)? I would not need to add many design models that need to be rendered to it either. More so it would be a few empty game objects with colliders of sorts that are holding data and it changes over time type of deal. So it would be easy. Too bad this does not work with Gaia yet I am assuming, if I needed that type of generation feature/objects set.
If I can ever find my balls and attempt to work with calculus I might finish that projection tool.
*** What do you mean about the heightmap I specify... so I can use cubemap heightmaps? If so at what resolution (assuming the 4gb limit, or is it 2gb)? Would like to learn more about that...and specifically if it were possible that I take your script (when I purchase) and write my own standalone C++ program to project a cubemap to a sphere to generate a mesh ( I need to learn the format that Unity uses for its mesh data in the mesh filter though, and all of those parameters, if you know any sources I would like to learn that) and then your other feature sets to do the LOD.
When I talk about heightmaps I'm no longer talking about textures, because Unity cannot handle textures this large. For you to sample your DEM data, you must load it as an array of float/short data, and then write your own code to sample it based on a given UV coordinate. The package I attached above shows you how to sample a Texture2D based on a UV, 3D point, as well as a 2D quad. The only part of the code you would have to replace to support your large DEM data is just the one line with .GetPixelBilinear(u, v). There is no need for any complicated mathematics as the rest of the code there does that, and doesn't need to be touched.
If you wrote that line, then it would be possible to more or less plug it into the new terrain component (coming soon™), and have the SGT planet have much higher resolution heights. The components I'm designing are only using texture based heights with procedural detail, because this is more than suitable for almost every Unity project, not to mention the vastly reduced memory requirements make it more practical.
As for object placement, there is the SgtTerrainObject component, which keeps the current GameObject snapped to the surface of the planet. This uses the direct height data though, so the LOD can can cause the object to become invisible in some scenarios. You can reduce this issue by placing the object on top of a vertex though.
Keep in mind the currently live version of SGT only works for planets up to 100km or so in radius before mesh cracks begin to appear from floating point precision issues. The next version will include an improved component that supports much larger planets (e.g. Earth radius) without these issues. However, at these scales the planet shader itself becomes incapable of tiling the detail textures properly without UV flickering due to floating point limitations. Solving these issues is more advanced and will be part of a new planetary terrain asset I'm working on (see pics and videos above from testers).
Yeah, you are probably right about the real world size of the planet being a bit much... because... This is one of 96 Tiles that I have made of Mars... and it is only 1/50th scale of the actual size... also Mars is on the smaller side compared to Earth... really puts it into perspective once you see it.
I've almost finished work on version 3.7.0 of SGT. The biggest change is the replacement of the SgtTerrain component with the new SgtDynamicPlanet component. Here's a video of it in action:
SgtTerrain uses compute shaders to run fast, but platform support for them doesn't seem to be improving, so it's not a good technology to rely on. This new SgtDynamicPlanet component does away with that and instead calculates everything on the CPU. Performance seems similar if not better, and it of course now works on all platforms. Just like SgtTerrain, this new component is designed to render planets based on heightmaps using the SGT Planet shader. Fully procedural planets, foliage spawning, and other vastly more advanced features will be part of a new separate asset that I'm still working on.
I plan to submit this in a few days, but Unity is in a backlog right now I believe, so I'm not sure when it will be accepted.
Indeed, real planets are huge. If you need high fidelity terrain that requires a lot of manual placement then traditional square terrains are the best solution for a million reasons.
Btw, the video is private, so I can't view it.
Hello! I bought SGT recently and it has a great potential
I want to ask several questions related to SGT terrain:
1. Is it possible to add more subdivisions for SGTTerrain component (or tell how to do it)? I found that terrain levels are defined in SgtTerrainLevel.cs, but I can't understand the logic of index buffers. Also is it possible to generate such arrays somehow?
2. Does SGTTerrainSpawner support some sort of spawn mask? For example, I want to spawn trees in certaint places of the planet, I draw texture where black pixels are empty space and white pixels are space with trees (in the same UV coordinates as heightmap), and then assign it in spawner component.
1 - The arrays there were hand made with a quick tool I made. It's possible to generate them with code, but I wanted them to be pretty and symmetrical which probably would have taken me longer. Extending this yourself would be quite difficult, so I don't recommend it. The SgtTerrain replacement (see video I posted above) comes with code to generate the chunk data based on one constant though, so you could modify it very easily.
2 - It doesn't, though the new terrain has this.
I can send you an early test build if you'd like?
Hello! Can anyone help with Floating Origin? is exist any easy setup asset/script to use galaxy-big floating origin system in one Unity3D scene with many different planets... but with assembly planets from square pieces of terrains, for example assembly cubicsphere to each planet ~50 squares of 300x300 Terrains? Or detail instruction with screenshots how to do that?
I dont have an answer for you, but I do have a suggestion (because this is an inherent issue with Unitys floating point solution) look into Using DOTS and having coordinates shift around the player in circumstances like flying as well as advanced calculations (easy once you flesh it out) for scaling objects based on distance and replacing them with sprites etc etc etc.
That's where i am in my current researching of the topic. Also consider object coordinate system. Create a matrix of collides that you cant see that also cull the others and when you are in them its attached objects are also visible etc etc
Oh and also, integrate them size wise in meters with mm precision. You can lock them to a coordinate system and triangulate your position with the bounds and extract it that way, possibly.
SGT's 'Universe' feature is a floating origin system that can make large scenes. It's a little difficult to use, but this will be greatly improved in the upcoming version 3.7.0.
I'm not sure what you mean by construction of a planet using 50 terrain squares, since normal terrains can't be transformed like normal GameObjects, so that wouldn't work. If you have 50 normal meshes that can form a planet then that would work with SGT though, but you might want to use the planet features of SGT to make it instead to save yourself some headache.