<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br>Not yet. That will be next step. Seems plausible since I can't find after quite a bit of testing any leaks, OpenGL errors reported, and testing on different systems with different Nvidia cards. etc, and tracing into VTK ( although trying to trace through all the calls to executive, algorithm, superclass, etc is quite cumbersome). Things just fail to move, silently.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">I found another post where someone had a slightly similar problem and said removing and re-adding actors fixed the problem, which we also seem to see.....</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">How would removing and adding the actors back into the renderer " fix" this?</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Also, why the runtime hit on a 64 bit build?.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Thanks </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Rick</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature"><br>Sent from my iPad</div><div><br>On Mar 7, 2016, at 8:22 AM, David Gobbi <<a href="mailto:david.gobbi@gmail.com">david.gobbi@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">Hi Richard,<div><br></div><div>Did you confirm that the MTime overflow is what is causing your software to fail?</div><div>Also, what Ken said.</div><div><br></div><div> - David</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 7, 2016 at 5:20 AM, Richard Frank <span dir="ltr"><<a href="mailto:rickfrank@me.com" target="_blank">rickfrank@me.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>Hi David,</div><div><br></div><div>A bit of looking at the documentation shows vtkTimeStamp having an unsigned long monotonically increasing, which on Windows 64 bit is 32 bits.<br><br>A seemingly "simple" work around for us would seem to be to redefine the mvar to be a uint64_t and rebuild VTK. That would seem to double the time length. </div><div><br></div><div>But I wonder then why this wasn't done before? There must be some unwanted side effects? Possible memory issues ( points having their own vtkTimeStamp)?</div><span><div><br></div><div>Thanks </div><div><br></div><div>Rick</div><div><br></div><div><br><div>Sent from my iPad</div></div></span><div><br><span>On Mar 6, 2016, at 10:18 PM, David Gobbi <<a href="mailto:david.gobbi@gmail.com" target="_blank">david.gobbi@gmail.com</a>> wrote:<br><br></span></div><div><div><blockquote type="cite"><div><div dir="ltr">Is this on Windows? VTK uses a 32-bit global MTime on Windows. Call GetMTime() on your actor to see if the MTime is approaching the limit. If you find that the MTime overflow is indeed the problem, then complain. Complain loudly. The MTime issue has been in the bugtracker for years.<div><br></div><div> - David <br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 6, 2016 at 7:56 PM, Richard Frank <span dir="ltr"><<a href="mailto:rickfrank@me.com" target="_blank">rickfrank@me.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We are moving an actor(s) ( assemblies ) in multiple QtViews that represent a set of surgical tools.<br>
<br>
In one of our unit tests, the tools are moved for approximately 1 - 1.5 hours and after that time period the tools no longer " move" during rendering, even though different position data is being set to them via SetUserTranform.<br>
<br>
There are, as far as we can tell; no reported memory leaks; no memory overwrites, and no reported OpenGL errors. When I trace into vtkOpenGLActor nothing appears to be amiss. This is on two different machines one with a quadro 5000m and the other with a high end geoforce card.<br>
<br>
If we use a keystroke to remove and add the actors back into the renderer, this will usually fix the problem, but we want to get to the root cause.<br>
<br>
I'd appreciate any tips on how to debug this.<br>
<br>
<br>
Thanks<br>
Rick<br></blockquote></div></div></div></div>
</div></blockquote></div></div></div></blockquote></div><br></div></div>
</div></blockquote></body></html>