[Richard]

JD and Francois

Does this mean the higher poly SU version is xrefed on export or does it require the high poly version to be in the "in model" component list? If the later Francois how do you ensure the hi poly version is not removed on purge?

JD? Mate in regards to the scaling of unnominated materials (those without a map) is it possible to have that 12" x 12" you have employed 1. be a metric (95% of the world) and 2. Be user defined as a preference.

I understand this would be a global change that would effect all non mapped materials in scene, though considering SU is more aligned to architecture larger say 2 - 4 metres may be a more suitable repeat. The things that I'd imagine would help are for things that cover a large area and therefore a heavier map say grass, concrete, paving, roads, etc and inparticular those that don't count on exact placement. This would have a huge effect when working with SU as those larger maps will not need to populate the material browser! Hence baaaam more speed to workflow in SU that SUCKS!

This is just getting better and better!

[Richard]

Or I guess could the plugin read the assigned units of the SU scene ie metres, millimeters, feet etc and apply this measure. I'd use metres for example ans then setting map repeat in the MXM is a simple conversion for repeat!

[JDHill]

Ah, let's not get ahead of ourselves...it is really just mostly for making sure things have some halfway-sensible default UVs at this point. The vague plan would be that when it becomes a first-class feature, you would have some direct control over the projections...it's much too early to know what that might look like though.

Regarding the proxy thing, the definitions need to be in the document, so yes, purging them would break your setups -- things that were supposed to be replaced by whatever you had purged would no longer get replaced. The purpose is to reduce the amount of high poly stuff in your viewport.

[brodie_geers]

I didn't use proxies for very long but the general workaround was just to put them on a hidden layer. Not ideal but at least then you can purge.

-Brodie

[Richard]

Ah, let's not get ahead of ourselves...it is really just mostly for making sure things have some halfway-sensible default UVs at this point. The vague plan would be that when it becomes a first-class feature, you would have some direct control over the projections...it's much too early to know what that might look like though.

Regarding the proxy thing, the definitions need to be in the document, so yes, purging them would break your setups -- things that were supposed to be replaced by whatever you had purged would no longer get replaced. The purpose is to reduce the amount of high poly stuff in your viewport.

Hey understood you first up mate though it is even then it's self a useful implement, I'm just really asking if even metric (making 1m tile) and imperial (making 12" tile) might simply be controlled by a simple check box. The conversion of tiling from 12" to metres for something I'm gonna now milk is !

Regarding the proxy thats a bummer! I can understand the issue though I so that to xref thing will happen later! One good tree in SU and it's gone! For some reason if I bring an Onyx tree to SU then to MR the mappings gone yet OBJ from Onyx to Studio a breeze, it's a bummer in workflow and so nailed with xref!

[fv]

Having components exchanged for mxs instances is of course ideal but I use proxies a lot these days and seriously big stuff I do in Studio.

To be honest, my Evermotiontrees are as big that I dare not even add too many in Studio. Placing about a dozen or so as instances in Studio takes maybe 5 minutes, makes my mxs file well over 500Mb, in a normal job that's about the max I can do. All other stuff I do in SU by proxies. Especially when I have lots of components copies.

Using proxies is not really for SU-starters and you need some work arounds by hidden layers. But I am sure the plugin writers can do a little trick to keep the _proxy related components unpurched at cleanup.
I am afraid to ask JD as I am beginning to feel he is already regretting implementing the "P" feature.

But for those who haven't. try proxy.rb and report back.
Francois

[fv]

Hey Brodie, missed your comment on household and banking before,
but maybe JD can do a brodie.rb exchanging everything into one big unrevertable bounding box making export and render a banzai blast of less than 2 seconds even with multilight switched on.
Ideal for those moments paying bills and household chores should be prioritized...
Actually, my wife would like such a plugin executable by the tv-remote.

[fv]

I just asked Thomthom who wrote cleanup for purching and cleaning SU files to update his plugin.

___
Hi Thom,
I am using your cleanup plugin a lot but also _proxy components made by proxy.rb.

When I cleanup a model I am afraid the original XX components exchanged for the XX_proxy components are purched.

Is it possible to update cleanup leaving an option for all components reletated to _proxy components unpurched at cleanup.

Tx, Francois
__

[JDHill]

Francois, the thing to keep in mind is that a definition will not be purged as long as it is referenced in the model (it could be intentionally deleted by ruby code, but any standard SketchUp 'purge' calls would not do this). That is to say, ThomThom should not need to modify any code of his -- the author of proxy.rb should make some minor changes, so that it works generically with other code, rather than having other code put in special cases to accommodate it. Specifically:

- before the definitions are swapped, proxy.rb could ensure that at least one instance of the source definition (i.e. the hi-poly source) will still exist in the model; this instance could be placed on a layer, and that layer's visiblity set to hidden

Additionally, it (proxy.rb) fails with some components; specifically, if you open a new document and try to use it on the standard Sang component, it fails, since Sang has no thickness. When the bounding box is created, its corners need to be biased by a very small amount, so that the created bounding box cannot end up being zero-thickness in any dimension.

[brodie_geers]

fv,

Which cleanup script are you referring to? Link? Something other than the usual purge.rb? If there's another cleanup script out there I must have it!

-Brodie

[numerobis]

Francois, the thing to keep in mind is that a definition will not be purged as long as it is referenced in the model

yes, so you have at least one copy of the proxy component inserted into the model. you can't insert only the low poly components, then the purge command would remove the proxy.

[fv]

Brodie, you can find practically all plugins on the Sketchucation site under the forum index "plugins". There is a post with all plugins sorted by their maker. Look under Thomthoms plugins and you will find the cleanup model plugin.
Here is the link to cleanup, very handy tool.
http://forums.sketchucation.com/viewtopic.php?t=22920

JD
I agree that plugins should not be dependent on other plugins to work properly. But _proxy has become a bit of a standard way of simplifying geometry. In such a case I would not mind cleaning up a model with the option to keep _proxy relations in tact and unpurged.

A workaround might be to revert one of the proxies to its original in the model before cleanup. To reimport the proxy(s) is also not a big deal incase you mess up cleaning up.

I am not sure if I ever need to proxy a component without thickness, thinking of how much of a difference that would really make.

At the moment I am really happy to know there is a proxy option left alive in the upcoming SU to Maxwel plugin.
Francois

[brodie_geers]

Aw, lovely, thanks. I forgot I did actually have that plugin, however it was an older version that I had a couple issues with so I forgot about it. I guess that's one of the pitfalls of SU needing so many plugins to do cool stuff. Mix that in with SU's God-awful plugin organization system and I've probably forgotten 1/2 the plugins I have on there.

-Brodie

[fv]

Yes, its getting a bit messy and I am happy I have a 30" screen, the plugins are taking over and updating SU is a matter of scanning the forums.
But at least Google hardly ever updates anything ...

Francois

[Richard]

Hey JD just a thought or question on default auto scaling feature you have incorporated?

What happens in the case of geometry that has been scaled in the case of a group, do the materials scale out to the stretch or are they still set at the 12" x 12" tile? (again option for 1mx1m would love) I'm hoping actually the materials don't scale and stay at default repeat on export. This will allow for faster modelling usings grouped primaries using the scale tool, my favoured quicker approach!