Hi Thom

I've been using your plugin and am loving it...

One small thing I have noticed is that a 'blank background' behind a 'glass' material is still interpreted as a complete transparency in the png exported file and if you're trying to slide in a sky behind say a glazed building, this can look a bit unrealistic.

Would there be anyway to alter the plugin to recognize a transparent sketchup material and produce a semi transparent section over these areas in the resulting png much like the alpha maps generated by Vray that accompany jpg exports where black represents 100% transparent, white 100% opaque and shades of grey somewhere in between...? I'm not asking for a true alpha map file like Vray, merely that the coloured png export takes cogniscence of the transparent materials...

Thanks

Dave

Thanks Gaieus

Working just fine now...
Even Medium seems to do the trick...
Thanks

I have an issue with overlaping png images.

Basically these are trees mapped onto a surface with the intention of mutiple copies being used to create background vegetation behind a building...
The png's have got a 'crisp' alpha masks..

In some instances, when overlaping, they display correctly with no issues (attached image 01). From other angles, the overlap produces an additional transparent zone or 'halo' around the images which subsequently 'eclipses' the image behind it. (Images 02 & 03)

If the skp view is exported as an image, this 'glitch' is evident...

Interestingly, if one cycles through objects, selecting them one at the time, the display issue is temporarily resolved on the object directly behind that selected!.....???

Has anyone experienced this? Could it be a graphics card issue? Do you know a trick to correct it?

Thanks in advance...

Dave

---

---

---

Yup...

Maybe Magneto is in the area...

Hi Thom

I am getting a few weird results with the drop component option...
I thought I would try an test with a series of cars on a slope to simulate a parking lot scenrio.

??? There are some non conformers

Test file attached.

Cheers

Dave

---

---

DROP COMPONENTS.skp

Awesome....

Thanks!

Hi there...

Could one of you accomplished ruby scripters knock up a plugin which I call 'gravity' allowing a series of components laid out in plan to be dropped onto a surface such that they are auto moved so their component axes intersect with the surface.

The scenario I need this for is for say placing a series of trees on a site. I have the plan layout of such planting but am having to manually drag each one down into position...

I can see an application for something like this in other scenarios too...

If there is already soemthing like this out there then please point me to it... I am aware of Didier Bur's 'component spray' but this is only good for random arrangements and i need something for a more structured placement...

Thanks in advance...

Dave

Thanks for the info TIG

Unfortunately its not always possible to find an existing thread where someone is experiencing the same issue as you...

Either way I believe my test matrix has covered when this will cause an issue... and like i mentioned it would appear best to create components in a non-geolocated file... As I am in architecture and the geolocation controls the sun, this is not my default workspace... but I have now learned my lesson!

It would help if the developers would issue such a warning though and at least build in the option into the component settings which I understand from the thread you pointed to, was something that actually existed in v7.

I discovered this whilst trying to make a library of new people and almost blamed your image trimmer!

Cheers

Dave

COMPONENT TEST MATRIX

Further to my last message, I have drawn up a test matrix for the component bug...
I also attach my test components with geo location as follows:

No Geo location - N/A

Accurate geo location - choose Durban, South Africa (my local area) and grab whatever comes up (co ords should read: 29.85.7886S & 31.027581E)

Manual Geo location - set up Durban, South Africa 30.000000S & 30.000000E

I am very interested to know if any of you find the same.

I don't know what this means for those people who have created libraries of components for re-use from a accurately or manually geo located or file as it would seem that the safest bet is to do so from in a non geo located skp world!

IMO the developers should change things, so that there is at least a swith option in the component setting allowing the choice of geolocation or not rather than having the user remember to clear geolocation or use a non-geolocated template file when wanting to save out components for re-use as part of a library...

Dave

---

ACCURATE_GEO COMP.skp

---

MANUAL_GEO COMP.skp

---

NO_GEO COMP.skp

---

Okay I think I have discovered why this is happening...

I had a go at isolating the plugins folder as Dave R suggested (in our PM conversations) but did not have any luck... so its not a plugin conflict!

I then tried to think back to what I had changed in skp since it last worked okay and remebered me setting the Geo location (manually) in my template file so that I would not have to set up the sun / time zone etc on every project and EUREKA! that seems to be it....

Basically every component that has been made using the template file with Geo location set and then loaded from a library as described earlier gets auto dropped in miles from the default world origin...

The issue was repeated on my new desktop pc as well as i used the same template file!"

I have also done a component test matrix which I will post shortly....