Looks like I found a jME3 bug! I generate a building in 3079, attach all the walls/floors to the building’s BatchNode, run batch(), and then later createMeshShape() on that BatchNode for bullet physics. Unfortunately, the leftover spatials (set to CullHint.Always) within the BatchNode get physics meshes created when they shouldn’t If I remove the batch() call, the resulting physics mesh looks as expected. Maybe don’t create physics meshes for objects set to CullHint.Always…? Maybe createMeshShape() should check if the object is a BatchNode and do something a bit differently? Maybe I should do something differently?
@phr00t: You say you get a compound shape with one large collision shape for the combined mesh plus all the single little parts as well? @nehon? Shouldn’t the BatchNode behave relatively normal to the collision shape factory?
Well I guess the createMeshShape doesn’t like the fact that the mesh are embed in the bigger batch mesh… @phr00t maybe as a workaround you could try to generate the collision shape before batching?
I don’t really see how we could alleviate this though, except from directly creating the mesh shape from the batch mesh? Is it doable @normen?
@phr00t maybe as a workaround you could try to generate the collision shape before batching?
I suppose I could do this, but I suspect createMeshShape would be faster working on a single mesh (that BatchNode put together) than a bunch of separate Geometries… it’d be nice if it worked. Thanks for the suggestion… let me know if I can be of help finding a better solution.
@phr00t said:
Is there a way to flag the spatials that have been "batched" in the BatchMesh to be skipped by createMeshShape...?
Actually they are already flagged
@normen we could indeed exclude these geometries from the shape creation
Just set the physicsignore flag then please:
[java] Boolean bool = spatial.getUserData(UserData.JME_PHYSICSIGNORE);
if (bool != null && bool.booleanValue()) {
continue; // go to the next child in the loop
}
[/java]
@Phr00t .So in the end I didn't. We talked about it, and it would have forfeit any attempt to have individual physics interaction with sub geoms. (sometime people want it th other way around than you do actually).
So I did as you hinted, I excluded geometries that are already batched form the shape creation.
I did a quick test and it seems to work ok.
Please report any issue.
@nehon & @normen, looks like things are backwards :’(
The big mesh I want the physics shape for is being skipped, while the leftover spatials are being made… looks like that boolean check needs to have a ! infront of it
ugh, this makes no sense to me. I batched the object into one mesh so I could render it & make physics meshes for it faster… why would I want the leftover spatials, which are not even placed at the right position or scale, to be made into physics meshes instead? Can there be an option provided to the developer to choose which group gets made into physics meshes? Or I suppose I just need to write my own function to fit that “!” in there…
@phr00t said:
ugh, this makes no sense to me. I batched the object into one mesh so I could render it & make physics meshes for it faster... why would I want the leftover spatials, which are not even placed at the right position or scale, to be made into physics meshes instead? Can there be an option provided to the developer to choose which group gets made into physics meshes? Or I suppose I just need to write my own function to fit that "!" in there...
As nehon said, people may want to batch the visual objects but still have separately movable physics objects (BatcNODE vs batching). I don't quite get what @nehon is trying to do though cause as he found out people might want to keep one or the other, so the physics ignore flag should be optional for either the combined or the single meshes.
@phr00t said:
ugh, this makes no sense to me. I batched the object into one mesh so I could render it & make physics meshes for it faster... why would I want the leftover spatials, which are not even placed at the right position or scale, to be made into physics meshes instead? Can there be an option provided to the developer to choose which group gets made into physics meshes? Or I suppose I just need to write my own function to fit that "!" in there...
As nehon said, people may want to batch the visual objects but still have separately movable physics objects (BatcNODE vs batching). I don't quite get what @nehon is trying to do though cause as he found out people might want to keep one or the other, so the physics ignore flag should be optional for either the combined or the single meshes.
I understand that situation… then it makes me wonder… why do those individual, left-over spatials scale & translation values get reset? At any rate, that isn’t what I’m trying to do, which I think is also a very useful thing: put together an object made up of sub-geometries, then “batch” it into one mesh for quick rendering and physics manipulation as a whole. I’m willing to fork the createCollisionMesh code for myself, but I do think both of these options should be available to the developer straight from the engine.
EDIT: I think we want the same thing via “so the physics ignore flag should be optional for either the combined or the single meshes”… wait and see what @nehon says?
If I remove the batch() call, the resulting physics mesh looks as expected. Maybe don’t create physics meshes for objects set to CullHint.Always…? Maybe createMeshShape() should check if the object is a BatchNode and do something a bit differently? Maybe I should do something differently? 
Thanks for the suggestion… let me know if I can be of help finding a better solution.
