@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.
@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.
Heh, probably I should probably be using this instead, thanks. I’ll give it a go…
EDIT: Yes, GeometryBatchFactory is what I wanted all along, apparently. Thank you for pointing that out I hope I at least solved someone’s future problem with BatchNode…
so it should work, i don’t really get what is going on. @phr00t yeah if your objects are static, better go with the geometryBatchFactory.
@normen, actually, i wanted users to be able to batch each individual geometries (calling the createShape on each of them), but also be able to call it on the batch once batched, and use only the batch mesh instead of sub geoms.
I don’t really get why it’s not working for now, the test should be ok…I’ll test further.
oh ok… i know what’s going on…
actually the mesh transforms are not yet updated.
The batch node add every single geometry mesh at 0,0,0, then updates the mesh with the geometries transforms on the first update.
That’s why it looks like you have all your objects stacked up at the center in the collision shape.
A call to updateGeometricState on the batchNode before adding the rigidBodyControl fixes the issue.
I guess I could call updateGeometricState after the batchNode is batched… idk…it will be done anyway on the first update, but there will just be a scenegraph traversal and no update so that’s not that bad… @normen, @pspeed what do you think?
@nehon: I guess the BatchNode would only be used/make sense with separate physics objects anyway, so maybe for BatchNode it could be the default behavior to always only flag the combined mesh… The data inside the BatchNode should be consistent, so yes, do updates of the states if its necessary, the user can still access everything so it should be working “intelligibly”. Also for the collision shape generation
Alright so to sum it up, I will set the batch geom to ignore physics (setting the userData flag) and remove my previous commit.
I’m gonna call the updateGeometricState after each batch.
The batch Node behavior regarding physics will be the same as any other nodes : creating a shape of it will create a shape for any sub geoms of the node.
Like this it’s consistent.
Edit : also to have one big static shape from batched geometries, users will have to use the GeometryBatchFactory.
I should probably be using this instead, thanks. I’ll give it a go…
I hope I at least solved someone’s future problem with BatchNode… 