[v8i MDL] Scale problem

Unknown said:

Model is broken in MDL

Please elaborate.

Unknown said:

Please elaborate.

Original model looks like this;

Scaled model look like this;

Scale operation distorts original model.

Unknown said:

What 'scale operation' are you using?  How do you construct your scaling transform?  How do you apply that transform to the object?  It's hard to diagnose 'model is broken in MDL' with no evidence.

Your post title mentions MDL, but you haven't shown us any code.

It looks like this;

double xScale,yScale,zScale;
ProductInfo pinfo;
Transform tMatrix;

// Calculate scale for each dimension
xScale = width/pinfo.byt_x;
yScale = depth/pinfo.byt_y;
zScale = height/pinfo.byt_z;

// scale cell
mdlTMatrix_scale(&tMatrix,NULL,xScale,yScale,zScale);
mdlElmdscr_transform(edP,&tMatrix);

Unknown said:

mdlTMatrix_scale(&tMatrix,NULL,xScale,yScale,zScale);

I don't know whether it's valid to apply that function to an uninitialised transform.  To be on the safe side, try this …

Transform t;
mdlTMatrix_getIdentity (&t);
mdlTMatrix_scale (&t, &t, xScale, yScale, zScale);

Unknown said:

I don't know whether it's valid to apply that function to an uninitialised transform.  To be on the safe side, try this …

Transform t;
mdlTMatrix_getIdentity (&t);
mdlTMatrix_scale (&t, &t, xScale, yScale, zScale);

Beside c) ;-)

b) makes no sense, mdlTMatrix_scale changes a transformation matrix, not a cell. mdlElmdscr_transform does the transformation. I've transformed some millions of nested cells, and never failed, so this should work.

a) maybe, have you checked the coordinate system settings, especially those for the smartsolids ? Maybe you'r running out of the volume modeller (parasolid) coordinate range.

f) if not a) than this looks to me like you are transforming only the first element of the chain of elements, that the cell is made of. How do you retrieve this edp, you shown in your code ?!

Michael

Michael Stark said:

b) makes no sense, mdlTMatrix_scale changes a transformation matrix, not a cell. mdlElmdscr_transform does the transformation. I've transformed some millions of nested cells, and never failed, so this should work.

You are right about mdlElmdscr_transform. :) I hope, it is working fine too. :)

Michael Stark said:

a) maybe, have you checked the coordinate system settings, especially those for the smartsolids ? Maybe you'r running out of the volume modeller (parasolid) coordinate range.

Very good point but everything are fine.

Michael Stark said:

f) if not a) than this looks to me like you are transforming only the first element of the chain of elements, that the cell is made of. How do you retrieve this edp, you shown in your code ?!

I am using mdlElmdcsr_transform for the whole cell at once.

Thanks.

Unknown said:

As far as I know if IN matrix is NULL then identity matrix is taken

Yes, but we don't know.  The documentation doesn't tell us the default behaviour.  What do you lose by writing the extra line?

Unknown said:

Yes, but we don't know.  The documentation doesn't tell us the default behaviour.  What do you lose by writing the extra line?

You are right, thanks. :)

It looks like you are applying a non-uniform scale in x (which strikes me as odd as your handle will no longer be round after this scale is applied?!?).

You have a smart solid that was created using "surface" representation...which is a hold over from the V7 days where Parasolid was an optional install and you wanted to be able to give the file to someone without Parasolid and still allow them to render it and see surfaces.

The surface representation SmartSolid is a problem for mdlElmdscr_transform with a non-uniform scale as this function can't allow elements to change size (input is a MSElementDescrP instead of an MSElementDescrH). In order to apply a non-uniform scale to a Type 18 surface of revolution, it has to be converted into a bspline surface as the non-uniform scale isn't directly supported for the Type 18. Since the type change would change the size of the element which is disallowed, it can't fully apply the transform to the element.

Try using mdlElmdscr_transformAllowModification instead (just pass the same DgnModelRef for the source/destination and see if this makes difference in the result.

HTH

-B

NOTE: The above is just speculation based on what I observed in your post-scale dgn, I didn't verify that this is was is actually happening. MicroStation's scale tool calls DisplayHandler::ApplyTransform and specifies that element size changes are allowed.

Unknown said:

Try using mdlElmdscr_transformAllowModification instead (just pass the same DgnModelRef for the source/destination and see if this makes difference in the result.

Thank you so much Brien and other people that tried to help.

mdlElmdscr_transformAllowModification made the difference and scaled properly as MicroStation do.

After scale, there are some little problems on the model but they don't affect rendering it.

> After scale, there are some little problems on the model but they don't affect rendering it.

SS3 doesn't display silhouettes in wireframe (except for cones). What you are looking at are the u/v rules created for the bspline surfaces that were the result of applying the non-uniform x scale to the cones and surfaces of revolution. If you don't mind editing your handle solid you can have a more consistent wireframe display.

Open the handle model, verify that the "Display Mode" option on the Element->3D and B-splines dialog is set to "Wireframe" (which it is currently for the Handle.cel you posted). Run the "Convert Brep" key-in and select your solid.

Attached image shows the difference, left red shows surface representation solid after scaling, left green shows wireframe representation:

HTH

-B

> After scale, there are some little problems on the model but they don't affect rendering it.

SS3 doesn't display silhouettes in wireframe (except for cones). What you are looking at are the u/v rules created for the bspline surfaces that were the result of applying the non-uniform x scale to the cones and surfaces of revolution. If you don't mind editing your handle solid you can have a more consistent wireframe display.

Open the handle model, verify that the "Display Mode" option on the Element->3D and B-splines dialog is set to "Wireframe" (which it is currently for the Handle.cel you posted). Run the "Convert Brep" key-in and select your solid.

Attached image shows the difference, left red shows surface representation solid after scaling, left green shows wireframe representation:

HTH

-B

Unknown said:

Open the handle model, verify that the "Display Mode" option on the Element->3D and B-splines dialog is set to "Wireframe" (which it is currently for the Handle.cel you posted). Run the "Convert Brep" key-in and select your solid.

Thank you Brien, this is excellent!

What does Convert Brep do actually?

Does it make any difference in 3D model during rendering?

Unknown said:

What does Convert Brep do actually?

Does it make any difference in 3D model during rendering?

Unknown said:

Convert Brep is basically doing an element->body->element round-trip. So when you pick an existing smart solid, it's effectively just updating the wireframe geometry (stored as cell components) using the current active settings. There's a change smartsolid display tool somewhere that accomplishes the same thing, but I always use the key-in.

No, it doesn't make a difference for rendering. The cell components are only used for wireframe display (and snapping), all other display modes output facets that come directly from the Parasolid (or ACIS) brep data. HTH