This was an issue I raised a long time ago, and I thought it had been fixed in vbRhinoscript, but I see not (or the fix has been backed out again):
ObjectsByType(8) (surfaces) does not get single-surface extrusion objects
ObjectsByType(16) (polysurfaces) does not get multi-surface extrusion objects
Type 1073741824 extrusion can be added to the list to force this, but it should not be necessary, IMO
Python rhinoscriptsyntax only:
Type 1073741824 extrusion is not included in the Python rhinoscriptsyntax Help for ObjectsByType
rs.IsExtrusion() method does not exist.
Things like rs.IsObjectSolid() fail for extrusion objects -
looks like they simply did not get added in object.py in this case, there may be others as well…
The problem is that Extrusions are not being considered as BReps. This means they are not “transparent”.
Extrusions are not Breps. But, Rhino can create Breps from Extrusions on-the-fly. Thus, commands that expect Breps can use Extrusions “transparently.”
With this said, I don’t have a problem modifying the ObjectsByType method to return both multi-faced Breps and Extrusions if the intType=16 code is provided. In doing this automatically, if the scripter only really wanted Breps, they would have to run a secondary IsBrep/IsExtrusion test to get the desired result.
As it stands now, you only need to specify both types in your filter, which provides the most flexibility.
GetObject() and GetObjects() with type 16 filter allow selection of extrusions…
Also as discussed long, long ago when extrusions were introduced, as Rhino produces them by default, their non-inclusion in something like objects by type has the potential to invalidate older scripts which attempt to find polysurface objects with filter 16.
Same problem here. Just recently ran into it. RS lets users pick extrusions as surfaces but then fails to perform surface-related methods on them.
I feel like this should be handled under the hood of RS (just like in Rhino itself) so extrusions can behave like surfaces/polysurfaces when used with script methods that require it; does it mean converting them temporarily or permanently - I don’t know… But this inconsistency indeed causes older scripts to fail a lot with the way extrusions are handled currently.
I’ve updated the ObjectsByType method to work more like GetObject and GetObjects. The updated will be available in SR7.
Jarek, if you have found RhinoScript methods that work in surfaces or polysurface but not on extrusions, let me know what the methods are and how I can repeat the problem. – Thanks.
Dale - so far I can confirm that Rhino.ExtractIsoCurve doesn’t work with Extrusion object types.
Surface-like extrusion objects are selectable with the 8 flag (surfaces) yet are unable to result in isocurves with that method. Ideally we would get resulting isocurves as if the Extrusion was converted into surface. What do you think?
I will let you know if I stumble across more methods with that problem.
Dale - and a new RS Wish: Rhino.ConvertExtrusion method, a more elegant equivalent of using Command.
Now the extrusions are causing more trouble in older scripts - I need to convert them to regular objects upfront - it’s very hard to track all that can go wrong with this object addition. For example: GetObject flag 8 and 16 still accepts extrusion, but then down the road I can’t use Rhino.ObjectType to determine if the object is a extrusion_single-surface-like or extrusion_polysurface-like; I can only determine if it is extrusion. I think there are workarounds to that like exploding them and testing out the result, but I’d rather just convert them for now.
Nope, doesn’t appear to have been added… You can use this as a workaround for now:
import rhinoscriptsyntax as rs
def IsExtrusion(objID):
return rs.ObjectType(obj)==1073741824
#test
obj=rs.GetObject()
if IsExtrusion(obj):
print "Object is an extrusion"
else:
print "Object is not an extrusion"