I'm looking for ways to clip an entire unity scene to a set of 4 planes. This is for an AR game, where I want to be able to zoom into a terrain, yet still have it only take up a given amount of space on a table (i.e: not extend over the edges of the table).
Thus far I've got clipping working as I want for the terrain and a water effect:
The above shows a much larger terrain being clipped to the size of the table. The other scene objects aren't clipped, since they use unmodifed standard shaders.
Here's a pic showing the terrain clipping in the editor.
You can see the clipping planes around the visible part of the terrain, and that other objects (trees etc) are not clipped and appear off the edge of the table.
The way I've done it involves adding parameters to each shader to define the clipping planes. This means customizing every shader I want to clip, which was fine when I was considering just terrain.
While this works, I'm not sure it's a great approach for hundreds of scene objects. I would need to modify whatever shaders I'm using, and then I'd have to be setting additional shader parameters every update for every object.
Not being an expert in Unity, I'm wondering if there are other approaches that are not "per shader" based that I might investigate?
The end goal is to render a scene within the bounds of some plane.
One easy way would be to use Box Colliders as triggers on each side of your plane. You could then turn off Renderers on objects staying in the trigger with OnTriggerEnter/OnTriggerStay and turn them on with OnTriggerExit.
You can also use Bounds.Contains.
Related
I am making a 3D isometric game, in my game, there is a lot of holes and the player can go into them, but the problem is when he goes into one of them he becomes invisible, I can,t move the camera it will change the concept I tried using shader like the one in this video but it makes the entire terrain transparent and glitchy (I am using unity terrain) so I am stuck and I need Idea how to make the layer visible inside the hole
What you're asking can be achieved in multiple ways, depending on your render pipeline and requirements.
If you're working with the Universal Render Pipeline (URP), you could create a Forward Renderer asset and create a custom render pass whenever your player is occluded by terrain.
You could assign a new Layer to the player, such as "Player", then select or deselect said mask from the Filters > Layer Mask properties of the Forward Render Data. Then assign the same or a custom material for when the player is occluded by terrain.
Alternatively, you could create either a cutout or a dither shader using Shader Graph, on which there are many tutorials
Camera GameObjects give you the option to select what layer you want them to "see" (render) using the culling mask. Think of layers as grouping GameObjects and giving that group a name.
You can have multiple cameras at the same time each one with a different name and different layer to render, or even change the viewing layer of a single camera depending on changes happening in the game.
Assign a layer tag in each of the terrain elements in your scene and have the camera render them accordingly and "cull" the rest.
Very helpful documentation on layers and camera culling mask.
How would i go about creating as a background for a 3d scene a plane with a texture that stretches into the horzon? I have tried a skybox but i think a skybox will also be needed "behind" the infinite plane.
It depends whether you need to have an actual geometry that will be seen from close up - if not, you can bake it into the skybox.
In some cases (i.e. when the user has stereoscopic display on their head) you will need to have actual geometry.
Its not exactly clear from your question if you want to create a 'floor' or a 'wall', but in both cases I would link it with player position somehow. A floor could follow players X an Z, while a 'wall' could be made a child to the camera, this way it would never leave the viewport.
Skybox would still be the cheapest by a significant margin, we can give more advice if you provide some additional information. i.e. what are you trying to achieve
I have a ScrollView with a working mask that block images, text etc when not in the viewport (visible area).
The problem I have is that ALL particles sytems are ALWAYS rendering and visible on screen, whether they are part of the viewport or not.
I would to know:
1) if masking is possible on Particle Systems
2) and if it is what have I overlooked or missed that makes the particles visible.
FYI I have tried layers, adding a specific mask to the object to the object with the particle system, adding a mask to the parent of the object with the particle system, and randomly altering renderer settings, and I'm ready to cry.
The problem is not the particle systems themselves, but with the shader the particles use.
The way Unity's Mask Stencil system works is through the stencil buffer, which only works if your shader plays nice with it. If you want to try to modify your shader for this, here is the relevant documentation. Otherwise, try changing to a different shader or using a different method to hide your particles, such as modifying Camera.rect, for which the documentation is here.
By the way, if we're being a stickler for terminology here, "viewport" doesn't mean what you think it means (within the context of computer graphics).
In current Unity,
For use in Unity.UI as conventional UI ..
for any "Sprite (2D and UI)", in fact it always defaults to having "Generate Mip Maps" turned ON. Every time you drop an image in, you have to turn that "off" and apply.
As noted in the comments, these days you can actually use world space UI canvasses, and indeed advanced users may indeed have (say) "buttons that float over the head of Zelda and they are in the far distance". However if you're a everyday Unity user adding a button, just turn it off :)
In Unity, "sprites" can still be positioned in 3D space. For example, on a world space canvas. Furthermore, mipmaps are used when the sprite is scaled. This is because the mipmap sampling is determined by the texel size rather than the distance.
If a sprite is flat and perfectly scaled then there is no reason to use mipmaps. This would likely apply to your icon example.
I suspect that it is enabled by default for 2D games where sprites will often not be perfectly scaled. To clarify, a sprite does not need to be on a canvas. Sprites can exist as their own GameObject with a Sprite Renderer (not on a canvas.) When this is the case, scaling the camera view will change the sprite's size on the screen resulting in mipmapping due to the texel size changing. This results in making the sprite always perfectly scaled challenging without a canvas.
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