Manta Interactive Ray Tracer Development Mailing List

Text archives Help


[Manta] Re: Re: two frame lag?


Chronological Thread 
  • From: David E DeMarle < >
  • To:
  • Subject: [Manta] Re: Re: two frame lag?
  • Date: Fri, 5 Feb 2010 11:35:32 -0500

Thanks Carson, but I am not sure I understand what you are saying about working in between swap buffer calls. A sample transaction follows this diatribe:

---------------------------------------------------------------------------------------------------------------
My understanding is that manta operates as follows:
m10 GOSUB callbacks
m20 display last rendered image
m30 ray trace next image
m40 GOTO m10

So when the vtk thread is between 10 and 60, manta is stuck at m20. Say manta has frame A ready.

Line 60 lets manta continue to m30 and it produces frame B. Manta then loops and does the callbacks asked for between 10 and 60 in line m10. Manta then gets stuck at m20 again, but frame B won't show any of them.

In line line 70 VTK gets frame B, which is useless, so it lets manta continue on to ray trace the first frame that has the changes and then gets them.

What am I missing?

 -

The paper says the pipeline is configurable, are there any examples of how to configure it to run:
m10 GOSUB CALLBACKS
m20 RAY TRACE
m30 display just rendered frame
m40 GOTO m10

 -

Alternatively are there calls I can make to tell manta to abort the rest of the current render and more importantly skip the next frame display sync?

 -

Alternatively, am I just doing something stupid?

------------------------------------------------------------------------------------------------------------------
The transactions are like this one:
(hypothetically called at line 30)
//----------------------------------------------------------------------------
void vtkMantaRenderer::SetBackground(double r, double g, double b)
{
  if ((this->Background[0] != r)||
      (this->Background[1] != g)||
      (this->Background[2] != b))
  {
  this->Superclass::SetBackground(r,g,b);
  this->MantaEngine->addTransaction
    ( "set background",
      Manta::Callback::create(this, &vtkMantaRenderer::InternalSetBackground));
  };
}

And the manta thread responds by executing this:
(hypothetically at some time after line 60 and before 70.
//----------------------------------------------------------------------------
void vtkMantaRenderer::InternalSetBackground()
{
  double *color = this->GetBackground();
  Manta::ConstantBackground * background = "new" Manta::ConstantBackground(
    Manta::Color(  Manta::RGBColor( color[0], color[1], color[2] )  )  );

  delete this->MantaScene->getBackground();
  this->MantaScene->setBackground( background );
}


David E DeMarle
Kitware, Inc.
R&D Engineer
28 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-371-3971 x109


On Thu, Feb 4, 2010 at 5:19 PM, Carson Brownlee < "> > wrote:
I'm using something similar but only have a one frame lag I believe since I render between swap buffer calls, which works fine when the user is rotating.  transactions fire before rendering, so if your syncing threads in 10 after a rendering is finished and releasing them at 60 then they should be completed before 70, something must obviously be wrong with the additional sync.  What do your transactions look like?

Another thing you could try is just launch beginRendering(true) and then put some code in a custom implementation of RTRT to set workers wanted to 0 after one frame is rendered.  This has the overhead of launching threads and won't render between your calls 90 and 10 but eliminates what looks like 3 render calls below.
Carson



On Feb 4, 2010, at 1:05 PM, David E DeMarle wrote:

I think I am missing something important.

In vtkManta, the VTK thread sends transaction requests to the manta threads and uses SyncDisplay::waitOnFrameReady to wait for them to take effect before it shows the pixels to the user. My problem is that there is a two frame lag.

This is how works now, written from the vtk thread's perspective (in BASIC)

10 waitOnFrameReady()        REM now the manta threads should be "stopped" because thread 0 is,
...                                             REM process changes in vtk state by issuing transactions to let manta threads know about it.
60 displayDone()                     REM release the manta threads, I expect callbacks to be received now
70 waitOnFrameReady()         REM this frame doesn't show the changes yet
80 displayDone()                     REM let manta render the frame that has the changes
90 waitOnFrameReady()         REM now the image I get has the changes in it

The effect is to halve the framerate, since I always have to ask manta to render twice to see what I ask it to draw.

Is there some good way to obviate the need for lines 80 and 90?

David E DeMarle
Kitware, Inc.
R&D Engineer
28 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-371-3971 x109





Archive powered by MHonArc 2.6.16.

Top of page