Conversion of a .3dm file with a simple sphere into a geomdl-compatible .json fails about rw3dm

[orbingol]

Thank you @akfhr for the bug report.

This problem seems like wrong processing of control points during import operation. The control points can be stored in 2 ways: P or Pw where P is a list of (x, y, z) and Pw is a list of (x * w, y * w, z * w, w). I think rw3dm currently exporting the control points as (x * w, y *w, z* w) and this is incorrect.

As a temporary fix, you can try to get the control points and weights list separately, divide control points by weights and set the updated control points. It will be fixed in the next rw3dm release.

[akfhr]

Dear Onur,

that was it! Thanks! :)

BTW: geomdl, rw3dm, both great!

[orbingol]

does it mean that the next version will export the coordinates of control points and its weights separately?

This issue will be fixed in the next minor version release, e.g. v2.0.3. Next major version release will support geomdl v6 and will definitely include the fix for the bug discussed in this issue.

[Batmanabcdefg]

does it mean that the next version will export the coordinates of control points and its weights separately?

[Batmanabcdefg]

@orbingol

do you mean that we have to add a new varible to save weights-values in the following code , and save it in data[...]?
Cite

        // Check if the NURBS surface is rational
        if (nurbsSurface.IsRational())
        {
            Json::Value weights;
            // Get weights
            for (int idxU = 0; idxU < sizeU; idxU++)
            {
                for (int idxV = 0; idxV < sizeV; idxV++)
                {
                    unsigned int idx = idxV + (idxU * sizeV);
                    weights[idx] = nurbsSurface.Weight(idxU, idxV);
                }
            }
            controlPoints["weights"] = weights;
        }
        data["size_u"] = sizeU;
        data["size_v"] = sizeV;
        data["control_points"] = controlPoints;

[orbingol]

@OVGULIU no need to change anything on the C++ side. You can fix it on the Python side. Please refer to #8 (comment) for more details.

[akfhr]

I have another question regarding the control point weighting.
For untrimmed surfaces, like the sphere in the above example, your proposed fix seems to work fine.

Now I want to export from rhino a trimmed surface, e.g., the top and bottom surface of the attached cylinder. The result looks like this:

The issue seems to be the trim curve which is not imported properly. Without any modification, the imported trim curve that trims the top surface looks like this:

A simple rescale, as done before with the surface of the sphere, doesn't seem to do the job:
trim.ctrlpts = [[cy/trim.weights[cIdx] for cy in cx] for cIdx,cx in enumerate(trim.ctrlpts)]

Apparently the curve control points are scaled plus offset somehow during import. What can I do in this case? Is there a need to touch the cpp code?

Once more, thanks for your time and help.

[Batmanabcdefg]

Hello @akfhr may I ask, how can we check/know that rw3dm read/import Rhino file (.3dm) correctly?

PS. @orbingol .:)

[orbingol]

Exporting trim curves is a tricky business. It has been some time but what I remember is since everything is stored in a BRep data structure, I was unable to find a way to distinguish between the loops and the trim curves. @akfhr the curve you are showing is actually a loop corresponding to the circular edge of the surface. I believe there should be a way to identify which curve is which but it clearly needs more experimentation.

Importing trim curves is more than a tricky business as OpenNURBS seems to have some issues with it (e.g. non-existent API calls, very limited documentation, representation of the trim curves in the data structure and goes on like that). It has been some time, though. I need to check it with the latest version of OpenNURBS.

[orbingol]

@OVGULIU the command-line apps should display some messages in case of an error. They might not be that clear, though. Are you having some problems with import/export?

[Batmanabcdefg]

@orbingol for example, we have a (very) complex cad part that is created in Rhino, firstly we have to convert it to the input file for geomdl, therefore we may ask, can rw3dm export Rhino file (.3dm) correctly? is "geomdl" the single way that we can check for it?

[orbingol]

@OVGULIU rw3dm is designed to export in the format that geomdl could understand (and it is also well documented, so any software that can parse JSON can understand it too). What rw3dm does is extraction of surfaces and curves from the model file using a for-loop. By means of the extraction process, it should be correct as much as possible considering the variables that needs to be extracted. It doesn't matter how complex your model is.

If you think of the representational correctness, i.e. the correctness of the CAD model, that depends on so many factors; including the delta value that was used to compute the geometric operations. Then, the complexity of the model can raise issues with the representational compatibility and the capability of the modeling engine. It is very much like the difference between IGES and STEP formats. I don't think this is directly related to geomdl as NURBS is generally considered as the direct representation of the models.

If you think from the perspective of the software development, then you should expect to see some tests, e.g. unit tests, system tests, etc. I was able to figure out some tests for geomdl itself, but I don't think I would be able to cover all possible cases for an exporter/importer application. I am willing to add some tests, though.

[orbingol]

Fixed on v2.0.3