I am using 64bit Windows 10 and have 8GB RAM.
I am using ONX_Model to write my plugin objects in 3dm file. The Write function returns false once the 3dm file reach ~2GB size. The error I am getting in the text log is this :
‘ONX_Model::Write archive.Write3dmObject(m_IDef_table) failed
ONX_Model::Write archive.EndWrite3dmObjectTable() failed’.
When I try to read the same incomplete 3dm file with ONX_Model::Read it fails. However if I open the 3dm file with Rhino it opens and gives me a message that some of the geometry is not readable, and upon choosing to skip the unreadable geometry the file is successfully opened in Rhino.
The question : is there limit on the size of 3dm archives that ONX_Model::Write can produce or that depends on the installed memory on the system.? Should I increase the memory in order to write files >2GB? And if there is such a limit why Rhino manages to open the 3dm file , while ONX_Model::Write fails.
Can I get some help with this please
Sorry for the delay. I’ve been out the past two week. There are no file size limitations in the current version of opennurbs. What version of opennurbs are you usng and are you using a 32-bit or 64-bit library?
I am using the openurbs that comes with the Rhino installation. When I start Rhino, with the program Process Explorer I can see that the loaded dll is opennurbsx64.dll. The dll is loaded from this path : C:\Program Files\Rhinoceros 5 (64-bit)\System.
The version of the loaded dll is 5.14.522.8390
Just to clarify, are you using the openNURBS, that comes with Rhino, from inside of a Rhino plug-in? Or are you trying to reference the DLL from an external application?
I am using the openNURBS that comes with Rhino from inside of a Rhino plugin.
Is it possible for you to provide some sample code that repeats the problem you are seeing?
Here is my test command. It takes maybe 7 min to execute on my laptop. The surface I select is simple plane with dimensions 32x16, but I think any similar will do. Once the archive hits 2GB size the Write method returns false.
go.SetGeometryFilter(CRhinoGetObject::surface_object | CRhinoGetObject::polysrf_object);
if (go.CommandResult() != CRhinoCommand::success)
// Validate selection for surface
const CRhinoObjRef& ref = go.Object(0);
const ON_Brep* srfBrep = ref.Brep();
FILE* archive_fp = ON::OpenFile(L"C:\\Users\\user\\Desktop\\testarchive.3dm", L"wb");
if (archive_fp == NULL)
RhinoMessageBox(L"File cant be opened", EnglishCommandName(), MB_OK);
const char* sStartSectionComment = __FILE__ "Session" __DATE__;
ON_BinaryFile archive(ON::write3dm, archive_fp);
for (int i = 0; i < 800000; i++)
ONX_Model_Object& object = model.m_object_table.AppendNew();
ON_Brep* dup = srfBrep->Duplicate();
object.m_object = dup;
bool result = model.Write(archive, /*rhinoversion*/5, sStartSectionComment, &error_log);
//result is false
I am able to repeat what you’ve reported. I’ve logged the bug.
Hi Dale thank you for your effort
When can I expect this bug to be fixed
Our priority right now is shipping Rhino 6. It is highly unlikely we will make any fixes to Rhino 5.
Have you trying using Rhino 6 and building plug-ins with the Rhino 6 C++ SDK?
I will try Rhino 6 soon. It will be great if this fix is included in Rhino 6.
RH-42943 is fixed in the latest BETA