I have printed the boolean returned from hasState(state) , it says false for the 1st statement , true for the 2nd one.
EDIT :
public abstract class BaseAppState implements AppState {
....
/**
* Sets the unique ID of this app state. Note: that setting
* this while an app state is attached to the state manager will
* have no effect on ID-based lookups.
*/
protected void setId( String id ) {
this.id = id;
}
}
Plus , i think the encapsulation here of setId() must be exposed , ie . public & not protected because , the user may setId(id:String) after the initialization of his/her class instance as well , for example i cannot do this :
The ID has to be set before being attached. Most states that care to use an ID will let you pass it on the constructor… because it needs to be set before you attach it anyway.
The most convenient way to attach an app state is with the super() constructor on your application and in that case, passing the ID on the constructor is best.
Making setId() public might indicate to the caller that they can set this any time… and they cannot.
Edit: and discussion beyond that is probably best for a separate post rather than adding noise to this thread.
In order to fix this issue, we need know the root cause. Is it just a matter of adding the “jme3-android-natives” library to the build dependencies, or is something wrong with the “jme3-android-natives” library we distribute?
In a week or less , the new documented testCases for the animation system would be ready , but I wonder what else do we need ? Do we need actually a wiki ? Or documented testCases & javaDocs are sufficient , I can do the java docs , but I don’t think that the wiki would be easy…
The Wiki must be updated for the new animation system. That’s issue 1402.
The new animation system was a feature of JME v3.3. As far as JME v3.4 is concerned, the lack of wiki documentation is a defect, one that must be fixed before any stable release.
JME v3.4 will remain open for fixes long after it’s closed to new features. There should be plenty of time to get the documentation in order, including the Wiki.
I upgraded my project to 3.4 and had only one issue. Everything looked a lot darker. It was because of the change to gamma correction being on by default. I was aware of this change from following the forums but I wouldn’t have had a clue otherwise.
I would suggest mentioning this prominently in the release docs as a potentially breaking change. Many people may not be aware of what gamma correction is or the effect it may have.
I have tried to get things working with gamma correction turned on, as it seems that is the correct way to do things. The documentation I found was hard to follow (for me). I think I fixed it by calling renderer.setLinearizeSrgbImages(false)
but that may not be right.
I’ll make sure we carefully document the potentially breaking change.
To do gamma correction properly, many games will need to re-design their lighting from scratch. The quick-and-dirty fix is to disable it in the app settings.
Regarding your workaround, if you enable gamma correction but setLinearizeSrgbImages(false) then you’re in a weird state: half enabled, half disabled.
It’s also weird because most apps become much brighter with gamma on (and not tweaked for gamma). For me, it washes out everything to more greyish hues.
My textures are just jpegs I load. They look like the first picture if I load them in an image viewer.
I’ll see if I can work out more from the docs. Something about the way I load the textures into jmonkeyengine? It would be good to have a short guide: how to turn on gamma correction. With code examples.
It would be interesting to see a self-contained test case where things get darker. That way we could see if anything else is at play with respect to lighting setup or whatever.
For me, every app so far makes things brighter with gamma on… to the point where I know step 1 is to reduce my lighting intensity.
And apps where gamma on looks ok, get darker when I turn it off.
I just did a quick example.
Without gamma:
With gamma:
…even the UI gets washed out with gamma on (which I suspect is because the alpha values mean something different with gamma on).
So I can’t explain why things get darker with gamma on for you. Whenever I do the math on paper, brighter is always the outcome.
In my experience recently testing some pbr terrain test cases, i found that turning on gamma correction indeed darkens most if the scene, but it also makes the colors in the scene appear more deeply saturated
However, any parts of the scene with low roughness, or lots of of bright reflectivity, will become way too bright with no gamma correction. Additionally, the majority of my particle emitters get way too bright and develop a natural lens flare that blinds the screen when gamma correction is off.
I also confirmed that going into fullscreen mode will ignore gamma correction and always run as if gamma correction is turned off for some reason
It would be interesting to see a self-contained test case where things get darker. That way we could see if anything else is at play with respect to lighting setup or whatever.
For me, every app so far makes things brighter with gamma on… to the point where I know step 1 is to reduce my lighting intensity.
I think this is especially true with textures in PBR scenes, since getting the colors right in an albedo map is much more important than a regular diffuse map.
I recall reading that the main difference between making an albedo map for PBR and the standard Diffuse Map is that an albedo texture is supposed to represent the color as it would look without any lighting at all - somewhat of a catch 22 since the naked eye needs light to see a texture, but still a very important point from my experience with PBR
Like snow albedo textures, for example, are not white in PBR, but are instead a light shade of gray. And using a white texture for snow in PBR will result in extremely bright unrealistic results, since snow is apparently not white in reality, at least not until it has light hitting it.
On my older HP ProBook 4330s with Intel HD Graphics 3000, setting gamma correction to true caused the scene to look darker but I’m not using this computer anymore so cannot verify with the new version
That’s issue 1226. I’ve added it to the “hit list” of issues to be fixed in v3.4. I’d be very grateful if someone would figure out why this happens and/or provide a fix!
@pspeed Regarding the scene getting darker when I turned on gamma correction.
I have since realised I was using the Unshaded material definition, from Common/MatDefs/Misc/Unshaded.j3md for all my textures. This is probably not correct, and I should have been using Common/MatDefs/Light/Lighting.j3md.
When I changed to using Lighting.j3md, everything was very bright (with or without gamma correction).
As an aside, it’s odd that shadows were being cast etc even though I was using Unshaded for everything. (see screenshots). From reading the documentation, Unshaded should look the same no matter what the lighting conditions are.
For now I have just turned off gamma correction so everything works as before.
For purposes of the release, I think the important thing is to allow people the option of turning off gamma correction if it causes issues (like in my case) so what was working before will keep working.
