Hm ok. Then it may be differences in how uniforms or parameters are passed. Please, shall you try this?
At the begining of the main function, replace this line:
vec3 v3Pos = vec3(g_WorldMatrix * inPosition);
with this:
vec3 v3Pos = vec3(inPosition);
…and use the fTemp variable again.
Nope invisible now.is probably somewhere but I dont find it.
I don’t see the attach button
[img]using opera on windows
If it is invisible, did you get a compiler error?
Nope, but if we dont calcualte the vertex position correctly It’s no wonder it is not showing up ^^
Btw do you use anywhere a noise function? as these are kinda random implemented over all cards
Nope, not noise.
I think it should show regardless, but in a wrong place.
Well when I tinhk about it sohul show directly around the 0,0,0 without rotation ?
Well that explains probably why Im not seeing it wince the camera is on the false side then ^^
Yes that is correct. The vertex position is correctly calculated by the usual gl_position = …
The shader uses that position in eye coordinates (v3Pos) to calculate the fragment colors. So, as you say it always will be located at 0,0,0, but it should be there painted in some color. In my brief experience with shaders, if the object does not show at all usually means an error in the shader, but given how differently video cards seem to behave about glsl, who knows.
I tested the scattering and got the same issue as Empire Phoenix.
I tested replacing fTemp by 0.01, and got some result somehow :
This is after rotating a little around the planet. I can see the cloud map, but nothing else. I think it’s in the place it should be.
i tried to experiment a little with the color in the frag shader, and it seems that this expression return a complete white color
exp(-fExposure * (v4RayleighColor * fLightIntensity + v4Diffuse * v4MieColor * fLightIntensity) * fLightIntensity);
one or more of the parameters must be wrong (nullified or something due to some ATI card specifics…).
Two tests for ATI users (I would like to have an ATI and try myself…):
- In the Main class, set PLANET_RADIUS = 4.0f;
If it does not improve, try together with this:
- In GroundFromSpace.vert, normalize v3Pos before calculating angles, ie:
float fCameraAngle = dot(-v3Ray, normalize(v3Pos)) / length(v3Pos);
float fLightAngle = dot(v3LightPos, normalize(v3Pos)) / length(v3Pos);
If these changes improve the results, then the origin of the problem must be how v3Pos is calculated initially, since everything is calculated from this point and the maths are really very sensible, easily resulting in infinite, NAN, or zero.
Thanks for the feedback nehon.
The planet radius doesn’t change the issue.
normalizing v3Pos however gives the same result than replacing fTemp by 0.01
when i remove the v4MieColor from the expression in the frag shader i got this result
which looks a lot better imo, but maybe it doesn’t look as it should.
Don’t know if that can help
Every bit helps. I need to make this work in ATI cards or otherwise it will be unusable.
Yeah tempvar is responsible that mieColor has the strange value that causing ti to blackout^^
The one above is the better result that I also had in the process of debugging
Sorry for this endless trial and error, it is actually what I had to go through to make it work in my nvidia… .
Another test, In the main function, replace:
vec3 v3Pos = vec3(g_WorldMatrix * inPosition);
with:
vec3 v3Pos = gl_Vertex.xyz;
jiyarza said:
Sorry for this endless trial and error, it is actually what I had to go through to make it work in my nvidia... .
Don't worry about that, i've been there before, and besides i'm really glad to help
I tried it and it does not work.
Note that i don't even think that the engine set the gl_Vertex variable. It's deprecated and replaced by inPosition.
InPosition is the position of the vertex in object space (or model space).
so vec3 v3Pos = vec3(g_WorldMatrix * inPosition); should make v3Pos the position of the vertex in world space, i think it's correct.
I'll try to play around with some more parameters and see what it does.
Also could you post a screen of the application when you start it with your nvidia card, so i could see what result to achieve?
You’ll know when it is right ;). This is how it looks:
About the way to calculate v3Pos. I have tried gl_Vertex and still works, though you are clearly right that it is more correct using the inPosition attribute.
Note that every other calculations in the vertex shader are either basic arithmetic, dot products or the exp function and presumably work similarly in all cards. So before trying to adjust any variables manually and see what happens, I would change the formula for v3Pos, trying the various transform matrix available (i know it is not a very scientific method, but still). For instance:
vec3 v3Pos = g_WorldViewProjectionMatrix * inPosition;
In my nvidia, using this transform yields a result pretty similar to the one you get with the current formula. Wierd!.:
EDIT: I have updated the code to start in a better angle (as shown in the picture), so you don’t have to rotate…
site number is acting up again. I’m gonna try squeeze past it…
Ok i found something, in the GroundFromSpace.j3md you don’t declare WorldMatrix in the worldParameters.
it’s the world view matrix instead.
The question is…how the hell is it working on nvidia cards ???
anyway i changed it and the result is not good yet. Here it is :
this is after a little rotation
As you can see the transition between day and night is a bit rough
i’ll keep searching
Good find!
Day-night is rough, however I see what seems a redish glow in the day-night transition, which is something missing (and should be there) in my nVidia (it is the same redish glow you get in the atmosphere as it fades to black). Looks like it is anyway.
Cheers
Same issue in ground from atmosphere.
Got to say it’s a really good piece of work, flying over the planet with the music is great!!
Did you compose the music yourself?
Anyway congratulation, it’s brilliant.
Yes I did. Glad you like it :). Music is also in the “prototype stage” …
Anyway, looks like at some point I stopped updating the j3md world parameters, since it made no difference to me. Good you catched that one. About the day-night transition, I am wondering if the fLightIntensity variable is even necessary in ATI cards, if it isn’t it will only sharpen the transition (talk about driver madness… ).