pouët.net

Go to bottom

Random "work in progress" shots

category: general [glöplog]
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
added on the 2013-04-18 17:48:57 by psonice psonice
demo goes first! :D
BB Image
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.
added on the 2013-04-18 20:39:53 by Xetick Xetick
Xetick: Looks awesome, will be nice to see the result if you go make a demo with it :)
added on the 2013-04-19 09:54:52 by ekoli ekoli
Looks like dancing ghosts :)
added on the 2013-04-19 10:10:44 by psonice psonice
@psonice, now I can't unsee it!
added on the 2013-04-20 05:43:30 by a13X_B a13X_B
i see three people eating invisible sandwiches
added on the 2013-04-20 18:53:46 by pista pista
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.
added on the 2013-04-20 19:39:14 by maali maali
You've been sniffing glue again, haven't you..
added on the 2013-04-21 00:05:53 by trc_wm trc_wm
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
added on the 2013-04-21 00:08:33 by maali maali
BB Image

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.
added on the 2013-04-22 02:23:02 by bloodnok bloodnok
motherfkn pterodactyls!
added on the 2013-04-22 10:18:12 by raer raer
OK, I admit I tried waaay too long to try and see what Maali was seeing, but there are totally pterodactyls in there...
added on the 2013-04-22 11:18:49 by bloodnok bloodnok
bloodnok, those timings, what are you measuring there?
added on the 2013-04-22 19:13:54 by TLM TLM
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...
added on the 2013-04-22 22:44:31 by bloodnok bloodnok
Quote:
being lit by the sun below the horizon (bug)


You know, a light source between the clouds and the ground would actually rule.
added on the 2013-04-22 22:53:29 by psonice psonice
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.
added on the 2013-04-23 00:02:58 by bloodnok bloodnok
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.
added on the 2013-04-23 01:09:20 by psonice psonice
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.
added on the 2013-04-23 01:35:09 by bloodnok bloodnok
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?
added on the 2013-04-23 02:09:12 by psonice psonice
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).
added on the 2013-04-23 02:45:40 by bloodnok bloodnok
Here's a view with the light above the clouds:

BB Image
added on the 2013-04-23 02:48:18 by bloodnok bloodnok
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.
added on the 2013-04-23 06:09:34 by bloodnok bloodnok
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.
added on the 2013-04-23 09:53:49 by psonice psonice

login

Go to top