Page 1 of 2 12 LastLast
Results 1 to 15 of 20

Thread: VParm weirdness

  1. #1
    creacon
    Join Date
    Nov 2005
    Location
    Belgium
    Posts
    1,300

    VParm weirdness

    Hi,

    does anybody have any idea (or what would be different) in the following 2 cases:
    Case 1 returns the correct values for both Vparms:

    double currentscalemultiplier = 0.0;
    double currentparticlesize = 0.0;
    LWTime currenttime = (double)frame / LW_Sceneinfo->framesPerSecond;

    LW_VParmfuncs->getVal(mysimobject->particles->VPParticlesize, currenttime, NULL, &currentparticlesize);
    LW_VParmfuncs->getVal(mysimobject->particles->VPDisplay_scalemult, currenttime, NULL, &currentscalemultiplier);

    case 2:
    always returns 0.0 for the first VParm and returns the correct value for the second one:

    double currentscalemultiplier = 0.0;
    double currentparticlesize = 0.0;
    LWTime currenttime = (double)frame / LW_Sceneinfo->framesPerSecond;

    LW_VParmfuncs->getVal(mysimobject->particles->VPDisplay_scalemult, currenttime, NULL, &currentscalemultiplier);
    LW_VParmfuncs->getVal(mysimobject->particles->VPParticlesize, currenttime, NULL, &currentparticlesize);

    These 2 code snippets are identical except for the order of getting the value from the VParm, I just lost a few hours on the weirdest bug I have ever seen.

    creacon

  2. #2
    LightWave Engineer Jarno's Avatar
    Join Date
    Aug 2003
    Location
    New Zealand
    Posts
    618
    From the LWSDK documentation on vparm:
    The value argument should always point to storage for three doubles, whether or not the vparm is a vector
    By supplying a pointer to one double it'll end up overwriting part of your stack.

    ---JvdL---

  3. #3
    creacon
    Join Date
    Nov 2005
    Location
    Belgium
    Posts
    1,300
    Wow, I am officially flabbergasted!
    I really have to learn to read the docs.

    Thanks for the tip. If I understand it correctly, it's half a miracle that it works the other way around.

    creacon

    Quote Originally Posted by Jarno View Post
    From the LWSDK documentation on vparm:

    By supplying a pointer to one double it'll end up overwriting part of your stack.

    ---JvdL---

  4. #4
    creacon
    Join Date
    Nov 2005
    Location
    Belgium
    Posts
    1,300
    I have a new problem now. I added an event callback to some of the VParms.
    If I add a key to the envelope the callback gets triggered 4 times:

    first LWVPEC_ENVNEW and that's OK.
    then 3 X LWVPEC_ENVUPDATE

    Is this the same "chaos by design" as the previous problem, or is the chaos in my code?

    The problem is that when the envelope changes, I need to perform an update, but I need to do this only once, not 3 times.

    creacon

  5. #5
    TrueArt Support
    Join Date
    Feb 2003
    Location
    Poland
    Posts
    7,993
    Maybe it's called because it's vector?
    1st time for X, 2nd time after Y, 3rd time after Z.. ?
    Try with scalar instead whether it's same.

  6. #6
    creacon
    Join Date
    Nov 2005
    Location
    Belgium
    Posts
    1,300
    It's a single float, there is only one curve in the envelope editor and it's defined as FLOAT.
    But if you look at Jarno's answer on my previous problem in this thread I wouldn't be surprised if it was the same thing.

    creacon

    Quote Originally Posted by Sensei View Post
    Maybe it's called because it's vector?
    1st time for X, 2nd time after Y, 3rd time after Z.. ?
    Try with scalar instead whether it's same.

  7. #7
    TrueArt Support
    Join Date
    Feb 2003
    Location
    Poland
    Posts
    7,993
    It's single float, then where is problem?
    If
    float x = old data;
    after event sent 1st time, we have x = new data;
    then after 2nd time event sent, we have again same data as in 1st event, so we don't need to regenerate anything (why to regenerate when it's same value?)
    so the same after 3rd time event sent, if it's same value..

  8. #8
    LightWave Engineer Jarno's Avatar
    Join Date
    Aug 2003
    Location
    New Zealand
    Posts
    618
    Probably there is an update event for each of the various keyframe parameters, such as curve shape.

    One thing you have to think about is: do you really have to do the update immediately there and then, or is it only needed the next time the plugin is evaluated?
    In many cases the latter is sufficient. Set a dirty flag in the event callback, then check for it and update just before it is really needed (typically at the start of the plugin's evaluate(), sometimes init() or newtime()).

    That aggregates mulitple changes, and improves interactivity by not taking up time while the user is tweaking keyframe values.

    ---JvdL---

  9. #9
    creacon
    Join Date
    Nov 2005
    Location
    Belgium
    Posts
    1,300
    Hi Jarno,

    That's what I am doing already for the "non urgent" updates where e.g. only the display needs updating.
    But when you change a simulation parameter (like viscosity), the whole simulation needs to be recalculated and I want the user to see the update immediately.

    For parameters that don't have an envelope attached that approach works perfectly. Change something and see the result.

    Are you sure about your answer? If you change the envelope (position, rotation, ...) of an animated object you see the update immediately in the viewport, are there 3 viewport updates each time you change the envelope?
    Or better, when is the update happening?

    creacon





    Quote Originally Posted by Jarno View Post
    Probably there is an update event for each of the various keyframe parameters, such as curve shape.

    One thing you have to think about is: do you really have to do the update immediately there and then, or is it only needed the next time the plugin is evaluated?
    In many cases the latter is sufficient. Set a dirty flag in the event callback, then check for it and update just before it is really needed (typically at the start of the plugin's evaluate(), sometimes init() or newtime()).

    That aggregates mulitple changes, and improves interactivity by not taking up time while the user is tweaking keyframe values.

    ---JvdL---

  10. #10
    TrueArt Support
    Join Date
    Feb 2003
    Location
    Poland
    Posts
    7,993
    Typically in call-back, triggered by event from LW, it is not doing real evaluation inside its body.
    Just updates some internal variable.
    And then calls f.e. LWInstUpdate of other handler.
    This causes calling evaluate() function.

    As I said already, you can compare new value from event, with currently stored value, to see whether they are same or not. This will limit to just 1 event.

  11. #11
    creacon
    Join Date
    Nov 2005
    Location
    Belgium
    Posts
    1,300
    I am doing that in a lot of places already, e.g. user changes color setting, variable NeedsColorUpdate is set and when the time changes or the display is refreshed (which i can force using a command) there is an update.
    But this case is a bit different, lets say that the user edits the viscosity envelope, and the value at the current timestep isn't changed but the values before that timestep are changed, then I still need to update the complete simulation.
    So if I want to compare the value with the previous value, I would need to check the complete envelope (VParm).

    For this particular event that I am catching, the docs say this:

    LWVPEC_ENVUPDATE
    Generated after the envelope has changed.

    So I really don't see why this would be called 3 times.

    creacon




    Quote Originally Posted by Sensei View Post
    Typically in call-back, triggered by event from LW, it is not doing real evaluation inside its body.
    Just updates some internal variable.
    And then calls f.e. LWInstUpdate of other handler.
    This causes calling evaluate() function.

    As I said already, you can compare new value from event, with currently stored value, to see whether they are same or not. This will limit to just 1 event.

  12. #12
    TrueArt Support
    Join Date
    Feb 2003
    Location
    Poland
    Posts
    7,993
    Updating it while event is sent will be serious bottleneck regardless there are 3 or 1 events.
    Imagine what will happen if mesh is real complex..

    Particle simulation in FX, is recalculated when user manually hit Calculate..
    Now imagine how it would work, if you change settings, and it's going through all frames..

  13. #13
    creacon
    Join Date
    Nov 2005
    Location
    Belgium
    Posts
    1,300
    That's exactly what I am doing, and even with 1 million particles the update is really fast.
    Isn't bullet doing the same thing when you change a parameter?

    creacon

    Quote Originally Posted by Sensei View Post
    Updating it while event is sent will be serious bottleneck regardless there are 3 or 1 events.
    Imagine what will happen if mesh is real complex..

    Particle simulation in FX, is recalculated when user manually hit Calculate..
    Now imagine how it would work, if you change settings, and it's going through all frames..

  14. #14
    creacon
    Join Date
    Nov 2005
    Location
    Belgium
    Posts
    1,300
    Did some more testing and Jarno is right (he's a Newtek developer after all :-), if I edit an envelope of a vector there are 9 update events triggered.
    So probably smaller events, like add the keyframe, set the curvetype, and set the value or something like that per float.

    Jarno, would it be possible to add an Update_ready event or something like that, that is triggered aftter the full update is done? Should be a small change.

    creacon

  15. #15
    LightWave Engineer Jarno's Avatar
    Join Date
    Aug 2003
    Location
    New Zealand
    Posts
    618
    I'm sure you think it is fast enough, but someone will start playing with sliders in the graph editor, or move a hundred keyframes around, and complain that Layout locks up as it spends a minute recalculating the particle sim several hundred times.

    The proper thing to do is set a dirty flag, and tell Layout that the state of your plugin has changed through LWInstUpdate.

    ---JvdL---

Page 1 of 2 12 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •