Is there a way of creating scalars and points without having to delete them from the part after?
I am using 2 scalars to create a point on a face at a given u,v location to then create a point3d object.
scalar_u = workpart.Scalars.CreateScalar(params(0), Scalar.DimensionalityType.None, SmartObject.UpdateOption.WithinModeling) scalar_v = workpart.Scalars.CreateScalar(params(1), Scalar.DimensionalityType.None, SmartObject.UpdateOption.WithinModeling) point_uv = workpart.Points.CreatePoint(my_face, scalar_u, scalar_v, SmartObject.UpdateOption.WithinModeling) dim my_point3d as point3d my_point3d.X = point_uv.Coordinates.X my_point3d.y = point_uv.Coordinates.y my_point3d.z = point_uv.Coordinates.z
I hadn't originally realised that all of these scalars and points were actually real 'objects' that were left over in the part file after the code had been terminated and as such was leaving parts full of them.
I now add them to a list of objects to delete but was wondering if there was a way of creating them in such a way as to not leave an object behind in the part in the first place?
Is this what the SmartObject.UpdateOption DontUpdate is used for?
Alternatively is there a more efficient way of getting a point3d object or x,y,z coordinates from u,v coordinates of a given face?
You can call UF_MODL_ask_face_props(), or its wrapper method, if you only need the XYZ. (It will not provide a Point3d, but it also won't create any surprising stuff to hang around.) It takes the tag of the face, and two doubles representing U and V for inputs.
In addition to what Steve posted, you might find the UF_MODL_ask_face_uv_minmax function useful; it may help determine the boundaries of those seemingly "trimmed" surfaces that you have encountered.
I would not be too concerned about creating invisible smart objects (points, scalars, xforms, etc) in your files. NX will (or at least it should) clean up these "orphan" smart objects for you. From the .net_ref API document:
"Smart Objects are created as condemned objects by default. Condemned
objects exist only to be referenced by other objects. This is the
definition of "condemned". Thus condemned Smart Objects are automatically
deleted whenever the last reference to them is deleted. You may change
the state of a Smart Object from "condemned" to "alive" by setting it
visible using UF_SO_set_visibility_option."
So keep those points invisible and NX should do the housekeeping for you...
Thanks for your suggestion. I've already investigated EvaluateFace and AskFaceProps.
Both of these fail on particualr types of faces with constant radii. I've submitted an IR about this now. Due to this neither are adequate for my purposes.
On top of this as they are returning so much information I've also found they are less efficient than the scalar/point method. In my current project I'm calling them in the order of 10,000s of times.
Thanks for the UF_MODL_ask_face_uv_minmax. I'm going to try and have a look at this and see if I can understand what's going on with my particular case where u,v location isn't tying up.
with regards to:
"I would not be too concerned about creating invisible smart objects (points, scalars, xforms, etc) in your files. NX will (or at least it should) clean up these "orphan" smart objects for you."
From experieince (with the code I've used), this isn't the case with scalars and points. These objects can persist and have even crippled parts if they're not removed. Once again the projects I'm working on have the potential to create orders of 10,000s each time they are run.
This is probably down to the my code and I was wondering if the smartobject.updateoption had anything to do with it.
I'll do a little tinkering with the options tomorrow and check the scalar and point counts with ug_inspect.
If you are creating that many objects, you might want to occasionally run a part cleaup with the .DeleteUnusedObjects option set. As long as the objects are not referenced by other objects, NX should delete them. You'll have to experiment with how often to run the cleanup (after X number of objects are created/no longer needed) to get a good balance of speed and stability.
Alternatively, you might also try setting each object to Nothing when you no longer need it. NX may not clean any of the objects up if your code is still running with references to the objects.
To calculate (x,y,z) point location from given (u,v) values, I always use
ufs.Modl.EvaluateFace, or its SNAP equivalent, face.Position.
If you want blazing speed on b-surfaces, there is Snap.Geom.Surface.Bsurface.Position. This is about 20x faster than the functions mentioned above because it doesn't involve any NX database access at all -- it's just pure math code.
In geometry construction code, it's often not the math that takes the time, its NX doing Update (which you don't want and don't need until your construction is all finished). If you're a bit careful, you can temporarily turn of Update using NXOpen.Update.SetUpdateLock.
As cowski said, you really do need to use the UF_MODL_ask_face_uv_minmax function. And then make sure you don't use any (u,v) values that are outside the min/max limits that it gives you. The error in your other code (the curvature stuff) is probably due to using hard-coded (u,v) = (0.5,0.5) values. This is OK on b-surfaces, because their uv-limits are (almost) always [0,1] x [0,1]. But (u,v) = (0.5,0.5) often won't work on a blend surface.
Thanks for the pointer on U,V bounds.
I had believed that the 1 and 0 were in fact the max extents of the displayed surface. This helps me better understand what's going on. I'll be using the 'UF_MODL_ask_face_uv_minmax' a lot from now on
At what version of NX is 'Snap.Geom.Surface.Bsurface.Position' available? It's not a recognised function in 8.5.
Similarly I can't get face.Curvatures(u,v) to work either.
Once again thankyou for all your help
Just when you feel like you're getting somewhere....
I'm still finding face blend surfaces that are problematic.
When I try to use the UF_MODL_ask_face_uv_minmax function the output is 0,0,0,0
Which un-surprisingly isn't conducive to great input for the subsequent functions.
I can work around this but was wondering if there's anything obvious that might cause this?
Attached file has the failing faces highlighted red.
I ran a simple program to list uvminmax and obtained
-5.01389294665922E-16 , 0.00574093531690362 , 0 , 1
-6.96187898996392E-15 , 0.00769722596039073 , 0 , 1.00602489933698
1.38777878078145E-17 , 0.0091175429881334 , 0 , 1
0.0151730094533014 , 0.022155350685374 , 0 , 1
-1.33573707650214E-16 , 0.00933208385570667 , 0 , 1
-3.43908929112402E-16 , 0.00708504915150053 , 0 , 1
5.87158497163254E-08 , 0.0043207106763709 , 0 , 1
1.02961259310086E-15 , 0.00756682558458452 , 0 , 1
2.55004350968591E-16 , 0.00426680144786836 , 0 , 1
0.0335427305109318 , 0.0422090286369431 , 0 , 1
Note that the u limits is quite small. Are you doining any rounding?