How to invoke/wait out the collision processing

spacecat56

I am working on a plugin in which I want to step through the timeline and render each frame, capturing the render output in a custom RenderHandler class in order to "do something special" with it before saving.

I see no way to use a custom RenderHandler class when using the RenderManager, so it seems I need to (and I have code that does) set up render options, find the renderer, instantiate my custom render handler, and step the scene from frame to frame calling the renderer with the desired camera, options, and render handler.

The problem I am stuck on is collision/smoothing. When I advance the frame (dzScene->setTime(..)) there are typically some clothing items that need to be collided/smoothed with the figures they are fit to. If I just advance the frame and call the render, this does not happen (and/or does not happen "soon enough") and the output from the render is pre-collision e.g. with pokethrough that the collision processing does eliminate.

A couple of seconds after the render progress dialog starts showing progress on a given frame, the viewport updates to show the clothing correctly. It seems that I need to invoke and/or wait out the collision cycles before (?) invoking the render. I've tried yielding and/or sleeping and/or checking DzBackgroundProgress::isActive() between advancing the time and invoking Render->render(...) but had no impact on the problem.

Does anyone know what I can do in a plugin to invoke and/or wait out the collision / smoothing cycle for e.g. clothing after advancing the current time in the scene?

And/or have any example of using a custom RenderHandler?

thanks!

spielereinz_8872e9675e

I have a very similar problem, so I'm really (really really :)) hoping someone has an answer for this....

BTW

I managed to create a *quick and dirty* fix by waiting 10 seconds right before the dzApp->getRenderMgr()->doRender( renderOptions ) call.
Basically I just assumed that the optimizer runs in a different thread and called Sleep(10000) while crossing my fingers......

This is, of-course, at best a sub-optimal solution since the delay is hardcoded and 10 seconds may be to much in some situations and to little in other.

dtamm

Find the DzMeshSmoothModifier modifier on the object, then find the DzBoolProperty named "Interactive Update" and then turn it on. Then get the mesh.

spielereinz_8872e9675e

dtamm said:

Find the DzMeshSmoothModifier modifier on the object, then find the DzBoolProperty named "Interactive Update" and then turn it on. Then get the mesh.

I'm not quite sure how this helps, since I'm trying to wait until I get an "I'm done with the optimizing message". Not get the optimized mesh itself?

spacecat56

dtamm said:

Find the DzMeshSmoothModifier modifier on the object, then find the DzBoolProperty named "Interactive Update" and then turn it on. Then get the mesh.

Yes, thanks dtamm, that works, I had settled on it (thinking of it as a workaround) after a few days with no replies. Of course, when my loop is finished I need to go back and reset all the ones that I toggled.

Are there any other class types that may be among the modifiers that can have similar deferred (deferrable) evaluation that I should also look for?

MetaGanic Designs

another possible approach is to get the current Viewport(s), and call refresh? Update? Redraw? I have had that issue in Scripting - where I apply something like a Pose, FBM or single Morph, but the viewport doesn't update until I move the mouse over/into it.

function processRefreshView()
{
 var oViewportMgr  = MainWindow.getViewportMgr();
 oViewportMgr.repaintActive3DViewport();
}

Have to say though, that this isn't always 100% as far as keeping the ViewPort up to date when running through a series/sequence of poses. Morphs seem to, and poses "usually", although occasionally the viewport appears to flip back to some initial state inbetween poses.

On the other hand, calling the/a Renderer after is 100% accurate. (ie: either ToRib or ToImage)

And no, Scripting it is not my fav passtime. :) Just happens to be something current that I had to do. There WILL be the same calls in C++, and likely even better ones, since the Scripting options are a sub-set.

MetaGanic Designs

as for dealing weth the Renderer, see Robs Scripting examples:

generic: http://docs.daz3d.com/doku.php/public/software/dazstudio/4/referenceguide/scripting/api_reference/samples/start
Renderer specific: (Scroll to the "Rendering" section at the very bottom. has ToRib, ToBackdrop and ToViewport examples.

Those are Scripting examples, but from C++ you have exactly the same options, and more. Although it's dzApp->getRenderMgr() instead of App.getTheRendererThingy... lol minor syntax differences, but exactly the same.

As for stepping the TimeLine:

  if ( m_bakeOn )
  {
   float frameStep( 0 );

   // step out for a sec so key-framed transforms can happen
   m_inPhysicsStep = false;
   m_inBakeFrameStep = true;

   // always leave frame 0 as start
   if ( dzScene->getFrame() < 1 )
    dzScene->stepTime( 1, true );

   frameStep = m_timeSimSubsteps;
   frameStep /= m_bakeAltFrameRate;

   if ( frameStep > m_bakeCurrentFrame )
   {
    dzScene->stepTime( 1, true ); // true = forward
    m_bakeCurrentFrame++;
   }

   m_inBakeFrameStep = false;
   m_inPhysicsStep = true;
  }

A TON of extra stuff in there, so cut out what you don't need/want... Basically, all you need is

         dzScene->stepTime( 1, true ); // true = forward

Once/as you change the time/frame, do whatever you need or want to do. Stepping forward through the time like that works 100%. You step ahead, Studio wil auto-recalc geoms, clothing projections, viewport refresh, etc.

MetaGanic Designs

( the reason to [occasionally] refer to Rob's Scripting examples when writing C++, is because he is completely anal about commenting, and about covering EVERY nitty-gritty detail! Sorry Rob, but truly, that is mean as a compliment. :) )