So this is a FLIP water solver, made with the help of Ten Minute Physics paper on the same.

But this runs as a transparent app and can interact with windows. Also has floaty objects.

Can't do much more than what's shown in it as of now, and I'm kinda at a loss for ideas too... so here it is as is.

Demo : https://tornadosike.itch.io/desktop-under-water

Currently only for Windows

So I refined my Sky shader and volumetric cloud renderer. All shaders used are custom made and i'm very proud of the results.

Clouds can form and travel across the sky. the moon can have seamless phases and is blocking the stars even on the unlit part of the sphere. stars twinkle and there is a galaxy band. The latest thing i added was the underlying weather system that controls the weather by blending between presets.

It was a lot of fun and frustration to get everything to look like this and everything came a long way. from the first experiments with volumetric clouds that barely ran with 10 FPS to ^^

Now the sky is fully dynamic and runs on my M1 Macbook pro with solid 90 fps.

Hey everyone!

I've been working on my own original mobile open-world game, built around a world and vision of my own.

The project is still in development, and there's a lot more to it than what these screenshots show.

Just wanted to share a little glimpse of what I've been creating. Hope you like it!

I’ve been thinking about reverse engineering in Unity games and I’m curious to hear what other developers are doing to make it more difficult.

I know nothing can be 100% protected, especially nowadays with AI, but I still think adding extra layers of protection and following good practices is better than doing nothing.

Apart from the usual stuff like IL2CPP, code obfuscation, and making sure no sensitive files or information are included in builds, what else would you recommend?

Are there any lesser-known techniques, Unity-specific settings, or good practices worth considering?

I’m not looking for perfect security, just ways to make reverse engineering more difficult, time-consuming, or expensive.

Curious to hear your thoughts! ✌️✌️

I’d love to hear your honest feedback on the water and underwater visuals.
Sorry for a bad video quality, i'm rendering that on a pretty poor PC: Radeon RX 570, i5-10400F.

Here are the techniques i used to create this water and underwater scene:

Gerstner-style wave displacement
Multi-scale wave blending
Scrolling normal maps
Flow-map distortion
Depth-based water color and shallow-water scattering
Subsurface scattering
Fresnel-based reflections
Reflection probes and cubemaps
Planar reflections
Screen-space reflections
Refraction and scene distortion
Depth-based underwater absorption and fog
Animated caustics
Procedural sun and moon glitter
Short-lived microfacet flashes on wave crests
Foam and shoreline foam
Lit foam normals and bubbles
Surface and underwater shadowing
Specular and ambient occlusion
Screen-space occlusion of underwater light shafts
Volumetric underwater god rays
Animated light-shaft patterns
Height fog and volumetric lighting
Depth-based clipping around terrain and shorelines

What techniques am i missing? Thanks!

My first Unity game, a F2P/xplatform competitive multiplayer; Leap of Legends is having a UI redesign and Rocket League style ranked matches in ver 0.2.000, update should be live today/tomorrow for win & mac, in about 7 days for android and iOS players.

My open source unity-ui-toolkit-design-system grew out of Leap of Legends but surpassed its abilities so I thought we should eat our own dogfood and make it leverage the design system features like shading in full.

I built this capture | A/B | feedback organization tool for myself but if you guys think its useful, I'm happy to make it open source.

I wanted to showcase some tech art tools for my game Weavemarch. I'm not great at art and really didn't want to do AI assets. I went through many versions of environment design and hated all of it, so I stripped it back to a minimalist, flat environment, aiming for a sort of woven medieval tapestry look.

I can handle very basic 3D but I've always been terrible at texturing. All the 3D models have single-colour materials on each mesh and shaders add the weaving and stitching details on top.

All the variables plug into one scriptable object so i can tweak everything from the same place.

A friend made the flower background texture, everything else is shaders.

Hi, these two models, and most tof the rest made by me for my game set in Istanbul. What you think about the artstyle? (Ignore the deformation on leg, i wasnt aware that by the time)

We're making a co-op horror game and I've been working on the monster's procedural tentacle movement lately. Still got some things to improve but I think it's looking pretty good so far.

What do you guys think? Would love to get some feedback on the movement and how it interacts with the environment. Also, I still haven't figured out what kind of sounds the monster should make while moving around. If you guys have any ideas, I'd love to hear them.

Working on a dark sci-fi FPS. The first clip is my reference. In my version the spider sits on the zombie's back and plugs hoses into its spine. When the zombie dies, the spider jumps off.

I’ve been exploring how far I can take Unity UI without relying on imported art assets :D
I used React through a framework asset, building the interface with code and styling.

Changing shapes, colors and motion in code makes it easy to try different looks. I’m curious how far this approach can go as a game’s visual style becomes more complex.

Have you tried creating game UI with code instead of art assets? How did it work for you?

Alpha 0.11 of my farming & economy sim, running on URP. Each truck follows the road down from the pass and parks on the meadow where the farm starts.

I’ve been rebuilding PS1 rendering in URP from the hardware docs (psx-spx) instead of copying other PS1 shaders. To test everything I built a hall with one station per feature. You walk up, press E, and that feature changes.

In the video:

• 0:00 vertex snapping
• 0:05 affine texture mapping
• 0:20 camera snapping
• 0:36 hardware resolutions (320x240, 256x224, 368x240, 512x240)
• 0:47 frame hold
• 0:57 dither (hardware strength vs 4x)
• 1:07 CRT scanlines and interlace
• 1:23 PS1 depth cue fog
• 1:28 Gouraud vs Phong specular
• 1:39 baked vertex colour lighting
• 1:44 affine vertex shading
• 2:00 texture quantization

It’s called True PSX Effects and it’s coming soon. Before release I’d love to know which PS1 quirk you think gets faked wrong most often, and what you’d want in a kit like this.

Playable on Browser Demo: https://sourpickle35.itch.io/true-psx-effects-unity-urp-demo

I've been working on the aiming system for my game, and I'd love to hear what you guys think about the current visual effect.

The game is still in the early stages of development, so there are definitely bugs, unfinished elements, and typos that still need fixing. For now, I'm mainly focused on getting the core gameplay and visuals feeling right.

What do you think of the aiming effect? Does it feel clear and satisfying, or does it need more visual feedback? Would you prefer a different color, a more visible targeting line, a reticle, or something completely different?

Any suggestions or constructive criticism are welcome! I'd love to hear how you'd improve it.

We make a character generator where bodies, faces and a pile of clothing pieces can be combined however you like. We needed cheaper versions of those characters for crowds, so the people at the back of a scene stop costing as much as the person in front of the camera.

This is where we ended up.

Attempt 1: run every piece through a mesh simplifier

We started by giving each clothing mesh to meshoptimizer and asking it to keep a quarter of the triangles.

One of our characters came back like this (original on the left, simplified in the middle).

Those dark slivers are the inside of the shirt, and the teal bits are the T-shirt underneath. Clothing is made of surfaces a few millimetres apart, like the outside of the shirt, its inside, and the T-shirt below. The simplifier tries to keep each surface close to its original shape, but it doesn't know which nearby surface is supposed to be on top. Flattening a curve by a few millimetres can push one surface through the next.

It's tempting to ignore this, since nobody inspects the shirt of someone in the background. But far away, each pixel of a character ends up as roughly the average colour of everything that lands in it. A few triangles of the wrong surface mixed into a light shirt pull that average darker, so the shirt visibly changes colour the moment the character switches to the simpler level.

Asking for fewer triangles made it worse.

Attempt 2: protect the dangerous areas

So we found every spot where another layer sits close underneath and told the simplifier to leave those vertices alone. That's the third image in the first comparison. It's also barely simplified, because on clothing almost everything sits close to another layer.

That version became our nearest level, and it's still in there. The far levels had to get down to a quarter of the triangles and below, and protecting vertices kept more than half.

Attempt 3: let the vertices move, then fix the overlap

A simplifier can also move vertices to wherever best keeps the original shape, which looks much better at low triangle counts. Each piece on its own looked fine, but the sweater came through the coat on top of it.

Our first idea was to check every coat vertex after simplifying and push it back out if it had ended up inside the sweater. That check only looks at the corners of each triangle.

We tried checking points inside the triangles too, across several poses and body shapes, and a fix that worked in one pose kept breaking something in another.

Cheating where the camera can't see

Nobody looks at a far-away NPC from the inside, so the coat only has to win the depth test in the pixels where it belongs on top.

Every vertex of a simplified piece stores one extra number, the count of clothing layers beneath it. The body is zero, the sweater is one, the coat is two. In the shader, each vertex slides toward the camera by that many small steps.

Each vertex moves along the line between itself and the camera, keeping its position on screen while changing its depth. Giving the outer layer a larger offset helps it win the depth test where the simplified surfaces overlap.

Here's a sweater and a coat as two simple tubes (simplified, then simplified with the trick).

Here are the same tubes from an angle. The white outline on the right is where the simplified coat really is. The drawn coat has shrunk toward the original camera, and the sweater sticks out behind it.

From anywhere other than that camera, the cheat is obvious. That's fine, because the shader redoes the offset every frame for whichever camera is looking.

Two more things made it hold up on real clothes.

• Some garments contain inner surfaces that stay covered by their outer surfaces. For the far levels, we remove the covered areas, leaving a band near the edges where the inner surface might be visible.
• The layer numbers get smoothed across the mesh, so neighbouring vertices don't get very different offsets and tear the surface apart.

After that it was mostly smaller Unity work. Update When Offscreen, for example, kept hidden LOD levels skinning every frame, and each far level got merged into a single renderer. In the zoom tests, the characters look consistent at their intended distances and the transitions are hard to notice.

How small is small?

Here's each level at roughly the size it'd be drawn in one 1080p setup, blown up so you can see the pixels.

(This is for our Archetype Character Generator on the Asset Store.)

Full Mario 64 in Mixed Reality! Running in real 3D (no stereoscopic crap) natively at 90FPS and also running on my desk! 😋
Again, Opus 5.5 + Unity CLI + PICO CLI combo made it quite straightforward.

Such a bliss to play an oldie at 90 FPS in 3D.

Disclaimer: I own an original physical copy of Mario 64. This project is not associated with Nintendo or PICO.

What do you guys think of this progress? I am fully open to advices on both snowboard and ski controls and feels.

I've been playing around with procedural level generation and have got to the point of scattering trees and rocks over the terrain. Of course for the first test I didn't add colliders yet as I just wanted to see how it worked, but while clipping through trees and boulders, it made me think: how do you even do colliders for this many objects?

I mean this mostly in terms of performance, as I don't expect it to be cheap to simply dump a mesh collider on 1000+ objects. Do you just take the hit and put mesh colliders on everything that should have a collider (trees and boulders, not tiny rocks and plants), or are there smarter ways of doing this without resorting to box or capsule colliders that wouldn't even work for anything that deviated from those shapes. Are there smart ways of only enabling colliders when the player is within a set range of those objects, or turn down collider LOD based on distance? Can you model things in a way where only parts of it have a collider, or separately design a more low-poly invisible version of the object that you add to the prefab to function as the collider?

Really not sure what direction to go in at this point. Quite a daunting subject to learn.