Batching breaks Vertex Colors

Troubleshooting graphics
1

Hey everyone,

title says it all: Batching breaks Vertex Colors.

You can test this easily yourself by applying the standard lighting shader on a model with vertex colors and ticking the necessary checkbox.
Unbatched, you… well … see the vertex colors, of course.
Batched, you get something different. My own shader returns all white objects; the lighting shader returns black and white objects (color not related to vertex colors at all).

It’s not relevant if you batch using BatchNode or GeometryBatchFactory. It’s the same result with both.

Can someone confirm this issue or has ideas why Vertex Colors don’t work?
Am I doing something wrong on my end?
Thanks.

2

This is working on my end, could you test?
[java]

import com.jme3.app.SimpleApplication;
import com.jme3.material.Material;
import com.jme3.scene.BatchNode;
import com.jme3.scene.Geometry;
import com.jme3.scene.VertexBuffer;
import com.jme3.scene.shape.Quad;

/**
*

  • @author Nehon
    */
    public class BatchNodeTest extends SimpleApplication {

    public static void main(String… argv) {
    BatchNodeTest app = new BatchNodeTest();
    app.start();
    }

    @Override
    public void simpleInitApp() {

     Quad q = new Quad(1, 1);
 
 q.setBuffer(VertexBuffer.Type.Color, 4, new float[]{1, 0, 0, 1,
     1, 0, 0, 1,
     1, 0, 0, 1,
     1, 0, 0, 1
 });
 q.updateBound();
 
 BatchNode bn = new BatchNode("batchNode");
 
 Geometry g = new Geometry("bla", q);
 Material m = new Material(assetManager, "Common/MatDefs/Misc/Unshaded.j3md");
 m.setBoolean("VertexColor", true);
 g.setMaterial(m);
 
 bn.attachChild(g);
 
 for (int i = 0; i < 100; i++) {
     Geometry g2 = g.clone(false);
     bn.attachChild(g2);
     g2.setLocalTranslation(i * 2, 0, 0);
 }
 
 bn.batch();
 
 rootNode.attachChild(bn);

    }
    }[/java]

3

//my fault sorry

i can confirm it does work even with meshes with different vertex colors…

4

Hm, this is working on my end as well.

If I replace
[java]
Geometry g = new Geometry(“bla”, q);
[/java]
with
[java]
Spatial g = assetManager.loadModel(“Models/rock4.j3o”);
[/java]
it does only work with batching disabled.

rock4.j3o has been converted from a vertex painted .blend file.
You can paint one yourself or I can mail you a model if you want.

5

how did you convert it? directly from the blend file or did you use ogre pipeline?

EDIT : Actually your previous post answers the question, coudl you test importing it with ogre?

6

Aha!
Converting with ogre works!

I don’t have a clue what the blender importer does that breaks vertex colors when optimizing, but I think it might be time to ask @Kaelthas for an opinion.

7

The Blender loader seems to create a byteBuffer for color whereas the test case above create a floatbuffer, I wonder if it’s the source of the issue.
EDIT : Ogre uses a FloatBuffer too

EDIT2 : mhh nope…if I use a byteBuffer in the test case it works too…
@m41q could you send me the file in a PM please?

8

Sure thing. Sent you a PM.

9

Ok I found the issue.
The buffer is set as normalized by the BlenderLoader (and should be), but the resulting buffer after batching is not.
So in the end it’s a BatchNode/GeometryBatchFactory bug.
Gonna fix it.

1 Like
10

Thank you very much for the fast solution.

If you fix it to the 3.0 branch today (or soon), will I be able to update to the next nightly the day after?

11

This has been fixed on the master branch.
If you’re using 3.0, you won’t have the fix I’m afraid.

You could switch to nightly…but I don’t recommend it as a fair amount of things changed since 3.0.

You could extend BatchNode and override the mergeGeometry method, but it’s private. You can get away with it by overriding doBatch and replace the call to mergeGeometry to your own method myMergeGeometry that would of course contain the fix. Kind of a hassle but it would work

You could use the ogre workaround, which IMO is the fastest and safest way to workaround this.

Though, note that your mesh will use more memory that the one created by the blender loader. Not a huge difference though.

1 Like
12
@nehon said: You could switch to nightly...but I don't recommend it as a fair amount of things changed since 3.0.

Are nightlies built from the master branch?
If so, it’ll be no problem, we’re already using nightly.

13

yes they are

14

ah, good :slight_smile:

15

Ahem…
are you sure they are built from the master branch?
I have nightly enabled and I was not able to update anything.
Or don’t the nightlies get built every night?

16
@m41q said: Ahem... are you sure they are built from the master branch? I have nightly enabled and I was not able to update anything. Or don't the nightlies get built every night?

I think @nehon means the .zip distro, the SDK nightly updates are not up to date, no.

1 Like
17

Yes, for now there is no other way to use nightlies (except building from the repo) so I assumed OP was already using this.

18

Haha, I didn’t even there was a .zip distro :smiley:
I just had nightlies enabled in the plugins settings.
Okay then.

19

Forgive me if I overlooked something, but I can’t find those .zips.

When I look at the sidebar in Download–>Nightly Builds, there are many zips. 22 days old zips however.
(Also in the sidebar are still links to googlecode, which made me question if the nightlies link was up-to-date as well)

So I looked on GitHub: And there is a “Download Zip” button. But, as I expected, it just downloaded the repository. This isn’t the right way, is it? I’m looking for installers and .exe files.

I’ve successfully build the jME SDK before, but that was before the gradle or github days. When I cloned the repository to my pc and tried to build it using netbeans (I have gradle installed), I get an error:

Execution failed for task ':sdk:cleanSdk'.
&gt; The following error occurred while executing this line:
  C:\Users\Daniel\Documents\NetBeansProjects\jme_master\jmonkeyengine\sdk\build.xml:7: The following error occurred while executing this line:
  C:\Users\Daniel\Documents\NetBeansProjects\jme_master\jmonkeyengine\sdk\nbproject\build-impl.xml:41: Cannot find NetBeans build harness. 
  Check that nbplatform.default.netbeans.dest.dir and nbplatform.default.harness.dir are defined.

Those two things are defined, as far as I could tell. Maybe it’s an ant or gradle thing…

I’m really trying my best, but there are no manuals! (At least none that I could find AND are up to date - I found this and that).

Could you please give me the link to the right .zips and/or explain how to build jME in netbeans with gradle?
Thanks.

20

http://updates.jmonkeyengine.org/nightly/3.1/engine/