Looking for suggestions for smoother (more efficient) jit.anim.node and jit.gl.camera animations


    Dec 06 2017 | 7:31 pm
    Hello, all. Fairly new to jit.gl land. I've created and rigged a model of a tree that I'm importing into jit.gl.model as a .dae file. I'm trying to animate the joints in real-time (rotating them on the x axis) to make the tree "sway". My patch right now just uses some cycle~ objects that are being "snapshot~" with the bangs from the middle outlet of jit.world to move the tree joints. Performance isn't too bad - I'm getting FPS in the mid 30s when the patch is locked, even though jit.world is set to @fps 60. It seems like the more I animate (number of tree limbs/joints, camera movements, light movements), the further the FPS drops. Is there some way I can make animation commands more efficient? I've tried jit.anim.drive instead of direct rotation or position commands to the camera and jit.anim.nodes and also tried setting up the jit.anim.nodes as parents/children. Neither seems to work - the jit.anim.drive method creates just as much of a FPS drop, and the jit.anim.nodes don't seem to operate as children (only the first in the chain moves, maybe this is because I'm directly animating joints with @name rather than a subsequent object?). This is running on a new 2017 MacBook Pro with the Radeon 555 video card. I realize that it might not be possible, but seeing the slapdash way that I'm addressing a big mess of joints, I thought there might be something I could do better that I don't know about yet. Thanks!
    P.S. Strangely, changing some of the attributes of jit.world towards what I assume would be less demanding settings (@fps30, @fsaa 0, @high_res 0) seems to have little (if any) effect at all.

    • Dec 09 2017 | 1:23 am
      Hey Eric! Actually, Max is crashing instantly once I try to load the .tif file, after turning on the rendering. Does that happen for you as well? Not easy to give pointers on the patch right now.
    • Dec 11 2017 | 2:21 pm
      Hello! Here is a link to the .dae model and .tif textures used in the patch (they're too big to attach): https://drive.google.com/open?id=14RLvxSm1fAHpV4ujir2sLdSYLn_fVLEM I did notice that the most reliable startup sequence was to first turn on jit.world, then click the message boxes to load the finalTreeDiffText and finalTreeNormalMap .tifs. Sometimes other sequences would cause a crash. Thanks for taking a look!
    • Dec 11 2017 | 5:00 pm
      Hi Eric. cool model!
      i know this is hard to believe, but I'm pretty sure the drop in FPS you are seeing is the rapidly changing floating number boxes. delete those and you should see a steady 60 fps (with the patch locked). we've got some improvements to this type of unwanted behavior coming in Max 8, but for now your best bet is to not use rapidly updating GUI objects in heavy Jitter patches.
    • Dec 11 2017 | 6:39 pm
      Thanks, Rob! I'm curious - I definitely noticed improvements when the patch was locked vs. when it was editable, and then I think I saw further improvements in the jit.world window when the patch was minimized altogether (although couldn't verify of course since I couldn't see the fpsgui). Will the float boxes still have a negative effect on FPS even if they aren't visible (i.e. if the window is minimized?).
    • Dec 11 2017 | 7:38 pm
      I remember finding out about the GUI objects impacting performance the hard way, particularly moving/interacting ones. My experience is that they will only affect performance if they are visible, so having a clean presentation mode with no automated GUI objects can be one way to make sure nothing will screw up the patch.
      Glad to hear improvements are coming, Rob!
    • Dec 11 2017 | 7:40 pm
      Yes the UI floating-point number boxes will still affect your FPS - they're being updated whether you can see them or not. Pruning any UI stuff you don't absolutely need is a generally good strategy for working with Max, period.