Experimenting more it looks like it's actually the object moving too little (~1 pixel) per frame, so bumping up the speed or capping the framerate at 60 so the object moves more than one "staircase step" per frame helps alleviate the issue. I wish there was a way to render individual objects from the same angle to avoid the temporal aliasing, but not restrict them to the pixel-snapped basis of the world. But the only way I can think of doing that is having a camera-subviewport setup for every single moving entity which seems super jank.

Unfortunately the snapping is kinda the point. Having unaligned objects requires rendering them outside the scene as you said, but then you have the trouble of compositing it back together. You could probably to it in a performant way if you have full control of the render pipeline, but within Godot seems difficult. Pixel perfect diagonal movement at less than sqrt(2) pixels per frame is basically flawed, something has to be compromised. Perhaps you could make an educated guess and snap to perfect diagonals if the object's velocity is that direction.

btw, your video is amazing and is helping me a lot

hmm... from my understanding, it should be smooth if all updates are run in _process (every frame), which they are in my scene. I only have a 60hz monitor, but I've tried all vsync modes and it's smooth in all of them. If you're doing work in _physics_process, then you're dependent on the physics tick rate and will need interpolation to smooth out the physics movement betwixt rendered frames. Unfortunately, automatic 3D physics interpolation has only just been merged upstream and will be in Godot 4.4, but there's likely a workaround or manual way to do it.

​@@denovodavid Thanks for the response! THAT WAS EXACTLY IT. For some unknown reason, I put the camera_rig in _physics_process, and moving it to _process() resolved the smoothness issue. I'm using 4.4, but I disabled the physics interpolation on the camera because it was bringing back the "pixel creep." For my case, it seems better to keep the interpolation disabled.

You should be able to use a parent object with the camera as a child, then offsetting the camera's transform. I originally did this in Godot, then realised x/y offset was simpler. Since the parent is now the "true" transform of the camera, you'll probably want to use that for all the relevant calculations. I don't use Unity anymore, so maybe Cinemachine has something that can make it simpler...

@@denovodavid hey thenk you! il try

`README.md` explains how to override the project settings for part 2/3 to work :)

@@denovodavid didn't see that, thank you :)

By the end, the pixelation happens within a SubViewport, of which the texture is displayed on a 2D node at the standard resolution of the window. So, if you put 2D/UI elements in the SubViewport, they will be pixelated, and if you place them outside, they will be at full resolution.

@@denovodavid Excuse the questions, I am new to Godot, To clarify, any objects(2D or 3D) placed outside of the pixelated SubViewport will not get pixelated right? I like the pixelated art style however, I am conflated if whether its best to pixelate objects via a shader or by camera.

@@Fullstackdesign yes, objects inside the subviewport are rendered separately to a smaller texture, thus pixelated when scaled up. (Just note, with this setup you cannot mix 3D pixelated and 3D non-pixelated objects together with correct depth sorting.)

I had a similar issue, but I had some luck with camera following by limiting the game max FPS to 30. (Character in the snap group of course)

Yes, the snap toggle is mainly for showcase/debug though; I always have it enabled in my main project.

Animated skinned meshes would require different techniques for that 2D feel. In addition to snapping, I would throttle the framerate of animation and rotation.

In editor settings I just set base color to #2d2e2f and accent color to #ffc500, that's it :)

nice question, does this approach supports also perspective projection?

I don't see a reason why it shouldn't work with 3D sprites. I would make them always face the camera (billboard), and scale the sprite size to match the same texel size as the output. The sprite origin might also play a role, making sure it's not snapping to the centre of a texel or something.

You likely can snap using only a shader, as long as you pass the appropriate "snap space" to it. I just didn't want to add custom shaders to everything.

hmm... maybe you would have to texel snap the object in view space and in light space. During the light space depth pass, it should be possible to snap vertices to texels, but I don't think that translates one-to-one with view space texels when sampling the attenuation. This requires further investigation.

In editor settings I just set base color to #2d2e2f and accent color to #ffc500, that's it :)

@@denovodavid Huh, I appear to be blind.. Appreciate it, thanks! And please keep the t3ssel-imit8or tutorials coming.. I feel like there's a bunch of awesome looking indie games just around the corner ;)

Yeah it's an awkward issue that affects 2D pixel art games as well, it only has partial solutions with trade-offs: - If you have an animated 3D character with a soft attached camera, it may be better to *not* snap them at all, as pixel creep from animation and movement will be far less noticeable than jittering. - If you soft attach to a consistently moving snapped static mesh it's basically impossible to avoid jittering. You will have to snap the object and hard attach the camera with no snapping to avoid the jitter, but you won't have sub-texel smooth movement. (My main project is at 640x360, so even hard attached movement is still pretty smooth.) - The only other way I can think is to render the object separately and insert it into the scene at a sub-texel level. That's a whole other pipeline to manage, but might be worth it if you really want those chunky texels. There's probably a way to mitigate the jitter by selectively snapping/unsnapping things based on speed and follow logic, but I haven't explored that yet.

Rotating the camera will always cause some form of pixel creep; it's a whole new "perspective" on the scene. There's no real way to snap if the camera rotated in the current frame. That being said, the solution here will continue snapping correctly once rotating has stopped.

@@denovodavid ah..in that case my dungeon crawler will just have some blur when turning, and that's okay, it's pretty quick. thanks!

@@thehogman. "being this mad over more people being able to make art" there's a typo here, you probably meant "mad at people normalizing the plagiarism of an original signature art style"

Yeah I'm not sure that a few lines of camera code I wrote in an afternoon really constitutes an art style. I know you like t3ssel8r's style a lot, but you cannot just take this code and have a game that looks like his. There's so much stuff to cover: toon lighting, outlines/edge highlights, cloud shadows, grass/foliage rendering, terrain, water shaders, particles systems, weather, god rays, and so much more VFX. There are assets you can buy on the Unity asset store that already handle the camera and outlines, it's not some secret technique. Personally, I would love more indie games in this style, it's my favourite, and the reason I got into shader programming.

Hey I remember watching your video! And yeah, the snapping and smoothing only requires the most basic of 3D pipelines :)

Thanks! I've since moved to simple toon lighting, but it would be cool to bring some of the shiny stuff back :)

Thank you! It's a sysinternals tool, ZoomIt: learn.microsoft.com/en-us/sysinternals/downloads/zoomit

Cheers! I use ZoomIt: learn.microsoft.com/en-us/sysinternals/downloads/zoomit

Yes, I didn’t show that version of the code specifically, but it works just fine in the final scene.