thomthom

Yeah, your example is absolutely correct! 🙂
And right, if there is a face with coordinates like these:

[7.2, 6.3]
[7.8, 6.3]
[8.8, 7.9]
[9.2, 5.9]

Then there is no point to run such a script, and the most logical thing to do would be to abort operation. It would be extremely cool if offending face would be highlighted, but I'm not sure if it's an easy thing to do, since it might be buried inside the component hierarchy and directly selecting it might be impossible.

Aerilius

Thanks, I will definitely try this, even though the plugin description doesn't look very revelant. But maybe it does what's needed as an unintended side effect, will check. 🙂

First of all, thanks a lot, TIG, I really appreciate your help! I've started to ask my friends familiar with programming about how to make a Ruby script based on Jim's advices, but you've actually wrote the whole thing already! It really feels great to be there, in such a friendly community. 😄

Plugin works great!

Hovewer, I feel really, really dumb for not thinking about the method proposed by RickW earlier. 😄 It is really perfect: incredibly simple and producing really great results, especially with high-res gradient image.

Still, I think your plugin, TIG, deserves a release: as the default fog control window is perhaps insufficiently precise in some other areas - for example, for some styles of architectural visualization. I imagine it would be very useful with one small addition - the detection of a distance to the camera from a certain point on screen. I don't know if API allows to read that, but if it is, it would be awesome: you just click on some vertex and get a distance to it, allowing you to precisely configure the fog distances for your needs (or perhaps other things, like Depth of Field falloff range in V-Ray). I don't know, maybe distance determination would work better as a separate window (or even separate plugin), or maybe it'll be handy to instantly paste it to the fog values. Oh, well, maybe such a plugin already exists? 😄 Nevertheless, great work and thank you again! 😄

@tig said:

The API code does allow you to change the two values of the texture size - in just the same as you can do manually - the default size is 10" (254mm).
I don't see how you can do it 'on the fly' as you make materials [you could simply adjust the size anyway - as you ought], but it'd be quite possible to write some code to change all textured materials to a different fixed size, and also use a default texture image on any untextured materials, also to that fixed size too. It'd then run the exporter, so that the external file matches these settings; on completion it could then do an 'abort_operation' to revert all of the materials as they were, leaving the external export-file unaffected. Alternatively it could change all of the texture sizes permanently and just use the temp-texture for non-textured materials for the export part, reverting those materials to be 'plain' afterwards...
If you manually ad a texture, resize it then remove the texture does the 'plain' material export with different mapping info ? e.g. it's previous texture size is remembered ? I've not tested this, if it does then you could temporarily add a texture to each untextured material, resize it and then remove the texture ?

Hi there TIG!

This thread is kind of old, but I would still be neat to know if it's possible to change the default tile size, so thanks for answering there. More precisely: I don't need to change any preexisting materials "on the fly" and I don't need to change the sizes for materials with textures. What would be handy is changing the default UV tile size in material properties, globally, for every material SketchUp is creating.

That would be a very useful safeguard feature for newbies not yet fully utilizing materials (no matter if they won't use placeholder materials and size values, their models will have reasonable UV sizes and will look decent with various in-engine materials). Or a neat help, for example, for level designers quickly prototyping geometry under strict deadlines: they will be able to slap several material types to separate a scene as needed, then replace these fills with suitable materials (like various concrete types) in the engine afterwards. All and all, having 10x10cm as default UV tile size is impractical.

The idea of assigning a placeholder texture to every untextured material, changing then available size values and disabling the texture after that sounds practical. Unfortunately, if I remember correctly, removing a texture removes tile size values from a material too, so these changes will be immediately lost.

Okay, I see what you mean and of course it makes perfect sense. You could still give a go to this plugin:
http://www.smustard.com/script/GroupByTexture
It was developed export issues in mind so could work. As I am seeing your image, maybe it would not even mess up triangulation after export too much (although with this auto merge function of SU 7, who knows - but there are good plugins to remove excessive geometry, too).