pouët.net

Yes. Out of limestone (=

Nice :D I'd love to try something like that. But then i'd love to finish a demo too :P

demo goes first! :D

130k particles, color intensity is based on the current music playing, a curl noise is also applied that changes in intensity based on the music.

Xetick: Looks awesome, will be nice to see the result if you go make a demo with it :)

Looks like dancing ghosts :)

@psonice, now I can't unsee it!

i see three people eating invisible sandwiches

i see a dog like creature cheering over the fact a girl with a ponytail tripled over a wire and is about to faceplant in the lap of a sitting triangle-head priest who is gently putting an hand on her head to direct her into the right area.

You've been sniffing glue again, haven't you..

no, i have just demonstrated why ppl around me said to go for the obvious answer with rorschach tests so i can stay out of trouble. also, is our synth finished yet? :D

Cloud illumination... being lit by the sun below the horizon (bug), don't quite have the scattering right, and operating in slide-show mode (7fps). Starting to think that I may not be able to get it running nicely in realtime.

motherfkn pterodactyls!

OK, I admit I tried waaay too long to try and see what Maali was seeing, but there are totally pterodactyls in there...

bloodnok, those timings, what are you measuring there?

TLM: mainly different steps in the render, although it must be returning before finishing execution on the RenderGBufferCombiner step, because that's where the bulk of the work is happening. The Lighting step is doing terrain shadows and AO whenever the light direction or terrain changes (ie: not every frame) and Copy2 is bringing data across from the terrain generation thread to the render thread (about once a second).

For the OpenGL timings, I guess I should put a glFinish() before stopping the timer...

You know, a light source between the clouds and the ground would actually rule.

psonice: as a demo effect I think that could work... The main problem I have is when the view direction and light direction are both at a low angle to the cloud layer. It has to raymarch a long way across the cloud slab and at each point raymarch out towards the light. If you can keep those angles under control then it's reasonably quick.

Yeah, that's a bad worst case (but probably looks great!). Careful camera angles to the rescue?

Btw, I take it you're using a bounding box/whatever and skipping the distance to the top of the cloud layer? If not, that should optimise out a lot of marching.

Yeah, only marching within the bounding box (technically bounding-slab since it's just the top/bottom planes that are intersected). I also put an upper limit on the marching distance for the shallow-ray case so I don't grind everything to a complete halt. Doing a constant number of marching steps per ray leads to some pretty crazy looking clouds, especially as the eye moves through the cloud layer. A constant step length looks better, but can lead to some nasty cases. I also added an early-exit where the cloud has absorbed so much light that there's no point in continuing.

I'm just thinking how that could be optimised... it's hard.

One thing I notice though: in your screenshot, the clouds are quite 'high res' in the distance and 'low res' in the foreground. Maybe there's a case here for multi-pass rendering, where you render the closest clouds at low res and the most distant clouds at full res?

hmm... what you said just made me realise something... I increase the step size of the ray marching as I move along the ray, but it starts with a constant that isn't scaled with distance from the eye. For distant ray-plane intersections I could start the raymarching with a much larger step.

I've been thinking about ways to optimise/fake it as well... no flashes of inspiration yet. The key would be being able to estimate the cloud density from an arbitrary point, looking towards the light. I'm using a noise-texture as a heightmap, mirrored about the middle of the cloud-plane, so something might be possible.

I was considering applying the same raymarching code I used for the terrain (==quadtree in mipmaps), however that gives you non-interpolated intersections (so basically minecraft).

Here's a view with the light above the clouds:

The intensive part is querying for the scattered light along the path of the view-ray.

One cheat that could work is to project the total cloud density along the sun-rays (which are parallel since the sun is so far away) onto the lower cloud plane. Then when querying for density inside the bounding box, calculate the position of the sampling point along the sun ray between its upper and lower plane intersections and linearly interpolate the density.

This assumes that the cloud density is distributed evenly throughout the volume, which is false. This could be improved by also calculating the first points along the sun-ray where the density ~=0 and ~=1. This would assume that the total density along the ray is clustered in a single place, which I guess would lead to artifacts where separate clouds are shadowing eachother.

At the end of the day I want to integrate this with the other atmospheric scattering code, so that the clouds will cast shadows on the terrain and the terrain will cast shadows on the cloud, along with all the other eye candy like shafts of light and haze etc.

Can you use mipmaps in the scatter ray? That seems like a good fit, since you want light to 'scatter', just use higher mipmap levels (and bigger steps) as you move along the ray. It'd approximate the scatter effect a little while accelerating that part.