@t0neg0d said: I really like how this has turned out. Finally got a chance to try it and... WOW! You've done a great job.
Thank you. Your support means a great deal to me.
1 Like
@pspeed said: Given that, your current sun may already be good enough... just add bloom.Note: in Mythruna I took great pains to tweak the bloom settings to time of day. If you don’t already provide recommended intensity, etc. then that may be something you can factor in. (shrug)
I’ve added bloom to the sun in my “trunk” codeline, along with a sun disc that doesn’t have rays baked into it.
Bloom does seem to promote the illusion that the sun is much brighter than anything else in the scene, but its effectiveness is limited because I can’t increase the filter’s blurScale past about 2.5 without getting distracted by artefacts.
I assume you increase the bloom’s intensity when the sun is high in the sky and decrease it when the sun is low. Is that right?
@sgold said: I've added bloom to the sun in my "trunk" codeline, along with a sun disc that doesn't have rays baked into it.Bloom does seem to promote the illusion that the sun is much brighter than anything else in the scene, but its effectiveness is limited because I can’t increase the filter’s blurScale past about 2.5 without getting distracted by artefacts.
I assume you increase the bloom’s intensity when the sun is high in the sky and decrease it when the sun is low. Is that right?
I think for me bloom is actually highest when it is near the horizon. I use a Vector4f to set all of the bloom parameters based on time of day:
bloom.setBlurScale( value.x );
bloom.setExposurePower( value.y );
bloom.setExposureCutOff( value.z );
bloom.setBloomIntensity( value.w );
At noon it’s like: 1.0f, 3.30f, 0.2f, 0.5f
And at dawn it’s: 2.7f, 4.57f, 0.189f, 1.75f
Note: my flare quad in the non-bloom pics. That makes a big difference for making the sun look bright as the bloom will pick that up and blend it with everything around. Between that and the higher bloom, that’s why my sunsets/sunrises look like they do.
1 Like
Well maybee this weekend I finally get the time to test this out 
@pspeed said: I think for me bloom is actually highest when it is near the horizon. I use a Vector4f to set all of the bloom parameters based on time of day: bloom.setBlurScale( value.x ); bloom.setExposurePower( value.y ); bloom.setExposureCutOff( value.z ); bloom.setBloomIntensity( value.w );At noon it’s like: 1.0f, 3.30f, 0.2f, 0.5f
And at dawn it’s: 2.7f, 4.57f, 0.189f, 1.75fNote: my flare quad in the non-bloom pics. That makes a big difference for making the sun look bright as the bloom will pick that up and blend it with everything around. Between that and the higher bloom, that’s why my sunsets/sunrises look like they do.
Huh. Not what I expected.
In my experience the sun looks more disc-like at sunset since its light is less dazzling, so I had assumed you’d want less blur then, not more.
I’ve added hooks to the “trunk” version of SkyMaterial to apply glow colors to each object.
Right now I’m testing SkyControl with the following fixed parameters:
[java]
bloom.setBloomIntensity(1.7f);
bloom.setBlurScale(2.5f);
bloom.setExposurePower(1f);
[/java]
I’m pretty sure I don’t need ExposureCutoff since I’m using GlowMode.Objects. The sun’s unshaded color and glow color vary in unison based on its elevation.
The sun looks fine when it’s high in the sky, but I’m not satisfied with sunrise/sunset: the disc dissolves into a red blur. I’ll play with the bloom parameters and the colors and see what happens if there’s some haze to the sun image.
@sgold said: In my experience the sun looks more disc-like at sunset since its light is less dazzling, so I had assumed you'd want less blur then, not more.
That would depend on the filter and exposure you use on your real life camera. Unless it is extremely hazy, the sun is pretty bright even at sunset.
If you look through these:
https://www.google.com/search?q=sunset&source=lnms&tbm=isch&sa=X&ei=AWnrUrSwOaKkyQH7xYDQBQ&ved=0CAkQ_AUoAQ&biw=1181&bih=774
…it’s easy to see who set their camera up to capture almost no light at all. This is one of those interesting cases that depends on how many and what types of pictures a person has seen… because real sunsets are pretty damn bright but no one remembers them that way. (These days I frequently notice scenes in real life that no one would let me get away with in a render: “bloom is too high”, “clouds are too uniform”, “sky shouldn’t be that color”, blah blah…)
Anyway, in your case, unless you are also glowing the sky then I guess bloom will have limited effect as just a glow object. Still better than nothing, though.
Also, repeating the picture here… you can see that even with those settings the sun at dawn has much more definition than the one later in the day… even though as you say the settings imply otherwise. That’s because of the relative difference in colors around it. The sky is brighter in the day.
@sgold
I’ve completed a custom sky (2x cubemaps) that works similar to the “animated” domes you use in SkyControl.
What it does:
- Based on 12 images. 6 for the night sky, 6 for the day sky.
– The day sky is primarily the same image (I used a basic “sky blue” color texture) applied to each face of the cubemap. - Added 2 parameters to the shader.
– SkyTrans, defines the transparency. This will be used during transition from one skybox to the other (dawn/dusk).
– DuskDawnColor, this is a color you use to blend your day/night transition with.
Blending looks like this:
[java]
float transparency = interpolateTime(duskdawnTime, cycleLength, currentTime);
((Geometry) sky).getMaterial().setFloat(“SkyTrans”, transparency);
((Geometry) sky).getMaterial().setColor(“DuskDawnColor”, purpleDusk);
[/java]
Anyway, my question is, would you rather keep your control the way it is, or would there be an interest to use the above instead? If it’s the former I’ll rip whatever I need from your control (dome to put the sun/moon/clouds) and move it into my own sky. If it’s the latter then I’ll try to implement something. Might not be ready today though (probably during the weekend).
Anyway, let me know.
Made a crappy video to show it a bit, but… yeah, it looks really bad on this. 
[video]http://youtu.be/gLhyetJdNu0[/video]
Would it be possible to support both, domes and cubemaps?
I cannot see a downside in that, as then everyone can use what they have, as I can see good usecases for both.
Eg it might be intresting to have a sky with dynamic stars, based on a secondary scene using a 180° cam in a 3d skybox.
(As I do a space game, it would be a somewhat cool feature if you see the actuall other suns/planets in the sky and not something unrelated)
1 Like
I agree that cubemap backgrounds would be useful for many apps out there, it’s just so convenient for switching sky backgrounds at any moment easily and mixing them together to make a transition like @madjack did in his YT video. Maybe you guys could mix your code together? Cubemaps are a joke to integrate really, it’s just a matter of branching over a method to choose between the other sky or the cubemap… maybe on the construction we could have a boolean parameter to tell the plugin what sky we want and then a method to accept the cubemap images and building the cube, setting it to the static frustumFar and voila! Anyhow, I totally agree there, it would seal the deal guys 
1 Like
@Empire Phoenix said: Would it be possible to support both, domes and cubemaps? I cannot see a downside in that, as then everyone can use what they have, as I can see good usecases for both.Eg it might be intresting to have a sky with dynamic stars, based on a secondary scene using a 180° cam in a 3d skybox.
(As I do a space game, it would be a somewhat cool feature if you see the actuall other suns/planets in the sky and not something unrelated)
Yes. In fact I’m quite excited about integrating cube maps into SkyControl. I added that on my TODO list on Wednesday (post #257776).
But before I start work on anything new, I want to finish tuning the sun. Plus, if there any bugs to be fixed, those will take priority over new features.
Well, my integration is 75% done.
There are little things to iron out but it’s mostly done.
Unfortunately, I’m done for the day. Hopefully if I have time tomorrow I’ll finish this up. Once that’s done you guys can either use it or wait for @sgold to make his own (or integrate mine his own way into it).
@madjack said: @sgold Anyway, my question is, would you rather keep your control the way it is, or would there be an interest to use the above instead? If it's the former I'll rip whatever I need from your control (dome to put the sun/moon/clouds) and move it into my own sky. If it's the latter then I'll try to implement something. Might not be ready today though (probably during the weekend).Anyway, let me know.
I’m unsure what you mean by “keep it the way it is”. SkyControl’s implementation and interfaces are still evolving.
I plan to continue using DomeMesh geometries, at least for clouds. However, I also plan to make it easy to integrate billboards and baked cube maps where they make sense. In fact, I’m already planning (in my head) a tutorial on using spacescape star maps with SkyControl.
@sgold said: Yes. In fact I'm quite excited about integrating cube maps into SkyControl. I added that on my TODO list on Wednesday (post #257776).But before I start work on anything new, I want to finish tuning the sun. Plus, if there any bugs to be fixed, those will take priority over new features.
It turns out that the simplest way to combine cube maps with SkyControl is to superimpose SkyControl’s sun, moon, and clouds on top of an existing cube map. To this end, I’ve added a “clearStarMaps()” method to SkyControl and added a new section to my AddToExistingGame tutorial to explain how it’s used.
I’m considering other ways one might integrate external assets with SkyControl. In the mean time, I hope this simple change (only in the “trunk” line of my JME3 Utilities Project) will satisfy many of you.
I’ve made my own integration, but that’s a good idea to propose both ways to everyone as I’m sure it’ll be used by many.
1 Like
@madjack said: I've made my own integration, but that's a good idea to propose both ways to everyone as I'm sure it'll be used by many.
Sounds good to me. I’d like to see what you did. Please provide a pointer to the source code of your integration.
Hi guys, I am finally integrating the SkyControl to my project for testing right at the moment
Sorry @sgold for the delay, I wanted to do that a week ago, but I’ve been busy with the BetterTerrainControl testing.
So yeah, first off, I followed the quick installation guide you published yesterday on the repository and it’s very good, but I ran into a small issue: by default, the JME3 was using the 1.5 Java SDK version and so it threw a couple of errors and wouldn’t run or compile:
[java]warning: [options] bootstrap class path not set in conjunction with -source 1.5
E:\Users\Ben\Documents\JME3\Test6\src\jme3utilities\MySkeleton.java:144: error: diamond operator is not supported in -source 1.5
Collection<String> names = new TreeSet<>();
(use -source 7 or higher to enable diamond operator)[/java]
…so the solution to this problem for me was simply going to the PROJECT PROPERTIES under the SOURCE tab and selecting the 1.7 Java SDK version (named “7”) and clean/rebuild button like this:
All SkyControl code errors are gone and it runs now. Hope it helps others having a similar issue
Stay tuned @sgold, I’m testing this right now in my project 
1 Like
@sgold said: Sounds good to me. I'd like to see what you did. Please provide a pointer to the source code of your integration.
Sources are on Ochlocracy’s GitHub, which is private.
Your code hasn’t changed much. I just added 3 params to the constructor (2x colorRGBA and Texture… texArr). If texture array is valid, the control uses the cubemaps instead of north/south domes. The rest is pretty much the same. Only added flags to check which of cubemaps or domes to manipulate (rotation, coloring, etc). That sort of thing.
I will try to put a video tonight, but odds are, it’ll happen tomorrow.
@.Ben. said: So yeah, first off, I followed the quick installation guide you published yesterday on the repository and it's very good, but I ran into a small issue: by default, the JME3 was using the 1.5 Java SDK version and so it threw a couple of errors and wouldn't run or compile:
Thank you for helping with beta testing.
I’m surprised by the issue you found. I had thought the Java version was encoded in the project. I’ll investigate and either set it or else document the necessary build steps.
Just so it’s clear, I did NOT use one of your projects, but I rather simply created a new one. JME3 selected “JDK 5” by default, which is NOT compatible with your class structures, especially the parts with the diamond operators.