Face.classify_point - compare results?
-
You can use the WayBack Machine to see the older versions of the docs:
http://waybackmachine.org/*/http://code.google.com/apis/sketchup/docs/ourdoc/face.html#classify_pointI had basically no info....
Not sure where I got the bitwise comparison from...
-
The current API lists 6 Constants [Brad has 7] BUT the .constants method returns 7 that aren't the same as Brad's 7 so something is wrong soemwhere?? aaargh!
My post http://forums.sketchucation.com/viewtopic.php?p=316191#p316191 list what I think might be right [today at least ] ??? -
Cheers TheDro
-
TheDro
Thanks, could you perhaps publish a definitive list in the Face API note explaining which is what and that there is [possibly] an obsolete constant too... Comparing and contrasting with the current text and the Brad's follow up notes too... -
Alright, let's try to put this one to rest
. I just tested it with a face on the xy plane with a hole in it and here are the results(and code):puts "On Face(Inside); " + face.classify_point([0.25,0.25,0]).to_s #1 puts "On Vertex; " + face.classify_point([0,0,0]).to_s #2 puts "On Edge; " + face.classify_point([0.25,0,0]).to_s #4 puts "Outside; " + face.classify_point([-0.5,0,0]).to_s #16 puts "In Hole; " + face.classify_point([0.6,0.6,0]).to_s #16 puts "NotOnPlane; " + face.classify_point([0,0,1]).to_s #32So this means that whether the point is in a hole or outside the face, the return value is the same (16). I think that answers TIG's question about the matter. The OnFace constant (which is
is not in the API nor am I able to choose a point that returns the value. It could therefore be obsolete. If someone can think of another case that I missed, let me know (other than an error (0) of course).Oh and just a quick note. The return value of the classify_point method will be one of the above values and NOT a sum of multiple values. I mention this because I expected a point on an vertex to return 6 or 7 because a point on a vertex is on the face and an edge at the same time, but this is not the case.
As for how I'll write my code, well there are two ways of doing and I think this would be the shortest way (syntactically) of doing it:
if (face.classify_point(point)&(Sketchup;;Face;;PointInside+Sketchup;;Face;;PointOnVertex+Sketchup;;Face;;PointOnEdge))!=0As long as those constants remain powers of 2, the code should work although to be safe I might just go with if((p==a) or (p==b) or (p==c)), which doesn't require any bitwise operations (I just find the bitwise way of doing cool since I've come to understand it recently
).EDIT:
As requested, here is the definitive list of the constants:0: Sketchup::Face::PointUnknown (error)
1: Sketchup::Face::PointInside (somewhere on the face)
2: Skethcup::Face::PointOnVertex (on one of the vertices of the face)
4: Skethcup::Face::PointOnEdge (on one of the edges of the face, vertices do not count since they return 2)
8: Sketchup::Face::PointOnFace (likely obsolete)
16:Sketchup::Face::PointOutside (on plane of the face but not on face; this includes holes)
32:Sketchup::Face::PointNotOnPlane (not on the face's plane)Remember that this is for version 8.0 and that the constants should be used instead of the numerical values for forward compatibility.
-
TheDro has edited the list provided a few posts back with 'all know data'...
Unexpectedly it agrees exactly with the list in the main API -[except for that omitting '8 PointOnFace' as it is obsolete anyway - why is it in the constants still ? Have Google just forgotten to remove it ?]
Brad's list in the API notes is therefore wrong [probably].
I've suggested to TheDro to add another note to the API docs to state what seems to be the correct situation with v8M1 -
I digged in my emails - here's a quote from a Googler:
@unknownuser said:
Here is a comment from our defect database about this issue
"..I learned that the Sketchup::Face::PointOnFace constant is never used, so I just removed it from the docs.."
-
Out of interest I wrote this snippet
Sketchup.constants.sort.each{|e|puts e;eval("Sketchup::"+e+".constants").each{|c|puts "\t"+c};puts}
which prints out all Sketchup 'constants' - as this on my system at least [e.g. I expect Geodesic is an extra type added by a script...] There aren't that many 'constants' found this way...AppObserver ArcCurve AttributeDictionaries AttributeDictionary Behavior Camera Color ComponentDefinition ComponentInstance Console ConstructionLine ConstructionPoint Curve DefinitionList DefinitionObserver DefinitionsObserver Drawingelement Edge EdgeUse Entities EntitiesObserver Entity EntityObserver Face PointOutside PointInside PointOnFace PointUnknown PointOnEdge PointNotOnPlane PointOnVertex Geodesic TETRA_S SQRT2 PRIMITIVES TETRA_R GOLDEN_MEAN TETRA_Q TETRA_T SQRT3 Group HLR Image Importer ImportFail ImportFileNotFound ImportSuccess ImporterNotFound ImportCanceled InputPoint InstanceObserver Layer Layers LayersObserver Loop Material Materials MaterialsObserver Menu Model ModelObserver OptionsManager OptionsProvider OptionsProviderObserver Page Pages UnitsPixels ImageLinked UnitsNormalizedY ImageEmbeddedAndLinked UnitsNormalizedX ImageEmbedded PagesObserver PickHelper RenderingOptions ROPAssign ROPSetDisplayInstanceAxes ROPSetFogHint ROPSetDisplaySketchAxes ROPSetGroundColor ROPSetExtendEdges ROPSetLineExtension ROPSetDepthQueWidth ROPSetSectionDefaultCutColor ROPSetFogUseBkColor ROPSetTexture ROPSetHighlightColor ROPEditComponent ROPSetModelTransparency ROPSetDrawUnderground ROPSetFaceColorMode ROPSetFogDist ROPSetLockedColor ROPSetSkyColor ROPSetJitterEdges ROPSetExtendLines ROPSetLineEndEdges ROPSetSectionInactiveColor ROPSetDisplayDims ROPSetTransparencyObsolete ROPSetForegroundColor ROPDrawHidden ROPSetEdgeType ROPSetDrawGround ROPSetProfileWidth ROPSetFogColor ROPSetProfilesOnlyEdges ROPSetHideConstructionGeometry ROPSetEdgeColorMode ROPSetDisplayColorByLayer ROPSetDepthQueEdges ROPSetSectionActiveColor ROPSetDisplayText ROPSetRenderMode ROPSetBackgroundColor ROPSetSectionDisplayMode ROPSetFaceColor ROPSetDrawHorizon ROPSetProfileEdges ROPSetDisplayFog ROPSetLineEndWidth ROPSetSectionCutWidth ROPSetEdgeDisplayMode ROPSetConstructionColor ROPTransparencySortMethod ROPSetMaterialTransparency ROPSetGroundTransparency RenderingOptionsObserver SectionPlane Selection SelectionObserver ShadowInfo ShadowInfoObserver Style Styles Text Texture TextureWriter Tools ToolsObserver UVHelper Vertex View ViewObserver ["AppObserver", "ArcCurve", "AttributeDictionaries", "AttributeDictionary", "Behavior", "Camera", "Color", "ComponentDefinition", "ComponentInstance", "Console", "ConstructionLine", "ConstructionPoint", "Curve", "DefinitionList", "DefinitionObserver", "DefinitionsObserver", "Drawingelement", "Edge", "EdgeUse", "Entities", "EntitiesObserver", "Entity", "EntityObserver", "Face", "Geodesic", "Group", "HLR", "Image", "Importer", "InputPoint", "InstanceObserver", "Layer", "Layers", "LayersObserver", "Loop", "Material", "Materials", "MaterialsObserver", "Menu", "Model", "ModelObserver", "OptionsManager", "OptionsProvider", "OptionsProviderObserver", "Page", "Pages", "PagesObserver", "PickHelper", "RenderingOptions", "RenderingOptionsObserver", "SectionPlane", "Selection", "SelectionObserver", "ShadowInfo", "ShadowInfoObserver", "Style", "Styles", "Text", "Texture", "TextureWriter", "Tools", "ToolsObserver", "UVHelper", "Vertex", "View", "ViewObserver"] -
RenderingOptionsgot contants!!
One can actually use constants - that refer to integers (I assume indexes) to refer to options. That should be more efficient than strings.
-
@thomthom said:
RenderingOptionsgot contants!!
One can actually use constants - that refer to integers (I assume indexes) to refer to options. That should be more efficient than strings.Yes it's weird ?
I can't really see what half of these do... -
hm... yea - the names are odd. Might just be internal constants. Which would explain why they are not documented.
-
Alright so I posted my results on the api but is it possible to edit it in case there is a mistake?(not that I've found one) Oh and it's posted as anonymous.... whatever.
Advertisement