UV usually refers to texture coordinates, not positions.
It looks like that code centers a Mesh based on the axis-aligned bounding box. If that’s what you want to do, you could use MyMesh.centerBuffer(mesh, Type.Position) :
Not really, it was an example. It was going to adjust the orientation to several different position for generic meshes. It would not just center the mesh but change to many different locations.
More like, not done. But it will alter the orientation of anything that is a boundingbox to lowerLeft/lowerCenter/Center orientation for fast quick adjustment.
private static Mesh alignBottonMesh(Mesh mesh, ORIENTATION orientation) {
Mesh newMesh = mesh;
Vector3f leftPoint = null;
BoundingVolume volume = mesh.getBound();
leftPoint = ((BoundingBox)volume).getMin(leftPoint);
Vector3f center = volume.getCenter();
int numVertices = mesh.getVertexCount();
VertexBuffer pb = mesh.getBuffer(Type.Position);
if (pb != null ) {
FloatBuffer fb = (FloatBuffer) pb.getData();
float[] uvCoordinates = BufferUtils.getFloatArray(fb);
for(int x=0; x < numVertices;x++ ) {
if (orientation == ORIENTATION.LOWER_CENTER) {
uvCoordinates[x * NUM_AXES] = uvCoordinates[x * NUM_AXES + 0] - center.x;
} else {
uvCoordinates[x * NUM_AXES] = uvCoordinates[x * NUM_AXES + 0] - leftPoint.x;
}
uvCoordinates[x * NUM_AXES + 1] = uvCoordinates[x * NUM_AXES + 1] + leftPoint.y;
uvCoordinates[x * NUM_AXES + 2] = uvCoordinates[x * NUM_AXES + 2] - center.z;
}
//apply new texture coordinates
VertexBuffer uvCoordsBuffer = new VertexBuffer(Type.Position);
uvCoordsBuffer.setupData(Usage.Static, 3, com.jme3.scene.VertexBuffer.Format.Float,
BufferUtils.createFloatBuffer(uvCoordinates));
newMesh.clearBuffer(Type.Position);
newMesh.setBuffer(uvCoordsBuffer);
newMesh.updateBound();
}
return newMesh;
}
private static Mesh centerMesh(Mesh mesh) {
Mesh newMesh = mesh;
BoundingVolume volume = mesh.getBound();
Vector3f center = volume.getCenter();
int numVertices = mesh.getVertexCount();
VertexBuffer pb = mesh.getBuffer(Type.Position);
if (pb != null ) {
FloatBuffer fb = (FloatBuffer) pb.getData();
float[] uvCoordinates = BufferUtils.getFloatArray(fb);
for(int x=0; x < numVertices;x++ ) {
if (center.x != 0 ) {
uvCoordinates[x * NUM_AXES] = uvCoordinates[x * NUM_AXES] - center.x;
}
if (center.y != 0) {
uvCoordinates[x * NUM_AXES + 1] = uvCoordinates[x * NUM_AXES + 1] - center.y;
}
if (center.z != 0) {
uvCoordinates[x * NUM_AXES + 2] = uvCoordinates[x * NUM_AXES + 2] - center.z;
}
}
//apply new texture coordinates
VertexBuffer uvCoordsBuffer = new VertexBuffer(Type.Position);
uvCoordsBuffer.setupData(Usage.Static, 3, com.jme3.scene.VertexBuffer.Format.Float,
BufferUtils.createFloatBuffer(uvCoordinates));
newMesh.clearBuffer(Type.Position);
newMesh.setBuffer(uvCoordsBuffer);
newMesh.updateBound();
}
return newMesh;
}
Why are you changing the position buffer with “uv” texture coordinates?
As I’ve said before, this topic deserves its own thread which is why I haven’t commented further. But if we really must discuss it here, Lemur’s DMesh class is an example of how to change buffers without copying all of the data multiple times.
Just 5 days remaining until the v3.5 features freeze!
5 Likes
Feature freeze happened last night, on schedule. However, no beta release is available for testing, due to an unexpected issue.
I’ve initiated 3 release attempts, denoted “beta1”, “beta2”, and “beta3”, all of which failed during the “Deploy Release” job, due to socket timeouts during communication with oss.sonatype.org:
- https://github.com/jMonkeyEngine/jmonkeyengine/runs/4544077828
- https://github.com/jMonkeyEngine/jmonkeyengine/runs/4544837534
- https://github.com/jMonkeyEngine/jmonkeyengine/runs/4551680146
I suspect this is a symptom of unusual traffic load at oss.sonatype.org, caused mainly by projects issuing releases in response to the Log4j vulnerability. I gather Sonatype has some new hosting infrastructure that’s less impacted by the load:
I’ll request migration to the new infrastructure.
For now, please ignore the (failed) beta releases listed at GitHub. I’ll probably delete them as soon as there’s a successful release.
EDIT: I opened ticket OSSRH-76277.
8 Likes
Our “org.jmonkeyengine” groupID has been migrated to the new staging infrastructure at Sonatype. I’ll update the Wiki accordingly.
Version “3.5.0-beta4” of jMonkeyEngine was released this morning. Here are the release notes:
Release jMonkeyEngine 3.5.0-beta4 · jMonkeyEngine/jmonkeyengine · GitHub
Note that “-beta1” through “-beta3” denote failed releases that have been deleted.
I’m waiting for the artifacts to reach Maven Central. After they do, I’ll create a new Development topic for beta testing.
5 Likes
I did make a simple graph.
currently on step 8
I could use more help with beta testing. See the thread V3.5.0 beta testing
4 Likes
Update: I still haven’t decided on a code-freeze date.
Based on the issues reported in v3.5.0-beta4, I’ve decided to cut a “-beta5” version before the end of December.
There’s still time to submit bug-fix PRs and get them into v3.5.0-stable. However, as time passes, the “v3.5” branch will become more and more risk-averse, so sooner is better!
5 Likes
Now for step 9…
The code-freeze date will be 23 January 2022. To be included in “v3.5.0-stable”, changes must be integrated into the “master” branch on or before 0800 UTC on that day.
At this point, testing is vital. If you can possibly help with beta testing, please try v3.5.0-beta6 and report any anomalies.
If you’ve got a last-minute bugfix for 3.5, please submit a pull request ASAP to allow time for review and revision.
Once JME 3.5 is published, I hope to take a long break from Engine development and testing. However, in the event a patch release is needed, I imagine I’ll find the time and energy to manage it.
13 Likes
JMonkeyEngine v3.5.0-stable is now available:
- Release jMonkeyEngine 3.5.0-stable · jMonkeyEngine/jmonkeyengine · GitHub (release notes and GitHub assets)
- Central Repository: org/jmonkeyengine (Maven artifacts)
- jMonkeyEngine3 (Javadoc)
It should appear in Maven Central Repository Search in an hour or two. Expect release notes, a blog announcement, a brief e-mail to donors, and a README update during the next 24 hours.
V3.5.0 involved a huge amount of time and effort. It was a collaborative effort by a large team of people, to whom I am very grateful. Thank you!
Let’s hear it for everyone who helped make it happen!!
21 Likes
A tweet on Twitter would be nice too. The jME account shouldn’t be so neglected, whoever has access to it. Twitter is an important marketing tool that could help attract more attention to the engine.
To everyone involved in the process of this new release, thank you very much!
9 Likes
yup, thanks a lot!
3 Likes
Thanks to everyone who participated in the new release and a special thanks to @sgold for guiding us to the goal! 
6 Likes
I second this. I recall a thread about the JME twitter being inactive from a new users few months ago, and I offered to help with posting to the JME twitter on certain occasions, but my offer felt like it was overlooked / casually denied, and no one else with access to these accounts seems to have stepped up since then either, which is a real shame.
It feels like there’s currently no drive to market the engine from the community member’s who have access to these accounts and we’re definitely missing out on a great opportunity to reach new devs and promote our work. I frequently see engines like Unreal posting about new updates and even retweeting in-dev projects from its user base. I know our reach isn’t nearly as large, but you have to start somewhere and it would still be more effective than posting nothing like we currently do.
8 Likes
no one else with access to these accounts seems to have stepped up
I don’t know who has access to the JME Twitter account. We lost our community manager in 2020, and the account credentials may have been lost in the transition.