[Plugin] Hatchfaces (v1.8 beta) UPDATED 15-Dec-2012
-
Excellent TIG!
So far so good! Havent failed yet. Works in off axis, strange rotations etc.
Needs some more testing of course, but THANK YOU! THANK YOU!
Things can probably move forward now.Oh Yeah, and the code is much more streamlined, as you call it.
-
Hello Jolran,
First of all; thanks again a million for your effort and to those who are helping you! It's a much much welcomed addition to Sketchup! I can't wait to test it out!
I think your Photoshop dialog already has all the options we could want. Maybe you could add a target layer-option for the hatches? The visual webdailog of course would be the most user-friendly but I wouldn't mind the non-visual dialog. You could always print out the patterns + names on a sheet of paper instead.
@jolran said:
Got the tiling going pretty nicely. (Not from file yet) It's quite slow if having complex patterns.
I wouldn't be too much concerned with the performance. The time for the calculation of hatches will be much less compared to having to draw them yourself by hand! The plugin itself always be a great time-saver and will save us from dull repetitive work.
Greetings,
Max
-
Hi Kaas!
Finaly someone answered
@unknownuser said:
Maybe you could add a target layer-option for the hatches?
That should be possible. You do mean put the hatch in a layer already existing in the model?
Anyway I think layers are pretty flexible to work with.@unknownuser said:
You could always print out the patterns + names on a sheet of paper instead.
That is a good solution, if going for inputboxes. I guess file browser is also possible, like TIG's 2d tools hatches.
Thank you for the inputs, and please don't hesitate to add more requests.
-
@jolran said:
You do mean put the hatch in a layer already existing in the model?
Yes. Most people will work with a template file which already contains standard layers, styles, scenes etc. I guess there is no need to over-complicate the code at this stage for adding new layers on the fly.
-
@unknownuser said:
I guess there is no need to over-complicate the code at this stage for adding new layers on the fly.
I don't swear by it, but it should be relatively straightforward to get a list of layers pop up in the inputbox.
I think it is a good idea you have, otherwise ALL hatches will end up into 1 layer unless moved manualy.
Putting "hatchlayer" as default in inputbox means one won't have to select layers if happy with that layer.I put this on the todo list
-
Good evening.
Things are moving forward, but have been hooked on webdialogs and speed performance lately.
All in all, all features I can think of is implemented. Loading from file and tiling with some options to it, is ok.(not from some dialog, in script)
The "tech" part:
Some sort of dialog has to be made. I'm thinking webdialog, but quite scared of diving into that part actually
But it will be difficult using dropdownlist with a long list. And I don't know if a list can be updated automatically if user add new components
I guess UI.openpanel can only be used for images?Also performance is an issue.. Things can get quite slow sometimes, maybe to slow..
The plugin tiles the group in 1 direction inside group1. Then it copies group1 in the cross direction.
Copying groups are fast. Exploding and intersections is slow. I don't know if there is any way to speed up thoose things.
Is there any way to copy and tile entities collection without using groupsHave also been experimenting with textures+lines combinations to "get away" with less geometry, but the result is less then satisfactory. Look pics:
More artistic questions arise, what is needed from hatches anyway?
Have been looking for ISO standards but can't find information regarding exact size of patterns. If you look at Doublecad for ex. When creating a hatch, the sizes of pattern often need to be adjusted. So what is the scaling standards? This could be of importance regarding speed. Cause, the bigger patter=less geometry >> speed increase.Any tips would be welcome.
-
If you go down the texture route then my 2dTools '2dHatching' already does much of this [without scaling etc]... with a fairly comprehensive list of tileable .PATT clone .jpg files...
-
Yeah, thanks. I have been looking at your plugin, TIG. There is no point in reinventing the wheel that's rolling well, so I will go the "line hatching" way. If it wasen't clear, I'm not convinced textures are good enough for CD's. Inconsistency in line widths..
So far as I can see, 2dtools imports a jpg texture, while hatchfaces will be working with skp.files.
And if I understand API docs right, you can only use images for UI:openpanel.The strategy I'm having is to have 1 color method for linehatching and another non-color method.
Non color method will be standard-mode, and it's there where I aim to increase speed somehow.
Plan A is to find a solution to create all edges inside 1 group without the need for exploding, then use face-classify to remove unwanted edges.Plan B is create groups, intersect with face-clone(gents) and remove unwanted edges with face-classify points. That way there is no need to explode large amounts of groups. But intersection can be quite slow...
Plan A need some thinking, and there is quite a lot of unnecessary geometry created as well. A big square, size of diagonal to compensate for rotations around center...
It's difficult to do rotations prior to tiling. Unless doing zick-zack copying -
UI.openpanel(title,folder,type)simply opens a file-browser, starting in the given folder and returns the selected file [if any] - so you could access whatever file-type[s] you want. The API example is simply showing one method..,My '2dHatching' happens to use jpg files that are kept in a special subfolder - it then uses the one of them that's been selected as the texture for a [new] material that's then applied to any picked face. It just so happens that I had all of the typical CAD PATTs as tileable jpg files! IF I had had them as tileable SKPs I would have simply changed my code to suit that file-type...
Idea...
You know thebb=face.boundsand from thatcent=bb.centeranddiag=bb.diagonal
Make your hatching group in the face.parent.entities, at the 'origin', laid flat.
Its center at the origin.
Draw you hatching from min to max based on the diag/2 used to offset points in x/y.
Now you have a load of lines in a group that will always exceed the bounds of the face is overlaid on it.
The group is not yet aligned with the face.plane.
Transform the group axes
group.transform!(Geom::Transformation.new(ORIGIN, face.normal))
Now the group's plane parallel to the face.plane
Move the group
group.transform!(Geom::Transformation.new(cent)).
Now the group is located with the same center as the face.
You now need the quickest way to trim your hatching to the face's loops...
Use intersect_with() on the group.entities and the face.edges+[face] this should then split all of the groups edges as the cross the face's perimeter edges.
Now iterate through the edges in the group and inspect them.
Useface.point_classify(mid)on the mid-point of every edge [we already have code for finding this from earlier exchanges].
As all edges have already been split by the intersection with face's perimeter edges only those that are on the face are to be kept - all others are then collected and erased en mass after the inspection.
So now we should have a group overlaying the face with its hatching lines all trimmed to the perimeter of the face, including any 'holes'.
No exploding or cloning required...Next... IF you want the hatching to have a 'perimeter' you can replicate the face.edges within the group.entities, transforming each edges vertices to match the group.transformation.inverse ?
IF you then want that perimeter to be split at every meeting with a hatching line then you can intersect_with() the group.entities with group.entities.to_a [you may find you need to do this more than once to ensure all are fully split?]. I can see little advantage in adding this??Optionally Exploding the group over the face will merge the edges with the then split face
I can't see why you'd want faces for the hatching inside the group... BUT if you do then you can clone the face inside the group and intersect the group.entities with the cloned_face....
For cross-hatching simply do the hatching twice and then group the two hatching groups into one ?
-
@jolran said:
Things can get quite slow sometimes, maybe too slow..
More artistic questions arise, what is needed from hatches anyway?
... This could be of importance regarding speed. Cause, the bigger patter=less geometry >> speed increase.Any tips would be welcome.
I can only speak for myself but I'm very interested in this plugin regardless of any speed issue. At the moment I draw the hatches in SU by hand. I can't imagine your plugin would be slower than doing this 'boring' process by hand.
As long as people can edit the hatch-SU-files themselves as well they can choose to use hi-res hatches or low-res and by doing so control the speed and add a personal style.
Going into the path of using textures as hatches would be a pity because people sometimes have to export LO files to dxf/dwg for use by other contractors who use Autocad etc. Hatched lines would convert into cad-lines. Textures would not.
Greetings and
,Max
-
@unknownuser said:
UI.openpanel(title,folder,type) simply opens a file-browser, starting in the given folder and returns the selected file [if any] - so you could access whatever file-type[s] you want. The API example is simply showing one method..,
Thats good to know when dealing with dialogs later on.
Regarding your idea, I will have a look at that, TIG. I'm not sure I'm quite following what you mean. I am using skp.component patterns loaded from file and place them on the face and do the tiling on required up/down vectors. Based on face diagonal length.
Anyway I will reread you idea to see more clearly what you mean. Thanks TIG.
Max. Thanks for giving feedback
I'm not going the texture way, so don't worry about that. The oportunity to be able to export the line geometry is what I had in mind as well. But mostly, it gives better and more predictable results when printing.
Also I won't experiment with performance(I hope)for to long. We are dealing with creating 2d-3d-geometry and not vectorgraphics, so that has to be taken in consideration for this plugin. -
Hmm.. reading my post again I think I wasent clear about how the plugin works at the moment, so here is a more illustrated explanation.
It looks like you where giving advice about linehatches, before TIG? I think we have that one working already.
Now it's pattern-time.Been looking at sin and cos
for calculating rotations and how relations of borders behave when tiling rotated geometry. To be able to copy less geometry.
Not an easy task. Also can't figure out a way to get length and width of face anyway so I will know how many copies to be made.Bounds.diagonal and center is good and consistent mesures. But NOT bounds.width or height, even if it's a face=2d bounds! It will still mesure from a 3d boundingbox compared to axes. So if the face is tilted youre scr@w@d..
Here's how it works at the moment anyway. Just the tiling. After tilings done. One can use proper method of intersecting and
remowing unwanted edges. Have tried different methods of those..
-
I was speaking about 'line-hatch' - I thought you were looking at speeding everything...
However, all you do differently for the 'component-hatch' is add component-instances to the [initially flat] group, set at the center and the with copies offset in x/y based on the 2d component's bounds.
The spacing of the instances is within the same limits as the 'line-hatch' version.
Then you explode the instances in the group and proceed with the intersect_with() etc as with line-hatch........ -
@unknownuser said:
I was speaking about 'line-hatch' - I thought you were looking at speeding everything...
Ahh, ok. I understand.
@unknownuser said:
Then you explode the instances in the group and proceed with the intersect_with() etc as with line-hatch........
Yeah, that's what I thought as well. Will try to get things rolling..
Thanks.
-
Been trying more realistic sizes of patterns. Noticed I was testing on a face 30 meters long
Times are a little better now, unless using circles with plenty of geometry..
This is on a pole 3m high. Remember time will be aprox the same if the pole would be 3 m wide...Now, still haven't found ISO standards for patterns so I'm eyeballing size here.. If someone find info regarding that please mention it here.
Colors on edges added.
-
Look at the jpg PATTerns in my 2dHatching subfolder - these are most of the standard ACAD PATT files - note how they are all relatively simple line patterns - NO real circles!
Simple hatch/cross-hatch are 'simple' - the concrete, grain etc are more complex - but still relatively simple tileable sets of a few edges... -
Yeah, you are right. The standard patterns are not that dense. The ones in "Hatchingextra" folder is quite dense, but not extreme.
Think I'll drop the "performance hysteria" for a moment, and continue with the rest of the job
-
The main folder is based on most of the ACAD standard PATTs.
The '..extras' folder contains mostly 'non-standard' hatches. -
@unknownuser said:
The '..extras' folder contains mostly 'non-standard' hatches
Ah, ok. That make sence.
Have been looking at the PAT format though.
http://docs.autodesk.com/ACD/2010/ENU/AutoCAD%202010%20User%20Documentation/index.html?url=WS73099cc142f4875513fb5cd10c4aa30d6b-7e57.htm,topicNumber=d0e368209Hmm, wonder if it would be possible with an importer of autcocad-patterns.. Major project perhaps.
Got my hands busy with learning html, css, js and jquery anyway
-
If you get a .pat file you will see it's set up like this
;; Notes... *Masonry-Angle, Masonry in section/plan @50mm c/c & @45deg. 45, 0,0, 0,50
Lines starting with a';;'are user notes and are ignored in pattern making.
Each line for a hatch type starts with a '*' and starts with the pattern's 'name' and 'description' separated by ','
The lines following it describe the lines to draw in the pattern - in this example rotated by45degrees and one line spaced in X/Y starting from0,0- they draw 'infinitely' unless a second point is given, spaced in X/Y0,50['units', mm in this example] - i.e. a line drawn offset every 50 at 45 degrees - it's as long as it needs to be to fill the 'loop'.
More complicated patterns spread over several lines and include a 'fixed length' line thus...
*Herringbone, 'Herringbone-pattern' 100x200mm brick/paving @45deg. 45, 0,0, 100,100, 300,-100 135, 70.710678,70.710678, 100,-100, 300,-100
Note how the three pairs of X/Y specify the lines' start-point, their end-point and their repeat, with different angles for two types of line...
The additional lines are used until a line of text starting with '*' or a 'blank' is encountered.
To mind-boggle you here's a complex wood-grain pattern...
*Panel, Woodgrain or paneling, approx 10mm repeat. 0,0,0,0,100,20,-30,10,-40 0,70,2.5,0,100,20,-80 0,60,7.5,0,100,10,-90 0,5,10,0,100,5,-70,5,-20 0,40,15,0,100,20,-30,5,-45 0,15,17.5,0,100,15,-85 0,40,20,0,100,30,-70 0,10,22.5,0,100,20,-80 0,50,25,0,100,50,-50 0,20,30,0,100,10,-30,20,-40 0,90,32.5,0,100,20,-80 0,70,35,0,100,10,-90 0,50,37.5,0,100,10,-90 0,0,40,0,100,20,-80 0,50,42.5,0,100,20,-80 0,50,47.5,0,100,20,-20,20,-40 0,30,52.5,0,100,10,-50,20,-20 0,50,55,0,100,30,-70 0,50,60,0,100,20,-80,0,0 0,10,62.5,0,100,30,-40,10,-20 0,10,67.5,0,100,50,-50 0,70,70,0,100,10,-90 0,40,72.5,0,100,20,-80 0,20,75,0,100,10,-40,10,-40 0,10,77.5,0,100,10,-30,20,-40 0,30,80,0,100,10,-50,10,-30 0,50,82.5,0,100,30,-70 0,10,87.5,0,100,20,-80 0,60,90,0,100,10,-90 0,80,92.5,0,100,10,-90 14.03624347,70,7.5,97.01425001,-24.25356251,10.3,-402.0105526 14.03624347,80,30,97.01425001,-24.25356251,10.3,-402.0105526 14.03624347,70,90,97.01425001,-24.25356251,10.3,-402.0105526 14.03624347,40,52.5,97.01425001,-24.25356251,10.3,-402.0105526 14.03624347,60,67.5,97.01425001,-24.25356251,10.3,-402.0105526 14.03624347,70,60,97.01425001,-24.25356251,10.3,-402.0105526 14.03624347,20,77.5,97.01425001,-24.25356251,10.3,-402.0105526 14.03624347,60,72.5,97.01425001,-24.25356251,10.3,-402.0105526 14.03624347,80,35,97.01425001,-24.25356251,20.6,-391.7105526 14.03624347,70,42.5,97.01425001,-24.25356251,20.6,-391.7105526 14.03624347,70,47.5,97.01425001,-24.25356251,20.6,-391.7105526 165.9637565,40,15,97.01425001,24.25356251,10.3,-20.6,10.3,-371.1105526 165.9637565,20,30,97.01425001,24.25356251,10.3,-402.0105526 165.9637565,20,75,97.01425001,24.25356251,20.6,-391.7105526 194.0362435,70,2.5,97.01425001,-24.25356251,10.3,-402.0105526 345.9637565,90,2.5,97.01425001,24.25356251,10.3,-402.0105526 345.9637565,60,37.5,97.01425001,24.25356251,10.3,-402.0105526 345.9637565,80,55,97.01425001,24.25356251,10.3,-402.0105526 345.9637565,40,62.5,97.01425001,24.25356251,10.3,-402.0105526 345.9637565,30,75,97.01425001,24.25356251,10.3,-402.0105526 345.9637565,40,80,97.01425001,24.25356251,10.3,-402.0105526 345.9637565,40,62.5,97.01425001,24.25356251,10.3,-402.0105526 345.9637565,70,77.5,97.01425001,24.25356251,41.2,-371.1105526 345.9637565,10,10,97.01425001,24.25356251,41.2,-371.1105526 345.9637565,20,17.5,97.01425001,24.25356251,41.2,-371.1105526 345.9637565,30,22.5,97.01425001,24.25356251,10.3,-20.6,20.6,-360.8105526 345.9637565,30,30,97.01425001,24.25356251,20.6,-20.6,20.6,-350.5105526 345.9637565,20,40,97.01425001,24.25356251,41.2,-371.1105526 345.9637565,10,47.5,97.01425001,24.25356251,41.2,-371.1105526 345.9637565,10,52.5,97.01425001,24.25356251,41.2,-371.1105526 345.9637565,80,82.5,97.01425001,24.25356251,10.3,-402.0105526 345.9637675,90,92.5,97.01425001,24.25356251,20.6,-391.7105526 345.9637675,30,87.5,97.01425001,24.25356251,20.6,-391.7105526 345.9637575,20,0,97.01425001,24.25356251,41.2,-371.1105526 345.9637575,80,70,97.01425001,24.25356251,30.9,-381.4105526 345.9637575,90,62.5,97.01425001,24.25356251,61.8,-350.5105526So you can read a .pat file using
lines=IO.readlines('path_to_file.pat')and then iterate throughlinesto find all pattern types and their specifications - replicating these as edges in your SKP...
Advertisement