[Plugin] Hatchfaces (v1.8 beta) UPDATED 15-Dec-2012
-
Kyyu! Thank you so much for your detailed explanation. Now I understand better. Much apreciated.
I think your intersect method is worth experimenting with for upcoming features. And or what features is possible.@unknownuser said:
this plugin will be not freeware
No one in here needs to worry this will become a comersial plugin.
Yes, of course I need to make money. But I have gotten so much help from TIG and Kyyu, Jim and others, so going comers. would be HIGHLY unethical! If even legal? This is a great learning experience for me, and I will try too remain humble and listen to
advice and suggestions being made.@unknownuser said:
in the new version of SketchUp this plugin should become a standard feature
Hatches, yes. So this work might be for nothing Although, it is possible only Layout will be the program that get hatches.
-
Yes! It happened!
Even if this is the final version of the plugin - that would be enough.
Many thanks you and those who helped you in this difficult and very necessary work.But I want to go further in my desires
How about this?
-
My comments...
Code like
jol_icons = Sketchup.find_support_file "Plugins/Hatchfaces/hatchfaces_s.png"
etc would be safer as
jol_icons = File.join(File.dirname(__FILE__)), 'Hatchfaces', 'hatchfaces_s.png')
because some users don't/can't put their stuff in the main Plugins folder -Sketchup.find_support_file()
is best avoided.Also how about adding a Plugins [or Tools?] menu item so users can shortcut to it easily...
Enabling the crosshatch options is relatively straight forward...
I would have three questions Angle, Spacing, and Crosshatch?
If the user has said 'Yes' [default='No'] as second dialog opens - the Angle set to the first set angle*-1 and the same Spacing - OK to do crosshatching or Cancel to not do crosshatching...
To process the hatching I'd move that part of the code out to a sub-method that takes several arguments - e.g.def hatch(angle,spacing,gents)
Then if there's no crosshatching you call if once passing the three values so it knows what to make and where to put stuff [gents]... If there is crosshatching it makes the hatch-group and then a group inside that, it runs the hatch sub-method in that sub-group entities... and then adds another sub-group for the crosshatching and runs the hatch sub-method with the new values in the second sub-group entities. This way the two hatches are grouped as one, but in each their own sub-group, so one of them could be erased later if a user desired it... -
It is not the final version There are things to fix. But I'm happy if the plugin is working for you, keep testing.
@unknownuser said:
But I want to go further in my desires
How about this?That can easy be made manualy in Sketchup if you use r.click intersect with selected(face and hatchgroup) so the hatched lines adds to the face. Then go into styles-> edit->profiles, and work with the setting there.
If you want border "thin" faces to be drawn, that's a different issue. This feature in code might not be that easy. I can have a look on that later. First I will try to get the crosshatching working.
One have to consider what feature to add or not. If that feature is 1 click in Sketchup, it might not be worth adding it to the code.
-
@jolran said:
That can easy be made manualy in Sketchup if you use r.click intersect with selected(face and hatchgroup) so the hatched lines adds to the face. Then go into styles-> edit->profiles, and work with the setting there.
Yes. It can be done. But in this case I am losing one large face, and in return get a lot of small faces. Seems to me it is not very well.
-
Ok I see what you mean. I will take a look at that later on. My 1st thought is that it will not be that easy to do.
In native Sketchup just use offset, doing that in code is not that straightforward, from what I know.
Crosshatching is on the next TODO list, and TIG's recommendations for filepaths.
Could spend some time on those... -
@unknownuser said:
some users don't/can't put their stuff in the main Plugins folder
Did not think of that good point.
@unknownuser said:
Also how about adding a Plugins [or Tools?] menu item so users can shortcut to it easily
Yes, yes. That should have been done earlier.
@unknownuser said:
'Yes' [default='No'] as second dialog opens
That's smart. I wasn't planning on doing it like that. But of course your way is more logical.
The code will need some work for this to happened. And I will try your method, if I can understand how to.Thank you TIG I will work on you advice.
PS: If it looks like I make promises for new features to be added and expect TIG to come to the rescue, it's not like that.
I understand you have other business to attend to, and I'm greatful for all the help I get.
Thanks -
Is that duplicate line needed at line# 136 ?
-
If you want to use the profile edge style. I was thinking you could keep the hatch faces and give them a transparent material. That worked. But then I thought, it's even simpler is just to hide them. I was worried that "unhide all" would unhide the faces, but it doesn't seem to effect the grouped faces.
-
@unknownuser said:
Is that duplicate line needed at line# 136 ?
No
Thank you for spotting that Sometimes I get wierd results when I copy from ruby code editor and paste to Notepad ++.
Did not doublecheck the results well enough.
Note. It is AS ruby code editor, not Jims version. Is Jims more stable? I think it's a webdialogthingy-bug.Thank you for keeping on testing stuff! It's of big help. How about a choice of keeping faces? With possibility to attach
material? That way one could use transparent material or whatever? Wonder if it is possible to use a dropdownlist getting the materials already added in the palette...Anyway, must get this second crosshatching inputbox working correctly first, and do some fancy methoding.
-
-
Sergey. Yes that is the behavior of profiles. I can see the problem you are getting at.
If I put in an option for "keeping face", you will get that behavior WITHOUT manipulating the original selection. Hatched lines and faces in one separate group called "Hatching".
On top of that,(as TIG recommended), when you want crosshatching. There will be 2 groups in that "Hatching" group. -
If you want 'thin' hatch lines you simply don't erase the faces within the hatching group[s] [i.e. keep the perimeter edges too]... then make a material if it doesn't exist called say 'HatchFaceMat' set it's color rgb=[255,255,255] and it's alpha=0 so it's completely transparent and apply that to all faces in the hatching group. If the Style has edges thin and profiles thick you get thin hatching.
It could even be a dialog option - Line-Style: 'Thin|Thick' - 'thin' where the faces are kept and made transparent OR 'thick' when the faces are erased... -
Thoose are exellent ideas! See if I can get this crosshatching work first
Getting some hard time putting structure to the code.I have made "line hatches" and "intersection" into 2 different methods. A heck of lot of instance variables..
I was wondering if it would be easier to let the 1st hatches get done first. Then make the second inputbox pop up?
Then just call the methods on @gents and do some sort of grouping. This can probably be done in several ways.
Question is wich method gives best performance, regarding workflow, edge creation etc. -
Hmm I got the second inputbox poping up after line creating. It's quite instant response. So having the 2nd inputbox first
or after 1st hatching doesent really matter, "workflow-wise" that is. I wonder if it's a risky way of doing things.Also wondering if I call on for 2nd Hatching, Using the line_making and intersect_method varibles in those are set
from earlier = @spacing and @angle. Could one use something like @spacing=20.to_l if not @spacing instead and just call the again in the method for crosshatching. Or would that mess up the default values, next time one run the plugin?Could of course put the whole rest in the crosshatch method, bit doesent feel very clever..
-
Or do the arguments in the definition heading like TIG said
def hatch(angle,spacing,gents)Hehum.. I'm to new to this.
-
Jolran, just a thought. I see that you now have the hatch assigned to a separate layer. It occurred to me if the hatch patterns were assigned layers by the distance between hatch lines. You would have a layer for small hatch patterns, medium patterns and large patterns. This way if I make a scene or PNG file of a small section of the overall model, I would just have the small hatch patterns turned on. And if I was making a scene or PNG graphic for the larger section of the over all model, I would have the small and medium hatch patterns turned off. This may be over kill and too much additional work.
And I can just assign layers to the hatches I make according to my wants.
To you Jolran and all who are helping, thanks for the running tutorial in making a plugin. This continued conversation is helpful.
Thanks to all, for the plugin and the ruby help.
-
@jolran said:
@unknownuser said:
Is that duplicate line needed at line# 136 ?
No
Thank you for spotting that Sometimes I get wierd results when I copy from ruby code editor and paste to Notepad ++.
Did not doublecheck the results well enough.
Note. It is AS ruby code editor, not Jims version. Is Jims more stable? I think it's a webdialogthingy-bug.Thank you for keeping on testing stuff! It's of big help. How about a choice of keeping faces? With possibility to attach
material? That way one could use transparent material or whatever? Wonder if it is possible to use a dropdownlist getting the materials already added in the palette...Anyway, must get this second crosshatching inputbox working correctly first, and do some fancy methoding.
I don't have any problems with copy/paste from Jim's Ruby Web Console (older one, not his newer one).
It's up to you about the features, keeping faces, or materials, ..etc. I don't have any preference as, I don't need to hatch stuff.
-Kwok
-
@sergey2402 said:
@kyyu said:
If you want to use the profile edge style.
Have I understood you correctly?
Yes, just hide or apply a transparent material to all the many small faces in the hatch group. Very easy to do with ruby.
-
@jolran said:
Or do the arguments in the definition heading like TIG said
def hatch(angle,spacing,gents)Hehum.. I'm to new to this.
I do it the way TIG is suggesting, passing arguments. I make instance varibles only when I really need to. I'm not saying I know the best way, but here is an example from a recent plugin of mine. Notice I have a @scale instance variable, but also a scale variable that's local to the scale method. What I'm doing in this paticular case is scaling back down. So I use "1/@scale", when calling the method. Also the method can't accicently change the instance variable, it's all local. Just to be clear, I'm not saying make instance variable and pass them to the method. It just happened that's the way I had it in that plugin. I think it was because, I had an initialize method at the begining and I wanted those values available to the main program method. So I made them class and instance variables.
def main ...stuff scale(@@ent.to_a, (1/@scale.to_f)) ...more stuff end def scale(ent, scale) tr = Geom;;Transformation.new(scale) Sketchup.active_model.active_entities.transform_entities(tr,ent) end
Advertisement