Seeking alpha testers for SkyControl

Last month I uploaded a video demo of SkyControl, a sky simulation for JME3 based on @t0neg0d 's SkyDome. Since then I’ve made some improvements and brought the code to a certain level of stability. Now I’m looking for a few brave souls to use it and provide feedback. If you’re working on a JME3 game with an outdoor setting, please consider becoming an alpha tester.

Source code, assets, and build instructions may be found at here. The source code is GPL’d. The documentation is mostly inline, in the form of JavaDoc.

Here’s an example of its use:
[java]
boolean starMotion = true; /* allow stars to move /
boolean bottomDome = true; /
helpful in case the scene has a low horizon /
SkyControl control = new SkyControl(assetManager, cam, cloudFlattening, starMotion,
bottomDome);
/
add SkyControl to the root node /
rootNode.addControl(control);
/
(optional) put SkyControl in charge of the lights, the shadow renderer, and the viewport background /
control.setAmbientLight(ambientLight);
control.setMainLight(mainLight);
control.setShadowRenderer(dlsr);
control.addViewPort(viewPort);
/
set the time to 3 p.m. /
float hour = 15f;
control.getSunAndStars().setHour(hour);
/
set cloud intensity to 50% /
float cloudiness = 0.5f;
control.setCloudiness(cloudiness);
/
enable the control */
control.setEnabled(true);
[/java]

Source code for the test app is here.

6 Likes

Im already using it in my game, though I dont have a directional shadow, but I plan on having it as an option later on. Its really nice.

1 Like

GPL, meaning that anybody who wants to use it in his game, has to make entire game GPL as well? That’s… harsh. Especially that I doubt that tonegod put her code as GPL, so extending her code and putting the viral license on top of it isn’t probably very nice thing to do. When she said ‘Feel free to use and abuse this.’, she probably has not meant ‘abuse by trying to pull people into forcefully opensourcing their entire games, just because they want to use a bit of nice sky cde’.

3 Likes

That’s good feedback, @abies. What license would you recommend?

I think jmonkey is licensed under BSD, but you could just have it under this… http://www.wtfpl.net/

=D

Basically anything except GPL and AGPL should be ok.

http://opensource.org/licenses

To avoid confusions, I would suggest sticking to one of:
Apache
BSD

or possibly LGPL, if you want to force people to contribute back changes to your library, but don’t expect them to open source rest of the code. But probably BSD is safest choice, given that jme3 is BSD and people are contributing back to it anyway…

3 Likes

Much as I sympathize with the WTFPL folks, I’m reluctant to go that route. Upon consideration, I’ve re-licensed the source code using the New BSD license. I would (for the moment) appreciate it if people would inform me of any changes they make which might prove useful to others, but no pressure.

By the way, when I say SkyControl is “based on SkyDome” that should not be taken to imply it is a wrapper for or simple mod to SkyDome. SkyDome provided inspiration and a vital starting point, without which SkyControl would never have happened. However, after hundreds of hours of development and testing, there’s little of the original SkyDome left in SkyControl: two texture files and some the techniques, such as translating the geometries to follow the camera. I’ve rewritten the Java and shaders to such an extent that I consider them my own work.

I’m pleased that @t0neg0d has been supportive of my work from the start

3 Likes

Good decision with the new license.

I could checkout and build successfully. And its also running so far with different settings.

Big thanks too you.

2 Likes

That’s encouraging news, @Lockhead. And you’re welcome.

I tried to use the SkyControl in my own project but keep getting an Exception.

[java]
SEVERE [com.jme3.app.Application]: Uncaught exception thrown in Thread[LWJGL Renderer Thread,6,IDE Main]
java.lang.IllegalArgumentException: direction must be a unit vector
at jme3utilities.sky.DomeMesh.directionUV(DomeMesh.java:200)
at jme3utilities.sky.SkyControl.updateSun(SkyControl.java:996)
at jme3utilities.sky.SkyControl.updateFull(SkyControl.java:723)
at jme3utilities.sky.SkyControl.update(SkyControl.java:606)
at com.jme3.scene.Spatial.runControlUpdate(Spatial.java:570)
at com.jme3.scene.Spatial.updateLogicalState(Spatial.java:688)
at com.jme3.scene.Node.updateLogicalState(Node.java:145)
at com.jme3.app.SimpleApplication.update(SimpleApplication.java:244)
at com.jme3.system.awt.AwtPanelsContext.updateInThread(AwtPanelsContext.java:188)
at com.jme3.system.awt.AwtPanelsContext.access$100(AwtPanelsContext.java:44)
at com.jme3.system.awt.AwtPanelsContext$AwtPanelsListener.update(AwtPanelsContext.java:68)
at com.jme3.system.lwjgl.LwjglOffscreenBuffer.runLoop(LwjglOffscreenBuffer.java:125)
at com.jme3.system.lwjgl.LwjglOffscreenBuffer.run(LwjglOffscreenBuffer.java:151)
[catch] at java.lang.Thread.run(Thread.java:722)
[/java]

From my knowledge my directionalLight vector is a unit vector and no one changes it. I even set it up manually but it didn’t help.
The Ambient/Directional Light and the SkyControl are both in the same node (rootNode of the simpleApplication).

1 Like

@Lockhead, short of siccing a debugger on your code to print the sun’s direction vector, it’s difficult to say what caused the exception. It could be mere rounding error or it could be a nontrivial bug. Could you set a breakpoint on line 200 of DomeMesh.java and tell me the value of the ‘direction’ parameter when it’s hit? Or log the vector prior to the exception being thrown? Alternatively, could you tell me the sequence of SkyControl method invocations which preceded the exception?

Also, there’s an assert at SunAndStart.java line 175 that might be relevant. Are you running with assertions enabled? If not, would you mind re-running with “-ea” added to the VM options in your project’s run properties?

Assertions are disabled. I’m using the NetBeans Platform with JME. If i have enabled assertions i get a ton of AssertionErrors (nothing to do with your stuff ;)), so i disabled them. Enabling doesn’t help because its prior to your code invocation.

The vector in DomeMesh.java prior to the exception is not an unit vector:
[java]
-0.1660731
-0.0050493046
0.9732561
[/java]
I noticed that it’s never the same. It’s always different. Probably a tpf thing?

I have noticed some flickering for a couple of ms prior to the exception. So something is going on.

Here are the values of updateSun() till the exception:
[java]
worldDirection: 0.779106 -0.62689215 8.742278E-8
uv: null

0.780978 -0.452873 -0.43009806
null

0.83215266 -0.5401574 -0.12555276
null

-1.8129567E26 5.024256E25 -4.214776E25
exception
[/java]

Maybe it’s something you assume that i should have. Some min/max/horizon thing.

Don’t know if i can provide a test case. My application is a little too big for that. But the old SkyDome worked.

Ignoring assertions makes me nervous, especially in the context of software testing. Surely those asserts were put there for a reason? Either they’re invalid (in which case remove them) or else triggering them indicates an error in the code. Even if most of them have nothing to do with my code, I’ll still want to know about any that do.

I wouldn’t expect the sun’s direction vector to depend much on tpf. It’s calculated from scratch on each update, and unless you’re changing something at a huge rate, it should change gradually. That final value (-1.8129567E26, 5.024256E25, -4.214776E25) is
so completely off-the-wall that it leads me to suspect memory corruption.

I’m interested in the values of ‘hour’, ‘observerLatitude’, ‘solarLongitude’, and ‘solarRaHours’ (in SunAndStars) prior to the exception. With those values, I can calculate what the direction vector should’ve been. Perhaps that will help me figure out what’s happening. I’ll add a ‘toString()’ method to SunAndStars to make this easier for you.

Thats the values before i figured out how to move the sky in time:
[java]
SkyControl: [hour=0,000000, lat=0,893239, long=0,000000, ra=0,000000]
SkyControl: [hour=0,000000, lat=0,893239, long=0,000000, ra=0,000000]
SkyControl: [hour=0,000000, lat=0,893239, long=0,000000, ra=0,000000]
SkyControl: [hour=0,000000, lat=0,893239, long=0,000000, ra=0,000000]
SkyControl: [hour=0,000000, lat=0,893239, long=0,000000, ra=0,000000]
SkyControl: [hour=0,000000, lat=0,893239, long=0,000000, ra=0,000000]
SkyControl: [hour=0,000000, lat=0,893239, long=0,000000, ra=0,000000]
[/java]

Thats after i started to increment the hour:
[java]
SkyControl: [hour=10,000000, lat=0,893239, long=0,000000, ra=0,000000]
SkyControl: [hour=10,010000, lat=0,893239, long=0,000000, ra=0,000000]
SkyControl: [hour=10,020000, lat=0,893239, long=0,000000, ra=0,000000]
SkyControl: [hour=10,030001, lat=0,893239, long=0,000000, ra=0,000000]
SkyControl: [hour=10,040001, lat=0,893239, long=0,000000, ra=0,000000]
SkyControl: [hour=10,050001, lat=0,893239, long=0,000000, ra=0,000000]
SkyControl: [hour=10,060001, lat=0,893239, long=0,000000, ra=0,000000]
SkyControl: [hour=10,070002, lat=0,893239, long=0,000000, ra=0,000000]
SkyControl: [hour=10,080002, lat=0,893239, long=0,000000, ra=0,000000]
SkyControl: [hour=10,090002, lat=0,893239, long=0,000000, ra=0,000000]
SkyControl: [hour=10,100002, lat=0,893239, long=0,000000, ra=0,000000]
SkyControl: [hour=10,110003, lat=0,893239, long=0,000000, ra=0,000000]
[/java]

But i got it to work now. I deactivated a third-party AppState (out of a whim and pure desperation ;)) and the exception is gone. The Sun is moving etc.
The only weird thing is that the third-party AppState is somehow responsible together with your control. And i don’t understand why because they are completely separate and operating in their own nodes.
But it seems that it’s now my problem and not yours anymore :p.

1 Like

I’m glad you got it to work. Thanks for letting me know.

I agree the interaction between SkyControl and the appstate is surprising. If you ever figure out the mechanism, I’d be interested to hear about it.

Good luck with the rest of your project.

What’s that AppState? If it’s effing things with other states, it might be a good idea to tell the author and also warn the other users here so they know of the potential problem.

It’s an internal third-party (Boid Simulation) so nothing that others should be afraid of ;). I narrowed it down to a setLocalRotation of a subnode in this AppState.

@Lockhead said: It's an internal third-party (Boid Simulation) so nothing that others should be afraid of ;). I narrowed it down to a setLocalRotation of a subnode in this AppState.

Is it the setLocalRotation() itself or the construction of the rotation that you are setting? Perhaps you are modifying a Quaternion that is shared by other things or a vector or something.

Has anyone else tried SkyControl? In case it was an issue for anyone, I recently added support for shadow filters.

Hey, so I’m testing your SkyControl. However, I’m getting problems with a shader. And since I’m not very familiar with shaders I’m not sure where to start troubleshooting this. This is the stack trace:

[java]Dec 17, 2013 1:26:45 AM com.jme3.renderer.lwjgl.LwjglRenderer updateShaderSourceData
WARNING: Bad compile of:
1 #define HAS_HAZE 1
2 #define HAS_OBJECT0 1
3 #define HAS_OBJECT1 1
4 #define HAS_OBJECT2 1
5 #define HAS_OBJECT3 1
6 #define HAS_OBJECT4 1
7 #define HAS_OBJECT5 1
8 /*
9 Copyright © 2013, Stephen Gold
10 All rights reserved.
11
12 Redistribution and use in source and binary forms, with or without
13 modification, are permitted provided that the following conditions are met:
14 * Redistributions of source code must retain the above copyright
15 notice, this list of conditions and the following disclaimer.
16 * Redistributions in binary form must reproduce the above copyright
17 notice, this list of conditions and the following disclaimer in the
18 documentation and/or other materials provided with the distribution.
19 * Stephen Gold’s name may not be used to endorse or promote products
20 derived from this software without specific prior written permission.
21
22 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS “AS IS” AND
23 ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
24 WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
25 DISCLAIMED. IN NO EVENT SHALL STEPHEN GOLD BE LIABLE FOR ANY
26 DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
27 (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
28 LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
29 ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
30 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
31 SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
32 /
33
34 /

35 * fragment shader used by dome62.j3md
36 */
37 uniform vec4 m_ClearColor;
38 varying vec2 skyTexCoord;
39
40 #ifdef HAS_STARS
41 uniform sampler2D m_StarsColorMap;
42 #endif
43
44 #ifdef HAS_OBJECT0
45 uniform vec4 m_Object0Color;
46 uniform sampler2D m_Object0ColorMap;
47 varying vec2 object0Coord;
48 #endif
49
50 #ifdef HAS_OBJECT1
51 uniform vec4 m_Object1Color;
52 uniform sampler2D m_Object1ColorMap;
53 varying vec2 object1Coord;
54 #endif
55
56 #ifdef HAS_OBJECT2
57 uniform vec4 m_Object2Color;
58 uniform sampler2D m_Object2ColorMap;
59 varying vec2 object2Coord;
60 #endif
61
62 #ifdef HAS_OBJECT3
63 uniform vec4 m_Object3Color;
64 uniform sampler2D m_Object3ColorMap;
65 varying vec2 object3Coord;
66 #endif
67
68 #ifdef HAS_OBJECT4
69 uniform vec4 m_Object4Color;
70 uniform sampler2D m_Object4ColorMap;
71 varying vec2 object4Coord;
72 #endif
73
74 #ifdef HAS_OBJECT5
75 uniform vec4 m_Object5Color;
76 uniform sampler2D m_Object5ColorMap;
77 varying vec2 object5Coord;
78 #endif
79
80 #ifdef HAS_CLOUDS0
81 uniform sampler2D m_Clouds0AlphaMap;
82 uniform vec4 m_Clouds0Color;
83 varying vec2 clouds0Coord;
84 #endif
85
86 #ifdef HAS_CLOUDS1
87 uniform sampler2D m_Clouds1AlphaMap;
88 uniform vec4 m_Clouds1Color;
89 varying vec2 clouds1Coord;
90 #endif
91
92 #ifdef HAS_HAZE
93 uniform sampler2D m_HazeAlphaMap;
94 uniform vec4 m_HazeColor;
95 #endif
96
97 void main(){
98 #ifdef HAS_STARS
99 vec4 stars = texture2D(m_StarsColorMap, skyTexCoord);
100 #else
101 vec4 stars = 0;
102 #endif
103
104 #ifdef HAS_OBJECT0
105 vec4 objects = texture2D(m_Object0ColorMap, object0Coord);
106 objects *= m_Object0Color;
107 #else
108 vec4 objects = 0;
109 #endif
110
111 #ifdef HAS_OBJECT1
112 vec4 object1 = texture2D(m_Object1ColorMap, object1Coord);
113 object1 *= m_Object1Color;
114 objects = mix(objects, object1, object1.a);
115 #endif
116
117 #ifdef HAS_OBJECT2
118 vec4 object2 = texture2D(m_Object2ColorMap, object2Coord);
119 object2 *= m_Object2Color;
120 objects = mix(objects, object2, object2.a);
121 #endif
122
123 #ifdef HAS_OBJECT3
124 vec4 object3 = texture2D(m_Object3ColorMap, object3Coord);
125 object3 *= m_Object3Color;
126 objects = mix(objects, object3, object3.a);
127 #endif
128
129 #ifdef HAS_OBJECT4
130 vec4 object4 = texture2D(m_Object4ColorMap, object4Coord);
131 object4 *= m_Object4Color;
132 objects = mix(objects, object4, object4.a);
133 #endif
134
135 #ifdef HAS_OBJECT5
136 vec4 object5 = texture2D(m_Object5ColorMap, object5Coord);
137 object5 *= m_Object5Color;
138 objects = mix(objects, object5, object5.a);
139 #endif
140
141 vec4 color = mix(stars, objects, objects.a);
142 color = mix(color, m_ClearColor, m_ClearColor.a);
143
144 // Bright parts of objects shine through the clear color.
145 color += objects * objects.a * (1 - m_ClearColor) * m_ClearColor.a;
146
147 #ifdef HAS_CLOUDS0
148 float density0 = texture2D(m_Clouds0AlphaMap, clouds0Coord).r;
149 density0 *= m_Clouds0Color.a;
150 color = mix(color, m_Clouds0Color, density0);
151 #endif
152
153 #ifdef HAS_CLOUDS1
154 float density1 = texture2D(m_Clouds1AlphaMap, clouds1Coord).r;
155 density1 *= m_Clouds1Color.a;
156 color = mix(color, m_Clouds1Color, density1);
157 #endif
158
159 #ifdef HAS_HAZE
160 float density = texture2D(m_HazeAlphaMap, skyTexCoord).r;
161 density *= m_HazeColor.a;
162 color = mix(color, m_HazeColor, density);
163 #endif
164
165 gl_FragColor = color;
166 }

Dec 17, 2013 1:26:45 AM com.jme3.app.Application handleError
SEVERE: Uncaught exception thrown in Thread[LWJGL Renderer Thread,5,main]
com.jme3.renderer.RendererException: compile error in:ShaderSource[name=MatDefs/skies/dome62/dome62.frag, defines, type=Fragment, language=GLSL100] error:ERROR: 0:101: Incompatible types in initialization (and no available implicit conversion)
ERROR: 0:141: Use of undeclared identifier ‘stars’
ERROR: 0:142: Use of undeclared identifier ‘color’
ERROR: 0:142: Use of undeclared identifier ‘color’
ERROR: 0:145: Use of undeclared identifier ‘color’
ERROR: 0:145: ‘-’ does not operate on ‘int’ and ‘vec4’
ERROR: 0:162: Use of undeclared identifier ‘color’
ERROR: 0:162: Use of undeclared identifier ‘color’
ERROR: 0:165: Use of undeclared identifier ‘color’

at com.jme3.renderer.lwjgl.LwjglRenderer.updateShaderSourceData(LwjglRenderer.java:1018)
at com.jme3.renderer.lwjgl.LwjglRenderer.updateShaderData(LwjglRenderer.java:1041)
at com.jme3.renderer.lwjgl.LwjglRenderer.setShader(LwjglRenderer.java:1107)
at com.jme3.material.Material.render(Material.java:1116)
at com.jme3.renderer.RenderManager.renderGeometry(RenderManager.java:523)
at com.jme3.renderer.queue.RenderQueue.renderGeometryList(RenderQueue.java:322)
at com.jme3.renderer.queue.RenderQueue.renderQueue(RenderQueue.java:377)
at com.jme3.renderer.RenderManager.renderViewPortQueues(RenderManager.java:768)
at com.jme3.renderer.RenderManager.flushQueue(RenderManager.java:719)
at com.jme3.renderer.RenderManager.renderViewPort(RenderManager.java:983)
at com.jme3.renderer.RenderManager.render(RenderManager.java:1029)
at com.jme3.app.SimpleApplication.update(SimpleApplication.java:252)
at com.jme3.system.lwjgl.LwjglAbstractDisplay.runLoop(LwjglAbstractDisplay.java:151)
at com.jme3.system.lwjgl.LwjglDisplay.runLoop(LwjglDisplay.java:185)
at com.jme3.system.lwjgl.LwjglAbstractDisplay.run(LwjglAbstractDisplay.java:228)
at java.lang.Thread.run(Thread.java:744)[/java]

Could it be related to my computer hardware, or something else? Running a macbook pro from this year, Intel HD Graphics 4000 768 MB graphics card

/Jonatan

1 Like