Soften coplanar ?
-
Hi.
Is there anything like Sketchups native soften coplanar in the API ?
It would be convienient for when baking Polygonsmesh with triangualted faces.
-
Let's assume you have collected all of the potential edges... using something like:
edges=Sketchup.active_model.selection.grep(Sketchup::Edge)
or
edges=Sketchup.active_model.active_entitites.grep(Sketchup::Edge)
Then useedges.each{|e| # skip perimeters and non-coplananr next unless e.faces.length==2 && e.faces[0].normal==e.faces[1].normal e.soft=true e.smooth=true }
-
Thanks TIG! I'll try that.
Although I wished not having to loop Everything one more time
-
Works well if I add:
next unless e.faces.length==2 && e.faces[0].normal==e.faces[1].normal && e.faces[0].normal.reverse==e.faces[1].normal.reverse
Could be something messed up in my mesh, but face down faces at ORIGIN plane got ignored.
An API method might have been faster, but this will do well.
Thanks!
-
next unless e.faces.length==2 && e.faces[0].normal.parallel?(e.faces[1].normal)
Should trap for reversed faces too ? Works for me...
What's the rest of you code like {} ?? -
Yeah, that works for me too.
rest of code ? I'm just grepping edges after add_faces_from_mesh.
And then running the code you provided.Had to use add_faces_from_mesh not to get smoothed edges (?).
Strange.. Must have broken something cause did not have any problems with fill from mesh before. Need to laborate with the fill_from_mesh parameters..edit: must have removed the second parameter in fill_from_mesh( mesh, true, 0)
accidentially. now it works, and much faster!edges = bake_group.entities.grep(Sketchup;;Edge) for e in edges next unless e.faces.length==2 && e.faces[0].normal.parallel?(e.faces[1].normal) e.soft = true && e.smooth = true end
-
This gives a little more flexibility if put as options. Could be better written..
Bit dangerous deleting edges like that..edges = bake_group.entities.grep(Sketchup;;Edge) # Options for ex dialog delete_coplanar = true angle_a = 0.001 angle_b = 35 for e in edges next if e.deleted? next unless e.faces.length == 2 ang = e.faces[0].normal.angle_between(e.faces[1].normal) case ang when delete_coplanar && 0.degrees e.erase! next when [angle_a, 0.0001].max.degrees...angle_b.degrees e.soft=true && e.smooth=true when ang > angle_b.degrees #e.material = "red" #debug! e.soft=false && e.smooth=false end end
-
Checking the normal isn't going to give correct result in all cases. You'd need to check if all the points of the faces all lie on the same plane.
-
The polygonmesh class is really a piece of art filled with mysterious behavior.
Dug up this old thread:
It does not seam to be accurate what says there.
I'm using Thomthoms example for hidding edges with negative index values.
Creating a Group and adding entities with add_faces_from_mesh or fill from mesh.Following that example mesh.add_polygon(1,-2,3) etc. Using positive values VS negative values has no effect.
No smooth_flags argument sets default to (12 ?)
So using mesh.add_polygon(1,2,3) gives same result as mesh.add_polygon(1,-2,3)Am I missing something ? There's no follow up in that thread stating what I'm experiencing here..
-
Yeah, I noticed some "irregularities" during some tests. This won't cover all scenarious, and to add many validychecks on top of fill from mesh would be to compute intensensive when dealing with plenty of geometry.
Since TIG is not a "mindreader" ( or is he ), I probably should have mentioned that the motif for creating this method is to try to restore a polygonsmesh to it's true geometry when baking. And the true meaning faces from a Component or Group.
Unfortunately if having faces with holes they don't come out well when baking the mesh unless I triangulate the faces. And since I probably will do something to the Mesh, the original face-Component cannot be used as a reference for removing holes after an intersection. At the moment I'm only triangulating faces with 5 or more vertices..
A face with a hole have minimum 6 vertices (?)edit: removed some irrelevant...
-
Yes, I recently discovered what was really going on here. We have updated docs pending for release.
Entities.fill_from_mesh:
- The weld_vertices has no effect. This is because the PolygonMesh merge points as well.
add_faces_from_mesh & fill_faces_from_mesh - smooth_flags:
This is a bit flag composed of these flags:0 No smoothing
1 Negative point index will hide the edge.
2 Negative point index will soften the edge.
4 Interior edges are softened. (Ignores the sign of the index)
8 All soft edges will also be smooth.Default value is
4 | 8
(12)So if you want to create a mesh where you control the smoothing of each edge:
2 | 8
entities.fill_faces_from_mesh(mesh, true, 2 | 8)
The current docs are just plain wrong. We'll probably introduce constants for these values in the future - to avoid developers using magic numbers.
-
@unknownuser said:
We have updated docs pending for release.
That's awesome news!
@unknownuser said:
entities.fill_faces_from_mesh(mesh, true, 2 |
Right. Will try that.
I persume you mean one can choose between 2 or 8, not apply expression in argument?
-
fill_faces_from_mesh ? Typo ?
-
2 | 8
Expression it is! Yei! It works. -
|
is theInteger
BITWISE OR operator (really method name.)
Both subclasses (Fixnum
&Bignum
) have this method.
see:
http://www.ruby-doc.org/core-1.8.6/Fixnum.html#method-i-7C -
Also there are many API methods that allow bit mask Integer arguments, where you can combine different bit flags using
**|**
.Some are not documented, like the 2nd arg to
UI.messagebox
can also (in addition to the button flag,) be OR'd with an icon integer flag that sets which standard icon (or none,) is displayed in the messagebox. -
ahh, nice info. I've used bitwise in JavaScript ( for performance reason ). Good to know they work in Ruby as well.
@unknownuser said:
Some are not documented, like the 2nd arg to UI.messagebox can also (in addition to the button flag,) be OR'd with an icon integer flag that sets which standard icon (or none,) is displayed in the messagebox.
How the heck do you guys know all this ?
Must spend a lot of time experimenting outside the docs.. -
Heh! Docs? The docs where in a very poor state five/size years ago. Poking about was the way to go.
(Not saying that the docs now are "good" or anything though... ...just that they where a lot worse.) -
@jolran said:
fill_faces_from_mesh ? Typo ?
Yes - should be "fill_from_mesh". Just love the consistency of the Ruby API naming...
-
@unknownuser said:
Yes - should be "fill_from_mesh". Just love the consistency of the Ruby API naming...
I had to ask, thought there where some new hidden stuff
Advertisement