Divider Script "RC Script Execution" Error (7182)

Rob_Sloan · April 15, 2022, 7:47pm

I’m working on a project that I intend to segment down to export, for which the new divider script is perfect. However, when I run the script and input the rows and columns, no overlap, RC appears to freak out and I get this “RC Script Execution” “err:7182” error. The only thing that I modified in the batch file, per the tutorial was the source folder.

From the console:

Processing failed: Please check the Reality Capture Help (press F1 to open) for a list of all commands and some examples of use… [The command ‘exportReconstructionRegion’ expects one argument. You have provided more than this. [7182]] [CPP\0x5555\0x557a]

What am I missing here?

kumateCR · April 20, 2022, 2:54pm

Hello,

Does the path to your source folder have any non-English letters, or maybe spaces?
Make sure to not put double quotation marks (once when the source folder is defined, and once in the path with exportReconstructionRegion command).

Could you please show me the path to the source folder, its definition in the script, and also how exportReconstructionRegion command is written in the script in case something was changed?

Rob_Sloan · April 24, 2022, 7:22pm

Ahh! The spaces in the folder name were the culprit. I removed that, tested it, and it immediately started working. Thank you!

Rob_Sloan · May 15, 2022, 11:40am

So I have a follow-up on this but based on a separate issue than the error itself. The division script will only mathematically work some subdivisions of the original reconstruction region some of the time. I’m working on a large 1km^2+ town-size model at the moment, and I can subdivide it into a 3-column, 7-row ReconRegion, but not a 3-column 21-row to make each subdivided model more square. Then, if I try to subdivide one of those into a 1-column 3-row, it does the same weird computation.

For example, here are the reconstruction regions built by the 1-column, 3-row divider script:

<ReconstructionRegion globalCoordinateSystem="+proj=longlat +datum=WGS84 +no_defs" globalCoordinateSystemName="epsg:4326 - GPS (WGS 84)"
   isGeoreferenced="1" isLatLon="1" widthHeightDepth="136.31015016941 154.334838872747 56.0000000075662">
  <globalCoordinateSystemWkt>GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137.0,298.257223563]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]]</globalCoordinateSystemWkt>
  <yawPitchRoll>-0.0122367575478116 0.00139276213810189 -0.00649515239168633</yawPitchRoll>
  <Header magic="5395016" version="2"/>
  <CentreEuclid>
    <centre>-1.43908395148811 0.487977001420313 -0.63050349149853</centre>
  </CentreEuclid>
  <Residual s="1.00013825576549" ownerId="{C6F80B93-31F9-45B0-87AE-86FFFB36A516}">
    <R>0.999999987601509 -7.57722619353502e-05 0.000138041823872166 7.57705830062176e-05 0.999999997055313 1.21675680406734e-05 -0.000138042745433006 -1.21571083753794e-05 0.999999990397988</R>
    <t>0.000863987149419005 0.000159706302031534 -0.0591850098263294</t>
  </Residual>
</ReconstructionRegion>

r2c1:

<ReconstructionRegion globalCoordinateSystem="+proj=longlat +datum=WGS84 +no_defs" globalCoordinateSystemName="epsg:4326 - GPS (WGS 84)"
   isGeoreferenced="1" isLatLon="1" widthHeightDepth="136.310150169655 15.433484077892 56.00000000618">
  <globalCoordinateSystemWkt>GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137.0,298.257223563]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]]</globalCoordinateSystemWkt>
  <yawPitchRoll>-0.0110131524435598 0.00201947160563529 -0.00584552461087589</yawPitchRoll>
  <Header magic="5395016" version="2"/>
  <CentreEuclid>
    <centre>-1.43905977255962 0.487966065667186 -0.656091270036995</centre>
  </CentreEuclid>
  <Residual s="1.00013825576549" ownerId="{C6F80B93-31F9-45B0-87AE-86FFFB36A516}">
    <R>0.999999987601509 -7.57722619353502e-05 0.000138041823872166 7.57705830062176e-05 0.999999997055313 1.21675680406734e-05 -0.000138042745433006 -1.21571083753794e-05 0.999999990397988</R>
    <t>0.000863987149419005 0.000159706302031534 -0.0591850098263294</t>
  </Residual>
</ReconstructionRegion>

r3c1:

<ReconstructionRegion globalCoordinateSystem="+proj=longlat +datum=WGS84 +no_defs" globalCoordinateSystemName="epsg:4326 - GPS (WGS 84)"
   isGeoreferenced="1" isLatLon="1" widthHeightDepth="136.31015016941 15.4334840779064 56.0000000073472">
  <globalCoordinateSystemWkt>GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137.0,298.257223563]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]]</globalCoordinateSystemWkt>
  <yawPitchRoll>-0.00978956465806833 0.00201950343583966 -0.00519606695165042</yawPitchRoll>
  <Header magic="5395016" version="2"/>
  <CentreEuclid>
    <centre>-1.43903559502254 0.487966067732492 -0.680836286395788</centre>
  </CentreEuclid>
  <Residual s="1.00013825576549" ownerId="{C6F80B93-31F9-45B0-87AE-86FFFB36A516}">
    <R>0.999999987601509 -7.57722619353502e-05 0.000138041823872166 7.57705830062176e-05 0.999999997055313 1.21675680406734e-05 -0.000138042745433006 -1.21571083753794e-05 0.999999990397988</R>
    <t>0.000863987149419005 0.000159706302031534 -0.0591850098263294</t>
  </Residual>
</ReconstructionRegion>

I can already tell that the divider script has inexplicably moved the decimal placement of the Height for rows 2 and 3, making it 15.4___ instead of 154.___. But I can’t just move that decimal placement in Notepad++ and fix it. The “Centre Euclid” and “YaxPitchRoll” would also have to be accounted for.

This is just one example of the Divider Script doing this. I’ve attempted re-downloading the script in case the divider script was corrupted, but the fresh download does the same thing. I’ve had it work with some combinations of row and column counts and not others. I cannot figure out a rhyme or reason for what works and what doesn’t.

WallaceWain · May 18, 2022, 8:01am

Hi Rob,

Please can you send some screenshots of the regions which are wrong, and draw on what they should look like. Sorry for the hassle it’s just a bit easier to see it visually, and then hopefully I should be able to see what went wrong. Probably the reason has something to do with the way the script moves the boxes around, as this is done by for example to move the box in the x direction it will be scaled to twice the size in the x direction from it’s origin point then shrunk to have the size by it’s center, when this is done twice the box shifts along by exaclty it’s own length but i guess in your case the scaling has gone wrong for some reason.

Rob_Sloan · May 18, 2022, 10:30am

For some reason I can’t upload the photos into this chatbox. Images are small jpg’s, but it’s not wanting to work.

Here’s a folder with the four images: GDrive Link

Reconstruction Region to be divided
1st Divider Section created
2nd Divider Section created
3rd Divider Section created

You should be able to see that the first one builds seemingly fine, but the second and third one build at 1/10th the proper height, and therefore everything is tossed out of whack.

WallaceWain · May 19, 2022, 6:51am

Hi Rob,

perfect thank you, I will take a look at the script and see if I can figure out what is causing it.

WallaceWain · May 19, 2022, 7:42am

Hi Rob,

thank you so much for getting in touch, you have found a bug with the script: please replace the scaling command on line 111:

with the scaling command on line 55:

so it should then read:

if you are interested in the reason for it not working is because the original version of the script only worked for values of rows and columns between 2 and 10 (due to batch not using floating point math), so we set up 2 variables to fake floating point (within limits, it will still only work for values from 1-99):

unfortunately these variables were only used the first time the box was scaled in the script.

I haven’t had a chance to properly test this yet, but hopefully it will work i had repro on the 1 column 3 row bug and it fixed that. Once tested we will replace the sample, thanks again!