If it’s missing, that’s an issue. It’s available from Maven.org and Bintray.com. Where did you download from?
I’ve plugged 3.4.0-alpha3 into both my games. No issues so far but I’ll continue to run with this version and see if anything comes up. Qualitatively the performance felt the same.
Areas my games covers:
- Gradle Build
- Desktop (jme3-desktop)
- SimpleWaterProcessor
- WaterFilter (Obviously different game from SimpleWaterProcessor)
- Custom Meshes
- Shaders (as in written by me, not just the built ins)
- JavaFx integration (used for menus etc)
- Picking
- jme3-lwjgl3 (I didn’t seem to have the problems joliver82 experienced)
- ParticleEmitter
- ogg sound files (jme3-jogg)
- wav sound files
from github releases → https://github.com/jMonkeyEngine/jmonkeyengine/releases/download/v3.4.0-alpha3/jME3.4.0-alpha3.zip
The zipfile contains an executable version of the JME test chooser. The executable shouldn’t contain both the jme3-lwjgl library and the jme3-lwjgl3 library because they contain conflicting classes (in the same way the jme3-bullet and jme3-jbullet contain conflicting classes).
Bottom line: intended behaviour
OK, got it. I didn’t know it came with the executable. Related to this… I thought jme3-lwjgl3 was to be set as default instead of jme3-lwjgl
Last time this came up (August 2019) my “read” of the consensus was to keep jme3-lwjgl (LWJGL v2) as the default.
Perhaps @RiccardoBlb can comment on the status of #1406. After it is merged I think it would be safe to make jme-lwjgl3
the default.
I read that thread some time ago but I didn’t follow it till the end so I just assumed that having passed so much time everything would have been fixed and default changed to lwjgl3
Thanks for the answers
Hello everyone,
would it be possible to add the getter and setter methods for the fieldOfView parameter of the Camera.java class to make it easier to read and write?
- public void setFieldOfView(float fov) {}
- public float getFieldOfView() {}
something like that so you don’t have to use a wrapper class like in the example?
public class MainCamera {
private Camera cam;
private float fieldOfView;
private float near;
private float far;
/**
* Creates a camera state that will initialize the application camera to a
* 45 degree fov, 0.1 near plane, and 1000 far plane.
*
* @param cam
*/
public MainCamera(Camera cam) {
this(cam, 45, 0.1f, 1000); // 45 is the default JME fov
}
/**
* Creates a camera state that will initialize the specified camera to the
* specified parameters. If the specified camera is null then the
* application's main camera will be used.
*
* @param cam
* @param fov
* @param near
* @param far
*/
public MainCamera(Camera cam, float fov, float near, float far) {
this.cam = cam;
this.fieldOfView = fov;
this.near = near;
this.far = far;
resetCamera();
}
public void setFieldOfView(float f) {
if (this.fieldOfView == f) {
return;
}
this.fieldOfView = f;
resetCamera();
}
public float getFieldOfView() {
return fieldOfView;
}
public void setNear(float f) {
if (this.near == f) {
return;
}
this.near = f;
resetCamera();
}
public float getNear() {
return near;
}
public void setFar(float f) {
if (this.far == f) {
return;
}
this.far = f;
resetCamera();
}
public float getFar() {
return far;
}
private void resetCamera() {
float aspect = (float) cam.getWidth() / (float) cam.getHeight();
cam.setFrustumPerspective(fieldOfView, aspect, near, far);
}
}
A minor report.
Error writing initTogleRotateInput method name, missing a g
Thanks for the feedback.
To keep this topic focused on the upcoming release, suggestions like these should go elsewhere: either as new issues/PRs at GitHub (best for long-term tracking) or as new topics here at the JME Forum (best for discussion).
No need to track or discuss renaming initTogleRotateInput()
. I’ll take care of it.
v3.4.0-alpha4 has been released. It’s available from MavenCentral but not from Bintray/JCenter.
Engine v3.4 remains open for new features, but may close without warning. Feature freeze has been delayed in hope of accommodating 3 enhancement PRs:
- PR 1443 “KHR_lights_punctual gltf extension” — waiting for PR 1466, which needs a few more requested changes
- PR 1478 “PBR Terrain shaders” — needs an example app, removal of unused code, and possibly some renaming
- PR 1483 “Joy axis update” — needs documentation, minor changes, and conflict resolution
Meanwhile, “spring cleaning” is underway in the master branch:
- modernizing Java sourcecode
- resolving javadoc warnings and errors
- deleting unused code
- adding missing licenses
I noticed there are some leftovers in these commits after removing unused fields.
For example this line
I didn’t know whether is()
has side-effects or not.
I have to say @sgold, you are doing great coordinating 3.4.0. I am very excited for this release as there will be a lot of great additions and fixes.
Thank you for all your hard work.
Thanks for your support.
I think v3.4 will go faster and smoother with more people helping:
- file, investigate, and discuss issues
- create and review pull requests
- test features and fixes (on multiple platforms!)
- add and update documentation
A pull request of jmeSurfaceView :
this targets those problems :
i will also invest some extra time in fixing AndroidHarness
rather than deprecating.
this is my first time to do a pull request to jme ,so if i had made something wrong , or non-acceptable , please let me know , i will happily undo the change.
Is this :
getStateManager().getState("SimpleAnimation",BasicImplementation.class);
equivalent to this :
getStateManager().getState(BasicImplementation.class)
because getting state by id isn’t working after :
@Override
protected void initialize(Application app) {
setId("SimpleAnimation");
......
i thought maybe i am doing something wrong.
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 :
BasicImplementation basicImplementation=new BasicImplementation(dataBaseStack,realScale,realRotation);
basicImplementation.setId("SimpleAnimation");
getStateManager().attach(basicImplementation);
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.
A recurrent issue here :
It actually exists since 2020 , but I have only & only faced it in alpha4 remote implementation & SNAPSHOT mavenLocal() build :
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?
Edit: discussion of the Android natives issue continued in Forum topic 44458 and GitHub issue 1496.