Random "work in progress" shots
category: general [glöplog]
ferris: i want to know what love is
barti: that looks cool. New demo?
sigflup: i find it extremely easy to masturbate to
TomoAlien> I wouldn't imagine any emulator would handle it.
Some draft I made in shadertoy. Will publish it once I figure out why does it crash browsers on windows, while working perfectly fine on Linux and Mac.
w23: amazing shot !! keep working :D please update us once you done here D:"
w23: angle shadercompiler it compiles to HLSL and then uses DirectX.
I think linux & mac use the native shadercompilers.
For Firefox see about:config -> webgl.prefer-native-gl, you also might want to uncheck the shader-validator. If that works - it's angle, you might want to file a bug with a minimal reproducer codesample.
I think linux & mac use the native shadercompilers.
For Firefox see about:config -> webgl.prefer-native-gl, you also might want to uncheck the shader-validator. If that works - it's angle, you might want to file a bug with a minimal reproducer codesample.
las: yes, I know about ANGLE :D. I just don't know how to properly debug it, instead of just commenting random stuff to see whan happens (and then restart browser again and again).
Thanks for suggestions, I will try them when I get home.
Thanks for suggestions, I will try them when I get home.
w23: very nice!
w23: Impressive! One little thing, there is something strange going on with the clouds on top part of the image... It feels like it's too opaque or something...
agree.. looks really nice..
TLM could it be a lack of distance fogging?
in reality at that height looking down on a landscape there'd be a slight distance fog/haze from top to clearer at the bottom
TLM could it be a lack of distance fogging?
in reality at that height looking down on a landscape there'd be a slight distance fog/haze from top to clearer at the bottom
The clouds overall feel too dark. Most clouds have more brights than dark "surface area", especially when viewed from above, since the shadowing within a cloud will happen at the point furthest from the sun, not the other way around.
a way I've tried before is to raymarch through the cloud and at each point, raymarch towards the light source until you leave the cloud. Attenuate the light coming in by the distance of the light-raymarch, then again by the distance from the cloud-entry to the current sample.
This only accounts for one level of scattering though, and is also slow as shit.
This only accounts for one level of scattering though, and is also slow as shit.
w23: there's something strange with both the cloud blending and the surface lighting. The clouds seems to be too dark when translucent, and the bumps are visible everywhere. Real-world bumpy surfaces are only really visible (for the diffuse term) really close to the transition from in-light to in-shadow. Are you doing all the rendering in gamma-space, by any chance? If so, try to take the square root of the resulting color and re-tweak all input-colors...
hi. I developed the 512 color method back in 2012 (We have advanced much further since then...)
The cycle exact emulator "Exodus" handles it fine. Unfortunately it requires a really beefy i5 (better i7) CPU to run at full speed.
www.exodusemulator.com
The cycle exact emulator "Exodus" handles it fine. Unfortunately it requires a really beefy i5 (better i7) CPU to run at full speed.
www.exodusemulator.com
Also I wouldn't go to the Sonic Retro IRC to ask technical questions... if me, Gerbilsoft, andlabs or Jorge aren't there, chances are you'll get a bullshit answer. Retro is full of noobs.
Chilly Willy has done quite a lot of work on the DMA/512 technique too
Oerg866, were you the first to implement the technique?
w32: If you want to take things a bit further, you could look at implementing an approximation for scattering within the cloud layer.
First of all, when you look at clouds in the real world (source: just been outside :)), only the very edges have any amount of transparency. It doesn't take much cloud depth for the light scattered from the cloud to completely overwhelm any light transmitted from behind the cloud. The only exception to this is when you've got the sun behind the cloud and even then it doesn't take much cloud for you not to be able to see the disc of the sun. So it means you can up the opacity of all but the thin parts of the cloud.
Next is looking at how clouds scatter light. Water vapour droplets are larger than the wavelength of visible light, so they tend to scatter white light in all directions. More light is scattered forwards compared to 90 degrees. Here's a place to start. Basically you need a phase function that gives you the intensity of light scattered from the incoming light ray in a given direction. Here's one I found for GLSL:
That will allow you to calculate the light scattered off the top of the cloud. You'll need an approximation for the light that bounces around inside the cloud before exiting towards the viewer. The easiest would be a simple ambient term, but you could do something based on cloud density/thickness.
First of all, when you look at clouds in the real world (source: just been outside :)), only the very edges have any amount of transparency. It doesn't take much cloud depth for the light scattered from the cloud to completely overwhelm any light transmitted from behind the cloud. The only exception to this is when you've got the sun behind the cloud and even then it doesn't take much cloud for you not to be able to see the disc of the sun. So it means you can up the opacity of all but the thin parts of the cloud.
Next is looking at how clouds scatter light. Water vapour droplets are larger than the wavelength of visible light, so they tend to scatter white light in all directions. More light is scattered forwards compared to 90 degrees. Here's a place to start. Basically you need a phase function that gives you the intensity of light scattered from the incoming light ray in a given direction. Here's one I found for GLSL:
Code:
// mie phase - @pyalot http://codeflow.org/entries/2011/apr/13/advanced-webgl-part-2-sky-rendering/
float phase(float alpha, float g){
float gg = g*g;
float a = 3.0*(1.0-gg);
float b = 2.0*(2.0+gg);
float c = 1.0+alpha*alpha;
float d = pow(1.0+gg-2.0*g*alpha, 1.5);
return (a/b)*(c/d);
}
// where alpha = dot(light_direction, view_direction)
// g controls the shape of the distribution. For clouds use something around 0.90-0.99 as a starting point.
That will allow you to calculate the light scattered off the top of the cloud. You'll need an approximation for the light that bounces around inside the cloud before exiting towards the viewer. The easiest would be a simple ambient term, but you could do something based on cloud density/thickness.
@sigflup: yes... chilly willy took my source and made a demonstration with some images, and used it even though i said in the readme he shouldn't (for now anyway) and collected lots of fame for it...
also sigflup, dont use images from google as artwork ;/
i know because i used the SAME picture when testing our 512 color shit :D
i know because i used the SAME picture when testing our 512 color shit :D
btw sorry if I sounded rude in that PM....
Wow. Thanks for feedback and suggestions. I now feel stupid and slightly embarrassed because there's no science in my shader at all, it's all about trivialness hacked together with a lot of magic numbers that I had to introduce and tweak, while not really understanding their actual physical meaning.
Hell, I don't think I fully understand this gamma thing.
So, thanks again for links and suggestions, I will now go and make myself a little smarter (hopefully) :D.
Hell, I don't think I fully understand this gamma thing.
So, thanks again for links and suggestions, I will now go and make myself a little smarter (hopefully) :D.
@oerg866 Did you post about it on a public forum? Is the original posting on gendev? I'm having trouble finding it
also, Chilly Willy says this:
also, Chilly Willy says this:
Quote:
As I understand it, Oerg866 had a friend who thought up the idea, but couldn't write code that would give a stable display. Oerg866 took that code and managed to find a stable method of starting the display, but never did more than that one demo and forgot about it. I got the code from Oerg866, cleaned it up into a proper demo, figured out how to use the 256 wide mode as well as 320 wide mode (H32 in addition to H40), and made a series of demos that would allow more people to try their hand at using this mode. That was when Nemesis (I think it was him) did a detailed bus analysis of why the code worked, and posted details and suggested new code that would be better. I made some more demos using that new code, culminating in my raycasting + mod music CD demo which displays the raycast level in H32 DDC mode.
@alien^PDX dont' use the same test picture because we used that test picture?