I just render to a low resolution RT. Elliot's method is more suited to games that have a mix of different resolution assets.

@@t3ssel8r is there a separate rt for each model, or is this for the entire scene?

whole scene

@@t3ssel8r I tried something similar at first, but found that locking objects to only moving pixel units at a time made them appear jittery, while not locking them made pixels swim. Did you find a way to get around this?

it's tricky to get right and there are many different things that affect it, including pixellation of entity movement, pixellation of camera movement, sub-pixel shifting of camera viewport, and of course pixel size. If you need individual sprites to slide across each other smoothly at different speeds, then of course you have no choice but pixellate separately.

there's a few different workable ideas. particle systems are one way, although you will want to pause the particle system so that they are not being recomputed every frame. You can also try using GPU instancing, or using the builtin terrain details system (which also uses GPU instancing). Since each mesh is so simple, I've also had success just pre-baking chunks into meshes.

I recreated this pretty closely and I used true GPU instancing with DrawMeshInstancedIndriect. I made a quad mesh with it's origin at the bottom center for correct billboarding, and applied a grass texture to it. When spawning the grass on startup, I read the terrains normals and heights at different points (like mentioned in the description) with the functions from TerrainData and pass them into the compute buffer. It works great with barely any framerate impact below 100k quads. DrawMeshInstancedIndirect does not have frustum culling. So if you want large terrains you probably have to implement that or load the grass in chunks or something like that.

@@starbi would you suggest using simple quads with opacity or actually geometry grass? What would be less demanding?

I assume the grass takes its color value from the terrain it was placed on. This automatically makes it work with lighting

Im having the same problem. Im using instanced indirect to draw sprites. I color it same as the terrain with a toonshader. However since i cannot access the shadow info in the vertex shader, just the fragment shader: Im getting half shaded grass and not per sprite shaded shadows. Did you find a solution?

shadow maps. maybe the bug in UE is with the calculation of the shadow view matrix. I don't know much about UE but you could compare a renderdoc capture of a perspective camera and an ortho camera to see what's different

@@t3ssel8r Thanks for suggesting, i will take a look!

It looks like others have recently been asking the same question.

it's essentially that, plus small adjustments to camera and viewport to make camera movements smooth

you should be able to just call graphics.blit with a null target to draw to the viewport

@@t3ssel8r I tried using Graphics.Blit with the RenderPipelineManager.endCameraRendering callback, but it still results in a black screen. I also tried it with RenderPipelineManager.endFrameRendering, but that causes recursive rendering and breaks unity all together. So where in the render pipeline should I call Graphics.Blit?

maybe in URP you need to use a command buffer as well? put the custom render pass on the camera that draws your scene, and do a commandbuffer.blit from there? set the camera's targetTexture to null, then you can blit to BuiltinRenderTextureType.CameraTarget. at least that's what I do in a custom SRP.

​@@t3ssel8r I just tried it, and I did get some result. I can use a custom render pass just fine when the camera's target is set to null, but now it doesn't use a rendertexture anymore, and I can just pixelate the the camera's final result. I guess I will try out some more things. I take it you're using the default built-in renderer?

I'm using a custom SRP now, which is a little more flexible than URP, but I don't know exactly what the different limitations of the different render pipelines are, because the documentation is not very clear on these edge cases.

the grass is made up of a bunch of grass-shaped sprites that are shaded with a single color equal to the color of the pixel at its base

@@t3ssel8r so are you able to combine the terrain's color, shading and shadows into a single color? I'm asking cause I'm trying to achieve the same effect on a shader by transfering normal and world position of the sprite to the shader in a MaterialPropertyBlock, but sampling the shadow map using the world position is giving me some weird artifacts that are visible around moving characters, where some of the sprites behind them appear dark even if not in a zone of shadow, and it becomes even more obvious when the characters move, cause some of the sprites behind them pop from light to dark and viceversa

I just use normal/position transfer instead and shade the sprites as if they were the terrain.

@@t3ssel8r How do you get the normals and the positions of the terrain?

@@flippykat9215 I believe from TerrainData when instancing them from c# code and pass them to the shader via materialpropertyblock

Elliot Bentine has a medium article on the subject