Over the last week I've been working intermittently on integrating 
ARToolkitPlus with the Ogre3d graphics engine as discussed in my message 
thread on the Ogre forums:
      http://www.ogre3d.org/phpBB2/viewtopic.php?t=22584
The simplest of examples is mostly working, as you can see in this 2Mb 
DivX video:
      http://www.edmstudio.com/ogre/06G20-artoolkitplus-rotations.avi

Issues I'm dealing with though:

1) The jitter that many people report.  Undoubtedly a combination of my 
camera's 320x240 resolution, poor camera calibration on my part, etc. 
The RPP algorithm seems to greatly reduce the jitter - well worth trying.

2) Frequent 'trivial' (in the mathematical sense) solutions.  I'll be 
getting correct tile position/orientation for several image frames and 
then a (0,0,0) position with 100% confidence.  (I take it confidence 
relates to the pattern, not the pose.)  Of course I could just choose to 
ignore these solutions, but it makes me wonder if I'm doing something 
wrong.  This happens with both available pose estimators.

3) I am seeing non-returning calls to
     markerId = mTracker->calc((unsigned char*)(img->imageData));
when using the RPP pose estimator:
     mTracker->setPoseEstimator(ARToolKitPlus::POSE_ESTIMATOR_RPP);
This happens repeatably (requires killing the process) and always seems 
to occur with the tile at an oblique angle.  I would, without 
hesitation, attribute this problem to faulty integration with Ogre 
except that it *never* happens when using the default algorithm.  That 
said, I've been unable to reproduce the lock-up using a saved image 
stream feeding a looping version of the ARToolkitPlus's simple code. 
I'll keep trying ... just wondered though if anyone else has experienced 
this problem?

For reference, I'm using v2.0.2 of ARToolkitPlus, compiled on Windows XP 
with VS Express 2005.   (The Ogre details, for anyone interested, are in 
  the message thread mentioned above.)

Cheers,
Darran.

-- 
Darran Edmundson [darran@e ............]
Interactive visualization for museums and industry
http://www.edmstudio.com

Darran Edmundson wrote:
> Over the last week I've been working intermittently on integrating
> ARToolkitPlus with the Ogre3d graphics engine as discussed in my
> message thread on the Ogre forums:
looks great - i guess though, that your camera calibration is not quite
accurate.
the cube is not sitting tightly on the marker.
using the MATLAB camera calibration toolbox makes this really easy, fast
and accurate (once you get used to it).
using a correct camera calibration also speeds up the pose estimation
part. e.g. on the Gizmondo switching to a correct calibration file
improved overall performance from 17 to 28 fps.
> 1) The jitter that many people report.  Undoubtedly a combination of
> my camera's 320x240 resolution, poor camera calibration on my part,
> etc. The RPP algorithm seems to greatly reduce the jitter - well worth
> trying.
did you try using the CONT variant of the standard pose estimator?
while i did not notice that much difference i get reports from people
saying it really does...
RPP should be better though (in case you don't have stability problems...)
> 2) Frequent 'trivial' (in the mathematical sense) solutions.  I'll be
> getting correct tile position/orientation for several image frames and
> then a (0,0,0) position with 100% confidence.  (I take it confidence
> relates to the pattern, not the pose.)  Of course I could just choose
> to ignore these solutions, but it makes me wonder if I'm doing
> something wrong.  This happens with both available pose estimators.
yes, the confidence factor tells how well the id detection algorithm
worked, it's not about the pose.
can you send me a camera image that results in such a pose estimation?
> 3) I am seeing non-returning calls to
>     markerId = mTracker->calc((unsigned char*)(img->imageData));
> when using the RPP pose estimator:
>     mTracker->setPoseEstimator(ARToolKitPlus::POSE_ESTIMATOR_RPP);
> This happens repeatably (requires killing the process) and always
> seems to occur with the tile at an oblique angle.  I would, without
> hesitation, attribute this problem to faulty integration with Ogre
> except that it *never* happens when using the default algorithm.  That
> said, I've been unable to reproduce the lock-up using a saved image
> stream feeding a looping version of the ARToolkitPlus's simple code.
> I'll keep trying ... just wondered though if anyone else has
> experienced this problem?
i already got reports on that.
again, if you send me a camera image that creates this effect i'd try to
look into this.

in any case i advice to switch to a 2.1.x release. we think did fix some
errors with the 2.1 update...

bye,
Daniel

This is a multi-part message in MIME format.
--------------030004020202010603010407
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Daniel Wagner wrote:

>Darran Edmundson wrote:
>  
>
>>2) Frequent 'trivial' (in the mathematical sense) solutions.  I'll be
>>getting correct tile position/orientation for several image frames and
>>then a (0,0,0) position with 100% confidence.  (I take it confidence
>>relates to the pattern, not the pose.)  Of course I could just choose
>>to ignore these solutions, but it makes me wonder if I'm doing
>>something wrong.  This happens with both available pose estimators.
>>    
>>
>yes, the confidence factor tells how well the id detection algorithm
>worked, it's not about the pose.
>can you send me a camera image that results in such a pose estimation?
>
I've been trying to pinpoint this bug in the past, and it has been an 
evasive bugger. The one solid example i did find that went wrong 100% 
was in 2.0.2 and did not bug in 2.1. Since then i moved on and use 
filtering as a temporal solution.

I noticed 2 phenomena:
- The pose matrix contains NaN (not a number) values.
- The pose containsvery small incorrect positional values. These values 
are not (0,0,0) but close enough. The values are also constant (same 
matrix) over the program execution.

The NaN currently happens less than 1% of the frames, the small 
inccorect positonal values around 4%, depending on the pose of the marker.
My current solution involves filtering these results out, since the 
framerate is still high enough.

mvg,
Tijs de Kler

 

--------------030004020202010603010407
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Daniel Wagner wrote:
<blockquote cite="mid44C86248.4080907@i ..............." type="cite">
  <pre wrap="">Darran Edmundson wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">2) Frequent 'trivial' (in the mathematical sense) solutions.  I'll be
getting correct tile position/orientation for several image frames and
then a (0,0,0) position with 100% confidence.  (I take it confidence
relates to the pattern, not the pose.)  Of course I could just choose
to ignore these solutions, but it makes me wonder if I'm doing
something wrong.  This happens with both available pose estimators.
    </pre>
  </blockquote>
  <pre wrap=""><!---->yes, the confidence factor tells how well the id detection algorithm
worked, it's not about the pose.
can you send me a camera image that results in such a pose estimation?</pre>
</blockquote>
I've been trying to pinpoint this bug in the past, and it has been an
evasive bugger. The one solid example i did find that went wrong 100%
was in 2.0.2 and did not bug in 2.1. Since then i moved on and use
filtering as a temporal solution.<br>
<br>
I noticed 2 phenomena:<br>
- The pose matrix contains NaN (not a number) values.<br>
- The pose containsvery small incorrect positional values. These values
are not (0,0,0) but close enough. The values are also constant (same
matrix) over the program execution.<br>
<br>
The NaN currently happens less than 1% of the frames, the small
inccorect positonal values around 4%, depending on the pose of the
marker.<br>
My current solution involves filtering these results out, since the
framerate is still high enough. <br>
<br>
mvg,<br>
Tijs de Kler<br>
<br>
&nbsp;<br>
</body>
</html>

--------------030004020202010603010407--

This is a multi-part message in MIME format.

------=_NextPart_000_0015_01C6B166.ACD0BF60
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi,

 

I had the same problem with NaN values in my matrix, I solved it

using doubles instead of floats for the math (just switch on the
_USE_DOUBLE_

pre-processor flag).

 

Regards,

 

  Toni

 

 

Daniel Wagner wrote: 

Darran Edmundson wrote:
  

2) Frequent 'trivial' (in the mathematical sense) solutions.  I'll be
getting correct tile position/orientation for several image frames and
then a (0,0,0) position with 100% confidence.  (I take it confidence
relates to the pattern, not the pose.)  Of course I could just choose
to ignore these solutions, but it makes me wonder if I'm doing
something wrong.  This happens with both available pose estimators.
    

yes, the confidence factor tells how well the id detection algorithm
worked, it's not about the pose.
can you send me a camera image that results in such a pose estimation?

I've been trying to pinpoint this bug in the past, and it has been an
evasive bugger. The one solid example i did find that went wrong 100% was in
2.0.2 and did not bug in 2.1. Since then i moved on and use filtering as a
temporal solution.

I noticed 2 phenomena:
- The pose matrix contains NaN (not a number) values.
- The pose containsvery small incorrect positional values. These values are
not (0,0,0) but close enough. The values are also constant (same matrix)
over the program execution.



The NaN currently happens less than 1% of the frames, the small inccorect
positonal values around 4%, depending on the pose of the marker.
My current solution involves filtering these results out, since the
framerate is still high enough. 



 

 

 


------=_NextPart_000_0015_01C6B166.ACD0BF60
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";
	color:black;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
pre
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";
	color:black;}
span.StileMessaggioDiPostaElettronica18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@p ... Section1
	{size:595.3pt 841.9pt;
	margin:70.85pt 2.0cm 2.0cm 2.0cm;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body bgcolor=3Dwhite lang=3DIT link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Hi,<o:p></o:p></s=
pan></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>I had the same =
problem
with <st1:place w:st=3D"on">NaN</st1:place> values in my matrix, I =
solved it<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>using doubles =
instead of
floats for the math (just switch on the =
_USE_DOUBLE_<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>pre-processor =
flag).<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Regards,<o:p></o:=
p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>&nbsp; =
Toni<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm =
0cm 4.0pt'>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
lang=3DEN-GB =
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>Daniel Wagner wrote: =
<o:p></o:p></span></font></p>

<pre wrap=3D""><font size=3D2 color=3Dblack face=3D"Courier New"><span
style=3D'font-size:10.0pt'>Darran Edmundson =
wrote:<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp; <o:p></o:p></span></font></pre>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt' =
type=3Dcite><pre wrap=3D""><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>2) Frequent 'trivial' (in the mathematical =
sense) solutions.&nbsp; I'll be<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>getting correct tile position/orientation for =
several image frames and<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>then a (0,0,0) position with 100% =
confidence.&nbsp; (I take it =
confidence<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>relates to the pattern, not the pose.)&nbsp; =
Of course I could just choose<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>to ignore these solutions, but it makes me =
wonder if I'm doing<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>something wrong.&nbsp; This happens with both =
available pose estimators.<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&nbsp;&nbsp;&nbsp; =
<o:p></o:p></span></font></pre></blockquote>

<pre wrap=3D""><font size=3D2 color=3Dblack face=3D"Courier New"><span
style=3D'font-size:10.0pt'>yes, the confidence factor tells how well the =
id detection algorithm<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>worked, it's not about the =
pose.<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>can you send me a camera image that results =
in such a pose estimation?<o:p></o:p></span></font></pre>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>I've been trying to pinpoint this bug in the =
past, and
it has been an evasive bugger. The one solid example i did find that =
went wrong
100% was in 2.0.2 and did not bug in 2.1. Since then i moved on and use
filtering as a temporal solution.<br>
<br>
I noticed 2 phenomena:<br>
- The pose matrix contains NaN (not a number) values.<br>
- The pose containsvery small incorrect positional values. These values =
are not
(0,0,0) but close enough. The values are also constant (same matrix) =
over the
program execution.<br>
<br>
</span></font><font color=3Dnavy><span =
style=3D'color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
lang=3DEN-GB style=3D'font-size:12.0pt'>The <st1:place =
w:st=3D"on">NaN</st1:place>
currently happens less than 1% of the frames, the small inccorect =
positonal
values around 4%, depending on the pose of the marker.<br>
</span>My current solution involves filtering these results out, since =
the
framerate is still high enough. <br>
<br>
<o:p></o:p></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

</div>

</div>

</body>

</html>

------=_NextPart_000_0015_01C6B166.ACD0BF60--

Hi Daniel (and Tijs and Toni),

Thanks for the quick reply(s).  I haven't had much chance to continue 
experimenting with ARToolkitPlus over the last day or so.  On the 
weekend though I plan to:
- try the CONT variant of the standard pose estimator
- recalibrate my camera with the Matlab toolkit
- keep searching for the problem in my use of the RPP code (see below)

A clarification.  In my first post I wrote:

> 2) Frequent 'trivial' (in the mathematical sense) solutions.  I'll be
> getting correct tile position/orientation for several image frames and
> then a (0,0,0) position with 100% confidence. ...  This happens with
 > both available pose estimators.

This was incorrect.  In fact, the (0,0,0) solutions are *only* occurring 
when using the RPP pose estimator.  Furthermore, these solutions are 
only happening when calling ARToolkitPlus from within my Ogre app.  That 
is, if I save the image stream that the Ogre app is using, and then play 
it back to your "simple" project, the problem disappears.  That's a 
pretty clear sign that the problem isn't your code at all, rather my 
integration (either code or compiler settings).  (Tijs, I'm curious if 
you see the same behaviour - i.e., save a frame that your filtering is 
removing and try feeding it to the "simple" demo code?)  The bizarre 
thing is that my Ogre application runs perfectly by simply commenting 
out the one line:
     mTracker->setPoseEstimator(ARToolKitPlus::POSE_ESTIMATOR_RPP);
Arghh.


> in any case i advice to switch to a 2.1.x release. we think did fix some
> errors with the 2.1 update...

Again, my error.  I am, in fact, using the 2.1.0 release.

Cheers,
Darran.

-- 
Darran Edmundson [darran@e ............]
Interactive visualization for museums and industry
http://www.edmstudio.com

I've spent most of the weekend trying to pin down the
bizarre behaviour I've been experiencing when using the
RPP solver in ARToolkitPlus.  Behaviour that only seems
to manifest when running inside of a simple Ogre3D app.
And I've got absolutely no progress to show for it :-(

For anyone interested, I've uploaded some demonstrative
movies to http://www.edmstudio.com/ogre/rpp-problem/.
They are labelled with the returned modelview matrix
and a framenumber corresponding to the webcam image.
(Ignore the poor calibration - I'm using the calibration
file for my work camera with my home webcam - but this
is *exactly* the same behaviour seen at work.)

06G31-artkp-rpp.avi:  Uses the RPP pose estimator.  Raw
grayscale versions of the sequence of images seen by the
webcam are saved to disk (test%0.4d.raw) as reference
data.  The "flashing" occurs when a trivial modelview
matrix is returned.  For example, see frame 238.  The
movie stops when the RPP estimator fails to return when
passed frame 306 (it never gets shown so the last
movie frame shows 305).

06G31-artkp-standard.avi:  Uses the standard pose estimator
but the same webcam data from above.  No trivial modelview
matrices returned and frame 306 doesn't lock up the standard
solver.  I.e. no problems whatsoever save the increased
jitter.

06G31-artkp-rpp-repeat.avi: Rerun with the RPP solver and
the reference data.  Shows repeatable behaviour.

I've uploaded the three sample frames mentioned above
(320x240x1) along with the camera calibration file.
Use these in the simple ARToolkitPlus app and you'll
find that they work fine with the RPP estimator.
This I just don't understand - I keep thinking there
is some naming conflict or compile setting issue between
the RPP portion of AGToolkitPlus and Ogre.

The code I'm running is dead simple.  It's a minor
variation on:

#include "ARToolKitPlus/TrackerSingleMarkerImpl.h"

void artester(void)
{
     const int width = 320, height = 240, bpp = 1;
     ARToolKitPlus::TrackerSingleMarker* mTracker = new
ARToolKitPlus::TrackerSingleMarkerImpl<6, 6, 36, 1, 8>(width,height);
     mTracker->init("quickcam.dat", 0.1f, 10.0f);
     mTracker->setPixelFormat(ARToolKitPlus::PIXEL_FORMAT_LUM);
     mTracker->setPatternWidth(0.09);
     mTracker->setBorderWidth(0.125f);
     mTracker->activateAutoThreshold(true);
     mTracker->setUndistortionMode(ARToolKitPlus::UNDIST_LUT);
     mTracker->setPoseEstimator(ARToolKitPlus::POSE_ESTIMATOR_RPP);
     mTracker->setMarkerMode(ARToolKitPlus::MARKER_ID_BCH);

     char* fname = "Images/test0306.raw";
     if(FILE* fp = fopen(fname, "rb"))
     {
         size_t numPixels = width*height*bpp;
         unsigned char *cameraBuffer = new unsigned char[numPixels];
         size_t numBytesRead = fread(cameraBuffer, 1, numPixels, fp);
         fclose(fp);

         int markerId = mTracker->calc(cameraBuffer);

         if( markerId != -1 )
         {
             float conf = (float) mTracker->getConfidence();
             std::cout << "Matched marker: " << markerId << " with
confidence: " << int(conf*100.0f) << std::endl;

             std::cout << "  ";
             for(int i=0; i<16; i++)
                 printf("%.3f  %s", mTracker->getModelViewMatrix()[i],
(i%4==3)?"\n  " : "");
         }
     }
}

Configuration is ARToolkitPlus 2.1.1, Ogre 1.2 SDK or 1.2.2 source
(doesn't matter, same result), XP, VS Express 2005.  It's 2am
here - time for sleep.  Any ideas what might be causing the RPP
estimator to give these strange results?

Cheers,
Darran.

P.S.  It is probably unrelated but I've been unable to compile
my code in the Ogre solution's debug mode.  I get:

1>C:\Packages\ARToolkitPlus\include\ARToolKitPlus/vector.h(62) : error
C2143: syntax error : missing ';' before '.'
1>C:\Packages\ARToolkitPlus\include\ARToolKitPlus/vector.h(62) : error
C2761: 'Ogre::MemoryManager &Ogre::MemoryManager::instance(void)' :
member function redeclaration not allowed
...

namespace Vector {
	static ARVec  *alloc( int clm );
	static int    free( ARVec *v );   <<<<<< line 62
         // static int    disp( ARVec *v );
	static ARFloat household( ARVec *x );
	static ARFloat innerproduct( ARVec *x, ARVec *y );
	static int    tridiagonalize( ARMat *a, ARVec *d, ARVec *e );
}

Hi,

have you tried to compile with _USE_DOUBLE_ ?

Cheers,


 Antonio

> -----Original Message-----
> From: owner-artoolkit@h .................. [mailto:owner-
> artoolkit@h ..................] On Behalf Of Darran Edmundson
> Sent: Monday, July 31, 2006 10:28 AM
> To: artoolkit@h ..................
> Subject: Re: Infinite loops and 'trivial' solutions with the
> ARToolkitPlus?
> 
> 
> [...]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
Antonio Bleile wrote:
> have you tried to compile with _USE_DOUBLE_ ?
_USE_DOUBLE_ shouldn't really make a difference since the RPP pose
estimator is always compiled with double (at least in the latest
versions). see src/librpp/rpp_types.h for that.

Daniel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 
iD8DBQFEzdUSQVW9sHd65aQRAgIjAJ9UIR5ev8mVpceWvE8UAMHenGTw7wCfcQ7z
4+FvqkKUd8ZRtxCMhgTFay8=
=1fk/
-----END PGP SIGNATURE-----

Daniel Wagner wrote:

> Antonio Bleile wrote:
>> have you tried to compile with _USE_DOUBLE_ ?

> _USE_DOUBLE_ shouldn't really make a difference since the RPP pose
> estimator is always compiled with double (at least in the latest
> versions). see src/librpp/rpp_types.h for that.

Captain Nemo to the rescue:
     http://www.ogre3d.org/phpBB2/viewtopic.php?p=167249#167249

"The ARToolkit uses double precision numbers. But DirectX changes all 
floating point calculations to single precision, unless you specify a 
special flag. If you start Ogre with "Floating point mode: fastest" (the 
default), this flag is not set. So, on the Ogre setup screen, change 
"Floating point mode" to "consistent" and everything works."

After 20+ hours of fruitless debugging, I am *so* glad to see this 
working.  We are really looking forward to using Ogre with ARToolkitPlus ...

Thanks everyone (especially Thomas) for helping to isolate and resolve 
the problem.

Cheers,
Darran.

-- 
Darran Edmundson [darran@e ............]
Interactive visualization for museums and industry
http://www.edmstudio.com