This is kind’a a weird situation - the current Scene Query Omnigraph nodes are targeted for prims on the stage, but, with a PointInstancer setup, a single PointInstancer prim could ‘represent’ hundreds/thousands of bodies/colliders in the Physx scene.
This request is for someway to interact with bodies/colliders authored via PointInstancer (specifically, instancing a prim that is setup as a body/collider).
Consider this scenario (that I’ve described before) - I can instance bodies/colliders in the scene and have their initial state frozen - then perform a omnigraph scene query to identify a set of bodies - what I want to do with this list of bodies is ‘awaken’ them so they now simulate.
Imagine a cube body/collider, instanced with PointInstancer, so that these instanced cubes form the shape of the letter ‘O’ - now, using OmniGraph scene query, I can gradually melt this letter ‘O’ by turning the sleeping bodies on and having them fall under gravity.
If this Use Case doesnt make sense as described, I can attach a simple scene.
A point of clarity, usually there is a 1:1 ratio between the mesh prim on the stage and the phsyx body/collider, but with a PointInstancer there is a 1:many relationship.
Hi,
yes this is something we should improve for the OG node. However the point instancer is supported in the underlaying code.
You can access the protoIndex in case of a point instancer if you use the raycast_closest function exposed on the physx_scene_query_interface:
docString = R"(
Raycast physics scene for the closest collision.
Args:
origin: Origin of the raycast.
dir: Unit direction of the raycast.
distance: Raycast distance.
bothSides: Boolean defining whether front and back side of a mesh triangle should be considered for hits.
Returns:
Return a dictionary with raycast hit::
'position': float3 -- Hit position.
'normal': float3 -- Hit normal.
'distance': float -- Hit distance.
'faceIndex': int -- Hit mesh face index.
'collision': string -- Hit collision USD path.
'rigidBody': string -- Hit rigid body USD path.
'protoIndex': int -- Rigid body protoIndex - if not point instancer 0xFFFFFFFF
'material': string -- Hit collider material USD path.
)";
We should improve the node to return even the protoIndex. This was you should know what instance was hit.
Please see the attached sample, I quickly threw together.
There are over 800 points in the PointInstancer, and the Prototype (cube1) has its ‘Start as Sleep’ physx property enabled.
So, there’s one mesh prim on the stage, but over 800 physx bodies on the GPU.
What I’d like to be able to do, is use the Scene Query OGN Nodes to target individual bodies that I can ‘wake up’ and have them start simulating.
It seems that, at some point the OGN scene query nodes could return a list of bodies?
…but it looks like this was changed in the release version?
BTW - the OGN ForceField Demo scene doesnt appear to be working in the release version.
o_points.usd (46.2 KB)
Hmm…looking at that image of the ForceFieldDemo OGN sample - that isnt really what I’m after either - because, there is no ‘prim path’ for these bodies (if I understand everything correctly).
My assumption is that there is a separation between the USD scene and the Physx scene - in that - I can have individual control over the physx properties of physx bodies created via PointInstancer.
Its kind of like, I’m using PointInstancer to quickly and easily create all these physx bodies - now I want to set unique properties over some number of those physx bodies - regardless of the current properties the prototype has? - if that makes sense?
It does make sense, but it wont work. Point instancer does create x instances of the same primitive. In this particular case of a rigid body. But there is no way for you to change the properties of the rigid body that are not part of the point instancer prim itself. Meaning you have an array of positions/rotations/scale/linear velocity/angular velocity, but thats it. You cant access individual rigid bodies properties through USD this way.
You could create multiple prototypes with various properties and then instance those prototypes.
Just to wakeUp the bodies should be in theory possible, but that function is not exposed. I am afraid what you are looking for is not fully exposed. The wake_up and apply_force_at_pos should be possible to update on our side to work with point instancers. Will create a feature request for those.
Hmm…#1 - you’ve given me an idea to try that might work in the interim. Lemme do some test and I’ll post back if it works.
#2 - thanks for filing the feature request - I’d imagine these would be arrays, wake_up [int representing the InstanceID to wake up], apply_force_at_pos [vec3 representing the direction (world space) and strength (based on the length of the vector)] - well, on second thought, I dont have vision into the internals here, so dunno what constraints you’re working with in exposing these functions.
Hmm…this is around 170k bodies and on my 3090 with 24GB vram and 48GB ram, it should be able to handle it.
But it crashes to desktop.
I’ve rebuilt this scene a couple times, so, the sample file is at a point where all the Prototypes are bodies with a ground and physics scene - so, should only have to hit play.
Thanks.
ov_letters_instancer.usd (4.3 MB)
edit: I guess I should clarify - I’ve made each letter in the word ‘Omniverse’ its own prototype.
I was able to reproduce the crash, its running out of memory. The problem is that all those letters are overlapping each other, so its actually crashing on the GPU while trying to compute all the eventual contacts. I am not sure what you are trying to achieve, but creating all the objects on the same spot wont work for physics. We run out of memory on the GPU while trying to allocate resources for the computations unfortunately.
Should the objects collide with each other from the beginning?
No, they shouldnt - I was testing multiple prototypes in a single instancer - so that each prototype (or letter in this case) can wake_up individually.
Its probably something to do with Houdini scene units - they are so very small compared to OV - that it might be reaching some minimal collider size limit or something - resulting in an overlap.
But, anyway, I’ll scale my Houdini scene up by some factor so that it matches Omniverse scene units and test again.
Thanks for checking on this crash - because, I thought I remember you guys said Physx can instance into the millions now - so I was surprised that 170k was choking on my system.