Game Development Community

ScatterSky fixed position

by Jesse Allen · in Torque 3D Professional · 10/22/2014 (8:10 pm) · 6 replies

Greetings, Torque goers! I have an inquiry about ScatterSky. According to the commented description of the ScatterSky class, "ScatterSky renders as a dome shaped mesh which is camera relative and always overhead."

What I'd like to do, however, is fix the ScatterSky into its location so that it doesn't move with the camera view. I believe I have the ScatterSky placement tracked down to be within the ScatterSky::render() function:

Point3F camPos( 0, 0, smViewerHeight );
   Point4F miscParams( camPos.z, camPos.z * camPos.z, mScale, mScale / mRayleighScaleDepth );

   Frustum frust = state->getCameraFrustum();
   frust.setFarDist( smEarthRadius + smAtmosphereRadius );
   MatrixF proj( true );
   frust.getProjectionMatrix( &proj );

   Point3F camPos2 = state->getCameraPosition();
   MatrixF xfm(true);
   xfm.setPosition(camPos2);//-Point3F( 0, 0, 200000.0f));
   GFX->multWorld(xfm);
   MatrixF xform(proj);//GFX->getProjectionMatrix());
   xform *= GFX->getViewMatrix();
   xform *=  GFX->getWorldMatrix();

It is difficult to tell exactly how the placement is being handled here, other than it is in some way based off of the CameraFrustum.

Does anyone have any idea how one might eliminate the dependency on the CameraFrustum so that the ScatterSky object may have its position set and fixed?
NextNext Thread
PrevPrevious Thread
More from Torque 3D Professional


Timmy01
#1
10/22/2014 (9:06 pm)
*Edit:
Hang on sorry that doesn't work lol

Torque Owner Jesse Allen
#2
10/22/2014 (9:33 pm)
No worries, Timmy :) As you can see it's fairly deeply embedded into the CameraFrustum and even shaders. It's a tough nut to crack, and I may potentially have to find a different solution altogether that doesn't involve ScatterSky. Was really wanting to leverage the use of TimeOfDay using ScatterSky, but failing a locked position I might just need to come up with a new solution entirely. Ultimately, though, if the dome mesh was locked into place it might be overly restricting anyways. I.e. the character couldn't wander far before seeing its edge.

Torque Owner Daniel Buckmaster
T3D Steering Committee
#3
10/23/2014 (12:11 am)
Why do you need the ScatterSky to be fixed? What's the undesirable behaviour you're trying to avoid?

Torque Owner Jesse Allen
#4
10/23/2014 (12:56 am)
I've come to the conclusion that it's silly to try and fix the ScatterSky. As noted in my above posting, your character wouldn't be able to travel far without seeing the edge of the sphere mesh above if you did. I only really want the Day/Night cycle so what I did was I just made a new class based off of ScatterSky and just yanked the VertexBuffer so no sphere mesh is rendered at all. I still get the rising and setting sun, and transitions of light :) In my case, I won't be using the clouds as would generally be the norm when using ScatterSky.

Oh, what I was trying to avoid was the sphere mesh (and clouds) in the background following the player up and down as he jumped (in sideview). It appears very jarring to the entire scene.

P.S. If anyone finds themselves making a sidescroller and wants the Day/Night cycles without the clouds and sphere mesh above let me know I've got a fix :)

Duion
#5
10/23/2014 (4:16 am)
There has been no real solution to this edge issue so far, but fixing the sky seems plausible, it only generates a new problem, what happens if you fly so high that you fly through the clouds?

Torque Owner Jesse Allen
#6
10/23/2014 (5:18 am)
@Duion: Did you read the post above yours? This is pretty much solved in my case already. I'm working on a sidescroller, so I've found the fix that I need personally. It does introduce new problems dealing with backdrops but such is the case when designing a new style of game 'out of the box' of what the engine had in mind initially. That's a challenge I'm willing to take on, since it's not that hard to be creative with a sideview backdrop.

I don't agree that fixing the sky is a good solution in any case, though. As I've stated twice in this thread already, fixing the ScatterSky doesn't offer a solution it only introduces problems. As a matter of fact, in any 3D setting I can't really see any reason to change it. The only reason I've had to find a workaround at all is due to the 2.5D nature of this project I'm working with. Otherwise I don't believe the ScatterSky moving with the CameraFrustum is a bad thing.