Announcement

Collapse
No announcement yet.

SDK: difficulty getting Phoenix to pick up particle interface during simulation

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • SDK: difficulty getting Phoenix to pick up particle interface during simulation

    I have a SimpleObject2 that exposes a few different interfaces (SimpleObject2, IParticleObjectExt, I_PARTICLEOBJ, I_VRAYGEOMETRY)...basically it's a particle system object that generates a renderable trimesh.

    I expose the particle interfaces for any 3rd party queries for its particles, but also expose the regular SimpleObject2 interface so that 3rd parties can get the mesh that its particles form. Simple enough.

    However, PhoenixFD only seems to query an object's particle interface during simulation, if a "CanConvertTo(triObjectClassID)" test fails. If such a test succeeds, the particle interface is never accessed. I'm assuming this is because Phoenix processes its input objects in the following way:

    Code:
    (pseudocode)
    
    if (canConvertTo(triObjectClassID))
    {
        //process mesh
    }else if (canConvertTo(particleClassID))
    {
       //process particles
    
        //(in my case, we never reach this code because the first conversion test always passes)
    }
    ,
    It would be nice if it processed them the other way around, defaulting to an attempt to grab particles first, and then trimesh...so that particle systems can return both interfaces and still provide particles to a Phoenix. I guess switching them would mean that Phoenix would always default to getting particles (and never the particle system's trimesh, which maybe we would want in some situations)...but that latter scenario seems like something that would happen less often than the former (and one can always force the latter by putting a mesh modifier on their particle system object...whereas the former can never be forced by the user without a special UI control added by a dev to disable trimesh conversion).
    Last edited by tysonibele; 27-02-2019, 01:49 PM.

  • #2
    Hmm, this is a very interesting topic. Yes indeed - you are right, this is the priority for processing of nodes by the Max simulator. When this was written, support for particle systems' instanced meshes did not exist yet, so it would be interesting to run our tests with the order reversed and see what happens. I hope during the next few days I will have some test results proving this can work out, or any arguments against it we can think about and overcome.
    Svetlin Nikolov, Ex Phoenix team lead

    Comment


    • #3
      Hey, just an update - this keeps getting delayed due to putting out fires...
      Svetlin Nikolov, Ex Phoenix team lead

      Comment


      • #4
        No problem

        Comment


        • #5
          Hey, finally an update - all tests have passed successfully, except for those that require simulators to talk to one another - such as cascade simulations or setting liquid on fire with two simulators. This seems like something that should not be a problem since it's a special case - haven't checked the code yet, but off the top of my head it's doable, so there is hope

          Will ping you when I know more..
          Svetlin Nikolov, Ex Phoenix team lead

          Comment


          • #6
            Thanks for the update

            Comment


            • #7
              Hey, so swapped the order of interaction so Phoenix interacts first with other Simulators, then with particles, and finally with geometries and tests are looking good so far. The change will be in the nightlies in a couple of days and I will ping you again.

              Cheers!
              Svetlin Nikolov, Ex Phoenix team lead

              Comment


              • #8
                Here are the conditions as of right now:

                if(another simulator){
                // process
                return;
                }

                if(obj->IsParticleSystem() || obj->GetInterface(I_PARTICLEOBJ)){
                // process
                return;
                }

                if(GetPhoenixFDRendInterface(obj)==nullptr &&
                (obj->SuperClassID()==GEOMOBJECT_CLASS_ID || obj->SuperClassID()==SHAPE_CLASS_ID) &&
                obj->CanConvertToType(triObjectClassID))
                {
                // process
                return;
                }

                Does this seem okay to you? How do you imagine the user workflow on the tyFlow side be in this case?
                Svetlin Nikolov, Ex Phoenix team lead

                Comment


                • #9
                  Thanks for the follow up! I think that's basically the order of events I was hoping for

                  Comment


                  • #10
                    Hey Svetlin,

                    I'm noticing some strangeness in how Phx is interfacing with my particles and I'm wondering if you can shed some insight...

                    When I add a tyFlow to a PHXSource with default settings, Phx queries my I_PARTICLEOBJ interface for speed/pos and seems fine (even with Motion Vel disabled).

                    When I change Prt Shape to "use particle shape", Phx quries my IParticleObjectExt interface for TM and shape, but not velocity. So my particle shapes fill with smoke but the velocities don't carry over.

                    If I then enable Motion Vel in the PhxSource, after 1 frame of simulating I get a "The simulation has stopped due to numerical errors!" error.

                    This is in 3.14, not a nightly. It's worth noting that tyFlow returns both I_PARTICLEOBJ and IParticleObjectExt. Is this confusing Phx? I can provide a scene file if you want.

                    Comment


                    • #11
                      Hmm, sounds inconsistent indeed, gotta check what's going on. If you have a scene file, it would help make sure we're on the same page and it would be working correctly after. Thank you!
                      Svetlin Nikolov, Ex Phoenix team lead

                      Comment


                      • #12
                        Hey Svetlin,

                        Did a bit more testing...it seems the velocities do carry through once steps per frame is increased. Perhaps the velocities are being constructed by comparing successively queried TMs when in shape mode? Either way, looks like this was user error. Sorry!

                        Comment


                        • #13
                          Ah, yes, this is correct - in shape mode the particle shapes are treated like moving geometries, so the additional logic that kicks in for particles does not execute - paths of moving particles are not connected and affected by the source emission, and instead a moving particle shape just imprints its emission at the positions where it lies at the beginning of each simulation step. This has to be improved, and especially since it caught you out, it's apparently not very intuitive or consistent...
                          Svetlin Nikolov, Ex Phoenix team lead

                          Comment

                          Working...
                          X