The HSV/HSB color space is not very well defined. Particualrly in the most common implementations color of the same volume/brightness are not appearing equally bright to a human eye.

But eventually unless you doa scientific application (e.g. if you just do it to get a nice garphical effect for another project) you can always tweak the conversion till you get pleasant results.

Personally I prefer YUV to HSB becuase it has better "equal" luminance values, and you get something similar to hue by the combining the u and v vectors.

I've downloaded the code, but I was too distracted with other things yet to dig into it.

Now that the code is working, I might try some other colour space conversions to see if it simplifies the shader.

After posting the updated code last night, I figured out what was causing the grey band at the bottom of the screen. In the BufferedImage version, I am faking the distance of the 'vertices' used to draw the sky, however, in the shader version it is using an orthographic projection where vertices are close to the camera. Having the vertices this close causes an issue with lerp-ing the overcast sky factor into the sky colour. Removing the lerp made the sky show with correct colours.

Found a different HSV to/from RGB conversion algorithm here which fixed the purple sunsets on the mobile. All I can think is that the GLSL compiler on the mobile didn't like the branching or something in the old version.

The problem of the grey band at the bottom of the screen still persists, but it is a minor issue now.

The atmosphere_libgdx.zip at the PAMD link in the first post contains the updated shader project.

After a little investigation, I think I have narrowed down the Android sunset colour problem to the function converting HSV back to RGB. If that step is taken out, the colours displayed on the desktop and the mobile are basically identical. I don't know if its the float precision, or maybe something to do with casts since that is the only function with casts in the frag shader.

Another thing I am pondering, is why in the simple render to BufferedImage version, the bottom of the screen renders in light colours (as it should) while in both desktop and mobile shader versions a grey band is rendered.

Anyway, any pointers anyone might have for things that I missed in the conversion to shaders, slight mathematical differences or shader gotchas, would be appreciated.

After Roquen reminded me about the paper, I spent this weekend getting a basic version of "A Practical Analytic Model for Daylight" working.

The code is based on the Sky Dome class from JME2, with the bits I didn't need removed, and converted to work in screen space. There are two versions, the first simply creates a BufferedImage and displays it in a JFrame. The second version uses a shader created from the first version's code.

One thing I do need a bit of help with, is that the Android version of the Libgdx shader code displays strange colours as the sun is setting. It seems to not be including any green in the colour output from the fragment shader. When the sun is high in the sky, everything looks normal, just as the sun nears the bottom of the screen it turns to purple and then dark blue.

Some of the things are easy, its just ones like the Rayleigh scale depth, or trying to figure out why if I draw the sky sphere with size "atmosphere radius + 1" (i.e. just outside the atmosphere depth) it doesn't work properly, but if it is drawn at "atmosphere radius * 1.5" does.

Over the weekend I found out just how hard it is for a not overly mathematical person to make heads or tails of the atmospheric scattering maths in research papers. I also found out how hard it is to find working example code (Java or otherwise) that shows even the most basic scattering equations working.

So, I present to you, an implementation of the GPU version of Sean Oneill's atmospheric scattering.

Since it can run on mobile phones running Java ME, I doubt it can improve performance that much. I mean, does it even allow floating point? I seem to recall the Java ME doesn't, which suggests that Java FX can't either.

It's not that Java ME can't use floating point numbers, the problem used to be that the phone hardware didn't support floating point operations. In fact, from what I have read, anything that offers CLDC 1.1 supports floating point.

I think the idea of a JVM on PS3 is a good one. However, I don't think it is going to get anywhere as a community driven effort. We as Java developers and game programming hobbyists don't have the weight or finances to get something like this off the ground.

I think for this to have any chance of happening, there needs to be official backing from Sun. Also Sony has to be shown an overwhelming business case as to why bothering with Java on their console is going to make them any money, or give a competitive advantage over Nintendo and Microsoft.

I think our only chance is for the PS3 JVM to ride in on the coat-tails of something like Project Darkstar, with a passionate spokesperson taking the lead and making the case *cough*ChrisM*cough*.

If drawing a few hundred quads on screen is causing major slowdowns for your tile engine then you have much bigger problems.

The batches you should be creating are making sure you draw all tiles with the same texture before switching textures and drawing the next batch of tiles. You could even get fancy and have multiple tile textures in a larger texture to avoid even more texture switching.

If its the shaders going wrong then I'm not really sure I can help. They're just pulled straight from the demo code zip. It could just be that it need some specific gfx card feature that both machines I've run it on just happen to have by chance (laptop 9500M, desktop 8800GTS).

Although from my experience running it on the laptop, and you using a mobile gfx card too, and both of us getting problems, I'm leaning towards it being a mobile gfx card/driver problem.

If you're desperate to see what it looks like I also got the C version compiled (for Windows). I could bundle it up with all the DLLs and send it to you. It does look slightly better too since the TIFF of the earth in the demo has a proper reflectance value while the JPG from the Java version just has uniform reflectance on land and sea.

I decided it would be much improved if the C code that he released was running in Java .

So, here it is. Nearly everything is done in shaders so and it uses 8 texture units. There is also a slight problem I found when running this on my laptop. In inscatterS.glsl I have commented out a line that causes a very nasty crash where the laptop's display driver stops responding. The same thing happened with the C version so its probably a driver problem. The same shader code worked fine on my desktop. So... you can pop that line back in if you think your gfx card driver is bug free.

If the link/download is broken, send me a PM and i'll email you the zip, its only ~90k.

Controls:left-mouse to move the sunshift + left-mouse to rotate the earthctrl + left-mouse to rotate the sceneup and down arrows to change altitude

Here are a few pics of my setup. Not quite as console packed as Chris' but I'm still at Uni so...

First pic (On the couch):This is a picture of my meagre home entertainment setup. The only piece of game related goodness is the PS2, sadly the only console I own. Also to be seen are my "coffee table", a small portion of my DVD collection, HL2 hat, and if you look closely a tyre pressure guage. Hard to see are all the cables snaking away from the VCR/DVD which connect to things in the next pic.

Second pic (Messy desk):As you can see here, my desk is a little messy. Two 20" widescreen monitors and down the bottom, my pride and joy, an HD widescreen video projector for 250cm of gaming/tv/movie goodness . Other things to note in this shot are my home-made plush headcrab relaxing with a bit of Java coding, and a Terminator head coffee mug (Universal Studios). The MGM Grand lion can be seen in its natural habitat stalking its prey, the ever elusive Wizard Hat of Excalibur (souvenirs from a trip to Las Vegas). If you look closely just behind the two stacks of CDs near my keyboard, you can see the closest thing I have to an XBox... a little toy XBox branded motorbike game that was in a packet of cereal.

BTW, if you need to ask why I have two monitors and a video projector and no furniture... I pity you

I am having kind of the same problem except ANY application stops repainting when I enable the OpenGL pipeline. When using a GLJPanel, the JOGL rendering stops as well.

I have noticed that things are fine until the window has been fully initialised, i.e. the taskbar button has been created, etc. Buttons repaint fine, the JOGL panel repaints, then everything just stops.

If I'm using the default L&F, the frame repaints properly on resizes, but none of the contents do. If I use a custom L&F, such as substance, the entire frame and contents stop repainting.

Everything works fine if I don't use "-Dsun.java2d.noddraw=true -Dsun.java.opengl=True".

I only noticed this after I updated to the latest version of 1.6 (1.6 b105 I think, I'm not at my dev machine). At the same time I also updated my video card drivers so like Pandaemonium I don't think it's a driver issue.

I also have the same problem with the Photo Cube demo from Chris Campbell's blog. Pipeline disabled works perfectly, pipeline enabled just stops repainting.

Ok, here is the new code rewritten from scratch. As I said above there is an issue with the offset when objects are shadowing themselves but overall it is working. There is room for optimisation of setting rendering states, etc. but the basics are there.

The two major issues with the first code were the setup of the texture matrix, and the shader code I was using to do the shadowing.

I cobbled the attached code together from various tutes around the web. The torus, plane, and spinning spheres display with something that looks like shadowing, but the shadows do not seem to match the rotation/orientation of the objects. I think the problem lies with how I am setting up the texture matrix but I can't figure out where I've gone wrong.

Would some kind soul familiar with GLSL shadow mapping please take a look and point me in the right direction?

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org