I tried to put my SkyBox into it's own game state with the idea of being able to turn it off as an option in the game.
Seems more like something you'd put into a Pass?
Perhaps, but there shouldn't be any reason why he couldn't do it in a GameState.
So the question remains then, why does it pop?
Can someone try to duplicate this… puhlease? It's not a huge deal for me because I have workarounds, but it raises a question. If having two GameStates showing simultaneously is a reasonable way to build a game, are there simultaneous GameState rendering problems in situations other than the one I'm encountering (assuming this problem is not something I'm doing wrong)?
I'm thinking of putting a lot of other eye candy (far in the future) in the same skybox GameState. That way somebody could turn off all the eye-candy if desired or needed because of computer speed/graphics card abilities. So it would be nice to have it work with GameStates in my opinion.
culli said:
So the question remains then, why does it pop?
Can someone try to duplicate this.... puhlease? It's not a huge deal for me because I have workarounds, but it raises a question. If having two GameStates showing simultaneously is a reasonable way to build a game, are there simultaneous GameState rendering problems in situations other than the one I'm encountering (assuming this problem is not something I'm doing wrong)?
I'm thinking of putting a lot of other eye candy (far in the future) in the same skybox GameState. That way somebody could turn off all the eye-candy if desired or needed because of computer speed/graphics card abilities. So it would be nice to have it work with GameStates in my opinion.
Can you try extending GameState instead of BasicGameState? My skybox state works fine, but I don't extend BasicGameState. I have noticed strange interactions between different states rendering while enabled at the same time...but I usually just chalk it up to me doing or using something wrong. :)
twibberjix said:
Can you try extending GameState instead of BasicGameState?
Hey culli,
Not sure if it makes a difference or not but in my skyboxstate i have a zbuffer render state applied to the rootnode.
ZBufferState zbs = DisplaySystem.getDisplaySystem().getRenderer()
.createZBufferState();
zbs.setEnabled(true);
zbs.setFunction(ZBufferState.CF_EQUAL);
rootNode.setRenderState(zbs);
rootNode.updateRenderState();
Other than that I don't see much difference. :?
One newbie said to the other slightly-less newbie (by number of posts):
Twibber, are you posting at 1am because your time zone is so different from mine, or because that's when you're up?
Anyway, I'll give the ZBufferState shot tonight, just got to work – 7am my time – my previous post was last night at 9:30pm.
culli said:
One newbie said to the other slightly-less newbie (by number of posts):
lol - by number of posts, this conversation is probably analogous to "the blind leading the blind". ;)
Maybe someone with more experience can explain pros and cons of doing the skybox as a gamestate versus a pass?
culli said:
Twibber, are you posting at 1am because your time zone is so different from mine, or because that's when you're up?
Anyway, I'll give the ZBufferState shot tonight, just got to work -- 7am my time -- my previous post was last night at 9:30pm.
I think it was between 10:30pm and 11pm my time when I posted. I just adjusted my timezone offset in my forum profile. If I'm up at 1am it's usually because I'm trying to debug something... or make one last change before I go to bed.
In my current game I have a skybox in my GameState and it's working just fine. Perhaps it is better suited for a Pass, but it should work just fine.
@Twibber: Blind leading the blind is exactly what I was going for. 8) Maybe that smiley's not just cool, maybe he's blind.
@Darkfrog: Ah, but do you have TWO game states running at the same time?
darkfrog said:
In my current game I have a skybox in my GameState and it's working just fine. Perhaps it is better suited for a Pass, but it should work just fine.
But why is it perhaps better suited for a Pass? As a GameState I have one toggle-able skybox available to any other state that happened to need a skybox for whatever was being displayed... As a Pass wouldn't I need a skybox in every state that wanted a skybox in the scene?
disclaimer: what is a pass doing anyway? the bloom effect examples that I played with messed with every single gamestate (including the loading state) i had active instead of just the nodes that I told it to :(
I think it's primarily for performance reasons, but I'll defer to someone that knows more about the pass system than myself to answer that…
More testing.
Sorry to hear err… read that you're giving up. 
Just a quick thought (someone correct me if I'm mistaken):
If adding your movement code into the skyboxstate fixes the problem with the skybox not updating correctly with the camera then maybe what's happening is the skybox update() is called before the camera is moved.
If that is what's happening then shouldn't putting your skybox.setLocalTranslation( camera getLocation() ) commands inside the skybox render() function have the same result as merging the movement code in with the skybox state? (Assuming that the order of things is all update() methods are called on all the active states, then all render() methods are called on all the states.)
I think that's the problem, too.
Moreover, I belive that skyboxes are better rendered in the last of your GameStates chain (at least in the last rendering gamestate). This way, the z-buffer ensures that we only draw the parts of the skybox that will be visible.
However, skyboxes must be rendered before any transparent geometry in front of them. I don't know if this can be achieved using different passes or even different gamestates. Does anyone have any clue on this? Is jMonkeyEngine making multiple passes and rendering transparent textures (ordered) after other geometry? Is there something like TransparentRenderState or BlendRenderState?
By now, I'm just rendering my skybox before any other geometry.
I tried moving the skybox.setLocalTranslation() to the render() method, but it didn't change things. I've tried a bunch of combinations and orders in render() and update() for this and I'm just missing something obvious, I know it. Sure is frustrating.
I really think what you guys are saying the answer. How do I move my skybox gamestate to be rendered after my main game state? In other words, how do I get the order of events needed?
It currently renders the skybox gamestate, then the main gamestate on top. The main gamestate is updating the input, so exactly what Twibber suggested seems to be happening. If I change the order (by adding them to the gamestatemanager in a different order), the main gamestate is not visible because the GameState is drawn on top. Looking at GameStateNode, that's the only change I understand I can make here. GameStateNode is just looping through the ArrayList of children calling their render() or update().
I could put the input update in the skybox gamestate, and create a fairly complex interaction between the main gamestate and the skybox where it does the input update conditionally depending on whether the skybox gamestate is active. This seems non-intuitive and kludgy.
Any tips?
Ok, I went with the kludge 
Basically, I build the skybox gamestate, then the main gamestate. Then I let the skybox see the KeyboardLookHandler and the skybox updates it just before the setLocalTranslation, instead of the having the main gamestate update the input. This breaks things with FengGUI, but I couldn't see another way around this problem. There is also the problem of turning off the skybox gamestate and it no longer updating the input.
Not an total solution, but it works as far as the visual problems. If somebody has a better idea, please speak up because I still think I'm missing something about the rendering order of GameStates as referred to by jjmontes. I'd rather have the skybox gamestate render last like he says.
Nothing wrong with kludges 
Have you tried putting your input handling stuff into its own state?