[Plugin] Hatchfaces (v1.8 beta) UPDATED 15-Dec-2012

jolran

Yeyy! Got the picture switching going. First success in Javascript.

Well this is the code I use if someone is in the need for it. If it can be improved, please tell.

The function change picture source by the name of selection in scrollist.
You will have to call the function in the <select> tag in the HTML, by "onchange" + "functionname".

function changePic(hatchImage)
{
    // Get the select options text
    var i=document.getElementById("selskp")
	var hatchSelect = i.options[i.selectedIndex].text; 
    
   // Create our Image src name, concat
    var hatchImage = "img/" + hatchSelect + ".gif";

    // Assign the image
   document.getElementById("imag").src = hatchImage;
}


And in the html you just call onchange="changePic()" 

<select id="selskp" name="components" size=15 onChange="changePic()" >

TIG

Y'see! it's easy
[If you spend hours learning it! ]

jolran

I woulden't say easy. I'm thick as a mid-evil castle door.

Yep, hours it is. Rewarding sensation when things get going a little. Time before that is frustrating pain .

jolran

Bonjour.

I thought giving a little update, so you don't think I have given up on the plugin.

Due to webdialog testing I'll noticed that the script had to be reorginized quite alot. Especially if LineHatching and ordinary component patterns are supposed to coexist in the same script. And there will be options for crosshatching for comp.patterns as well!

color background(or none).
So in order to keep the same requested grouping as LineHatches, there where a lot of conditions to be met to even be able to test the dialog. And the webdialog part is hard to code..
At the moment I can "stear" the plugin with @variables set to TRUE or FALSE or VALUE.
The idea is to link those to the Webdialog later on.

The way I have organized the script is methods on top. And a main script just calling methods with if statements. The methods have few arguments. Mostly (group) or (face), so things are easy to keep track of and to reuse methods.

Then the question is. Is there any performance differences in having it set up this way. Compared to having Modules loaded in(with methods) like I see a lot of coders use. It's not a very long script. 400 - 500 lines of code.

Here's a pic of crosshatching with comp-pattern. Grouping the same as LineHatching. Can't get rid of the border on comp-patterns though. Tough nut to crack...
Much easier with LineHatches.

version1.8 preview.jpg

ipsketchpi

Great plug in, I did it little different till now. These plug in is cool stuff in SU. Thank you.

jolran

Thanks for feedback .

FYI. I'm working on the next version quite hard and on an every day basis. Even if there hasent been any updates lately in this topic.

ciudadanochano

Hello:

I´m new in this forum. Could be possible to be rendered with v-ray?. If it were a normal material?

Thanks.

jolran

Hi Ciudadanochano!

I can imagine having a woodframe-construction with wood textures and in some angles show of some hatchpatterns. Is it something like that you desire?

But I think one will need a face with a material in any case, for a render. Unless "wireframe" is an option in your render-engine?
I have Vray as well. And could probably look in to that a little later on..

You can fake it though if you can match Sketchups field of view and pixelratio!

Just render 1 black and white version in Sketchup(with hatches) and and 1 version i Vray.
Then blend the pics with some type of layerblending in Photoshop.
Cheap trick though ....

kaas

Hello Jolran,

Any new developments you're willing to share?

Greetings, Max

jolran

Yes, sure if you like.

Think I'm ready with the base of the dialog. I'm porting it to Sketchup as of speak.

There where a lot of Javascriptcode to get the interface responding to certain events. For ex if one checkbox is selected another element is disabled, and such.
Using Jquery to help with DOM handling and events. And a spinnbox plugin.

I'm also sending lists from Sketchup to Dialog. Materials, components and layers.
Instead of hardcoding them in the HTML.
For patterns the user will be able to create new components as long as they put them in correct folder. And maybe create a pic as well(optional).

It's moving forward everyday actually. Slowly but steady. Will still have a lot of cleaning, testing and streamlining to do. But hopfully it will be a useful plugin.

Here is a screencap from latest dialog version. The style is to keep the interface as "Sketchup" as possible. Opinions in this style would be nice.
I could go crazy with colors but I kinda like this Sketchup style.

kaas

Hello Jolran,

Good to see you're still developing the plugin.

The screenshot looks good! Very nice you use the Sketchup style for the dialog, it's more easy on the eyes. I Hope you can treat us with a new test version at some point in the near future. Good luck in the meantime!

Greetings, Max

jolran

Thank you Max.

Glad you liked the style. It's quite easily changed if users would want so.

@unknownuser said:

I Hope you can treat us with a new test version at some point in the near future

I'm working on it. Quite hard acctually, it's my baby. Can't give any dates, cause I'm not experienced enough in scripting to tell how long certain things will take

There is one thing that might pose some problems for the whole idea of the plugin.
After intersections there are quite often errors. I don't think it has so much to do with the script itself creating errors, but as to Sketchups accuracy. Wich is 0,001 inches.

It's really bugging me. Sometimes edges don't intersect with faces or small faces gets lost.

My theory is that I'm importing components and tiling them and doing plenty of transformations, wich can lead to: Vertices and edges are lying outside a position tolerance of what Sketchup can handle(intersect).

Compare that to using native Sketchup tools creating geometry. For ex drawing edges with the pen tool on a face, that would almost always give you tolerated vertice positions(unless you group and move them) for intersecting.

Well that's only a theory. But I must solve the problem somehow.

Hope that did not come out to negative Max. But as you can see there are still some work to do.

dtrarch

Hi Jolran

Just a lurker but what fun to see you and TIG hang in with such tenacity.
Thanks for this really useful and interesting tool.

Cheers

dtr

markitekt

Any news on what looks to be a very promising plugin?
Mark P.

brookefox

After having used the plugin, I came back by because I thought I had some ideas for you but seeing the various screen shots it looks as if you are well beyond what I get with the plugin, so either mine is not up to speed or I am not implementing correctly or you have not posted one which gives what is shown... My version just has hatches > line hatches resulting in only the possibility of cross hatching.

I forgot to say how thrilled I am to find your routine and hopeful for what I may be able to do with it... It fills a long standing hole in SU's arsenal.

jolran

Hello everyone!

I AM working on the plugin. Just have been very busy lately with house renovation(I do this SU-programming on spare time).

Brookefox. The downloadable version you have, only does linehatches at the moment.
Although I've earlier posted pictures of current development features (here and in LO-forums)in order to get feedback and suggestions.

Must admit, for a while I got the impression most people where content with using textures for hatching(At least at the LO forums). So I got a little side-tracked
Started to work on other features, like 3d hatching and such..

Thanks for the feedback guys Really apreciate it.

Will be back on track soon.

/ Joel.

brookefox

Thanks for checking in, Joel. My guess is some of us would be happy to use a more fully implemented beta, as it seems so useful, with the obvious risks inherent. Personally, I'm looking for all edges and faces (no textures, no images), and components (preferably gridded). In my small experience it seems like the gridded components offer the greatest promise as they may be infinitely and easily editable.

If I could just cast components on a specified grid within bounding edges (faced or not), I think I could be happy. (What happens to components that intersect bounding edges? Ideally, they would be trimmed, or optionally trimmed.)

jolran

Thanks for the input and ideas Brookefox

Gridded components you say? Do you mean patterns or using some sort of workplane?

You will be able to load premade patterns(components) from folders. Where you also can make your own patterns and stuff them in there.

Anyway, The way the plugin is working now, is that a face-edges determine the boundarys. That way the user don't have to worry about which plane one is working on.
Everything outside the face will be trimmed, including holes. Just like it's working in the current downloadable version.

The plugin as is now, is not beta ready . I actually might do a "light" version for user testing at first. Cause there are so many things added it might be difficult for me to keep track of things when complaints starts to hail in

jolran

@unknownuser said:

Just 'patterns,' which are in fact component instances which can then all be changed by editing one of them

Brookefox, I'm afraid that will not be possible if you mean altering them after the hatch-components are fitted to the face.
What will happend(in the code) is that all tiled instances will be exploded before doing an intersection with the face. And in the end become 1 large component.

I think Smidths plugins was an request to solve a particular problem, spacing out plants and stuff, including triangular array. In those cases one may not wish to delete geometry outside the faces. Works very well for what it was designed for, I think.

Hatchfaces plugin obviously will be more "pattern-fit a face" sort of thing.

Thanks for answering.

brookefox

@jolran said:

@unknownuser said:

Just 'patterns,' which are in fact component instances which can then all be changed by editing one of them

Brookefox, I'm afraid that will not be possible if you mean altering them after the hatch-components are fitted to the face. What will happend(in the code) is that all tiled instances will be exploded before doing an intersection with the face. And in the end become 1 large component.... Hatchfaces plugin obviously will be more "pattern-fit a face" sort of thing.

I guess that is really all that could be expected and quite a bit, at that. I'll wait with the hordes, not drooling.