Offline
Thanks for the info!
While at it, can you take a look at this improvement? It would be an enormous help for users inserting edges into n-gons to control triangulation, and to users with quad-based geometry or otherwise unavoidable coplanar face sequences:
Is it possible to fix the chamfer process failing on such a corner?
It's pretty much impossible to avoid places like those in serious quad-based hardsurface modeling, and other chamfering implementations (in 3ds Max, Maya, etc.) never had issues with topology like that, so I'm not sure if anything really prevents proper chamfering here. Typically, corners like those are simply resolved like this:
@massimo said:
@bac9-flcl said:
I'm sequentially clicking on the faces.
You have to click and drag without releasing the mouse button.
Oh, so that's what I had to do. Thanks. It's just that dragging is not usually used with any stock tools (which were designed to work with clicks), so it wasn't something immediately evident.
Okay, follow-up questions then:
How should I handle situations where a required sequence of faces can't be observed from one camera angle? What's the intended way of sampling the mapping from a neighboring face to continue the texture mapping where you left off? I.e. what's the equivalent of Alt+LMB click of the stock Paint Bucket tool in your control scheme?
Why are clicks on faces sometime triggering a distinct "camera shutter" sound effect (instead of opening the texture mapping editing mode like the tooltip says) and what's it notifying about?
Why editing the tile offset on one face within the Natural UV produced sequence of faces triggers the change of tile offsets on every single neighbouring face? It's a very neat feature, but it would be good to know if there is a way to switch back to isolated editing of one face which is sometimes precisely what's needed. For example, after perfectly aligned sequential mapping is already completed, mapping of involved faces is usually only modified to break the repetitive tiling patterns, in which case only isolated faces have to be edited - hence the question on how to activate that mode.
Is there a way to affect the initial offset of the texture? I see that hovering the cursor over one edge or another before beginning your swipe rotates the texture to be aligned with it. Is there any way to control the alignment of translation node? Very often, for example, I need the wall texture to be aligned vertically to one of the floor vertices.
And some small feature requests. 
Can you please add the display of UV tile coordinates to the editing mode? Per-vertex UV coordinates are more or less pointless to show, of course, but sometimes it's extremely important to know whether the texture tile you're applying to the surface comes from between 0U,0V and 1U,1V or some far-off tile between 25U,42V and 26U,43V. One example of that are various texture baking workflows where you won't be able to bake ambient occlusion or normals of your model if your texture coordinates aren't contained within one origin tile. So usually you have to open the editing mode and correct the offset, and for that situation, it would be nice to have some guiding numbers showing where you are instead of having to edit the offset blindly.
In relation to that - it's probably a quite simple thing to implement, but it will go a long way to reducing rendering artifacts of texture mapping on large models in low-precision formats. Can you make it so that the texture tile placed onto a face will always be taken from somewhere close to the center of the UV space? It can be achieved by using the closest vertex instead of the origin point of the scene to calculate the offset. Thing is, many mesh formats and GPUs are using floating point formats of low precision to store texture coords, which gives lots of trouble to tiles with coords in hundreds and thousands. For example, iOS devices won't be able to render texture mapping on those faces in a proper manner, showing you torn, noisy fragments of the texture jumping back and forth on the face if it's coords are in the thosands.
And again, in relation to that: is it possible to override the default UV tile size SketchUp developers have hardcoded into all materials? It's around 10x10cm and as you can guess, it results in absolutely insane UV coords on any relatively large architectural objects that don't have textured materials to override the value. Which causes both problems with precision I have mentioned above, and some other issues (for example, previewing how textures will look on your mesh is pretty hard with default UV tile size because your fancy texture of e.g. a brick wall will obviously be sized 10x10cm and repeated thousands of times over the surfaces, completely out of scale). A more reasonable value, like 1x1m or 2x2m would do wonders to make default texture mapping more usable. Hopefully it's a value exposed to Ruby API that can just be accessed and changed.
Thanks in advance for any answers and thanks for the wonderful work this plugin is again! 
@fredo6 said:
@bac9-flcl said:
Sure, here is a model with that texture, two sample meshes and two examples of stock texture mapping. Switch between the scenes to navigate it.
I am not sure of what you try to achieve.
You cannot paint the shape in one go, because ThruPaint will try to go around the shape while going up (The first goal was to paint smooth meshes).
So you need to paint each side separately, as illustrated in the video.
[attachment=1:1upsydfr]<!-- ia1 -->ThruPaint - Texture natural 2.gif<!-- ia1 -->[/attachment:1upsydfr]
Please advise if I missed something
Fredo
Yeah, I'm interested precisely in painting each side separately, obviously. ThruPaint is not producing the mapping similar to depicted on your gif for me, though. Maybe I don't understand something about controls? I'm sequentially clicking on the faces. Should I hold some additional button for Natural UV to come into effect?
@fredo6 said:
Interesting. You seem to understand how UVs work with Sketchup.
Would you have a sample model, with your texture, so that I try and see what is going on.Thanks
Fredo
Sure, here is a model with that texture, two sample meshes and two examples of stock texture mapping. Switch between the scenes to navigate it.
I'm not sure I understand how Natural UV mode is supposed to work. No mesh I've tried it with ever got continuous texture mapping like one stock SU painting tool in Alt-mdode is capable of applying. Only the rotation is rarely repeated properly, but the position of the tile in UV space is completely off. Here is a simple example, two bent rectangular columns made with some repeated rotations and pulls. Simple sequence of faces, no triangles, no bidirectional corners.
Stock SU paint bucket tool creates proper continuous texture mapping for each face based on UVs from the border of each previous face (of course, you have to edit the coordinates on the first face at least once to override the automatic projection mapping). ThruPaint produces a seemingly random sequence of tile positions and rotations even if the first face mapping was modified and even though the faces were painted in order, just like with the stock tool.
Some more examples of the behavior I'm trying to get (easily achieved with the stock Paint Bucket tool and Alt key sampling of each face texture mapping through the sequence):
What am I missing to get that essential feature to work? As you surely know, GPUs treat every edge without continuous texture mapping as a set of two edges (i.e. borders of a UV islands), which is why results like those aren't particularly useful if you don't want to render more than twice vertices than necessary. Surely I'm just overlooking some setting or hotkey.
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.
Hi everyone! I've wanted to share a common issue with you and propose a solution to it.
So, while plugins like UVTools 0.2 are available, most of you are probably using SketchUp native tools for your texture mapping needs. One thing that is interesting to point out there is SketchUp carefree attitude towards UV coordinates and tiling. If you're texturing a brick building, it's not unreasonable to guess that your texture mapping will look similar to this:
That happens, obviously, because there is no reference to UV coordinates in SketchUp texture mapping mode, which means there is no way to tell which texture tile you're using. Only reference you have are red/green/blue/yellow controllers, initially sitting at the corners of original tile, but these change their position if the texture mapping was picked/inherited from another face (which is almost always the case).
While it's acceptable for tiled materials like brick to employ coordinates outside of original tile, this can be problematic for some cases.
Let's take a look at "ideal" lowpoly building model akin to ones used in Google Earth.
To optimize the file size and performance, it's using one single texture for everything. This texture contains every unique feature of the building, so there is no need to waste space on tiled roof textures, windows and stuff like that. It's not too hard to pinpoint repeating elements, even in fairly complex architecture.
The model is comprised of faces fitting these parts, which are mapped by appropriate parts of that texture.
Looks nice so far. But let's say we need to use that model in some proprietary engine (like high-end GPS navigator) or bake renderer, where UV space allowed for use is strictly limited to [0,1], i.e. only first tile can be used. This kind of requirement is very common.
Let's take a look at our faces in 3ds Max UV Editor to make sure everything sits inside the first tile. We expect lots of faces to be outside of [0,1] range (after all, we're using picked materials and inherited texture mapping from other faces quite often, so offsets are unavoidable), but it shouldn't be too hard to fix. Just a couple of grid-snapped move operations on UV islands, probably.
Disappointing, but expected. Still, well, it's not like everything could be too far from the first tile. We've only used inherited mapping a couple of times in a row tops. Let's zoom out a bit, everything should be nearby. Right?
Ugh, okay. Anything further?
You've got to be kidding me. But wait, there is more.
That's more than 20 tiles away from point of origin (!!!).
Now, remember, every face there is lined up with some part of the texture. Nothing goes over tile borders. So basically, everything should fit perfectly into one tile: only problem is, faces are scattered around a hundred tiles. Wrong ones.
And there is no grid snapping in the UV editor. You can't even fix the step of your move tool to the size of UV tile to make dragging everything back precise and easy. You have to zoom in and align every face again, manually (thankfully, at least axis snapping is available, so that was limited to a single axis at a time).
Eventually, it was done.
Guess how much time was wasted on dragging everything back to the point of origin? A bit too much.
Now to the proposed solution.
Obviously, changing SketchUp UV editor is out of reach for plugins, so it's not possible to implement some sort of optional range lock that will prevent texture mapping from flying away into infinity.
What can be done, though (probably) is the processing of UV data after the model is finished. As I've mentioned earlier, ideally, every face should be inside a tile, no border intersections around. This should make it possible to determine with absolute certainty on which tile a face is situated. So, let's say there is a magic button that we press once a model is finalized. It starts a check that will look up coordinates of UV islands.
Knowing these, it's then possible to determine the tile, and then, we can easily fix the position by adding an integer value like -1 to the UV island coordinates.
Extreme edition suggestion: if some face is crossing the tile border, abort the check and highlight it in the viewport.
As far as I understand, this kind of check should be possible and this kind of access to UV data with write permission should be available for plugins.
To elaborate on object types that can require this kind of check, here are some additional examples. In addition to Google Earth-like objects, everything I said is applicable to objects like these:
[img:1smkgstp]http://i.imgur.com/Efzld.jpg[/img:1smkgstp]
[img:1smkgstp]http://i.imgur.com/nFXqR.jpg[/img:1smkgstp]
[img:1smkgstp]http://i.imgur.com/oB89n.jpg[/img:1smkgstp]
[img:1smkgstp]http://i.imgur.com/X4QZC.jpg[/img:1smkgstp]
[img:1smkgstp]http://i.imgur.com/QLcd7.jpg[/img:1smkgstp]
[img:1smkgstp]http://i.imgur.com/yPw5j.jpg[/img:1smkgstp]
Contrary to the popular belief, these kinds of objects can be mapped with SketchUp native tools. Only problem is aforementioned offset of some UV islands, which will prevent you, for example, from baking ambient occlusion in external software.
So, what do you think? Is it possible to write a plugin that will check UV island positions and move them to the first tile by adding integer values to their coordinates? Would it be useful, in your opinion.
Thanks in advance for any answer!
@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.
This plugin is absolutely awesome, thanks a lot!
I'm exporting models to CryENGINE3, which is limited with FP16 vertex coordinate precision, so moving the pivot point to the center of a bounding box to utilize the whole range of available values on each axis is a very important thing to do. Your plugin just saved me tons of time otherwise wasted on doing this manually.
And yeah, the possibility to disable the centering for vertical axis (and using e.g bottom of the bounding box) is awesome too - especially for more or less flat models where I can sacrifice some excess precision in exchange for ease of object placement. Or also, it's very useful for small props, like furniture or natural clutter, which can be placed in hundreds - digging each object from the ground would have been quite bothersome).