Hi Devsh.
I just mean, if possible, trying to make the visual enhancements with minimal change to the cloud system as it is now. (to keep compatability)
As I said, the new version of irrWeatherManager should be released by January 5th or sooner, and then you can start your work with the shaders.
We'll see how it goes and then figure on another release.
irrWeatherManager 0.0.5 - weather system for Irrlicht
New release: irrWeatherManager 0.1.5
Sourceforge page:
http://sourceforge.net/projects/irrweather/
Screenshots:
https://sourceforge.net/dbimage.php?id=288199
https://sourceforge.net/dbimage.php?id=288197
https://sourceforge.net/dbimage.php?id=288201
Change log:
This is a pretty big release. It's a major improvement from 0.0.1.
All the media has been changed (cloud particles use 4x4 palettes now) including cloud textures, skydome textures, and skybox textures.
The scene clear color and fog is now set to the atmosphere's lowest point's color.
Everyone using the older version should certainly update to this latest release.
Enjoy, and please leave feedback.
Sourceforge page:
http://sourceforge.net/projects/irrweather/
Screenshots:
https://sourceforge.net/dbimage.php?id=288199
https://sourceforge.net/dbimage.php?id=288197
https://sourceforge.net/dbimage.php?id=288201
Change log:
Added: random texture coordinates for each cloud particle on the cloud's palette
Removed: cloud particle sorting and child particles
Improved: added setDefaults() function to SCloudCreationInfo
Removed: SCloudCreationInfo constructor
Added: better support for cloud creation info in cloud layer creation
Added: support for random cloud particle palettes for each cloud
Added: simple moon
Added: ICloudLayer class that keeps a list of all clouds in it and provides access functions to them
Added: functions to add, get, and remove cloud layers to the weather manager
Added: two new cumulus particle palettes
Fixed: crash when application using irrWeatherManager is closed
Added: lightning effects using Sudi's CBoltSceneNode
Added: "host cloud" lights up when lightning bolt comes out of it (early test)
Fixed: ICloudSceneNode's bounding box now fits over the particles, not just their positions, so it's the "true" bounding box
Changed: sky and starbox textures now fade into a fog color; atmosphere looks more expansive and unlimited now
Fixed: cloud rendering bug
Added: ICloudSceneNode::setCloudParticleSize()
Fixed: corrected some credits in source files
Changed: cleaned up code
Changed: updated skydome and skybox textures to use alpha channel for "fog"
Added: some changes to IAtmosphereSkySceneNode
Added: auto-update fog color to IAtmosphereSkySceneNode
This is a pretty big release. It's a major improvement from 0.0.1.
All the media has been changed (cloud particles use 4x4 palettes now) including cloud textures, skydome textures, and skybox textures.
The scene clear color and fog is now set to the atmosphere's lowest point's color.
Everyone using the older version should certainly update to this latest release.
Enjoy, and please leave feedback.
Josiah Hartzell
I've tended to the code for sun update... I have made changed to headers and sources with "Atmosphere" in them. There is no more sun movement bug, however I find the code EXTREMELY messy (like mine before) so I will go through it cleaning up pazystamo's original code etc.
I will also be working towards implementing atmospheric scattering on both the ground and the sky and providing the texture for cheap reflections for nodes (by name, something like "skyDomeScatter"), so you can use it. I have reworked my shader which doesn't have pixel distribution issues anymore (stereographic projection of hemisphere on a circle which is then morphed to a square). I have provided source in there
After that I will resume cleaning up and introduce options to make the cloud textures higher resolution with more particles, also I will add batched and hardware modes for billboards in the clouds. Then I will slowly implement techniques from Flight Simulator, first being the octagonal ring of impostors to make the cloud cover even thicker.
http://www.mediafire.com/?6rnjfn5xnjsnec6
EDIT: I came up with a basic idea of my algorithm
GroundScatter+ThroughLighting(a.k.a. rimlighting)+ThroughDiffuse+Ambient+DiffuseReflectance
The ambient term doesnt require explanation
Basically the water droplets in a cloud do two things, diffract and reflect light.
The light from the skydome is reflected by the cloud, the thing is that the cloud has no explicit normals and the light is reflected from everywhere. However we can define that the light reflected from the center of the cloud is blocked or outscattered by the thickness of other droplets between it and the camera. Also light from the skydome is unlikely to reach the droplet through the other side of the cloud.
Therefore we can model the cloud with a bounding ellipsoid (like bbox and sphere), for each fragment/vertex we can compute a normal describing a hemisphere on a tangent plane based on the direction from center of the elipsoid. This can all be approximated by a spherical harmonic of the skydome with optimized updates, the coefficients can be read back with a WARPED normal which would mean that a wider angle of the harmonic would be read back. However the ellipsoid cannot take extremes of the cloud into account (like really far out puffs) so statistical measures must be taken into account ((2-3)*standard_deviation of distance from center being the ellipsoid's radii). This then means we can attenuate the reflected skydome light by the length of the ray passing from the surface of the elipsoid to the vertex/fragment raised to the power of a reflectance exponent and then multiplied by a constant and with an added constant unique for each cloud. If we imagine the exponent as gl_FrontMaterial.shininess, the constant as "specular" and the added constant as some other value. Then clouds full of snow and ice can be really reflective and thick heavy storm clouds can not be reflective.
Next up we have the clouds scattered lighting, two kinds. From the sun straight to your eye through the cloud and from the sun to the cloud diffracted out in many ways to your eye. We must trace a ray through the cloud from the sun to the current vertex/pixel and through the cloud to the eye, this is computationally weird. We simply cant do it realtime, however we can represent each billboard with a sphere and group the smaller spheres together into elipsoids so we dont run out of frame time or instructions. We precompute the opacity/optical depth of the billboards by marching through their textures and calculating an average
O = (E(areaoftexel/PI*(1-alpha)*(k-grayscale)))*c
where k is a constant, c is another constant. We can then scale that by the diameters for each elipsoid obtaining an optical depth in 3 directions.
Now for the beautiful part, we trace the ray through the cloud's elipsoids and get the length of the ray inside each of them. The opacity cast by the puff will equal O*diameter/length, the opacities received by many puffs will sum up. Then the diffuse light of the sun will equal sunDiffuse-sunDiffuse*sumof(Opacity for the sun to fragment ray) clamped to a minimum of 0.0 which can be attenuated by the dot-product of the sun and the normal we used in looking up the skydome reflectance.
The story is similar with the RimLighting/ThroughLighting, but the light received by sunDiffuse-sunDiffuse*sumof(Opacity for the sun to fragment ray) is attenuated by the exponential (again shininess) cosine of the angle between the sun-to-frag and camera-to-frag rays and the summed opacity of the puffs between the fragment and the camera. Here I must make an amendment to my idea about SH reflectance from skydome, the camera opacity to fragment reflecting light will be the same as here instead of the one through the crude ellipse.
I may experiment with attenuating both ThroughLighting and ThroughDiffuse by the angle between the camera ray and the normal of the point where it comes out of the cloud and the same for the camera ray however I think it wont produce reliable results.
The scatter term will be done like for terrain scattering but I may use the data from the above to sample scattering directly through the cloud and treat it more like an atmosphere.
I should yield a result close to this
I will also be working towards implementing atmospheric scattering on both the ground and the sky and providing the texture for cheap reflections for nodes (by name, something like "skyDomeScatter"), so you can use it. I have reworked my shader which doesn't have pixel distribution issues anymore (stereographic projection of hemisphere on a circle which is then morphed to a square). I have provided source in there
After that I will resume cleaning up and introduce options to make the cloud textures higher resolution with more particles, also I will add batched and hardware modes for billboards in the clouds. Then I will slowly implement techniques from Flight Simulator, first being the octagonal ring of impostors to make the cloud cover even thicker.
http://www.mediafire.com/?6rnjfn5xnjsnec6
EDIT: I came up with a basic idea of my algorithm
GroundScatter+ThroughLighting(a.k.a. rimlighting)+ThroughDiffuse+Ambient+DiffuseReflectance
The ambient term doesnt require explanation
Basically the water droplets in a cloud do two things, diffract and reflect light.
The light from the skydome is reflected by the cloud, the thing is that the cloud has no explicit normals and the light is reflected from everywhere. However we can define that the light reflected from the center of the cloud is blocked or outscattered by the thickness of other droplets between it and the camera. Also light from the skydome is unlikely to reach the droplet through the other side of the cloud.
Therefore we can model the cloud with a bounding ellipsoid (like bbox and sphere), for each fragment/vertex we can compute a normal describing a hemisphere on a tangent plane based on the direction from center of the elipsoid. This can all be approximated by a spherical harmonic of the skydome with optimized updates, the coefficients can be read back with a WARPED normal which would mean that a wider angle of the harmonic would be read back. However the ellipsoid cannot take extremes of the cloud into account (like really far out puffs) so statistical measures must be taken into account ((2-3)*standard_deviation of distance from center being the ellipsoid's radii). This then means we can attenuate the reflected skydome light by the length of the ray passing from the surface of the elipsoid to the vertex/fragment raised to the power of a reflectance exponent and then multiplied by a constant and with an added constant unique for each cloud. If we imagine the exponent as gl_FrontMaterial.shininess, the constant as "specular" and the added constant as some other value. Then clouds full of snow and ice can be really reflective and thick heavy storm clouds can not be reflective.
Next up we have the clouds scattered lighting, two kinds. From the sun straight to your eye through the cloud and from the sun to the cloud diffracted out in many ways to your eye. We must trace a ray through the cloud from the sun to the current vertex/pixel and through the cloud to the eye, this is computationally weird. We simply cant do it realtime, however we can represent each billboard with a sphere and group the smaller spheres together into elipsoids so we dont run out of frame time or instructions. We precompute the opacity/optical depth of the billboards by marching through their textures and calculating an average
O = (E(areaoftexel/PI*(1-alpha)*(k-grayscale)))*c
where k is a constant, c is another constant. We can then scale that by the diameters for each elipsoid obtaining an optical depth in 3 directions.
Now for the beautiful part, we trace the ray through the cloud's elipsoids and get the length of the ray inside each of them. The opacity cast by the puff will equal O*diameter/length, the opacities received by many puffs will sum up. Then the diffuse light of the sun will equal sunDiffuse-sunDiffuse*sumof(Opacity for the sun to fragment ray) clamped to a minimum of 0.0 which can be attenuated by the dot-product of the sun and the normal we used in looking up the skydome reflectance.
The story is similar with the RimLighting/ThroughLighting, but the light received by sunDiffuse-sunDiffuse*sumof(Opacity for the sun to fragment ray) is attenuated by the exponential (again shininess) cosine of the angle between the sun-to-frag and camera-to-frag rays and the summed opacity of the puffs between the fragment and the camera. Here I must make an amendment to my idea about SH reflectance from skydome, the camera opacity to fragment reflecting light will be the same as here instead of the one through the crude ellipse.
I may experiment with attenuating both ThroughLighting and ThroughDiffuse by the angle between the camera ray and the normal of the point where it comes out of the cloud and the same for the camera ray however I think it wont produce reliable results.
The scatter term will be done like for terrain scattering but I may use the data from the above to sample scattering directly through the cloud and treat it more like an atmosphere.
I should yield a result close to this
Last edited by devsh on Sat Dec 18, 2010 8:47 pm, edited 1 time in total.
The features you're working on sound good, Devsh.
About the original ATMOSphere code, yeah, it's very messy. I haven't yet gotten to cleaning it up, but instead focused on the more important things first.
Don't forget, the cloud textures can be any width and height. The texture coordinates are from 0.0 to 1.0, not from 0 to texture height or 0 to texture width.
ie, a 512x512 texture with 4x4 particle sectors would work the same as a 2048x2048 texture with 4x4 particle sectors.
But it is a good idea to give the user an option to specify the amount of particles in the texture.
One thing I'll have to advise against, however, is providing a download to another full version of irrWeatherManager.
A few more times of that and we will have several of the "same" versions flying around with different features and such, and that will only complicate support for users, among other things.
So if you will, just send me the changed files to be integrated with the stable releases so we can avoid such problems.
About the original ATMOSphere code, yeah, it's very messy. I haven't yet gotten to cleaning it up, but instead focused on the more important things first.
Don't forget, the cloud textures can be any width and height. The texture coordinates are from 0.0 to 1.0, not from 0 to texture height or 0 to texture width.
ie, a 512x512 texture with 4x4 particle sectors would work the same as a 2048x2048 texture with 4x4 particle sectors.
But it is a good idea to give the user an option to specify the amount of particles in the texture.
One thing I'll have to advise against, however, is providing a download to another full version of irrWeatherManager.
A few more times of that and we will have several of the "same" versions flying around with different features and such, and that will only complicate support for users, among other things.
So if you will, just send me the changed files to be integrated with the stable releases so we can avoid such problems.
Josiah Hartzell
Too many complications. We went over this. 
Helping is fine and encouraged, but this is still a one-person project;
I created it for the reason of using it in my game.
Your contributions are just as the contributions of ATMOSphere, bolt scene node, etc.
Therefore, the only versions that should be available for download are those from my Sourceforge downloads.
Helping is fine and encouraged, but this is still a one-person project;
I created it for the reason of using it in my game.
Your contributions are just as the contributions of ATMOSphere, bolt scene node, etc.
Therefore, the only versions that should be available for download are those from my Sourceforge downloads.
Josiah Hartzell
SVN is not adding too many complications... trust me I was where you were and replying "SVN is too many complications" was my euphemism for "how the gently caress do you use that thing?"... its easy to set up with the right client, all you gotta do is click commit each time you make a change and I can view your progress live instead of you having to zip entire source or worse yet, me sending you zips where you have to search for changes etc. a diff file gets in done in one click. Not to mention branches where the development is independent and the tested stuff can be merged.
as long as there is no svn i will post my updates to your weather manager publicly (but somewhere else than this thread)
as long as there is no svn i will post my updates to your weather manager publicly (but somewhere else than this thread)
Dear cobra,
I have found yet another bug, You are not sorting your billboards. You may not be aware but the cloud puffs pop in front of each other and there is no physically correct occlusion.
Two ways we go about this, have each cloud as a hardware billboard batch (my other proj) and have hardware vertex buffers and dynamic index lists. We set the first indices to draw the triangles furthest away from the camera plane (not the camera). Ofc for legacy hw we need to have non hw batched billboards. I will be planning to regenerate the index lists in a separate thread.
EDIT: I also fixed the second sun+moon bug, not only it was jittering while the camera was moving but also going back and forth due to bad interpolation. I've cleaned up most of the ATMOsphere code, I will only need to fix the skydome (which is a sky cone really ) and clean up the code in Sky&&Star nodes. Then I shall proceed into action with a nice compiler flag, and build a real-time scattering framework. Then I will apply this on terrain instead of the crappy fog. But that is all after christmass because I'm off away.
I have found yet another bug, You are not sorting your billboards. You may not be aware but the cloud puffs pop in front of each other and there is no physically correct occlusion.
Two ways we go about this, have each cloud as a hardware billboard batch (my other proj) and have hardware vertex buffers and dynamic index lists. We set the first indices to draw the triangles furthest away from the camera plane (not the camera). Ofc for legacy hw we need to have non hw batched billboards. I will be planning to regenerate the index lists in a separate thread.
EDIT: I also fixed the second sun+moon bug, not only it was jittering while the camera was moving but also going back and forth due to bad interpolation. I've cleaned up most of the ATMOsphere code, I will only need to fix the skydome (which is a sky cone really
) and clean up the code in Sky&&Star nodes. Then I shall proceed into action with a nice compiler flag, and build a real-time scattering framework. Then I will apply this on terrain instead of the crappy fog. But that is all after christmass because I'm off away.DevSH, the progress sounds pretty good.
I'll see about setting up an SVN for us to share code.
However, by adding complications I did not mean actually using the SVN.
- Josiah
I'll see about setting up an SVN for us to share code.
However, by adding complications I did not mean actually using the SVN.
- Josiah
Last edited by cobra on Wed Feb 23, 2011 3:49 am, edited 1 time in total.
Josiah Hartzell
the IAtmosphereWeatherManager class is almost fully cleaned up, and optimized and bug free.
I am adding extra functionality to IAtmosphereSkyNode to approximate realtime scattering and provide a texture which is refreshed 4-8 times a second (more often if day speed really fast) and I will be swapping sun and moon rotation on CPU for GPU vertex shader code. (all only enabled if compiler flag IRR_WEATHER_ADVANCED_GFX is enabled). Furthermore the skydome texture can be used for cheap reflections, I will also add an option to compute a spherical harmonic from the skydome (CPU using lowres/lowsample straight-to-harmonic method without calculating texel solid angles etc or GPU method involving pingponging the skydome texture if floating point render targets are supported)
EDIT: Love it how he calls me DevSH, lol... my nickname was invented about 3 years before I even had the faintest idea of spherical harmonics
I am adding extra functionality to IAtmosphereSkyNode to approximate realtime scattering and provide a texture which is refreshed 4-8 times a second (more often if day speed really fast) and I will be swapping sun and moon rotation on CPU for GPU vertex shader code. (all only enabled if compiler flag IRR_WEATHER_ADVANCED_GFX is enabled). Furthermore the skydome texture can be used for cheap reflections, I will also add an option to compute a spherical harmonic from the skydome (CPU using lowres/lowsample straight-to-harmonic method without calculating texel solid angles etc or GPU method involving pingponging the skydome texture if floating point render targets are supported)
EDIT: Love it how he calls me DevSH, lol... my nickname was invented about 3 years before I even had the faintest idea of spherical harmonics