GeRayCollider and other projections

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 24/09/2006 at 12:43, xxxxxxxx wrote:

Sorry if i'm ignorant, but couldn't you use the ViewportSelect class. That's what it is for. You could draw custom polys and handles in there, or simply put all objects, including the axis objects in the array for initialization. And most importantly you don't need to care about projections.

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 24/09/2006 at 14:14, xxxxxxxx wrote:

You are correct. But this class is not available before R9 - this is why I wished that C4DObjectList were useful - it is available.

Although I always state R9.102, I'm also working with the R8.207 and R8.503 SDK's (separate compiles to include later features as the version goes up).

So, this will solve the problem for R9.102, but what can be done about the others?

Thanks!

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 24/09/2006 at 16:14, xxxxxxxx wrote:

ViewportSelect fails, fails, and fails even more.

1. It cannot be used to select 'virtual objects' drawn into the view using BaseDraw::DrawPolygonObject() - it did not find any intersections. I think the docs mean "for stuff like highlighting and modeling objects in the document".

2. It ate memory like a hungry American at an All-you-can-eat buffet - just little mouse movements and "Not enough memory" - out of 2.5GB. That was with both AutoAlloc<ViewportSelect> in the routine and ViewportSelect::Alloc() once in InitTool() (and Free() in FreeTool()). I'll bet that this is large swaths of ViewportPixel arrays - which cannot be freed - that may linger as I need to call Init() and GetNearestPolygon() multiple times (one for each instance of the object).

3. Next...

Thanks,

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 25/09/2006 at 01:03, xxxxxxxx wrote:

This is very strange. Have you tried it with R9.5 ? I think i've never used it in R9.1. And i can tell you that it seems to work fine in R9.5. Also in R9.5 there are two functions that might be just what you need
Bool DrawPolygon(const Vector* p, LONG ptcnt, LONG i, BaseObject* op, Bool onlyvisible = -1);
Bool DrawHandle(const Vector& p, LONG i, BaseObject* op, Bool onlyvisible = -1);

Perhaps Mikal can confirm that this class is buggy in R9.1 ?!

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 25/09/2006 at 01:31, xxxxxxxx wrote:

Unfortunately, I'm stuck with R9.1 (and the other two). Basically, the plugin supports R8.2 and above - so that is my common denominator. But of course, I'll do the best with these and use what is available in the R9.1 SDK. The reason for not expanding to R9.5 or R9.6 (yet) is that three compiles per system is already enough. Though instabilities encountered with R9.6 (mainly MacOS) may require a separate compile/version.

I don't know why ViewportSelect is non-responsive and memory consumptive. The code that I used is basically the same code that I posted here a little while back for selecting 'body parts' - it didn't suffer from the memory problem. It would be enlightening to know by what means the ViewportPixel arrays are flushed (I was assuming and hoping that ViewportSelect::Init() would furnish this since there is no other means). As noted, it is interesting that the memory consumption occurs even if doing AutoAlloc<ViewportSelect> in the method that does the intersection test. Surely this is an anomaly that needs explanation.

Being a little vindictive, it would be sooo much easier if Maxon would furnish the code to their Move/Scale/Rotate tools - despite their proprietary nature. I have no choice but to 'recreate' them for my unique circumstances and it is proving a daunting task (as can be seen by my continued pleas). So little (virtually nothing) is explained about all of this that it is more or less guessing than development.

Thank you for your help so far. Hopefully more concrete information will be provided through more official channels.

Thanks!

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 26/09/2006 at 04:12, xxxxxxxx wrote:

Okay, I'm going to post some sample code. Maybe that will get a fire burning...

This just shows the Control draw and pick for the X-Axis Twist (Y&Z; omitted for clarity) - called from ToolData::Draw() :

// IPPTool.DrawTwistControl  
//*---------------------------------------------------------------------------*  
void IPPTool::DrawTwistControl(BaseDraw* bd, BaseDrawHelp* bh, BOOL activeBD)  
//*---------------------------------------------------------------------------*  
{  
     Matrix     m =     selectedBP->GetMg();  
     Vector     ctr =     bd->WS(m.off);  
  
     LONG left, top, right, bottom, width, height;  
     bd->GetFrame(&left;, &top;, &right;, &bottom;);  
     width =          right - left + 1;  
     height =     bottom - top + 1;  
     Real     rad =     (Real)((width > height)?(height>>2) :(width>>2));  
  
     // Scale for PolygonObject  
     LONG     proj =     bd->GetProjection();  
     Real     rad2 =     2.0 * Len(ScreenToWorld(Vector(ctr.x+rad*0.5, ctr.y, ctr.z), bd, proj)-ScreenToWorld(ctr, bd, proj));  
     m.v1 =          !m.v1 * rad2;  
     m.v2 =          !m.v2 * rad2;  
     m.v3 =          !m.v3 * rad2;  
  
#ifdef C4D_R9  
     bd->LineZOffset(32);  
#endif  
     bd->SetTransparency(0);  
     // 'Sphere'  
     //bd->SetPen(GetWorldContainer().GetVector(WPREF_SELECT_AXIS_COL));  
     //bd->Circle2D(ctr.x, ctr.y, rad);  
     // 'Ring'  
     BaseContainer*          bc =     selectedBP->GetDataInstance();  
     if (!bc)          return;  
     LONG     rorder =     bc->GetLong(IPP_RORDER);  
     // X-Axis  
     if ((rorder == ROTORDER_XYZ) || (rorder == ROTORDER_XZY))  
     {  
          Matrix     mx =     m*zrotMat;  
          // Check if cursor is over a Visual Control  
          if (activeBD && !dragMode)  
          {  
               // Highlighting from cursor  
               Vector     wtail =     bd->SW(Vector(mouseX,mouseY,0.0));  
               Vector     whead =     bd->SW(Vector(mouseX,mouseY,100000.0)) - wtail;  
               Vector     otail;  
               Vector     oray;  
               Matrix     imx =     !mx;  
               GeRayColResult     xRes;  
               // X-Axis  
               rotatObj->SetMg(mx);  
               // - Is cursor over the visible portion of this ring  
               rayC->Init(rotatObj, FALSE);  
               otail =               imx * wtail;  
               oray =               whead ^ imx;  
               if (rayC->Intersect(otail, !oray, 100000.0))     xMode = rayC->GetNearestIntersection(&xRes;);  
               // Compare the hits for visibility and nearness  
               if (xMode && xRes.backface)     xMode =          FALSE;  
               if (xMode)                         { xHitPos =     xRes.hitpos;     radius = rad; }  
               restrictMode =     xMode;  
          }  
          if (xMode)     ocp.color =     GetWorldContainer().GetVector(WPREF_SELECT_AXIS_COL);  
          else          ocp.color =     GetWorldContainer().GetVector(WPREF_XAXIS_COL);  
          rotatObj->SetColorProperties(&ocp;);  
          rotatObj->SetMg(mx);  
#ifdef C4D_R9  
          bd->DrawPolygonObject(bh, rotatObj, 0L);  
          bd->LineZOffset(0);  
#else  
          bd->PolygonObject(bh, rotatObj, 0L);  
#endif  
     }  
}

I can't issue my first commercial update (with crucial fixes) until this tool is finished. Only two issues here: picking in projections other than Perspective/Parallel and finding a tangent vector pointing in the positive rotation direction for an axis (for mouse movement with these controls).

Thanks,

Robert

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 26/09/2006 at 05:25, xxxxxxxx wrote:

After some more thorough tests, here are the projections that work and don't work for the tools:

Work (Translate and Scale)
--------
Perspective
Parallel
Gentleman
Front
Left
Bottom

Don't (Translate and Scale)
---------
Dimetric
Isometric
Bird
Frog
Military
Top
Right
Back

Work (Rotate and Twist)
--------
Perspective
Parallel
Bottom

Don't (Rotate and Twist)
---------
Dimetric
Isometric
Bird
Frog
Military
Gentleman
Front
Left
Top
Right
Back

That's an odd lot of choices. Also, I noticed that I had partial picking in Right for the Rotate tool in one circumstance, but only at the edges. Could this be a depth issue? Maybe this will help in the determination.

Thanks,

Robert

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 26/09/2006 at 21:25, xxxxxxxx wrote:

Hello? (i.e.: bump)

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 27/09/2006 at 18:09, xxxxxxxx wrote:

Anyone? If the controls can't be picked, then the operation cannot be axially constrained and the axis cannot be used to determine how the mouse coordinates should react.

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 27/09/2006 at 19:36, xxxxxxxx wrote:

Okay, I've figured it out - definitely a depth issue. In most of the other view projections, the objects are near or on the other side of the view plane. So, instead of this:

Vector wtail = bd->SW(Vector(mouseX,mouseY,0.0));

I used this:

Vector wtail = bd->SW(Vector(mouseX,mouseY,-100000.0));

Was it really that difficult to tell me that little piece of information?

Now I can finalize this tool and get the update out pronto.

Thanks,

Robert