Pocster

Claude's (expletive deleted)ing thick today!

Sunsets do it for me!. Been working on "real" rainbows. Most engines cheat at this but mine's created correctly (I think!). Now I need the water to freeze over time. GPU burden has been creeping up again as expected. So optimisations required yet again. Lightening thunder storms are extremely impressive and expensive!

Finally got decent looking snow. It accumulates on terrain and thaws.

Tell you what - that's a massive understatement. What I mean is I've created a custom 3d engine that would be commercial grade - yet not 1 line of code. That is the real power of AI. I see plenty of youtube/reddit "wrote this in 5 hours with Fable from 1 prompt". Some are believable some are slop. But most are relatively simple (still impressive that Ai can take "write me a really good minecraft game with dinosaurs in it" and still produce something). But use it properly from experience and build it up layer by layer rather than the final product from 1 prompt and its a phenomenal tool. The accomplishment here is WELL beyond my technical ability. But the "difficult" parts the code and horrific maths aren't my burden 99% of the time. I'm still in awe of what's possible. Must also admit it can take some effort - occasionally days on 1 feature to be correct. Or bastard bugs... we had a few mountain tops going black as you approach. No obvious reason some would and some wouldn't. Check all the render stuff/textures/lighting everything me and Claude could think of. Nothing obvious. Found it out of frustration!. The ray march on water can shoot a ray so far that it can hit a mountain top. Essentially at that point its a NaN so plots black! - what a bast!. Water affecting a mountain maybe 4km away in real space. That kind of bug finding without Claude (as I've done many a time when a software engineer) its pure torture and can literally take weeks to find...

That was an esp32 project and works!. I'll integrate that into Avalon later. One thing at a time! ( well lots of things at lots of times really - so never get bored!)

Theres always ways to optimise. My main lever is of course the shaders (even though Claude wrote them) and pre-baking - 256Gb to burn so we create lots once at runtime to use later and save on some computations. The original premise is still there - just got a bit distracted. But yes the Alex/Chatgpt from Avalon 1 will be imported into this. The robot running over these luscious landscapes will tell you when your chicken is ready and then you're playing Ed Sheeran AGAIN!

Amateur ! Time to analyse shaders ! Optimise 💪

PUKE now does God rays, lightening storms, ambient occlusion , terrain can influence cloud colours and likewise; same for water etc. So all in the same render pipeline. Limits in webgpu are no more than 16 sampler passes for the march. This limit has been a constant problem. Also back at a crippling frame rate if you have max clouds/max rain and a lightening storm and decide to look at a grazing angle over water!.

Pocster's Unreal Kafkaesque Engine P.U.K.E (tm)

Oh yes and the amazing cube marched clouds. VERY expensive! need to optimise again soon !. Lit!, can have a nice storm with them! Which means a detour (as usual) to .... lightening!!!

Taken all day to get right ; Claude wants to quit many times! Heavy rain actually runs down slopes! Looks fantastic. I dont think even the might Unreal Engine does this.

10% gpu; yep!. 25% if you get the worst possible grazing angle over water. Added upscale (for some minor quality loss) even on the water grazing angle if I drop to 70% gpu at 13%, drop to 50%, gpu 10% Plenty of engine for more fun!

Hit 50% gpu with procedural background planets/nebula/stars. So optimise , optimise, optimise. Took a while now back at around 30% gpu. Proper (frustrating) exposure aswell. So when you look at something really bright you are blinded for a bit and colour 'seaps' back in. Trying to function like an eye rather than a camera (so binned lens flare). Going for clouds again (3rd attempt) - tricky one but got a 25 page spec for it. Then more fun... always bugged me with a height map that of course you cant have arches/overhangs/caves but have another spec for a hybrid system that allows such things. Another sped up thing was that the baking was taking upto 4 seconds (which bugs me) ; down to 1 second now. So startup is far quicker.

I'm not building houses any more Uncle Nick - I'm building worlds!

Horrific bugs I'd never had found. Absolute bitches - well above my pay grade. But.....better than my holiday snaps!

Claude not being so good today. Causing more problems than it fixes. Adding and removing without my knowledge...

gpu at 50% thats with a grazing angle view (worse case for ray march) , water on screen, bloom. So a best case of a worst case. So optimise time. I reckon I can get that 50% down to 25% by pre-baking as much as possible in the terrain that gives a noticeable gain. 320Mb about to be burnt (insane when you think about it just how much 320Mb is , nowadays viewed as nothing)

No one and I mean no one fully understands quaternion maths … it’s magic maths !

I do. Sometimes it's wrong. But trust me accuracy is paramount to realism - I'm on it! You've got bedtime reading of Beer-Lambert and quaternion maths. You wont like either of those trust me!

Te-he! As I said water looks different from different angles. So near us (the camera) you see the turquoise and seabed further you would not at this angle; i.e. you cant see the nice blue because our angle is so low - we are looking over it. If I pulled the camera up into the air and looked down at that spot it's there. So looking at water and looking across water are very different views - it's something through the previous 5 versions (oh my!) I just couldn't get correct. look at piccy 1; water we are near is 'clear' (depends on a LOT of maths, sun angle, sea bed, refraction, specular etc etc etc etc ), but look across at the mountains, a reflection and is dark. Beer-lambert (remember you started this science/maths argument! 🙂 ). But I'll let my mate Claude answer.... " The blue stops because of viewing angle, not shadow. What you're seeing as turquoise is light that passed through the surface, reflected off sunlit sand, and came back out — and how much survives depends on how far it travelled through water, not how deep the water is. Directly in front of the camera you're looking down into it, so a metre of depth costs about two metres of travel and the sand shows through. Along the beach receding to the right you're looking almost flat across the surface, and the same metre of depth costs a hundred times more travel. Nothing survives that, so it goes dark. That much is real: at grazing angles you genuinely do stop seeing into water, and a photo taken from that low across a lake shows a mirror at the far shore rather than turquoise. Where ours overdoes it is that the surface doesn't yet bend the view ray. Refraction puts a hard ceiling on the underwater path — about 1.5× the depth, from any viewpoint — so real shallows stay bright the whole length of a beach. Without that ceiling the path grows without limit as the view flattens, and the band dies far earlier than it should. Separately, what replaces it should be a bright mirror of the horizon sky; ours fades reflections to black near horizontal, which is why that stretch reads dark instead of silver."

All the things as an ex games programmer I notice and hate. But with finite compute and finite ram compromises must be made. Give me and my new best friend Claude (I've not even sworn at it yet! , honestly not once! , whilst CHAT , well (expletive deleted) me ... I couldn't stop swearing ). The point you made is valid "looks wrong, but not sure why" - I do that a lot. I have to explain what IS wrong - usually in a technical term. So you find things visually 'wrong' thats fine. I just grabbed some random screenshots tbh .

I'll do a video at some point. Water from a certain angle with certain lighting looks 100% convincing. Static's can't show that. Regarding your 2nd comment - not sure exactly what you mean and again depends on camera angle. What's the dogs here is zero lod, zero geo morphing, zero z shadow fighting. So terrain no matter how far you can see looks the bollocks. Focus on 1 peak in the distance - move towards it; perfect!. Also remember Work In Progress!__dbg.marcher.u.waveEarlyExit.value = 0

Yeah the waves do have a mathematical view. Easy to see when static, less so when moving. Procedural generation will do that!.

water now is staggeringly good! Proper beer/lamb for depth, waves, lapping, water's a bugger because the same water looks different depending on your view. Look at your feet see the seabed, look across it and it can be almost dark. Managed to get that working successfully.

Been a slog. Up'd opus 5 to max (no idea if that truly benefitted tbh). Perseverance pays off with these things though. Near photo realistic landscapes now - eclipses previous effort by some margin. But nothing to show yet until we beat my personal PITA ..... WATER. Such a difficult thing to get right; always a compromise on visuals against performance. Usually looks cheap or just too "gamey". So like the terrain we are going for realism. To achieve that I decided we need to model how/why/where volumes of water form. My logic being if its physically correct then we are half way to it looking correct. Usually these things are cheats like most 'effects'. So we use what we have plenty of... ram. For shadows for example to save a few computes per pixel the entire landscape shadow map is pre computed (around 8gb) - it can be optimised later size wise. Doing just this knocked 5% of render time. I can think of similar such tricks for water.