I used your Skydome in my game. I am realy impressed how easy it is and how good it works. I have some small issues. I will try to make it clear with the following screenshots.
As you can see at this pic the clouds end at some point near the horizon. This happen when I use cloudFlattering > 0.
I have some problems with the gras. I am using GrasLayerUtil from l2jserver-client project. I am sure about this problem. It could be possible that the gras doesn’t work very well.
In the last pic you can see a very nice result. I am very happy with the new sky and I will definitly use it. If you want to read more about the this skydome in my game Drohtin check out this post.
I read something about the software license. So wich one do you use?
The clouds in SkyControl end at the astronomical horizon, 90 degrees from the zenith. If your world is finite and not ringed by hills, or if your camera is significantly above the hilltops, your actual horizon will be below the astronomical horizon. A simple workaround would be to add some hills around the perimeter of your world.
There are various ways I might deal with low horizons in SkyControl. I’ll see what I can come up with.
I’m not familiar with GrasLayerUtil, so I won’t attempt to help you with that.
SkyControl is licensed under a FreeBSD license, which is very permissive. The text of the license is included at the top of every source file, and I encourage you to read it.
I thought about the idea with the mountains. But for some kind of maps (e.g. islands) it doesn’t work. So a possibilty to low the horizon will be great. I checked the licence in sourecode (thx for this hint).
I am also woundering if it is possible to add the seasons to the Skydome. It will be quiet nice if the solar altitude changes after a while. I found this value already in the class SunAndStar (solarLongitude). Are you thinking about an automatic mode to update this? For example x days are over and the altitude change about y.
Please stop calling it “SkyDome” – that’s the name of t0neg0d’s plugin, which is similar but quite distinct from SkyControl.
SkyControl already has seasons. As of Dec. 14th, you can set the approximate day of the year using getSunAndSky().setSolarLongitude(month, day). That will change the solar longitude which changes the solar declination and thus (indirectly) the sun’s altitude. There’s no direct support for incrementing the day at midnight, so a game that extends over several days should probably invoke setSolarLongitude(longitude) directly.
I’m still thinking about how best to address low horizons. The answer may depend on what else is in the scene. For an island setting, you might make the bottom dome look like ocean. For a flying game it might make more sense to distort the cloud dome.
By the way, I plan to alter portions of the API during the coming week. The main motivation for the change will be to enable SkyControl to update multiple shadow filters and/or shadow renderers – currently it can only update one of each, and it turns out that isn’t always sufficient.
@sgold said:
Please stop calling it "SkyDome" -- that's the name of t0neg0d's plugin, which is similar but quite distinct from SkyControl.
SkyControl already has seasons. As of Dec. 14th, you can set the approximate day of the year using getSunAndSky().setSolarLongitude(month, day). That will change the solar longitude which changes the solar declination and thus (indirectly) the sun’s altitude. There’s no direct support for incrementing the day at midnight, so a game that extends over several days should probably invoke setSolarLongitude(longitude) directly.
I’m still thinking about how best to address low horizons. The answer may depend on what else is in the scene. For an island setting, you might make the bottom dome look like ocean. For a flying game it might make more sense to distort the cloud dome.
I second this The plugin that is out there was a test to figure out how to get a freaking plugin to work. It is completely unfinished and I only used to it so someone could grab what was useful out of it and make something people could actually use.
@sgold said:
By the way, I plan to alter portions of the API during the coming week. The main motivation for the change will be to enable SkyControl to update multiple shadow filters and/or shadow renderers -- currently it can only update one of each, and it turns out that isn't always sufficient.
I committed this a little while ago. Each sky control instance now has an updater to keep track of its lights, shadows, and view ports. Here’s a summary of the API changes:
(1) to specify the main directional light source, invoke skyControl.getUpdater().setMainLight(light) – instead of skyControl.setMainLight(light)
(2) to specify the ambient light source, invoke skyControl.getUpdater().setAmbientLight(light) – instead of skyControl.setAmbientLight(light)
(3) to add a shadow filter, invoke skyControl.getUpdater().addShadowFilter(filter) – instead of skyControl.setShadowFilter(filter)
(4) to remove a shadow filter, invoke skyControl.getUpdater().removeShadowFilter(filter) – instead of skyControl.setShadowFilter(null)
(5) to add a shadow renderer, invoke skyControl.getUpdater().addShadowRenderer(dlsr) – instead of skyControl.setShadowRenderer(dlsr)
(6) to remove a shadow renderer, invoke skyControl.getUpdater().removeShadowRenderer(dlsr) – instead of skyControl.setShadowRenderer(null)
(7) to add a view port, invoke skyControl.getUpdater().addViewPort(viewPort) – instead of skyControl.addViewPort(viewPort)
(8) to remove a view port, invoke skyControl.getUpdater().removeViewPort(viewPort) – instead of skyControl.removeViewPort(viewPort)
I apologize for the inconvenience. The API will continue to evolve, but hereafter in a compatible fashion I hope.
@drothindev said:
I thought about the idea with the mountains. But for some kind of maps (e.g. islands) it doesn't work. So a possibilty to low the horizon will be great.
I’ve added a way to compensate for low horizons by depressing the clouds-only dome. To configure the amount of depression, invoke skyControl.setCloudYOffset(offset), where offset is between 0 and 1. This technique only works with cloudFlattening>0.
Offset=0 gives to the old behavior (now the default) in which clouds end abruptly at the astronomical horizon. I suggest you start with offset=0.3 and tune it from there by trial and error. If you wind up using an offset greater than 0.3, you may find it helpful to also reduce cloudFlattening from 0.9 to 0.8 or so.
I’ve noticed that if you change (camera) elevation, the “illusion” provided by the sky breaks as the texture effects will not be updated to account for the new horizon. You can also “fly through” the dome. Maybe the dome should just follow the camera.
@sgold said:
I've added a way to compensate for low horizons by depressing the clouds-only dome. To configure the amount of depression, invoke skyControl.setCloudYOffset(offset), where offset is between 0 and 1. This technique only works with cloudFlattening>0.
Offset=0 gives to the old behavior (now the default) in which clouds end abruptly at the astronomical horizon. I suggest you start with offset=0.3 and tune it from there by trial and error. If you wind up using an offset greater than 0.3, you may find it helpful to also reduce cloudFlattening from 0.9 to 0.8 or so.
@stenb said:
I've noticed that if you change (camera) elevation, the "illusion" provided by the sky breaks as the texture effects will not be updated to account for the new horizon. You can also "fly through" the dome. Maybe the dome should just follow the camera.
Disregard this for now, using skyControl.setCloudYOffset(0.5f) indeed works satisfactorily.
<span style=“text-decoration:line-through;”>There’s something in the SkyControl that doesn’t play nice with big 3D models. The model is not rendered on the screen with SkyControl enabled. Any idea on what it could be and how to debug?</span>
No there isn’t. I just didn’t realize I had to add my ViewPort to the SkyControl to get it to show.
Here’s my understanding of the situation:
(1) SkyControl already tracks camera motion, so raising the camera should not “break” it. At worst a high camera might expose a cloudless band near the horizon, which could be addressed by increasing cloudYOffset.
(2) SkyControl collects viewports solely for the purpose of updating their background colors, which are visible only when bottomDome=false; adding ViewPorts to SkyControl should not affect the visibility of the stars, sun, moon, or clouds.
(1) Has anyone tested SkyControl on an Android platform?
(2) Is there still interest in developing alternative cloud textures for SkyControl?
(3) Is there still interest in higher resolution starry-sky textures.
(4) Is there interest in adapting SkyControl for outer-space games?
(5) Does the performance seem satisfactory? And if not then under what conditions?
I vote for 3. A higher resolution starry-sky texture will be great.
I would also love to have more influence on the clouds. I am thinking about some weather effects (like rain or snow) and therefor I need other clouds. I already set cloudiness to the maximum but I still can see some sky.
Extrem cool will be a whole weather system (maybe in a later version of skycontrol )
@sgold said:
@stenb, I'm puzzled by your conclusions.
Here’s my understanding of the situation:
(1) SkyControl already tracks camera motion, so raising the camera should not “break” it. At worst a high camera might expose a cloudless band near the horizon, which could be addressed by increasing cloudYOffset.
(2) SkyControl collects viewports solely for the purpose of updating their background colors, which are visible only when bottomDome=false; adding ViewPorts to SkyControl should not affect the visibility of the stars, sun, moon, or clouds.
Yeah it had nothing to do with ViewPorts either.
The ability to go “above” the sky is something local to my application. I have a feature built in that raytraces on right-click and latches on to any geometry found along that ray. This automatically makes the camera “follow” the geometry and makes it possible to navigate outside of bounds (sky no longer follows camera in this case). So yeah, it’s a local problem.
@stenb said:
The ability to go "above" the sky is something local to my application. I have a feature built in that raytraces on right-click and latches on to any geometry found along that ray. This automatically makes the camera "follow" the geometry and makes it possible to navigate outside of bounds (sky no longer follows camera in this case). So yeah, it's a local problem.
I remember having a similar issue in my game at some point.
@drothindev said:
I vote for 3. A higher resolution starry-sky texture will be great.
I would also love to have more influence on the clouds. I am thinking about some weather effects (like rain or snow) and therefor I need other clouds. I already set cloudiness to the maximum but I still can see some sky.
Extrem cool will be a whole weather system (maybe in a later version of skycontrol )
I’ve created some 16-megapixel textures for use with star motion. If you want a SkyControl instance to use these textures, simply add an invocation of
[java]
skyControl.setStarMaps(“Textures/skies/star-maps/16m”);
[/java]
to your code.
@drothindev said:
I would also love to have more influence on the clouds. I am thinking about some weather effects (like rain or snow) and therefor I need other clouds. I already set cloudiness to the maximum but I still can see some sky.
Extrem cool will be a whole weather system (maybe in a later version of skycontrol :wink:)
I’ve committed a few alternative cloud textures for people to play with, including one based on visible-light satellite imagery of a Category 5 hurricane, which provides the basis for a new --cyclone option in TestSkyControl. While I’m not thrilled by how it turned out, it hints at what’s possible.
I’ve added a getCloudLayer() method to SkyControl, which provides access to individual cloud layers. Once you see how it’s used in TestSkyControl, the javadoc should make it fairly self-explanatory. However, feel free to pipe up if you get stuck.
The plugin that is out there was a test to figure out how to get a freaking plugin to work. It is completely unfinished and I only used to it so someone could grab what was useful out of it and make something people could actually use.
)