Apparent duplicated textures

[L_Rob]

Hi everyone,

I have to admit that I have not paid much attention to minimizing textures in the past, other than fiddling with the Material Editor, but my current project appears to have a number of large texture surfaces duplicated on multiple textures and I'm wondering if there is a way to reduce the texture count.
This is one of my most complicated models to date, and that might be part of the problem; two adjacent ferry terminals in Victoria BC.

Other than a couple of small files for repeating textures, all of the surfaces in the Sketchup model come from two 2048 x 2048 images; one saved as .jpg and the other as .png which includes the ground texture faded out at the margins of the model so it will blend well, and a lot of transparencies.
After I 'minimize textures' in MCX with the max set at 2048 x 2048 and save them, I end up with 3 textures, same size that are almost, but not quite identical. (The textures are not mipmapped.)
Attached is a screen clip of the 5 2048 x 2048 textures (where in SU there were 2) which illustrates the issue better than I can describe it.

Any solutions?

Thanks much,
Larry

 

[L_Rob]

Just a thought, but I wonder if the following might be part of the explanation: experimenting with a way to avoid the clone stamp look of repeat railing textures and because I have extra room on the orthoimage of the ground, I made a very long section of a railing, maybe 2000 pixels wide. If I'm careful, I only paint one side of the railing and it is seen from the far side, but I don't know if this must be interpreted as one texture or two textures that are mirror imaged. And if I make a mistake and have to paint the railing on both sides of the surface to make the sides match, this may require two textures because Sketchup probably exports what it sees on the surface and might not record it as a mirror image in the dae file. Don't know, but it might explain my almost identical but mirror imaged textures.

 

[=rk=]

If you want SU to preserve your original texture, then you must not scale or warp it in relation to other faces. Let's say you moved the yellow pin to get the image to warp properly, to get it to line up on your long rail. Those values are preserved in the SU document and not the image; so when you export from SU, it has to generate an image that already has those warpings in it - and a separate image for each unique warping.
One solution is to go back into MCX and reassign the "splinter" textures of the model to the master or original texture. This usually has the effect of getting everything right with minor discrepancies like having roof shingles misaligned or oddly patterned window panes - in your case you are probably going to have to carefully address how you go about applying texture to that rail and maybe even export it as a separate object, I'm not sure.

 

[tgibson]

How many textures do you have in the MCX Material Editor *before* minimizing textures?

 

[L_Rob]

Thanks guys,

Tom, I'll check to see how many textures I have in MCX before minimizing drawcalls, but it's well over 100 increasing every second I think.

RK, thanks for this; it explains most if not all of the issue. In order to have my high resolution orthoimage (well, Jon Patch's orthoimage I should say) fit my model which is constrained by the existing scenery I had to warp it some. But I'm also placing a lot of textures in areas of the orthoimage that I'm not otherwise using. This has worked OK before because I've previously not had to warp the large ground texture.

So looks like my choices are to have the model not fit, roads and shorelines not matching, etc, or in effect start over with the orthoimage split into several pieces (not) or live with extra textures.... or maybe I could export the large flat surface (the parking lot) from SU and warp the orthoimage layer in Photoshop to match it. If I could do it to the accuracy I'd need that is; the model is over a 1000 feet long.
Larry

 

[tgibson]

Can you use a separate texture for the things you need to warp, and would this save on the size of the extra textures at least?

 

[L_Rob]

Tom, I spent a fair amount of time warping my ground image in Photoshop so I did not have to warp it in Sketchup and did a test export. MCX arranged the individual textures differently, but no reduction in number or size. So either I did something wrong, or forgot something (likely) or it does not solve the issue. Almost all my texture placements in Sketchup are fine tuned by warping (with the pins), and maybe I don't really need to do this. But I hate having things look sloppy up close. In the past when I've been making things just for myself I've not worried that much about unnecessary textures, but this project will be shared; at least that's the idea. Oh well, it's worth what one pays for it. Nothing.

 

[=rk=]

I didn't write the draw call batcher, so I can only explain it the way I understand and use it. The reason I write anything at all is that it appears there is some misunderstanding. When I model in SU, I often mix photo images with colored polygons. When rendered, each texture image and each color are individual draw calls. It is as if the virtual graphics quill has to dip into a separate inkwell for each color. Draw call batching creates one or more textures, then takes each instance of that color and maps it to the new texture file(s). Presto! 15 colors, or more, just became a single draw call. It can also map smaller images to the texture file, so long as they fit. Now you could do this same thing in Photoshop, carefully stacking your images onto a 4096 max pixel size texture, but MCX won't scale the textures, so far as I know. So if your smaller textures are significant in relation to whatever you have as your maximum texture size in the batcher, you will only fit a few onto each minimized texture.

Now as far as moving the pins, try to look at it like each adjustment makes a new file. It is ok to warp the image if you can use it consistently, just use the exported warped and not the original with the .dae.

 

[L_Rob]

Thanks rk, I think I understand how the process works a little better, especially the effect of moving the pins. I think the fundamental problem is the rather crude method of building boats that I started with, where I make the boat directly off a couple of photos imported into SU. I'm still using that method more or less. Eventually this requires warping different surface textures, or copying the area of the photo being used, squaring it up and adjusting the height to width so it will fit without warping or scaling one axis. That's where I get lazy... it's hard to get it exactly right.

At least I hope I understood your note correctly.

Larry

 

[=rk=]

Ya no, that's about the size of it. One time I did a custom one-off scenery of Hospital Hill locally here in Portland, Or, for someone who liked my scenery - and I thought, "no problem, the models are already at the GE Warehouse and geo-located at that, I'll just run a quick conversion, placement and add some helo decks." Turns out either OHSU or the Shriner's Hospital (I forget which) is some ornate Gothic style structure with all these faces and abutments and whomever had modeled it had fractured the textures into some 300 shards of absurd dimensions like 9 pix by 84 pix and even MCX couldn't piece them together into anything less than about 150 MB for like 546 k of model which was only marginally clear - and yet somehow this model passed Google's very rigid but now defunct parameters for acceptance into the Building Layer.

 

[L_Rob]

rk, that prompts another thought; my first attempt at a boat was a conversion of a WSF ferry I found on the Google Warehouse, but no go in converting with MCX. The boat was rather simple, and had only one minor texture, the rest solid color, but it turned out that the problem was that the vertex count was way over the max of 65k. Eventually I got it down by cutting parts out, but the real problem was that it's very easy to create a vast number of triangles and vertices in SU by using the tools without thinking. The default circle for example has 24 segments. Put one circle default circle inside rectangle and the triangle count goes from 2 to a really huge number which I forget at the moment. And it only gets worse as you start adding more portholes or whatever this way. But based on your comments, I now wonder if there is another potential problem. Let's say you used a warped texture to paint a surface with a bunch of 24 segment holes in it using the 'project' setting based on another surface that is not co-planar; each one of those new triangles might need a separate texture. Could this happen?

Since that first attempt I've found a fair number of ways to minimize the triangle counts without sacrificing the model quality, but it's something that I have to continually think about. And maybe it's even more important than I thought.

 

[=rk=]

SU would always allow parallel co-planar triangles to occupy the same texture and since a porthole is ultimately a plane, you would be ok. Additionally, so long as you are applying textures by projection, any triangles colored based on that orientation would be part of a single texture. A problem can arise if you select a surface and then context click "Make Unique Texture," which essentially does the same thing as moving the yellow pin. See, when you choose to adjust position and you see the entire texture sheet superimposed over the model, that's how it "looks" in the texture folder and when you swing that yellow pin, it is as if you are doing a cookie cut of that texture sheet at the orientation you've arranged. If you do it for every window and doorway of an otherwise simple building, you will have a relatively large texture folder.

There is also potential for unanticipated bulk because SU recognizes complex polygons. Gmax automatically triangulates every shape, so if you make a box in Gmax, it is a minimum of 12 polygons, meanwhile SU will report 6 four sided polygons for the box it makes, but then when you import into MCX you see a much higher count. We know MCX doesn't triangulate the faces, so those triangles must be calculated, but for whatever reason not counted in the SU model properties.

 

[L_Rob]

=rk=, your comments have been really helpful. Here's another related question I would have never thought about prior. Often I have to wrap textures around curved surfaces, like the railing round the stern of a boat. It's vertical along the sides of the boat, then curves around the stern and often angles inward.
I start by painting the unwarped texture directly onto a fore and aft rail segment.

When the rail section is no longer coplanar, I use the eyedropper tool (alt-B) to copy the preceding texture and paint it onto the next. Using the 'pin' view, and if I did it right, there will be two pins that fix the texture at the margin last painted. I then move one of the two remaining pins to the right point on the rail texture and pull it so it snaps into the far vertex of the rail segment. When I lift the remaining pin, I see 2 dotted lines that converge at a dot, and if I pull the pin towards that dot, the texture snaps into perfect alignment; the rail wraps around the stern properly.

The question is, when I allow the texture to snap into its final shape this way, am I generating a new texture? (This has other applications too, besides just railings.)

 

[=rk=]

The thing you'll want to remember is that each polygon knows where it sits and which way it is pointed on the map of your texture sheet and it does not matter the orientation of adjacent polygons (this is important). Each pin except the red one changes the texture sheet somehow in relation to it's X/Y edges, so any polygons mapped to those will be lost or altered by moving pins. It's basic cartography.
There are many options that seem less contrived. We have discussed rails and they in particular exist as a regularly repeating pattern. Did you know that you can use the default fence elements in SU, as textures in .png format which allows transparency and MCX will preserve that transparency through the conversion to .DDS and into render in FSX? Obviously you want to texture both sides..
Getting back to your single texture sheet to cover the entire model, can you not create a section of rail and map it to the texture sheet; then set the section on the model and copy/paste it onto a curved pattern at the edge of the deck? It is very conservative in that each instance of rail calls the same piece of texture sheet, essentially one draw call. The technique you described above will create a unique texture for each adjacent polygon; have you tried this trick? It works especially well on things like tires and airplane cowls: so you take your texture and project it onto the model, or convert something you found online in .3ds and the texture doesn't sit right, or like in the .3ds, is actually garbled in places. In the View menu select "Hidden Geometry." Now when you click a surface, only that specific polygon you clicked highlights. Go to the edge of the tire where the texture starts to fall off, or the edge of the garble in the .3ds. Click the closest "good" poly with you eyedropper, then paint the first "bad" poly. Repeat this process, copying from a formerly bad polygon to the next one over. What happens is that you tend to draw the texture around the surface, as described above, but there is no moving of pins, so no new textures. I have recovered badly garbled models this way and, of course, adjusted my own nicely. Eventually you will get to the "edge" where the UV warp difference between the poly surface and texture is too different and the eyedropper starts giving random samples. Now context click to position texture. In the superimposed view, you can often see ways to shift the texture sheet, without changing it's UV, to cover the polygons on the edge of the tire or cowl.

 

[L_Rob]

Hi =rk=, thanks for the further detailed explanation. I've been guilty of mixing apples and oranges in this discussion; the single long railing is a current experiment because it was very complex and comes from a photo taken at a distance and I wanted to fake the look to some extent without modeling all the complexity.

For the boats, I use the method you mention (repeating textures), except I make my own transparency from photos of the boat in question; usually one or two rail segments extending the full width of the texture image, but because boats have so many different railings I stack 3 or 4 of the railing images on the same texture, say 128 x 512, or twice that.

As for the 'pins' I've definitely got the idea from you that if I'm using the fixed pin mode (red movement pin, green scaling, blue skew and yellow warp, and moving the blue and yellow pins will distort the texture. I would think that moving the green, (scaling pin) however does not create a new texture. Is that right?

But I don't use the fixed pin mode for repeating texture railings. The method I was describing only works when you see the yellow pushpins. It's really the only fast way to get the railings precisely aligned that I've found. My question had to do with placement of the last yellow push pin (not fixed pin mode); that when you lift it you see two dashed lines that converge at a dot, and the texture snaps to that shape. What is the physical meaning of those dashed lines? Now that I think of it, even though the texture seems to want to be a certain shape, it probably is creating a new texture. right?

I should be able to check this easily by using the dropper tool on a couple of segments and painting them onto a couple of very large text surfaces to exaggerate any distortion.

One way I *think* been trying to keep these extra textures down is to copy the railing from one side and flip along the appropriate axis and place it on the opposite side of the boat, and then not change it further. (Usually I make most of the railings during the half model phase of building which I later copy and flip, but sometimes I have to redo parts.) But this assumes that mirror images all use the same texture. Maybe that's not true! Transparent railings could be a special case because if they have not been previously painted, you can paint from either side.

Yes, I always work with the hidden geometry on, but I use the N key a lot to see what things are going to look like. I've used the technique you describe a lot (if I understood your trick right). It's very handy for pilings, posts, masts, etc. I copy and clean up the appropriate part of my image and then project this onto the post, but often the texture is such that the projection does not quite cover all of one side of the post. I can move the texture over a fraction and project the texture on polys in question and that usually solves it. But even if I'm doing a 6 sided post or piling, it really only looks good when seen roughly from the direction used for the projection plus or minus say 40 to 50 degrees. More recently I've been widening the texture 3 plus times and doing a lot of retouching so the whole surface looks appropriate, and then sequentially painting each poly on the pole or piling. No changing any pins. A lot more work, but it looks a lot better, especially if I use the clone tool on the texture image with right-left button clicked along the margins. That way I get a perfect match.

 

[=rk=]

Moving the green pin would have to create a new texture because it distorts the X/Y map of placement in relation to the X/Y map of the texture. If you have an 8 pixel wide texture and map the first 6 pixels in a row to your model, then come to #7 and find it is too close to the edge; when you stretch that texture, it moves pixel #7 from being the the edge, therefore it has lost it's orientation to the other polygons already mapped to the other pixels and must be made unique for this edge polygon and any other poly's mapped to it; Unless pixel mapping data also contains a scale value, a fact which I am unclear on.
It is acceptable to use mirror images because remember that the polygon has X,Y,Z map data, it also has U and V. One of the letters stands for orientation and the other either stands for scaling (which means you could move the green pin without consequence) or it further defines orientation, in the schema "U, V, W, X, Y, Z." So, for the affected poly's, reverse the UV's (flip horizontal or vertical in the SU context menu) and the poly's will map to the same texture.

The action of the texture "snapping" as you describe, I believe is a SU glitch and I will describe my hypothesis. When scaling an image using the green pin the "reflection" on the polygon for which the texture is being adjusted "looses alignment" with the semi-transparent superimposed repeating map of the texture sheet. At this point, if you move the yellow pin, as you describe, the reflection snaps into alignment with the superimposed map. If you accept the change without touching the yellow pin, the resulting texture is neither the reflection, nor the part of the map that was "over" the polygon; meaning you, or at least I, have no discernible perception over the action. To continue I must examine a large polygon or group of poly's, estimate the offset and try again; however, if I simply click the yellow pin, without moving it, the texture snaps and presents on the polygon exactly as I would expect it. Try it and see if you encounter something I've missed.

To offer further observation on the dashed lines, I have noticed the pins default to an exact square orientation to each other. If you are texturing a hangar door, you can move the red pin to the bottom corner of the door in the image, (done by "unsticking" the pin by click/click/dragging it, click to re-stick) then you can slide the image to the corner of the door in the model, with the red pin right on the corner of the geometry. When you scale the image, it pulls exactly from and to that corner.
When you re-position the pins this way, you need to preserve the angles or odd things happen. Say you move the red "anchor" pin to the corner of the door. Now click-drag the blue "height" adjustment pin to a spot above (higher on the screen) than the red pin. When you are close a dashed line will appear and the pin will tend to "stick" to this line. Then click-drag the green "width" pin, there is also a dashed line horizontal back to the red. Now when you click-drag the yellow "perspective" pin, it will want to stick at the intersection of the green vertical and blue horizontal dashed line. If you do not perform this "squaring" alignment, then when you scale the image it warps oddly, sort of in an axis around these pins and I believe the non-square configurations are a way to add fidelity to the scaling action, like scaling it in a helix to wrap around a propeller or mimicking parallelax perspective, but the math is far too complex for this monkey poking with sticks.

 

[L_Rob]

=rk=, I spent some time with a couple of text textures trying to figure out exactly what the pins do; there are some distinct oddiites. Rather than trying to guess what the intent or purpose is, maybe I can just list a few things I'm more or less certain of:
A fundamental distinction between the fixed pin with red blue green and yellow boxes and the yellow push pin mode is that in the push pin mode moving a pin does not move any others. In the former case, moving the red, green or blue pins moves some of the others too, depending on the purpose.

There are two types of blue dashed lines (at least they are blue in the default styles). The very faint dotted lines remain orthogonal with respect to the texture. If the texture for a rectangle gets badly distorted by accident you can move pins until these dotted line appear and use them to restore the texture to its unwarped state.

I'm not clear on what the darker blue lines that meet at a dot are actually indicating. I have a suspicion that they give an indication of the state or shape of the texture that was used to paint the surface. That texture may have been previously distorted. I wonder if another new texture is created when you move the pins so that the texture snaps into place. Could this just be telling me "OK, with this shape you have not created a new texture"? That is, what's the underlying purpose? Some sort of 'wrapping' behavior as you mentioned, but at the expense of a new texture?

The location where one finds the pins when you use texture>position seems rather complex;
If the texture is not rotated 90 degrees, the R, G B and Y pins act as described in the help file. However if it is rotated 90 degrees, those functions do not work; if you try to change the height to width ratio with the blue pin (or the yellow one), the texture warps. It's frustrating unless you re-position the pins so they are in their standard locations using the faint dotted lines as guides.

Frequently when you position a texture the pins are initially found at the corners of the semi transparent texture sheet which can be a pain when adjusting a small poly. For me the trick has been to click 'done' then use the dropper tool on the surface in question and paint it again... but slowly... If I do it too rapidly (quickly by habit) it does not work. I've I'm lucky, now when I position the texture, and provided it's on a rectangle, I now see the pins precisely at the corners of the rectangle which is very handy. But this does not always work and I'm not sure why. Sometimes the pins end up placed around a larger rectangle, or sometimes they remain at the corners of the transparent texture sheet.

I guess what I'm getting at is that it would be nice to have a set of rules that one could use to predict how the pins will act in different situations; what they are really doing. The help file at least is of little use for more complex circumstances.

 

[=rk=]

Perhaps you have heard the expression, "those that can do, those that can't teach." I always used to have trouble with instructions and help documents until I heard that phrase. In terms of perception, there are consequences to vision that don't exist in the 3d world and I believe that the action of the pins is largely an attempt to quantify and allow control of that. One of the biggest discrepancies is parallax, where an elevator shaft shrinks to a point - visually, of course; in the software program those four lines continue to converge indefinitely, or at least through to the limit of the allocated decimal places.

I interpret the pins to snap when the software believes it matches the parallax of the viewer. I see this most clearly when I am projecting textures onto an angled plane and the surface matches, from my view, exactly that portion of the texture sheet, and then when I rotate the object so my view is perpendicular to the surface, the texture appears elongated, as I would expect.