I am making an open world game and i want to know if there is a way of doing terrain streaming ( loading the terrain into mamory only if the player is close to it ) without using the LoadLevelAdditiveAsync function . i am using free version so this function is not available to me .
Don't forget as long as your terrain patches together nicely, you can always Instantiate terrain prefabs at run time.
Depending on how proficient you are at it, you can also procedurally create terrain at run time as well.
You can do it, and there are different ways to do it. I figure the easiest way to do it (but definitely not the most memory friendly) would be to define your entire level in one scene with multiple small terrains, using the TerrainStitcher tool to deal with seams. Then you could parent all objects under each terrain to a single transform, and use Instantiate to create/destroy them at runtime (in another scene). There are tools that take this approach a bit further, like this one.
But remember that in general big terrains in Unity aren't memory friendly and will reduce your performance. When using an endless terrain, where you don't care about defining the terrain before runtime you can reuse a few terrain objects and simply reposition them, but if you're designing them first, there isn't too much you can do other than lowering terrain settings like Pixel Error, and limiting details and grass.
Related
I am working on a Projection Mapping Project and I am prototyping in Unity 3D. I have a cube like object with a 3D terrain and characters in it.
To recreate the 3D perspective and feel I am using two projectors which will project in a real world object which is exactly like the Unity Object. In order to do this I need to extract 2D views from the shape in Unity.
Is there an easy way to achieve this ?
Interesting project. It sounds like you would need multiple displays, one for each projector, each using a separate virtual camera in Unity, like documented there.
Not sure if I understood your concept correctly from the description above. If the spectator should be able to walk around the cube, onto which the rendered virtual scene should be projected, it would also be necessary to track a spectator's head/eyes to realize a convincing 3D effect. The virtual scene would need to be rendered from the matching point of view in virtual space (works for only one spectator). Otherwise the perspective would only be "right" from one single point in real space.
The effect would also only be convincing with stereo view, either by using shutter glasses or something similar. Shadows are another problem, when projecting onto the cube from outside the scene. By using only two projectors, you would also need to correct the perspective distortion, when projecting onto multiple sides of cube at the same time.
As an inspiration: There's also this fantastic experiment by Johnny Chung Lee demonstrating a head tracking technique using the Wii Remote, that might be useful in a projection mapping project like yours.
(In order to really solve this problem, it might be best to use AR glasses instead of conventional projectors, which have the projector built in, and use special projection surfaces that allow for multiple spectators at the same time (like CastAR). But I have no idea, if these devices are already on the market... - However, I see the appeal of a simple projection mapping without using special equipment. In that case it might be possible to get away from a realistic 3D scene, and use more experimental/abstract graphics, projected onto the cube...)
I am new to Unity and would like to be able to emulate the idea of 'digging' a hole in the 'earth' with a spade, at runtime and have the terrain slightly ahead of my camera lower slightly, then move that dug 'earth' into a pile somewhere next to the hole.
I have created a terrain using the preview terrain tools and now want to alter it at runtime a little like you see in this part of this video : https://youtu.be/l_2uGpjBMl4?t=2970
I want to be able to make a small 'dig' into my environment, just like a spade making a hole in the earth, and that state to then be something I can persist.
I then want to be able to move the 'dig' volume, i.e the 'earth' onto somewhere else in the terrain - literally imagine what happens when you dig a hole.
If I want to follow this guy's video, he is generating his terrain, and I am not sure how to apply his logic, because I would likely want to shoot a raycast from my camera, and where it intersects with the world, then alter the 'mesh' of my painted terrain, and then add to a 'pile' of earth somewhere else. I am not sure about just doing the piles of earth with just changing the height of the terrain, because there would need to be a volume associated with the 'earth' you have dug, so it's more of a object, than a terrain if you see what I mean.
I realise this is a bit of a braindump, but I am looking for direction and have done research these are the questions I would like answered, I want this to be a sounding board for whether my thoughts are on the right path, and if not, what is an optimal course for learning some techniques for achieving this.
You need to use Terrain.terrainData which contains the GetHeights and SetHeightsDelayLOD methods. SetHeights is also available, but is not as efficient. Check the documentation to see how they work!
Feel free to close this question if it is deemed too subjective. I realize that it might very well be, as it may focus heavily on best practices, which, if not an industry standard, may be subjective.
The Problem & Idea:
I'm using the tilemap system in unity (2D), and its been working great, but I have a few concerns regarding my particular usage. What I'd like to have is multiple "battle maps" that will get instantiated when the battle scene is switched to. My current idea is to just make each type of battle map a prefab (prefab on the grid, since the tilemaps are just layers), and then instantiate the grid when the scene loads in.
Is this best practice or is there any better way? Does having 10 maps vs 200 maps make a difference?
Other Things I've Considered:
Would it be a better idea to make one huge tilemap with all of the battle maps drawn a distance away from each other and just restrict the camera to moving only within the "current" battle map? The absolute max size I could see a map being is, let's say 30x20 tops, probably closer to half that though.
An earlier idea was to use small pixel map images to render the maps in. This was before I found out about Unity's tilemap system, which, admittedly, I'd rather use because it is so much simpler to visualize, and less work to develop.
The Scenario:
For simplicity's sake, let us assume the game has 2 scenes, the main menu, and a battle scene. Basically, the idea is to enter the battle scene and have a random battle map to be spawned out of what's available. The character(s) get placed, and any additionals also get placed, say, items, or what have you.
Is what I proposed above best practice? And should I consider any other other two systems I've also described? Or is there something I'm not thinking of that would be even better?
I don't believe that any of the above ways wouldn't work, I'm just curious if any of them is the best way to go about doing this.
Your consideration to have all of your battle maps drawn on a single tilemap and restricting the camera to only the region of the current map is an instant red-flag.
In my experience with unity, if I want to have a large level drawn on a grid I will have to break it up into chunks (each chunk is a separate tilemap) for performance reasons in the editor and in the game, so I would not recommend doing that.
If your goal is fast load times, then instancing a prefab as you suggested is not a terrible idea as long as the respective tilemap is fairly small (less than 10000 tiles), otherwise you would almost difinitely notice the map getting loaded in. If you are trying to load large tilemaps seemlessly, it may help to load the tilemap asynchronously before the actual switch occurs.
I would keep only the current map and next map loaded in the scene to ensure a seamless transition and optimal resource usage. Unity's tilemaps are not light.
Imagine a large free-roam game in Unity,
The yellow size indicates about the largest you can make a typical Terrain in Unity.
Art dept. will completely build, meter by meter, the entire scene.
Please note, this has absolutely no connection to repeating scenery (as in runners) or procedural scenery (as in say some race games).
Really, what is the correct and good way to do this in Unity?
use say 50 or so terrains, each perhaps 100m x 100m ?
can you even have or use that many terrains?
or what?
For anyone googling here.
The correct solution is indeed
Terrain stitching
that's it.
In practice you must use one of the tools available to do this (eg, TerrainFormer) or, your team will write from scratch a terrain stitcher.
Yes, you just use "many terrains".
The best approach to the exact problem posed,
is in fact to just:
"use lots of Terrains".
It seems to be perfectly viable in Unity to have many (dozens) of Terrain units, basically "sitting next to each other".
In practice, you'll need TerrainFormer
https://assetstore.unity.com/packages/tools/terrain/terrain-former-20052
or one of the similar tools.
(Or, I suppose, from scratch write your own tool to stitch terrains, and allow you manipulate them all at once, join the edge-heights perfectly, etc etc.)
It's not realistically possible to just perfectly sit many Terrains together (by hand), matching all the edges, etc etc. So you're going to need a "stitcher" package for putting many Terrain squares together.
So, this huge area ..
has about 12 Terrain.
So that's the answer, you can indeed have "many, many" Terrain in a Unity project, you do indeed essentially just "sit them next to each other". In practice it's not achievable unless you use one of the editor tools such as TerrainFormer.
The proper way to do this would have been with procedural mesh generation with MeshFilter and Mesh API but you mentioned that this not at all random or generative so that one is eliminated.
It's just simply a very long, thin, hand-made environment
The best way in this case would be a Modular Level Design. You need to create Modular Assets. With this you can have a long road in pieces which can be tileable. A good modeling artist should be able to create and texture modular assets with 3D modeling packages like Blender, Maya or 3ds Max.
All the programmer has to do is make each asset a prefab then use the Instantiate function to instantiate them to create any distance of environment. You can also create a static environment in the scene from the Editor. Almost anything can be made into a modular Asset especially buildings and roads.
After assembling them in Unity, you can do static batch on all the instantiated modular parts with Unity's StaticBatchingUtility.Combine to improve performance of the game since they are not being moved.
Below is an example of a modular road asset that can be used to create almost any amount of road:
You already answered your question
in this case would it be better to not bother with Unity's otherwise excellent Terrain, and the modellers would just outright build the long course/scenery? (Obviously you'd have to chunk it so it all occludes fine)
I think it's the way to go. If the performance is an issue, try putting each chunk in different scenes and then have a master scene to load them async and additively. And of course you want to unload each scene as it becomes invisible in the camera.
I personally go with your own solution which is letting the Unity Occlusion Culling system to take care of the hiding and showing chunks. I only go with the separate scenes approach if I'm not getting enough performance this way.
I recently had the same problem. We build a tilebased infinite runner with road crossings. The camera was positioned behind and over the car looking down on the street and the player car. So the setup is quite comparable.
We used Curvy from the Asset store to create paths for moving the player and also for creating the geometry of the streets and the surroundings among the streets.
https://assetstore.unity.com/packages/tools/level-design/curvy-splines-7038
It is also easy to spawn tiles with curvy paths and combine them at runtime. So you can separate long distances into smaller segments and spawn them randomly.
We also used QuickBrush from ProCore to quickly paint environment detail to the geometry like trees, bushes or stones. I think procore tools are now implemented in the new Unity 2018 version.
Worked quite well.
When implementing a large hexagonal grid (256x256) of tiles in a Unity game, the game becomes very slow and hardly able to function. The hexagons are in a prefab. A script controls the size of the grid and the spacing between each hexagon. How does one go about rendering a 1024x1024 grid of Unity objects?
When the game is built on Win64 it is also still quite slow.
This is an image of hexagons rendered:
http://i.imgur.com/UbA6USt.png
Try making the grid elements static and make sure static batching is turned ON in player settings. This will optimize their rendering significantly. You probably should even go as far as combining them all into a single mesh (see tools like this one for that purpose).
If you can show us the actual scene hierarchy and the actual structure of your grid nodes then we can help even more.
Because of how Unity works, non-static objects have a tendency to get heavy - they each end up with their own transforms and end up getting drawn even when they're not on screen.
It's the reason more minecraft clones aren't seen coming out of Unity.
If you can't set the hexagons to static for some reason (i.e.: creating procedural levels etc), you'll have to perhaps simulate the hexagons through creative shader manipulation (like saving each mesh into a single array of vertices with a second that tracks a corresponding mesh id) or by writing a script that creates/adds vertices and faces to a single mesh on a single game object.
You may also speed up the scene by creating smaller levels and loading/unloading them as the player moves towards them. See: Application.LoadLevelAdditive