Community
ReCap SDK Forum
Welcome to Autodesk’s ReCap SDK Forum. Share your knowledge, ask questions, get support and explore popular ReCap SDK topics.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Release date SDK fixes

19 REPLIES 19
Reply
Message 1 of 20
martin.graner
1626 Views, 19 Replies

Release date SDK fixes

Is there a known release date for the SDK with bug fixes?

 

Will the functionality to write structured RCS files from RCPointBuffer be included?

 

Is the functionality for an out-of-core strategy for RCPointBuffer to write big unstructured RCS files which won't fit into memory in the development list?

 

I'm asking because we'd like to Release a new version of PointCab around the Intergeo which takes place in Frankfurt 16th-18th of October this year. Most important to this is the ability to read and write from Non ASII paths.

 

Thanks in advance.

Martin

Tags (1)
19 REPLIES 19
Message 2 of 20

Hi Martin:

We'll get a fix out for this soon and in time for Intergeo.  Please expect someone from our team to contact you shortly.



Michael M.

Senior Product Manager - Reality Solutions

Message 3 of 20
yan.fu
in reply to: michael.mizuno

 Hi @martin.graner,

 

We have released a hot-fix to address the non-ascii file path issue. You can download the new release package from ADN website. 

Please let us know if there is any issue with it.

 

Thank you very much!

 

Regards,

Yan

Message 4 of 20
martin.graner
in reply to: yan.fu

Hi @yan.fu,

the import from non ASCII works now perfect.

 

Thank you very much.

 

Is there a schedule for my other two requests when they will be availible?

 

Martin

Message 5 of 20
vaidas
in reply to: yan.fu

I cant find where to donwload hot fix, can you give a link?

Message 6 of 20
karthik.nathan
in reply to: vaidas

Hi @vaidas,

 

The Reality Solutions SDK page in Autodesk Developer Network has been updated with v19.0.1 of the SDK. Once you click "I accept", the link provided to download the SDK will be for v19.0.1.

 

-Karthik

Message 7 of 20
martin.graner
in reply to: vaidas

Hi @vaidas,

 

you need to go to: ADN Development

And then press on Software (at the top) Reality Solutions SDK, then you will receive an email with a download link valid for 24 Hours.

 

Martin

Message 8 of 20
vaidas
in reply to: karthik.nathan

I see, i have this version so i think i misunderstand something. i try to convert las file to rcp and it fails when las file has unicode chracters in name. i thouhgt this issue was solved. here is sample output:

>RCPCreatorSample.exe -i "c:\\temp\\4.Himmel & Hav, Skovbørnehave, Fælledvej 132.las" -o "c:\\temp" -c "C:\\Program Files\\Undet\\Undet Indexer\\Codec" -s
Importing 1 scans to c:\temp\4.Himmel & Hav, Skovb°rnehave, Fµlledvej 132.rcp
[F][c:\\temp\\4.himmel & hav, skovb°rnehave, fµlledvej 132.las][1]
Total Progress: 0%
Scan: 4.himmel & hav, skovb°rnehave, fµlledvej 132 Progress: 0%
Total Progress: 100%
Scan: 4.himmel & hav, skovb°rnehave, fµlledvej 132 Progress: 100%
[E][100013][Fail to import the files]
Scan failed to import

if i rename las file to something like 'las.las' it works fine. maybe you know is there some easy fix?

 

Message 9 of 20
martin.graner
in reply to: vaidas

They fixed the import, so now one is able to import *.rcp files from Non-ASCII paths.

I just ran into the same issue like you @vaidas, I'm not able to create a *.rcp file from an e57 file which is in a path with a mutated vowel, like T:\ScanData\Autodesk\WSHome_ünordered\Test.e57

 

What in addition puzzles me is that the path displayed in the output is all in small letters

[F][t:\scandata\autodesk\wshome_ünordered\test.e57][1]

 

Intergeo is one week away now Smiley Frustrated

Message 10 of 20
yan.fu
in reply to: martin.graner

Thank you for reporting this issue. We will look into it.

 

Regards,

Yan

Message 11 of 20
benglin
in reply to: martin.graner

Greetings, @martin.graner

 

I'm sorry for not making it clearer in my previous response. The fix that went in to v19.0.1 release was meant to address an issue where E57Codec.rcip (or any other codec for that matter) cannot be loaded if it resides under a path with Unicode characters. That fix, however, did not extend to cover another path related issue within the E57Codec.rcip plug-in. I apologize for having misunderstood the issue you reported earlier when you mentioned e57.

 

I have generated a new E57Codec.rcip file with an extended fix to cover the problem within E57Codec.rcip itself, please see it resolves the issue you are facing.

 

Thanks for your understanding/patience Smiley Happy

"https://damassets.autodesk.net/content/dam/autodesk/logos/autodesk-logo-primary-rgb-black-small_forum.png"
Message 12 of 20
martin.graner
in reply to: benglin

Hi @benglin,

 

thanks for the rcip file, it works now perfect.

The issue I mentioned in the other topic was the same as here. I was not able to use importFiles(...) on an *.e57 (to create a rcp from an e57) if it was in a non ASCII path. Perhaps it would have been more wise to open an extra topic there instead of writing it into the rcp import issue thread, my bad.

 

The other thing I had with importFiles(...) was the slash vs backslash thing.

 

Perhaps one last thing regarding the importFiles(...) function. I'm not sure if this happens if there is a space in the path or special charakters, but the displayed message which files are imported and where the file is saved is not displayed correctly on my machine:

First line the output of importFiles(...), the second line the callback.

The real path to the rcp should be T:\ScanData\FARO\WSHome_αρμαρίου ΠΥΡΓΟΣ\poincab\Demo_Haus_Results\3D\cloud_0.rcp

 

Importing 2 scans to T:\ScanData\FARO\WSHome_[F][t:\scandata\faro\wshome_
Total Progress: 6 %

 

Thanks for the fix :slightly_smiling_face:

Now you need to do the same for the las.rcip for @vaidas Smiley Wink

Message 13 of 20
vaidas
in reply to: benglin

Hi can you fix LAS codec too? Thanks

Message 14 of 20
benglin
in reply to: martin.graner

Hi @martin.graner,

 

I'm glad the binary worked well for you (and best of luck for Intergeo, whatever that is)! Smiley Happy

 

As for your further queries, here are my answers:

 

  1. From my experiment based on v19.0.1 release, importFile(...) function works with both forward and backward slashes. The only time when it fails, it returns rcNoValidFiles, and that happens when the output folder already contains result RCP/RCS files generated by a previous run. Can you confirm this is the case?
  2. The truncated file path you saw in the Standard Output was, as you have correctly guessed, caused by Unicode characters in the file path. The command line interface does not deal with Unicode characters that well I'm afraid, but the data internally is correct.
  3. I would have loved to fix the issue with LAS codec for you, unfortunately the third party LAS library does not work with UTF-8 strings natively like E57 library does. An obvious workaround for this case would be to temporary copy the to system's %temp% folder prior to calling importer.importFiles(), before eventually deleting the temporary file. 

 

Hope that helps! 

 

Thanks,
Ben.

"https://damassets.autodesk.net/content/dam/autodesk/logos/autodesk-logo-primary-rgb-black-small_forum.png"
Message 15 of 20
martin.graner
in reply to: benglin

Hi @benglin,

thanks for the luck, will need it. The Intergeo is one of the biggest trade fairs regarding surveying in europe.

 


@benglin wrote:

Hi @martin.graner,

 

I'm glad the binary worked well for you (and best of luck for Intergeo, whatever that is)! Smiley Happy

 

As for your further queries, here are my answers:

 

  1. From my experiment based on v19.0.1 release, importFile(...) function works with both forward and backward slashes. The only time when it fails, it returns rcNoValidFiles, and that happens when the output folder already contains result RCP/RCS files generated by a previous run. Can you confirm this is the case?
  2. The truncated file path you saw in the Standard Output was, as you have correctly guessed, caused by Unicode characters in the file path. The command line interface does not deal with Unicode characters that well I'm afraid, but the data internally is correct.

 

Hope that helps! 

 

Thanks,
Ben.


  1. I have checked that. It is indeed working, however if one uses slashes in the path (/) and is importing a structured E57 then there won't be mirrorballs in the RCP file, while the created RCS files are structured. If using backslashes (\) everything is fine.
    The errorcode you mentioned is happening as well, I never faced it until now, because we delete the rcp file and the support folder before calling importFile(...)
  2. Yup the command line is not so important while everything is working as it should.

 

Kind regards

Martin

Message 16 of 20
lamorlette
in reply to: martin.graner

Hello @benglin,

I am not sure about which fixes are in 19.0.1:

Please, should I be able to use a path with UTF8 characters when calling RCProject::loadFromFile()?

I tried in different ways, I still get a rcInvalidProject error.

Message 17 of 20
benglin
in reply to: lamorlette

Hi @lamorlette RCProject::loadFromFile() method takes RCString as the absolute path to an RCP file, it should be a UTF-16 string (i.e. the usual wchar_t *, std::wstring should work). There might be issues with the RCP you're trying to load that it returns rcInvalidProject error code. To rule out any potential path related issues, can you please store the RCP file (and its Support folder) under a path with just ANSI characters, and see if that helps? I'll be glad to clarify further questions if you have.

"https://damassets.autodesk.net/content/dam/autodesk/logos/autodesk-logo-primary-rgb-black-small_forum.png"
Message 18 of 20
lamorlette
in reply to: benglin

@benglin After many tries, I found out that RCProject::loadFromFile() loads correctly files with RCString constructed from std::wstring, if I use UTF16 characters ≤ 00FF.

So file_ÿ.rcp loads correctly but not file_Ā.rcp.

Could you please try and tell me if you get the same behaviour, or if I am doing something wrong?

 

Note: this behaviour is the same with SDK 19.0 and 19.0.1.

 

Shall I start a new topic about this for clarity?

Message 19 of 20
benglin
in reply to: lamorlette

Yes please, @lamorlett another topic (related to Unicode file names) would be great. We can include a reference to that new topic here so readers can follow it up, and we won't end up cluttering this thread. Sorry for the late reply, I was addressing another competing priority these two days, will look at this problem soon as that's done. You can tag me over in your new post, thanks!

"https://damassets.autodesk.net/content/dam/autodesk/logos/autodesk-logo-primary-rgb-black-small_forum.png"
Message 20 of 20
lamorlette
in reply to: benglin

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Rail Community


 

Autodesk Design & Make Report