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
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.

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
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
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?
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 ![]()
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 ![]()
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 ![]()
Now you need to do the same for the las.rcip for @vaidas ![]()
Hi @martin.graner,
I'm glad the binary worked well for you (and best of luck for Intergeo, whatever that is)! ![]()
As for your further queries, here are my answers:
Hope that helps!
Thanks,
Ben.
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)!
As for your further queries, here are my answers:
- 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?
- 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.
Kind regards
Martin
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.
@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?
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!
Can't find what you're looking for? Ask the community or share your knowledge.
