How to Upgrade to .9 alpha

Alright folks, if you've been reading the forums over the last week or so, you already know that we planned to do several changes to jME that might impact your code.  (Actually, many of these changes have been proposed and discussed for the version .9 release for months now.)  If you haven't been to the forums recently, you might be here after updating cvs and panicking.  No need for alarm, we're here as always to walk you through things.



The first major change is that we have dropped support completely for the widget and old ui packages.  As Mark has pointed out on here many times, ui was no longer actively maintained and widget was so old it was really an anachronism.  We recommend converting to nui or bui and may adopt one of those as our official ui package in the future or roll our own.  Yes, if you were heavily using either package, we do understand that this is a burden.  We apologize in advance for this, but you have two choices really: keep using a pre Sept. 15th cvs (or of course v.8 jME) or bite the bullet and convert to one of the third party packages.



The second change (less major) is that you no longer access VBO fields directly on your Spatial object.  Instead there is a new VBOInfo object and Spatial field.  If that field is null, the Renderer will skip vbo creation, vbo checks and so forth and consequentially not use vbos.  If you want to use VBOs, you can do so easily by calling:


myGeometry.setVBOInfo(new VBOInfo(true));



The third major change involves how you access and manipulate geometric data in your scenegraph.  Previously, jME maintained two sets of data for each geometric data type: an array and an nio Buffer.  The array was very easily accessed and updated in an object oriented way.  The Buffer copy of that array was necessary to send the data to OpenGL efficiently.  Unfortunately, maintaining two sets of the same data meant that Geometry objects were a lot bigger than they needed to be and updates to the data meant that the nio Buffer had to be repopulated, reducing performance.

Obviously we needed to drop something and it had to be the arrays.  Specifically, the vertex, color, normal and texture arrays from Geometry and the index array in TriMesh/CompositeMesh.  Most people will not notice this much because they generally load models or create Shapes and use those.  For those of you who do need to access this data though, I'll finally stop my long winded speech and show you how :)

Example 1: (from TestOBBTree)

old way:

   ColorRGBA[] color1 = s.getColors();
   for (int i = 0; i < results.getCollisionData(0).getSourceTris().size(); i++) {
      int triIndex = ((Integer) results.getCollisionData(0).getSourceTris().get(i)).intValue();
      s.getTriangle(triIndex, indexBuffer);
      color1[indexBuffer[0]] = ColorRGBA.red;
      color1[indexBuffer[1]] = ColorRGBA.red;
      color1[indexBuffer[2]] = ColorRGBA.red;
   }
   s.setColors(color1);




new way:

   FloatBuffer color1 = s.getColorBuffer();
   for (int i = 0; i < results.getCollisionData(0).getSourceTris().size(); i++) {
      int triIndex = ((Integer) results.getCollisionData(0).getSourceTris().get(i)).intValue();
      s.getTriangle(triIndex, indexBuffer);
      BufferUtils.setInBuffer(ColorRGBA.red, color1, indexBuffer[0]);
      BufferUtils.setInBuffer(ColorRGBA.red, color1, indexBuffer[1]);
      BufferUtils.setInBuffer(ColorRGBA.red, color1, indexBuffer[2]);
   }




As you can see there's only a few changes, we now call getColorBuffer() instead of getColors().  We also don't need to update anything.  The other change is how we set the data into the buffer.  Normally you'd have to calculate an offset and then place each r, g, b and a float into the FloatBuffer.  You can do that of course, but we've made it easier on you.  With com.jme.util.geom.BufferUtils you simply call setInBuffer and pass it the color or vector you want to set into the buffer along with which buffer and an index.  The index is the same number as your previous array index, so no need to recalculate that either.


Example 2: The simple buffer construction.

If you already have elaborate ways of constructing your arrays, you may be too lazy to convert those methods to work with nio Buffers.  That's ok.  You can do this instead:

old way:

Vector3f[] verts = generateSomeVerts();
myTrimesh.setVertices(verts);



cheaters new way:

Vector3f[] verts = generateSomeVerts();
myTrimesh.setVertices(BufferUtils.createFloatBuffer(verts));




Example 3: Creating a new buffer

old way:

verts = new Vector3f[vertQuantity];



new way:

vertBuf = BufferUtils.createVector3Buffer(vertQuantity);




There are a handful of other useful methods in BufferUtils.  Please see the javadoc for more information and also feel free to ask questions here or on irc.

Still to come before .9 is official are changes to Boundings and a few other optimizations.  These, thankfully, should not affect the api at all.

Thanks for growing with us!

-- Josh

PS: It is also important to note that we have upgraded our lwjgl libs to version .98  Please check your development environments accordingly.

jmephysics is broken:-(

How do I replace:

setTextureCoord(int textureUnit, int index, Vector2f value)

          setTextureCoord sets a single coord into the texture array.



using the new system?



Also I've got a lot of broken code manipulating geometry data (trimesh/compositemesh):

        setVertices(verts);

        setNormals(norms);

        setColors(colors);

        setTextures(texCoords);

        setIndices(indices);



that needs to be retrofitted.



Do you have simple examples of how to do this for each type.

I had a quick look but I'm a little confused due to the different situations.

A simple example of each generic change would help me retrofit a lot faster.



Fortunately my current project required only 1 update, but I now have a bunch of red x's in my Eclipse Package explorer giving me a lot of mental stress:-(



Many thanks,

sv

sonicviz said:

jmephysics is broken:-(


I (or someone else) will fix this over the weekend.
sonicviz said:

How do I replace:
setTextureCoord(int textureUnit, int index, Vector2f value)


See Example#1.  From the above var names and assuming you called the above method on "myGeometry" you could use the helper method:

BufferUtils.setInBuffer(value, myGeometry.getTextureBuffer(textureUnit), index);
sonicviz said:

Also I've got a lot of *broken* code manipulating geometry data (trimesh/compositemesh):
        setVertices(verts);
        setNormals(norms);
        setColors(colors);
        setTextures(texCoords);
        setIndices(indices);


Please see example#2 above.  The first one is already shown there.  The rest involve simply wrapping your variable in BufferUtils.createFloatBuffer

I would suggest learning to deal directly with FloatBuffers and using setVertexBuffer, setNormalBuffer, etc, but the above mentioned method is there in case you can't or won't.  :)

Per,



I haven't updated from CVS yet (I know, I'm shameful)…what exactly is wrong with jME-Physics?  If it's not incredibly complicated I would be happy to fix it.  I'm assuming it's just pointing to removed or changed methods?



Thanks,



darkfrog

I'm not sure so I think I better ask:



This will still work?





    TriMesh mesh = (TriMesh)pr.getPickData(i).getTargetMesh();

    for (int j = 0; j < mesh.getTriangleQuantity(); j++)

    {

    mesh.getTriangle(j, vertices);

Vector3f res = it.rayIntersectsTriangle(downRay.origin, downRay.direction, vertices[0], vertices[1], vertices[2]);

if (res != null && (FastMath.abs(res.x) < FastMath.abs(hot)))

hot = res.x;





I need that for calculating the height over terrain to keep my character model on the ground.



BTW wouldn't it make sense to have a HOT function in jME?

darkfrog said:

Per,

I haven't updated from CVS yet (I know, I'm shameful)...what exactly is wrong with jME-Physics?  If it's not incredibly complicated I would be happy to fix it.  I'm assuming it's just pointing to removed or changed methods?

Thanks,

darkfrog


Yeah, I have no idea either, and I can't check atm because I havn't got my dev stuff set up. I can't imagine it'd be anything complicated to fix though.

Galun, picking/collision still works (or at least works as well as it did before the change  ;)).



Most projects (physics, monkeyworld3d, etc) should only take a couple hours at the most to move over. Depends on how much you directly accessed the vectors. The Bang! Howdy folks moved over BUI and Bang! Howdy which he said took about an hour. But remember, we are here to help everyone through this, we understand that changing public interfaces on people is a bit of a pain, but in this case the benefits FAR out weigh the problems.



As Renanse mentioned, the BufferUtils are there for your convience, but I would recommend that you try not to rely on it heavily. Learn how to manipulate the buffers and it will probably help you in the long run.



Let us know if you come across any new bugs.

Galun, just to second Mojo, that exact code should still work.  Also, HOT function?

hello everybody,



Checking out from CVS…

change my lines of code with new VBO implementation…

compiling : everything is fine !  :smiley:

conversion to 0.9 alpha for my project has taken me 12 minutes ! that's a wonderful job guys  8) !



There's only one thing which  has change but it's probably due to the new lwjgl lib and it's definitively not a bug :

now the keyboard nationnality is taken into account so when i affect the 'Q' touch in the code, it's Q for QWERTY and it's Q for AZERTY too (it is now normal but the layout of key will now change along with nationnality,  i think i will make a keyboard configuration via a property file so every player can config his layout according to its country)



Thanks again guys, you rock !



bye,



Adenthar.

renanse said:

Galun, just to second Mojo, that exact code should still work.

Just converted my stuff and I only had to correct 30 errors.



Lost my sound though…API is quite different



But I gained 200 FPS in some places so good work :slight_smile: