Hi, Boyd:<br><br><div class="gmail_quote">On Tue, Dec 20, 2011 at 11:47 AM, Boyd Tidwell <span dir="ltr"><<a href="mailto:boyd@csimsoft.com" target="_blank">boyd@csimsoft.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The code for the "Create offset curve" command has some problems. <br><br>The following:<br><br> cylinder radius 1 z 1 <br> create curve offset curve 1 distance 0.5<br><br>raises in an exception because the direction vector passed through a series of calls is (0 0 0). The actual code raising the exception is gp_Dir.lxx, lines 41-42:<br>
<br> Standard_Real D = sqrt (Xv * Xv + Yv * Yv + Zv * Zv);<br> Standard_ConstructionError_Raise_if (D <= gp::Resolution(), "");<br><br> I am told by the Cubit experts here that a zero value direction vector for this command should assume the offset is to be planar so in this case a direction vector of (0 0 1) should be used. This is indeed how the current version of Cubit behaves. </blockquote>
<div><br>This part is not implement yet, but I am planning to add it to the to-do list.<br> <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
When the option "direction 0 0 1" is added to the command the OCC code works properly. At least the first time. If the exact command is entered a second time, the resultant curve is offset by an additional 0.5 making the total offset 1.0. Each time the command is repeated, the offset is incremented by another 0.5 which is incorrect behavior. <br>
<br></blockquote><div>This sounds to me an (Cubit) interpreter issue. Can you make a break at OCCModifyEngine::offset_curves(), and check offset_distance value for me? if it kept increasing, the the upper level interpreter has something to do with it. Please let me know if you consistantly see it to be 0.5 and yet offset a wrong distance. Thanks. <br>
<br>Also, I don't have the newest Cubit to double check this command, however, I tried to see what Cubit did in cubit12.2 for this command with an offset_direction. It seems to me that this direction doesn't make sense in Cubit, and it always treats the curve plannar offset. This makes me more curious to know what the command interpreter does for this.<br>
<br><br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">After the create offset command with direction is entered, a "reset" command yields the following:<br>
<br> Traceback (most recent call last):<br> File "<string>", line 1, in <module><br>
File "C:\Cubit_Open_Cascade\cubit_build_OC\claro\bin\Debug\cubit.py", line 2278, in cmd<br> return _cubit.cmd(*args)<br> RuntimeError: Access violation - no RTTI data!<br><br>Cursory debug reveals the failure occurs when attempting to destroy the existing geometry.<br>
<br></blockquote><div><br>I'll take a look on this.<br><br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Also, when the magnitude of the direction vector is increased to any value other than 1 (such as 0 0 3), strange no-planar behavior results when, in fact, the magnitude should have no affect on how the command behaves.<br>
<br></blockquote><div>Please also double check on your side, if the offset distance and direction are passed in correctly to OCCModifyEngine::offset_curves. Thanks.<br><br>BTW, I am going to take a 2-week vacation from tomorrow, you are welcome to sending in more bugs as your testing going on. I will probably get back to you on those in the new year.<br>
<br>Merry Christmas and Happy New Year!<br><br>Jane<br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thank you for looking at this. Sorry it is so long but I thought the detail would help.<span><font color="#888888"><br>
<br> - Boyd<br><br>
</font></span></blockquote></div><br>