Problem creating oblong sculpties

Kwakkelde Kwak · December 15, 2011

Josh Susanto wrote:

Please do.

I don't have the time or patience to get between you and Chosen:)

Josh Susanto wrote:

Thank you.

You're welcome.

Josh Susanto wrote:

It will build you architectures consistent with current RL engineering constraints.

Exactly, and that's what most people in SL are after aswell, something they can recognize.

Josh Susanto wrote:

If RL construction materials behaved more like prims, I'd expect to see tetras used more already in RL. They're strucurally stronger than boxes.

Yes they are stronger, but they are near impossible to design and work with. (In SL even worse than in RL) Production and building costs are on a whole different level than your average concrete wall and floor or drywall construction. They are nice for flashy architecture, not for common building. We've lived in boxes for milennia and we will for some more. It's just the most efficient and cost effective way of building for human use. Btw I don't understand what you mean by "if RL construction materials behaved more like prims".

Josh Susanto wrote:

What you'll give up by using more tetras is a bit of snugness and familiarity. What you'll gain is more data to apply to intentional contrast elements such as rock, plants, furniture and appliances. Moreover, the tetras may allow even more compelling types of contrasts.

I don't quite understand what kind of data you are talking about.

Josh Susanto wrote:

OTOH, we can save even more data by making one-sided, strictly flat avatars and having them interact on a completely planar sim space. Maybe some kind of all-female shopping mall... in ancient Egypt....

That actually sounds quite interesting:)

Josh Susanto wrote:

I think that depends on how and when the new rules are implemented. Advanced notices and long adjustment periods are just good customer relations policies in almost any business. But things do have to change sometimes. Most consumers understand that. The other approach I expect will eventually be applied by LL is to make the pertinent changes abruptly without announcing them, but to prepare some kind of semi-plausible contingency explanation about finally having given in to an unstoppable groundswell of customer demand for such changes. They will, again, increase my chocolate ration.

A good percentage of all things you see at any time on your SL screen are probably sculpt. LL won't break all that content at once. They might do it in the future, if the sculptpercentage has decreased substantially. So I mean FAR future. What they could do is grandfather existing sculpts and apply the new rules to all new ones uploaded. I'd be all for that, sculpt creation would grind to a halt without breaking any content. People like yourself should be given the time to brush up their modelling skills ofcourse so they can continue their business with mesh instead.

Josh Susanto wrote:

Unless gradually converted. Especially in-world, for free. Almost everything I've made should be pretty easy to convert already.

Converted into what? Same geometry means same rendering cost. Your items might convert well, I looked at some on the marketplace and I'm sure they will. Others won't, like the giant mountains I described.

Josh Susanto wrote:

And how hard would it be for LL to provide sim owners with a "remove land" function that frees up that data?

No land means nothing to stand on...I don't think that will work very well. Besides that, you're comparing apples and pears. The 512 and 1024 mountains are outside of the sim and can't be walked on. They are scenery, not replacement for or addition to ground.

Chosen Few · December 15, 2011

Josh Susanto wrote:

I want to say thanks to all who have contributed to this thread, and to all who continue to contribute.

Even if I do come off as an a-hole, I imagine that this is a conversation that would also be helpful for some other people to read.

Please consider that before dropping out.

You're welcome, and I'm glad the information is helpful for you. I believe you're absolutely right that it is likely helping other readers as well. That's the main reason I do this, so that the readership at large can take what they need from having as much information available as possible.

At this point, I think we've more than established the broadest genralities of the medium, and now we're transitioning into what will likely be a VERY productive discussion about various concepts and techniques. With that in mind, if it's all the same to you, I'd like to drop most of the side chatter we've been throwing at each other about various philoshophical points. Not that it's not enjoyable to discuss such things, but I've got a new work project starting, and I won't be able to spend all day on these posts for a while.

Josh Susanto wrote:

1) Scene

2) RenderLayers

3) World

4) Camera

5) Cube

6) Lamp

7) nothing more

OK, then. Obviously your model did not import. Now we can concentrate on figuring out why.

I'd like to take a look at one of your OBJ's. As you mentioned, you can't upload an OBJ file to the forums. So, that leaves two options. One is you can upload it to a free file sharing site, such as File Dropper, and then just post the URL here. Another is you can open the OBJ in a text editor, and post the text here, via the Insert Code function. I'd prefer the former, as it would eliminatge the chance of error in the cutting and pasting.

Josh Susanto wrote:

What part do you think I didn't follow?

So you understand, it's not that I think you did or didn't follow anything in particular. I merely suggested it as one possibility among several for what MIGHT have gone wrong.

Josh Susanto wrote:

Doing that, I'm able to get the desktop folder up on the right, which is where I would expect to find the .obj, but it's not showing. In fact, according to Blender, the whole desktop folder appears to be empty. If it only shows compatible file types, that might make some sense. But it also does not show any of the folders I know are definitely there on my desktop.

Is your desktop in a nonstandard location on your hard drive? Maybe Blender and/or your OS is getting confused.

Try this:

1. Create a new folder on your C drive. Name it "objTest". Put one of your OBJ files in it.

2. In the Blender import dialog, under System on the left, click on the C drive.

3. All the folders on the drive should now be displayed on the right. Double-click on objTest.

4. You should now see your OBJ file, and you should be able to click on it for import.

By the way, just so you know, it's not the greatest idea to store files on your desktop. Since the desktop is always open, the references to its contents need to remain in memory at all times. The more you've got on there, the slower your computer will run. Also, it's really easy to inadvertently delete or alter things on the desktop as you're working. For best performance, and best safety, keep your files organized into folders that you can open only when needed, and then close when not.

Josh Susanto wrote:

If you believe your own explantions, then help me get my mesh production working,p>

Working on it.

Josh Susanto wrote:

If you believe your own explantions, then help me get my mesh production working,p>

So, ceteris paribus, I should be able to get two tetrahedrons for less than the cost of a cube?>/p>

Strictly speaking, yes. Assuming no extraneous subdivisions, two tetrahedrons would be eight triangles, from eight vertices, while a single cube would be 12 triangles, from that same number of vertices. So, all other things being equal, the two tetrahedrons have a slightly lower weight than the one cube.

I'm not sure what practical implications you have in mind for the comparison, though. It's not like you can put two tetrahedrons together to form a cube. If you need a cubic shape, then you need a cube. Tetrahedrons will only do if you need a tetrahedral shape.

As I'm sure you know, if do you do combine two tetrahedrons, there are only three possible outcomes for the resultant shape. If you join them face to face, you end up with a dipyramid, plus two hidden faces on the inside that you don't need. If you join them edge to edge, you get an irregular octahedron, with an extra edge that you don't need. And if you join them corner to corner, you get a different type of irregular octahedron, with an extra vertex you don't need.

Josh Susanto wrote:

IIf a cube has twice as many verts as a tetrahedron and three times as many triangles, then why are mesh builders not using more tetrahedrons? Or are they and I'm just not seeing it yet?p>

To what end?

If your goal is to make the simplest possible platform, then as Kwak suggeted, all you need is a single triangle. It need not have any depth to it.

If it's just one triangle it will only be visible from one side, of course. If you want to be able to see it from both sides, then you'll just need two of them, arranged back to back. If you merge the vertices, you'll end up with two faces, 3 verts. That's the simplest viewable-from-all-angles object you can make. (Well, nearly all angles, anyway. If you're viewing it orthographically, right along the edge, it would be invisible. But since SL only has a single perspective camera, the chances of ever aligning things that precisely are nill.)

Josh Susanto wrote:

But, even if there is, there really shouldn't be any way around that with sculpts either... correct?

By rights, no, there really shouldn't be. Ditto for prims, while we're on the subject.

But there's just no way to change that now, without destroying nearly all pre-existing content. If we were to abandon SL as we know it, and start completely over with SL 2.0, we wouldn't have to maintain the old rules. But as long as we're keeping the world we already have, prims and sculpties will always have to be inaccurately weighted.

Josh Susanto wrote:

But if we move the verts but keep the total pixel distribution uniform, then the pixel distribution between verts will change, won't it? This isn't even an applications question. This is a simple logic question.

Allow me to illustrate. In the image below, all four planes have the exact same geometric structure, and have the exact same texture on them. Yet the two on the left look quite different from the two on the right.

On the planes on the left, the texture image is distorted. The center of the texure is stretched horizontally, and the sides are squsihed. This is because each pair of vertices has the same number of texture pixels (texels) between them.

On the planes on the right, however, the texture looks perfectly uniform, exactly as it was designed to look, even though the arrangement of the vertices is not uniform. This is because each pair of vertices does NOT have same number of texture texels between them.

The planes on the left have uniform UV mapping, just a like a sculpty. So, the texture stretches on the larger polygons, and squshes on the smaller ones. The planes on the right, however, have had their UV layout properly adjusted, so that the larger polygons have more texels on them than the smaller ones do. Thus, the texture can look as intended, no matter where the vertices are.

Starting to make sense?

Josh Susanto wrote:

Do you make spheroids which are nonpolar in regard to verts or merely nonpolar in regard to the surface texture?

Both. It depends on what my particular goal is for the specific model in question. In some cases, I'll use a cubic sphere, like the one Drongle showed. (These are what all the z-spheres in Zbrush really are, by the way.) In other cases, I'll use a standard bipolar sphere. In other cases, I'll use something more like a soccer ball. It all depends in what's most practical in each case.

As for the texturing, sometimes I'll use the polar coordinates filter in Photoshop, to counter-distort the texture in advance, so that it appears to straighten out back to normal as the bipolar sphere distorts it. Other times I'll simply adjust the UV's to prevent distortion in the first place. Still other times, I'll apply the texture as a projection, or paint it directly onto the surface using a 3D paint tool, thus eliminating UV concerns almost entirely. Again, it all depends on what's best for the situation at hand.

Josh Susanto wrote:

Because for a nonpolar texturing to map to a nonpolar spheroid, the spheroid has to be nonpolar, too.

No, it doesn't. You can arrange your UV's literally any way you want. It's the UV's, and only the UV's, that dictate what part of the image maps to what part of the surface.

Since your experience with sculpties and prims has been such that the UV's have been entirely beyond your control, you're not yet aware of the possibilities that such control affords. You'll be blown away at how much you can do, once you start learning how.

Josh Susanto wrote:

For one of these things to be polar and the other not, the verts will have to come loose from the texture unless I start with the shape before creating the texture. If I do that, I'll not only not be getting a pucker, I'll not be getting other more desireable qualities that presently my my work distinguishable to my niche of consumers.

The vertices themselves are never married to the texture in any way at all. On the UV canvas, each UV point represents a vertex, and each point can be placed literally anywhere on the canvas.

Because you've never before had the option for anything even approaching that kind of control, it's not surprising that it didn't occur to you, and that you made he assumptions you did about how it must work. It should now come as welcome relief to you that this vital piece of the puzzle, of which you'd previously been unaware, does indeed exist. I have no doubt you'll be a monster with it, once you understand the how-to's.

Josh Susanto wrote:

Meanwhile, could you reproduce the shown mapping with the below alternate texture and show me the opposite pole?

Sure.

Oh, and here's a recreation of the original, with the displacement applied, as promised. I included the source sphere in the shot, for reference. I went with 16x16 this time, instead of 32x32, to make it easier to look at.

Needless to say, the end result has more than just 16x16 quads in it, substantially more, in fact. But that's the price you pay when matching every curve suggested by such a complex surface texture. If I were doing this for real, rather than just for an exercise, I'd use a much simpler displacement map.

That's peripheral to the main point, though, which is that there's no puckering of the texture going on at all. The reason for this is because of how I UV'ed it.

Take a look at the image below. The UV layout for default bipolar sphere is what's in the figure on the left, basically just a uniform grid. That uniformity utilizes the whole texture canvas very efficiently, of course, but it does so with no regard for the imagery of the texture itself, or the relative sizing of the polygons on the model surface. Thius, you end up with a pucker where the top and bottom of the texture each have to be squished down to a single point at each pole.

The UV layout I used for this example is the one on the right. The arrangement is an orb. The size and shape of each UV quad and triangle corresponds as well as possible with the size and shape of each polygonal face on the model. Hence, no apparent distortion as the texture wraps around the model.

This, of course, presents a different set of problems, one being that the top half and bottom half of the sphere occupy exactly the same canvas space, so the texturing ends up symeterical across the equator. To solve that problem, I could simply separate the two halves, and place each one on a different part of the canvas.

These are just a couple of examples among literally countless millions of possible ways to UV a sphere (or any other model). With sculpties, you had no choice but to use the fixed UV layout, just like the one on the left in the above picture. With arbitrary meshes, you can set it up literally any you want. What we've discussed so far is just the a tiny snowflake on the smallest tip of an icerberg the size of the known universe. The possibilities are endless.

Josh Susanto · December 15, 2011

>Exactly, and that's what most people in SL are after aswell, something they can recognize.

Mostly, yes. But there is a small market for surreal objects; irreal objects with realistic surface textures. Aliens also deserve proper alien architecture, and there certainly are aliens. Beyond that, I can already visualize several much less conspicuous ways to use tetahedrons. My point is not that everything should be made of them, but that if they're as efficient in mesh as has been suggested to me so far, they may very well be getting underutilized at this point.

>Yes they are stronger, but they are near impossible to design and work with. (In SL even worse than in RL)

A large part of that is simply lack of development of their use. The last 10 years have shown an explosion of building designs that might have been considered impossible without computer modeling.

>Production and building costs are on a whole different level than your average concrete wall and floor or drywall construction.

Again, partly due to lack of adequate development of the pertinent materials and applications. But the cost in mesh in SL should actually be a lot lower than for other components, which would seem to turn the component cost hierarchy more-or-less on its head, at least virtually.

>They are nice for flashy architecture, not for common building. We've lived in boxes for milennia and we will for some more.

Bucky Fuller's domes are noisier inside than Frankloid's, but they also don't burn down as easily. There are always trade-offs, and there's practically always some kind of buyer for anything truly innovative.

>It's just the most efficient and cost effective way of building for human use.

I suppose if we're supposed to apply all the same standards in SL as in RL, maybe I should stick to designing double-wide trailers?

>Btw I don't understand what you mean by "if RL construction materials behaved more like prims".

I mean that we can push a prim into another prim to any depth from any angle and just leave it there. I haven't seen that done with prefabricated concrete components. There are a bunch of other things that can't be as literally done with RL construction materials because they will just plain break and fall off. What are the tensile limits of mesh? For space and underwater architecture, especially, I should think mesh tetras off something plausible in terms of large polymer prefab components that could some day be produced in RL. No?

>I don't quite understand what kind of data you are talking about.

I meant data costs not incurred by using other less efficient kinds of components where they don't offer some advantage sufficiently offsetting the higher data cost in any specific context.

>That actually sounds quite interesting

My wife will see you in Mallworld. Meanwhile, I think we can do even better by making a quasi-monochrome hieroglyphic version in grainy sepiatone. I might add one male character, though. A Rudolph Nureyev avatar from Afternoon of a Faun.

>A good percentage of all things you see at any time on your SL screen are probably sculpt.

Linden-produced items included. I think that might be a major reason they haven't already begun the process. Maybe we should keep an eye on that as an indicator of imminent action.

>I'd be all for that, sculpt creation would grind to a halt without breaking any content.

I'm a little bit uncomfortable with that because it would create a kind of competitive advantage for the grandfathered content. That might me a lot of extra money for me, yes, but that doesn't mean it's the right thing to do for the total market from the standpoint of sincere capitalism.

>People like yourself should be given the time to brush up their modelling skills ofcourse so they can continue their business with mesh instead.

Aside from tetrhedrons, one of the first things I want to start doing with mesh is just putting mesh version of my stuff on the contents tabs of my sculpt products, so users are ready with it any time and don't necessarily have to buy something else in order to go meshy.

>Converted into what? Same geometry means same rendering cost. Your items might convert well, I looked at some on the marketplace and I'm sure they will. Others won't, like the giant mountains I described.

Almost all my sculpt maps are at 128x128, so it's potentially a lot more shape data for people who want it than what they're currently seeing when the sculpts are rezzing as sculpts. A very simple shift to some mesh version could also offer them simpler and less costly shapes under what I now understand are the real data costs.

>No land means nothing to stand on...I don't think that will work very well.

They can stand on something else if standing is important at all. They can stand on 2 triangles, for example.

>Besides that, you're comparing apples and pears. The 512 and 1024 mountains are outside of the sim and can't be walked on. They are scenery, not replacement for or addition to ground.

I'm not very clear, it's true, on exactly how all the data demands are met in SL. I just know that the ground is not strictly necessary, and that it uses a lot of data. Getting rid of it was just a suggestion, really. What if people want to make their own kind of ground instead? Why should it always be redundant?

Drongle McMahon · December 15, 2011

These spheroids are hot! Thanks for getting me interested in them.

Kwakkelde Kwak · December 16, 2011

Josh Susanto wrote:

My point is not that everything should be made of them, but that if they're as efficient in mesh as has been suggested to me so far, they may very well be getting underutilized at this point.

I think you need to stop thinking in prims and start thinking in mesh. Yes I can't think of a 3D object that uses less data per prim than the tetrahedron. But that doesn't mean it's the most efficient building block, both in use of space and in use of data. You can make a door- and windowless building with 11 planes (2 times 6 minus the underside of the floor), that would be 22 triangles. Those 22 triangles would allow only 5 tetrahedrons. I don't think that would build anything that could be considered a building.

Josh Susanto wrote:

A large part of that is simply lack of development of their use. The last 10 years have shown an explosion of building designs that might have been considered impossible without computer modeling.

Yes things are possible now that weren't possible before. CAD helped a lot with that. Still, look out the window and tell me how many of the buildings you see are made out of box like components, then count the number of tetrahedron based builds. My guess is you are looking at a 100% to 0% difference. Building techniques like this can be compared with the cast iron constructions from the 18th, 19th and 20th century. They were used for big constructions where their specific characteristics suited their function better than brick and wood. However, I can't think of any major use in dwellings from the top of my head. Yes cast iron was used in some, but always used the way a wooden column or beam would have been used. New material yes, new way of construction, no. Part of the reason for this is the stubborn nature of the building industry, more important is the fact the technique simply doesn't suit normal housing.

As for SL, again I would say stop thinking in prims, start thinking mesh. Any curved surface made on a computer is kind of built out of tetrahedrons, though less uniform as in the dome example you gave. Any quad on the outer surface of a double bent plane is two triangles. if you divide the quad the other way on the inside...what do we have? tetrahedrons...

Josh Susanto wrote:

Again, partly due to lack of adequate development of the pertinent materials and applications. But the cost in mesh in SL should actually be a lot lower than for other components, which would seem to turn the component cost hierarchy more-or-less on its head, at least virtually.

You can't save a lot of data on an SL box. You can save a lot of data on a sphere or torus. You can save some data on a cylinder, you can save a lot of data on sculpts. Using mesh isn't more efficient just because it's mesh. It can be more efficient because you have full control over the objects. Start making 48 sided cylinders and you would be better off with a standard prim, well cost wise ofcourse, not visually. (I take it you ment rendering cost not prim cost.) If you ment primcost, I agree, but that would mean most prims would become obsolete and one of the nice things about SL in my opinion is the fact anyone can fairly build something nice quickly, without having access to or understanding of 3rd party 3D software.

Josh Susanto wrote:

Bucky Fuller's domes are noisier inside than Frankloid's, but they also don't burn down as easily. There are always trade-offs, and there's practically always some kind of buyer for anything truly innovative.

Fire hazards are mostly due to the interior, metal structures won't burn under normal circumstances no, but they will collapse rather wuickly, which can be a lot more dangerous.

Josh Susanto wrote:

I suppose if we're supposed to apply all the same standards in SL as in RL, maybe I should stick to designing double-wide trailers?

I don't think they are the norm where most people live. In SL you should build what you want to build though, whether it looks medieval, comtemporary or alien and whether it is out of boxes or tetrahedrons.

Josh Susanto wrote:

I mean that we can push a prim into another prim to any depth from any angle and just leave it there. I haven't seen that done with prefabricated concrete components. There are a bunch of other things that can't be as literally done with RL construction materials because they will just plain break and fall off. What are the tensile limits of mesh? For space and underwater architecture, especially, I should think mesh tetras off something plausible in terms of large polymer prefab components that could some day be produced in RL. No?

Those prefab components are relatively expensive in RL. Imagine all the molds needed. Every build would need new ones, opposed to the normal which can be used over and over (and over). Tensile limits of mesh? I guess you mean RL mesh. far greater than any box like object ofcourse, compared to the amount of material used. There's a lot of development in materials, so it will only become greater, this doesn't change the fact the entire technique is pretty much useless for normal construction. Only stronger shape I can think of is a solid dome, which is even less flexible in use than the mesh. And guess where the dome is used? in space...and under water:)

The whole thing with anything that's not a box is that they won't connect very well. On a flat surface you can have building blocks in repeated uniform triangles, squares or hexagons. In 3D space this is not the case, hence the need for computers and production techniques to make everything fit nicely, using various shapes.

Josh Susanto wrote:

My wife will see you in Mallworld. Meanwhile, I think we can do even better by making a quasi-monochrome hieroglyphic version in grainy sepiatone. I might add one male character, though. A Rudolph Nureyev avatar from Afternoon of a Faun.

I actually once considered making a monochrome sim. Together with the cartoonlike possibilities Loki and others have shown on the forums and some Sin City color effects and atmosphere, that could look amazing.

Josh Susanto wrote:

I'm a little bit uncomfortable with that because it would create a kind of competitive advantage for the grandfathered content. That might me a lot of extra money for me, yes, but that doesn't mean it's the right thing to do for the total market from the standpoint of sincere capitalism.

Capitalism, blah! Besides, as you said yourself in some cases the sculpt is preferred over the mesh. Especially since we can't make meshes bigger than 64 meters. It's not ALL about render efficiency. Advantages for older things are part of SL anyway, I can live with that. Megaprims that can't be created any longer, higher stipends for old premium accounts, lower tiers if I'm not mistaken.... it will always be here.

Josh Susanto wrote:

Aside from tetrhedrons, one of the first things I want to start doing with mesh is just putting mesh version of my stuff on the contents tabs of my sculpt products, so users are ready with it any time and don't necessarily have to buy something else in order to go meshy.

If you change your items to mesh without changing any of the geometry, you gain nothing. The wireframe will be the same, so will the rendering cost. The only result you will see is probably higher prim cost.

Josh Susanto wrote:

Almost all my sculpt maps are at 128x128, so it's potentially a lot more shape data for people who want it than what they're currently seeing when the sculpts are rezzing as sculpts. A very simple shift to some mesh version could also offer them simpler and less costly shapes under what I now understand are the real data costs.

As Chosen would say: A sculpt is a sculpt is a sculpt. Whether it's 64x64, 128x128 or 1024x1024, the number of triangles on your screen would be the same. As I said above, changing to mesh won't save you anything, not renderwise anyway. I don't know if they would be transferred between servers and viewers any slower or faster. You can only save data by removing triangles, which is probably very possible in a lot of your creations.

Josh Susanto wrote:

They can stand on something else if standing is important at all. They can stand on 2 triangles, for example.

I'm not very clear, it's true, on exactly how all the data demands are met in SL. I just know that the ground is not strictly necessary, and that it uses a lot of data. Getting rid of it was just a suggestion, really. What if people want to make their own kind of ground instead? Why should it always be redundant?

Interesting idea, I don't think it will catch on though. If you want to save on rendercost for the ground, you can also start building at 2000 meters high and set your landing point there. Not sure if the data would be loaded when entering the sim, but your graphics card wouldn't have to render it. You can also turn off water and ground rendering in the advanced menus, but that's ofcourse only viewer side and can't be forced onto others when entering the sim, nor does it remove the physical ground.

Josh Susanto · December 16, 2011

Summary: YES, IT FINALLY LOADED.

>I'd like to drop most of the side chatter we've been throwing at each other about various philoshophical points.

Agreed. It may have been necessary from a personality conflict standpoint in order to establish that, while our frustrations here are different, they nonetheless have a common element which we can probably address.

>I'd like to take a look at one of your OBJ's.

I emailed it to someone who hates Blender, but who was nonetheless willing to run it through Blender for me to convert to .dae, specifically so that I could then load it to Sketchup. The Sketchup load was no problem at all, with the.dae straight from my desktop. Clearly Blender and Sketchup are different in some other important ways, aside from the Sketchup focus on extrusion. The obj started as a mushroom sculpt and ended up just fine in Skechup, still looking like the same mushroom shape as before. Thanks again for suggesting Sketchup, which I imagine I will use for at least a few things eventually, even if it means I have to convert obj to dae first.

>So you understand, it's not that I think you did or didn't follow anything in particular. I merely suggested it as one possibility among several for what MIGHT have gone wrong.

I think we've both been expressing a lot of frustration here. Hopefully, now we can move past that and hope everyone reading the earlier stuff will just have a good laugh.

>1. Create a new folder on your C drive. Name it "objTest". Put one of your OBJ files in it.

Check.

>2. In the Blender import dialog, under System on the left, click on the C drive.

Check.

>3. All the folders on the drive should now be displayed on the right. Double-click on objTest.

Check

>4. You should now see your OBJ file, and you should be able to click on it for import.

Check; found; imported, viewed;.... mushroom. EXCELLENT. You may now subject me to whatever forms of ridicule may give you the greatest pleasure. You have earned it. THANK YOU.

>By the way, just so you know, it's not the greatest idea to store files on your desktop. Since the desktop is always open, the references to its contents need to remain in memory at all times. The more you've got on there, the slower your computer will run. Also, it's really easy to inadvertently delete or alter things on the desktop as you're working. For best performance, and best safety, keep your files organized into folders that you can open only when needed, and then close when not.

AND, when a desktop folder appears while accessing files with an app, it may be there just for show, and not actually be content-accessible in such a way. I'm starting to remember why I was an avowed Apple user until 2007. Don't worry, though; this is not even close to enough to make me consider going to Apple again after what happened with them. In the interest of limiting side chatter, please also don't mention American Airlines or Citibank.

(So, ceteris paribus, I should be able to get two tetrahedrons for less than the cost of a cube?)

>Strictly speaking, yes. Assuming no extraneous subdivisions, two tetrahedrons would be eight triangles, from eight vertices, while a single cube would be 12 triangles, from that same number of vertices. So, all other things being equal, the two tetrahedrons have a slightly lower weight than the one cube.

Great.

>I'm not sure what practical implications you have in mind for the comparison, though. It's not like you can put two tetrahedrons together to form a cube. If you need a cubic shape, then you need a cube. Tetrahedrons will only do if you need a tetrahedral shape.

I will use a cubic shape if I need a cubic shape. But cutting an opening into the side of block seems like it might be less data efficient than slapping 2 comparatively flat right tetras together to create a rectangular wall with a triangular opening at the bottom, for example. I understand I can get a similar wall with even less data, but there is realism and then there is realism. I just might not want infinitely thin walls.

>As I'm sure you know, if do you do combine two tetrahedrons, there are only three possible outcomes for the resultant shape. If you join them face to face, you end up with a dipyramid, plus two hidden faces on the inside that you don't need.

Understood. If I put any face of a solid against the face of another solid in such a way that one of the faces is completely hidden, I might as well eliminate the hidden face.

>If you join them edge to edge, you get an irregular octahedron, with an extra edge that you don't need. And if you join them corner to corner, you get a different type of irregular octahedron, with an extra vertex you don't need.

Yes, I get it. Basically, if I do inefficient things with tetras that people also already do with cubes, the tetras will also be inefficient.

My thinking about this is more in terms of tetras penetrating each other, and/or being used as solid plane-like objects any place where people simply haven't given much thought to why they continue to use boxes.

>To what end?

If even the occasional block can be replaced with 2 tetras (without hurting the total aesthetics of the stucture) reducing thus the data cost, there's an economy of scale should some percentage of a structure be produced in such a way. If some of them can be replaced with a single tetra, this effect only stands to be escalated. What if a blocky building uses the equivalent of 100 mesh blocks and you can replace about half of them with 1 or 2 tetras? That changes the shape of your building, but how much data might you be able to save?

>If your goal is to make the simplest possible platform, then as Kwak suggeted, all you need is a single triangle. It need not have any depth to it.

I might do that for my own use, but I wouldn't try to sell it.

(But, even if there is, there really shouldn't be any way around that with sculpts either... correct?)

>By rights, no, there really shouldn't be. Ditto for prims, while we're on the subject.

That's hard for me to understand. If prim equivalency uses prims for comparison, how can they be undercharged for data cost compared to themselves? Isn't this a bit like when people describe the 7th harmonic as being "out of tune"?

>But there's just no way to change that now, without destroying nearly all pre-existing content. If we were to abandon SL as we know it, and start completely over with SL 2.0, we wouldn't have to maintain the old rules. But as long as we're keeping the world we already have, prims and sculpties will always have to be inaccurately weighted.

That's pretty weird.

(But if we move the verts but keep the total pixel distribution uniform, then the pixel distribution between verts will change, won't it? This isn't even an applications question. This is a simple logic question.)

>Allow me to illustrate. In the image below, all four planes have the exact same geometric structure, and have the exact same texture on them. Yet the two on the left look quite different from the two on the right.

> On the planes on the left, the texture image is distorted. The center of the texure is stretched horizontally, and the sides are squsihed. This is because each pair of vertices has the same number of texture pixels (texels) between them.

Which one is distorted is a matter of what one considers to be a distortion. I understand that "distorted" is probably a term thoroughly reified by its use in these contexts. To me, a uniform distribution of pixels over a non-uniform distribution of shape determinants could also be considered a kind of distortion.

>On the planes on the right, however, the texture looks perfectly uniform, exactly as it was designed to look, even though the arrangement of the vertices is not uniform. This is because each pair of vertices does NOT have same number of texture texels between them.

That's fine, but I don't design my textures (when I design them) with the idea of having them map uniformly. I specifically want them to take on the grain of the shape which is derived from them, in order to accentuate curvature. I appreciate that you're explaining that there are other options, though. I expect I'll eventually want to use whatever is available for at least something, so I agree the other options are worth mentioning.

>The planes on the left have uniform UV mapping, just a like a sculpty. So, the texture stretches on the larger polygons, and squshes on the smaller ones. The planes on the right, however, have had their UV layout properly adjusted, so that the larger polygons have more texels on them than the smaller ones do. Thus, the texture can look as intended, no matter where the vertices are.

>Starting to make sense?

I see that. But with stuff like what I've been making, I'd need to have some way of exerting a lot of control over the contours as related to image itself, regardless of how uniformly it might be nice to have it distributed. I'll need to be able to produce the shape with either no verts at all, or with a bunch of extra verts, and then narrow the verts down strictly to those which occur at the points of most acute changes to surface angle. Is there some kind of algorithm that assigns vert priority based on positions of maximum curvature, given a model object of some much higher resolution?

(Do you make spheroids which are nonpolar in regard to verts or merely nonpolar in regard to the surface texture?)

>Both. It depends on what my particular goal is for the specific model in question. In some cases, I'll use a cubic sphere, like the one Drongle showed. (These are what all the z-spheres in Zbrush really are, by the way.) In other cases, I'll use a standard bipolar sphere. In other cases, I'll use something more like a soccer ball. It all depends in what's most practical in each case.

Assuming I wanted to, how would I find the edge of the surface image on one oy your soccer balls?

>As for the texturing, sometimes I'll use the polar coordinates filter in Photoshop, to counter-distort the texture in advance, so that it appears to straighten out back to normal as the bipolar sphere distorts it.

That's actually the whole reason I wanted Photoshop. What I really want, though, is something that will simply stretch each line of a cutout horizontally to the edges of the frame (and inward to fill any gaps, if there). With that, I'd already be able to cut out statues and such, and sculpt them with all the dead verts on each side pushed onto the shaped portion while keeping the shape correspondent to the surface image.

>Other times I'll simply adjust the UV's to prevent distortion in the first place. Still other times, I'll apply the texture as a projection, or paint it directly onto the surface using a 3D paint tool, thus eliminating UV concerns almost entirely. Again, it all depends on what's best for the situation at hand.

Well explained.

(Because for a nonpolar texturing to map to a nonpolar spheroid, the spheroid has to be nonpolar, too.)

>No, it doesn't. You can arrange your UV's literally any way you want. It's the UV's, and only the UV's, that dictate what part of the image maps to what part of the surface.

Sounds good. But there are going to have to be some major shortcuts in terms of the app making some intelligent decisions about what point needs a vert and what point doesn't.

>Since your experience with sculpties and prims has been such that the UV's have been entirely beyond your control, you're not yet aware of the possibilities that such control affords. You'll be blown away at how much you can do, once you start learning how.

I think it's overstated to say that it has been entirely beyond my control. I've been limited to 1024 data points on strictly rectangular fields, but, because the data I export is of higher resolution than what will eventually have to rez, I can really move the verts around quite bit without changing the fundamental shape of the final object beyond shifting the concentration of detail. I just need to perform the same set of manipulations to the surface as I perform to the sculpt, in order to keep the pixels on the right part of the final object. OTOH, it's impossible me for to imagine not being able to do a lot better with more sophisticated tools, even if the end result might end up as another sculpt rather than as mesh. There are quite a few sculpts in which I have finally tweaked the image in various ways because, while sculpts make pretty good guesses about how to hold a photo image, they are necessarily imprecise guesses. If the back of the prim doesn't matter, I can often push some extra pixels around to the front by increasing the texture duplication by some small, but appreciable fraction. Also, because 128 sculpts rez at 32 by skipping lines, I sometimes offset one or both axes at 0.012 or thereabouts to trick the image back into what is something like its proper position, lost by the line skipping. I'm eager to find better ways to deal with such matters, but deficient control isn't exactly total lack of control. One could always have more control, sure.

(For one of these things to be polar and the other not, the verts will have to come loose from the texture unless I start with the shape before creating the texture. If I do that, I'll not only not be getting a pucker, I'll not be getting other more desireable qualities that presently my my work distinguishable to my niche of consumers.)

>The vertices themselves are never married to the texture in any way at all. On the UV canvas, each UV point represents a vertex, and each point can be placed literally anywhere on the canvas.

I'm not concerned with the verts being marries to the texture. I'm concerned with the shape being married to the texture. If the verts are somehow not married to the shape, that sounds helpful. Am I making my point clearly here?

>Because you've never before had the option for anything even approaching that kind of control, it's not surprising that it didn't occur to you, and that you made he assumptions you did about how it must work. It should now come as welcome relief to you that this vital piece of the puzzle, of which you'd previously been unaware, does indeed exist. I have no doubt you'll be a monster with it, once you understand the how-to's.

What I have been working withe very badly approaches what you seem to describe. That is; because the real number of verts on my real model is larger than the number of verts that will actually rez, I can somewhat control which ones will affect the final rezzed result and which ones will not. It's simply a matter of allowing some of them to intrude upon their neighbors.

(Meanwhile, could you reproduce the shown mapping with the below alternate texture and show me the opposite pole?)

Sure.

Not to try to seem more difficult, but I believe I asked for the opposite pole with the new image, not the same pole with the new image in which the poles of the image have been reverse. I should be seeing "where is the pucker" again, but constructed from corner texture data rather than center texture data, wrapped on where the 4 conrers of the image would come together under the same mapping as in the original example. Otherwise, you might as well write "where are the corners" and show me the image on the end of a standard SL cylinder.

>The UV layout I used for this example is the one on the right. The arrangement is an orb. The size and shape of each UV quad and triangle corresponds as well as possible with the size and shape of each polygonal face on the model. Hence, no apparent distortion as the texture wraps around the model.

So you've cut off the corners?

No wonder I wouldn't see the pucker. You're not actually projecting a square image onto a sphere as we discussed; you're projecting a roughly circular portion of it. That's not a bad thing to do, necessarily, but it's not what we described. If I'm willing to stuff a bunch of polygons up inside of my own polar spheroids, I supposed I could get something roughly analogous. Looking at the circular limits of the map as shown, I'm curious how things will actually line up where the pucker allegedly isn't, rather than at the opposite end where I wouldn't expect it anyway.

Damn. I was really hoping to maintain the more upbeat tone here.

Hopefully I'll be updating you in a little bit with some more positive Blender results. I care a lot more about that than about whether or not you're wasting the corners of your textures in order to defeat pleating. And I'm pretty sure that you've now cleared my main data bottlneck, so I'm almost ashamed to bother you with the spheroid question. Answer it or don't answer it as you like. I'm not going to beat you over the head with it.

Drongle McMahon · December 17, 2011

"...you're projecting a roughly circular portion of it..."

Simple. Just stretch the circular uv map out to the square boundary, as in the top here, with the result in SL below. If you look carefully, you can see that the equator of this sphere has the entire edge of the square spread around it.

(I'm afraid of Chose getting RSI from toom much typing! :matte-motes-smile:)

Chosen Few · December 17, 2011

Josh Susanto wrote:

Summary: YES, IT FINALLY LOADED.

Hallelujah!

Since it worked from a location other than your desktop, I have to assume something is unusually configured on your machine. That could explain a lot of the troubles you'd described previously, actually. It's well beyond the scope of this forum to try to straighten that out, though. The important thing is you now have a working solution.

Best advice: Use your desktop just for shortcut icons, and keep your data stored elsewhere (preferably on an entirely separate drive, if at all possible).

Josh Susanto wrote:

If prim equivalency uses prims for comparison, how can they be undercharged for data cost compared to themselves?

Larger prims get "undercharged", compared to smaller ones. With mesh models, we rightly accept that certain costs increase as size goes up, since the distance over which higher LOD's are viewable also increases. Those same factors apply in exactly the same way to prims and sculpties, yet the both of those are kept artificially at one unit of measure, regardless of size. That's as unfair for prims as it is for sculpties.

Josh Susanto wrote:

I might do that for my own use, but I wouldn't try to sell it.

That's good, because I seriously doubt there could EVER be a market for a single triangle. It's analogous to putting a single letter on a piece of paper, and trying to sell it in a book store.

Josh Susanto wrote:

Which one is distorted is a matter of what one considers to be a distortion. I understand that "distorted" is probably a term thoroughly reified by its use in these contexts. To me, a uniform distribution of pixels over a non-uniform distribution of shape determinants could also be considered a kind of distortion.

Once again, you seem so focused on the semantics that you've apparently missed the point.

Josh Susanto wrote:

I see that. But with stuff like what I've been making, I'd need to have some way of exerting a lot of control over the contours as related to image itself, regardless of how uniformly it might be nice to have it distributed. I'll need to be able to produce the shape with either no verts at all, or with a bunch of extra verts, and then narrow the verts down strictly to those which occur at the points of most acute changes to surface angle. Is there some kind of algorithm that assigns vert priority based on positions of maximum curvature, given a model object of some much higher resolution?

Josh, when you will accept the fact that nothing I've ever shown you, or ever will show you, will cause you to lose any of the abilities you already have? The whole point is for you to have MORE control, not less.

Think about what you just said. You want the be able to map the real contours of the surface to those suggested by the texture, right? Well, what if a particular texture detail you want to emphasize happens to fall in between two vertices instead of directly on one of them. If the UV's are locked, you have no way of correcting for that. However, if the UV's are adjustable, as is the case with every non-sculpty mesh model in the world, you can make the proper corrections very easily.

For a quick example, let's revisit that simple brick pattern I used earlier. If I apply that texture to a sculpty plane, it looks like this:

Notice none of the vertices happen to correspond with the corners of the bricks. If I want to make a relief sculpture from this texture, with that existing relationship between the texture and the surface, the results won't be pretty. I've got lots of extra vertices in the middle of each brick, where I don't them, and almost none in between the bricks, where I do need them. Without the ability to alter that relationship, there's just no way to apply relief to the contours that differentiate the bricks from the mortar.

However, if I CAN change the relationship between the texture and the surface to whatever I want it to be, it's a whole other story. By adjusting the UV layout, I can create exactly the 1:1 relationship between the texture and the surface topology that I need. I'm free to concentrate vertices at the edges of the bricks, as well as get rid of all the unneeded ones in the middles.

Take a look:

With the above layout, I can very easily raise the bricks, and leave the mortar flat. See:

It's also well worth noting that the triangle count is only 734, as opposed to the 2048 in the first picture. So not only does the this end result look far better than the non-UV-adjustable sculpty ever could, it's also got 2/3 less polygons.

By the way, notice that in the version on the left, the bricks look rounded over while in version on the right, they look flat-faced. That's because I softened the edge normals on the left one, and hardened the edge normals on the right one. Normals are another thing you have no control over with sculpties, but which you can employ to great effect with meshes.

As I said, once you get into this, you'll be astounded at how much you can do that you could never even dream of with sculpties.

Josh Susanto wrote:

Assuming I wanted to, how would I find the edge of the surface image on one oy your soccer balls?

Assuming I've done my job properly, you'll never see a texture edge at all, on any model, whether it's a soccer ball or anything else. To know what's what, you'd have to look at the texture itself, and the UV map.

Josh Susanto wrote:

Sounds good. But there are going to have to be some major shortcuts in terms of the app making some intelligent decisions about what point needs a vert and what point doesn't.

I'm not sure what you're saying here. I think your definition of "vertex" might be a bit off.

Josh Susanto wrote:

I think it's overstated to say that it has been entirely beyond my control. I've been limited to 1024 data points on strictly rectangular fields, but, because the data I export is of higher resolution than what will eventually have to rez, I can really move the verts around quite bit without changing the fundamental shape of the final object beyond shifting the concentration of detail. I just need to perform the same set of manipulations to the surface as I perform to the sculpt, in order to keep the pixels on the right part of the final object.

No, it's not overstated at all, and what you're describing here is NOT UV mapping. Again, because you don't yet have any experience with it, you're not yet equipped to understand. You're making inaccurate assumptions based on other experiences you have had that, while seemingly similar to you, really are not related to the actual subject at hand.

Josh Susanto wrote:

I'm not concerned with the verts being marries to the texture. I'm concerned with the shape being married to the texture. If the verts are somehow not married to the shape, that sounds helpful. Am I making my point clearly here?

Sorry, but no, you're not being clear at all. Vertices can never be "not married" to the shape of the model. For all intents and purposes, they ARE the shape.

UV points are what determine the relationship the texture has with the surface. As I tried to explain before, every vertex is represented on the texture canvas by one, if not several, UV points. Each of those points can be anywhere you want it to be on the canvas. If you want uniform, even spacing, like on a sculpty, you can have that. If you want something less restrictive, you can have that, too. You can do it any way you want.

Josh Susanto wrote:

What I have been working withe very badly approaches what you seem to describe. That is; because the real number of verts on my real model is larger than the number of verts that will actually rez, I can somewhat control which ones will affect the final rezzed result and which ones will not. It's simply a matter of allowing some of them to intrude upon their neighbors.

I get what you're saying, but it's so far removed from what UV mapping really is, it's effectively unrelated.

Josh Susanto wrote:

Not to try to seem more difficult, but I believe I asked for the opposite pole with the new image, not the same pole with the new image in which the poles of the image have been reverse. I should be seeing "where is the pucker" again, but constructed from corner texture data rather than center texture data, wrapped on where the 4 conrers of the image would come together under the same mapping as in the original example. Otherwise, you might as well write "where are the corners" and show me the image on the end of a standard SL cylinder.

That IS the opposite pole. As I explained a little further down in that last post, I mapped the sphere to be symmetrical across the equator. I didn't have to do it that way, of course, but it just happened to be a quick and easy thing to do, so I did it. My purpose at that point in the discussion, if you recall, was merely to demonstrate that puckers need not exist. There are million other ways to do it besides just the one way I happened to do it in that example.

If it makes you feel better, here it is, remapped to bring the corners to the middle:

And here's the new UV map:

This took just an extra minute, to chop up the map, and rearrange it. Alternatively, I could have left the map intact, and offset the texture placement by 50% in each direction, and the end result would have been the same.

Josh Susanto wrote:

So you've cut off the corners?

Yes, and that's a problem because?

It's perfectly normal to have unused canvas space on a UV map. It happens more often than not. It's best to minimize that wherever possible, of course. But it's not a problem to have some. In fact, it's usually advantageous.

Had I wanted to utilize the entire canvas, I very easily could have. Drongle has shown one method for doing that. There are millions more. I just opted not to do it for what I thought would be a simple demonstration that would have been over and done with the moment you saw it. I never envisioned that we'd be going back and forth about it for a week. I shoudln't have to example every possible applied permutation just for you to accept that an applicable principle is indeed a principle, and is indeed applicable.

Josh Susanto wrote:

You're not actually projecting a square image onto a sphere as we discussed; you're projecting a roughly circular portion of it.

We never discussed projecting anything. What we DID discuss was the fact that you puckers don't have to exist, after you insisted they did. I merely demonstrated one way of preventing them, among thousands of possible ways.

Using a projection would be another way.

Josh Susanto wrote:

That's not a bad thing to do, necessarily, but it's not what we described.

What we described was eliminating puckers via rearranging the UV map. That's exactly what I did. If you don't like that particular mapping, you're free to use any of a hundred million other possibilities. And if you don't like any of those, there are a million million million more where they came from.

Josh Susanto wrote:

If I'm willing to stuff a bunch of polygons up inside of my own polar spheroids, I supposed I could get something roughly analogous.

No, you couldn't. Moving polygons around is NOT the same thing as moving UV's around. Until you accept that fact, you will remain hopelessly lost.

Josh Susanto wrote:

Looking at the circular limits of the map as shown, I'm curious how things will actually line up where the pucker allegedly isn't, rather than at the opposite end where I wouldn't expect it anyway.

How many times do I have to say it? What part of "symmetrical across the equator" wasn't clear? Both poles are identical, because both poles have exactly the same UV mapping. Notice you only see half as many quads in the orbital layout as in the rectangular layout. This is because the other half are positioned in exactly the same place as the first half.

The SL avatar utlizes this same technique. That's why whatever you do to one arm happens to the other arm. The UV's for both arms are in the same place on the canvas, stacked right on top of each other. It's an incredibly common technique.

Josh Susanto wrote:

Damn. I was really hoping to maintain the more upbeat tone here.

I don't know what the hell you think you have to be upset about. There are millions of millions of millions of millions of possibilities open to you now that weren't before. The fact that you had inaccurate, and largely irrelevant, expectations about the workings of one particular example does not change that in any way.

Josh Susanto wrote:

Hopefully I'll be updating you in a little bit with some more positive Blender results. I care a lot more about that than about whether or not you're wasting the corners of your textures in order to defeat pleating. And I'm pretty sure that you've now cleared my main data bottlneck, so I'm almost ashamed to bother you with the spheroid question. Answer it or don't answer it as you like. I'm not going to beat you over the head with it.

I'm happy to provide information wherever and whenever I can, and I'm very glad that you're looking forward to getting positive results with Blender.

For the record, though, I did not "waste the corners". I opted for a very quick solution to a problem so simple it's practically a non-issue (for anything except sculpties, anyway), just to make a point. For a round object, a round map is often the most painless solution. I don't understand why you think there's anything wrong with it.

The reason puckers exist on sculpties (assuming you don't correct for them in the texturing itself) is precisely because you cannot adjust the UV mapping at all. There's no other reason.

Edited for spelling, and to respond to additional points I had to skip over the first time though, for time reasons.

Josh Susanto · December 17, 2011

>If you look carefully, you can see that the equator of this sphere has the entire edge of the square spread around it.

That's a fine effect for spheres that mirror at the equator, but I'm making rocks.

Josh Susanto · December 17, 2011

>These spheroids are hot! Thanks for getting me interested in them.

Please contact Firefury Burns about that.

He'll know why.

Drongle McMahon · December 17, 2011

Chosen already explained how that that was simple to arrange. The top and bottom maps here are stacked for simplicity. It's just as easy to make them separate, so they use different parts of the textures and displacement maps, or to use the same UV maps but different materials fpr top and bottom.

Josh Susanto · December 18, 2011

>I think you need to stop thinking in prims and start thinking in mesh. Yes I can't think of a 3D object that uses less data per prim than the tetrahedron. But that doesn't mean it's the most efficient building block, both in use of space and in use of data. You can make a door- and windowless building with 11 planes (2 times 6 minus the underside of the floor), that would be 22 triangles. Those 22 triangles would allow only 5 tetrahedrons. I don't think that would build anything that could be considered a building.

I was thinking more of economies of scale to be produced by tetras variously penetrating each other in order to make multiple floors, walls, and room spaces. The buildings would just have some pointy stuff on the outside. If I understand correctly, a point where 2 interpenetrating tetras intersect can effectively serve as a vert without requiring a vert. Am I wrong?

>Yes things are possible now that weren't possible before. CAD helped a lot with that. Still, look out the window and tell me how many of the buildings you see are made out of box like components, then count the number of tetrahedron based builds. My guess is you are looking at a 100% to 0% difference.

That's almost entirely due to RL constraints. SL constraints are different. That is, a really data-cheap building in SL could look like a really expensive building in RL. Spending more data in SL to make buildings look they'de be cheaper in RL is one possible aesthetic, I suppose. But it need not be the only one.

>Part of the reason for this is the stubborn nature of the building industry, more important is the fact the technique simply doesn't suit normal housing.

If the point is that I people in SL just don't want houses made out of tetrahedrons, that's probably much more true than untrue. But there are plenty of other building types that might benefit from using less data. Shopping centers, for example, could be produced with more shop spaces at a lower data cost, leaving more data for tenants and other things. Of course, I expect a lot of that will end being done, instead, just with triangles, so there's even less data, although walls and floors will appear to be infinitely thin. I guess that could be considered simply to further anticipate technical developments in RL in which load-bearing structures will be made microscopically thin. That might be further than I want to go, though.

>As for SL, again I would say stop thinking in prims, start thinking mesh. Any curved surface made on a computer is kind of built out of tetrahedrons, though less uniform as in the dome example you gave. Any quad on the outer surface of a double bent plane is two triangles. if you divide the quad the other way on the inside...what do we have? tetrahedrons...

I'm pretty sure I see what you're talking about. But the complexity of such shapes tends not to exploit the interpenetration of tetras; it sort of just adds them together because that produces shapes that are more familiar in RL.

>You can't save a lot of data on an SL box.

I think that must boil down to the question of how many I don't use. No?

>You can save a lot of data on a sphere or torus. You can save some data on a cylinder, you can save a lot of data on sculpts.

I can save a lot of data on things that have varied amounts of curvature, yes, by eliminating some of the data wasted on curvature that either isn't really there, or is almost not really there.

With my recent sculpt items, I'm pretty sure that they're reasonably efficient towards the effects they produce, because there's enough curvature that would be appreciably lost if some verts were just cut out of the frame. Whether the effect is worth getting at such a data cost is a different question. If it isn't worth it, it also will probably not be worth the data costs in mesh versions. Sculpts that waste data have a lot of space on them which is flat or almost flat. I see that with oblongs that have a blank spot at the end. Probably those are the most obvious thing to replace with mesh. The only ones I've made, though, are baked down from 16 cylinders, so they use all the available shape data to produce shape information. My interest in making mesh versions of this week's rock products, for example, is not strictly about saving data, but about giving consumers a different set of options with essentially the same product. I expect that if they can be made reasonably physical and rezzed at 64m with the higher resolution not be currently used in my 128 sculpt maps, they'll make appreciable contributions to mesh landscaping projects.

Using simpler shapes where possible means that people can have both one of my rock formations and some kind of a building strcuture with less dithering over the data costs. Or more trees and better trees. Or whatever. I guess part of the question for me is whether I'd personally prefer a traditional house with geometric trees and rocks, or realistic trees and rocks with a more geometric house.

>Using mesh isn't more efficient just because it's mesh.

I think that was one of my own earliest points on this thread, actually.

>It can be more efficient because you have full control over the objects. Start making 48 sided cylinders and you would be better off with a standard prim, well cost wise ofcourse, not visually.

Anything that is round could always be even rounder. At some point, though, things could not possibly be less round. I'd like to see that principle explored more completely than it has been.

>(I take it you ment rendering cost not prim cost.)

These are things about which I remain both ignorant, and, to the extent of what I yet know, extremely suspicious.

>If you ment primcost, I agree, but that would mean most prims would become obsolete and one of the nice things about SL in my opinion is the fact anyone can fairly build something nice quickly, without having access to or understanding of 3rd party 3D software.

That's a pretty compelling point. New users and their continued use will probably always be more important than any efficiency gap between any 2 building options. I see it, thanks.

>Fire hazards are mostly due to the interior, metal structures won't burn under normal circumstances no, but they will collapse rather wuickly, which can be a lot more dangerous.

There's always an upside and a downside. Frankloid eliminated a bunch of interior walls, which was nice. But it also meant that a fire in one part of the house was also in all other parts of the house really quickly. That might not have happened so much if he didn't use so much wood. That and he put the entrances in inconvenientent places for fire crews. More private, yes. But only as long as the building still hasn't burned down. I've never seen one of Fuller's domes collapse, although I've seen some made temporarily by other people being tediously dismantled, since they just don't fall over like the wall of a trailer. Really noisy inside, though. That's an undeniable fact.

>I don't think they are the norm where most people live. In SL you should build what you want to build though, whether it looks medieval, comtemporary or alien and whether it is out of boxes or tetrahedrons.

I was again being a bit facetious. But trailers do seem to be a good balance between efficiency and familiarity. Plus they're modular and portable, so maybe SL could benefit from having more of them, at least as long as there are still no physicalized tornado scripts.

>Those prefab components are relatively expensive in RL. Imagine all the molds needed. Every build would need new ones, opposed to the normal which can be used over and over (and over).

Of course. And "I'm worried my house will look too expensive" is a concern I hear all day, every day in SL. What was I thinking?

>Tensile limits of mesh? I guess you mean RL mesh.

No. I meant, what is the point of using what appear to be traditional material in SL if they are already used in ways that utterly ignore their RL physical limitations? Why not use something that has no clear correspondence to RL physical limits? If our eyes are really not sure what it is or how it was produced, it stands to seem less implausible than unstudded walls made of infinitely thin brick. If it takes less data, too, so much the better.

>Only stronger shape I can think of is a solid dome, which is even less flexible in use than the mesh. And guess where the dome is used? in space...and under water**Only uploaded images may be used in postings**://secondlife.i.lithium.com/i/smilies/16x16_smiley-happy.gif" border="0" alt=":smileyhappy:" title="Smiley Happy" />

Mesh domes, due to curvature, would seem to be going in the opposite direction from the tetra idea. OTOH, the more boxes you don't use because you're using tetras, the more data you'll be able to use for domes.

>The whole thing with anything that's not a box is that they won't connect very well.

They won't connect very will if I can´t just push them into each other arbitrarily and leave them there, no.

Why would I be unable to do that with mesh tetras?

>On a flat surface you can have building blocks in repeated uniform triangles, squares or hexagons. In 3D space this is not the case, hence the need for computers and production techniques to make everything fit nicely, using various shapes.

OR, I can just become better at things like remembering the interior angles of complex geometric solids.

>I actually once considered making a monochrome sim. Together with the cartoonlike possibilities Loki and others have shown on the forums and some Sin City color effects and atmosphere, that could look amazing.

The sad part is that there doesn't currently seem to be any data savings to running a sim in monochrome. Just being able to go there as an automatically decolorized AV in a decolorized space would be interesting. Especially if we could intermittently run some random scratchy lines down the screen and produce some subtle, persistent flickering noise.

>Capitalism, blah!

NOW you've hurt my feelings.

>Besides, as you said yourself in some cases the sculpt is preferred over the mesh.

Not always for the best reasons, though. My SLM listings say "better than mesh" simply because more people can still see sculpts. It's opportunistic subjectivism.

>Especially since we can't make meshes bigger than 64 meters.

I assume that will change at some point.

>It's not ALL about render efficiency. Advantages for older things are part of SL anyway, I can live with that. Megaprims that can't be created any longer, higher stipends for old premium accounts, lower tiers if I'm not mistaken.... it will always be here.

I still don't like it in principle. But I guess a larger issue, where such a principle will apply, is honoring existing agreements, even if one can't continue to make new agreements of the same kind.

>If you change your items to mesh without changing any of the geometry, you gain nothing. The wireframe will be the same, so will the rendering cost. The only result you will see is probably higher prim cost.

I should be able to change the wire frame to a more resolved one, by using the 128x128 sculpt data I already have. In fact the same should be true of the 64's that most people are using. And if I want to cut the 128's down to 32x32 or something comparable with mesh, I can probably be a lot more selective than SL's sculpt rendering system happens to be about which verts should render and which ones are a waste of data.

>As Chosen would say: A sculpt is a sculpt is a sculpt.

Except when it's mesh.

>Whether it's 64x64, 128x128 or 1024x1024, the number of triangles on your screen would be the same.

Except that I have produced my sculpts at higher resolution, seen them rendered at higher resolution outside of SL, and maintained the same higher level of resolution in the data I have loaded to SL, even if SL has no use for most of it. Moreover, I have imported with the idea of later export in mind.

>As I said above, changing to mesh won't save you anything, not renderwise anyway. I don't know if they would be transferred between servers and viewers any slower or faster.

Understood.

>You can only save data by removing triangles, which is probably very possible in a lot of your creations.

Yes. The tricky part is going to be removing the correct ones by some means that doesn't take hours per item.

That's why I've asked about some possible function that removes data heirarchically in inverse correlation to how much curvature will be lost in the process.

Kwakkelde Kwak · December 18, 2011

Josh Susanto wrote:

I was thinking more of economies of scale to be produced by tetras variously penetrating each other in order to make multiple floors, walls, and room spaces. The buildings would just have some pointy stuff on the outside. If I understand correctly, a point where 2 interpenetrating tetras intersect can effectively serve as a vert without requiring a vert. Am I wrong?

Apart from the fact I'd like to keep calling it an intersection, not "effectively a vert", you are right. But this principle is also the case for any other 3D geometry. You can intersect boxes, spheres, cylinders, anything. A tetrahedron has no advantages over any other shape in this respect. See the shape below, it's constructed out of only four cubes:

<< I can't seem to post the picture, also ate half my post..grrr

Here's the link: polyhedron>>

Image from wikipedia

Josh Susanto wrote:

That's almost entirely due to RL constraints. SL constraints are different. That is, a really data-cheap building in SL could look like a really expensive building in RL. Spending more data in SL to make buildings look they'de be cheaper in RL is one possible aesthetic, I suppose. But it need not be the only one.

Some constraints or design challenges are exactly the same in SL and RL. The reason some RL objects need CAD over a simple sketch or even full drawing, is usually the sheer complexity, both in structural integrity and appearance. There is no difference in CADing for SL or RL, that is until the designed object needs to be actually built. My point is building with boxes is faster and easier than with any other shape.Imagine your desk being built out of tetrahedrons. At the same "bounding box" or "extreme dimensions"or however you want to call it, on such a desk you wouldn't be able to fit more than your monitor and keyboard/mouse. I'd like the extra space to place a book, or my pencils, or my scanner, or anything. The usable surface is only half of that of a box at the same overall size.Combining two tetras to get the top of the desk flat and square, which you seem to be suggesting (it's not entirely clear to me), would leave you with a dimensionless hinge where they meet. In SL this wouldn't be an issue, I agree. You however can't push the two tetrahedrons into eachother without losing the square surface.

If you stop thinking in prims and start thinking in "least amount of data", you would probably end up with a pyramid upside down, that has 5 vertices and 6 triangles. I know this is effectively the same as joining two tetrahedrons and removing the hidden geometry, but the thinking process behind it makes more sense. You need to ask yourself: "what do I want?" Then you need to build that with as little data as possible. If the answer to the question is: "I want to build with tetrahedrons", you build with those. if the answer is "I want to use as little data to construct something that looks like it could exist in RL", you certainly don't build with tetrahedrons.

More data to make something look less expensive? If you want something that looks cheap in SL, I can think of many many examples, if you need to use the extra data to accomplish that, then that is what you do.

Josh Susanto wrote:

If the point is that I people in SL just don't want houses made out of tetrahedrons, that's probably much more true than untrue. But there are plenty of other building types that might benefit from using less data. Shopping centers, for example, could be produced with more shop spaces at a lower data cost, leaving more data for tenants and other things. Of course, I expect a lot of that will end being done, instead, just with triangles, so there's even less data, although walls and floors will appear to be infinitely thin. I guess that could be considered simply to further anticipate technical developments in RL in which load-bearing structures will be made microscopically thin. That might be further than I want to go, though.

As I said above, "using as little dataas possible " should be your starting point then, not "using tetrahedrons".

On a sidenote, lots of loadbearing constructions in RL are "microscopically thin". You need to let gravity work in your favour and make good use of the tensile strength of the used material. Think cables... For dividers, think curtains...

There's this rather famous challenge where you need to make the highest tower possible with a sheet of A4 paper and a roll of tape (both virtually flat). Sometimes there's the extra challenge of it having to be able to keep the weight of a soda can. You'd be amazed how high it can get.

Josh Susanto wrote:

I'm pretty sure I see what you're talking about. But the complexity of such shapes tends not to exploit the interpenetration of tetras; it sort of just adds them together because that produces shapes that are more familiar in RL.

Now I am confused why you brought up the dome in the first place, I thought it was because that used tetrahedrons, ones that DO NOT intersect.

Josh Susanto wrote:

Sculpts that waste data have a lot of space on them which is flat or almost flat. I see that with oblongs that have a blank spot at the end. Probably those are the most obvious thing to replace with mesh. The only ones I've made, though, are baked down from 16 cylinders, so they use all the available shape data to produce shape information.

I'm still not quite sure on this myself. As far as I know the graphics card only renders visible (normals facing the screen) triangles. The SL render cost for a sculpt is based on the number of vertices though, and in a sculpt, those are virtually set ( There's a very small difference in number of vertices on normal and the different oblong sculpts). I think the rendercost SL will show you, is based on this set number for vertices, not on the number of faces that need to be rendered on screen. (SL rendercost is an estimation, GPU rendercost is real). This would mean the sculpts that have blanks are effectively MORE renderfriendly than ones that use all the pixels. On the other hand, the blank space adds useless data that needs to be sent between servers and viewers and I guess the CPU needs to work harder to turn the sculpt map into something that can be rendered.

If anyone can tell me more about this process, please do.

Josh Susanto wrote:

There's always an upside and a downside. Frankloid eliminated a bunch of interior walls, which was nice. But it also meant that a fire in one part of the house was also in all other parts of the house really quickly. That might not have happened so much if he didn't use so much wood. That and he put the entrances in inconvenientent places for fire crews. More private, yes. But only as long as the building still hasn't burned down. I've never seen one of Fuller's domes collapse, although I've seen some made temporarily by other people being tediously dismantled, since they just don't fall over like the wall of a trailer. Really noisy inside, though. That's an undeniable fact.

I think Frank Lloyd used more walls than you will find in most dome structures.

Why you didn't see any of the domes collapse, is probably because you've never seen on on fire, which was what I ment. I'd pick a solid wooden structure over a steel one in case of fire anytime. Wood doesn't burn as quickly as you might think. Steel structures, which are usually very slender, have terrible structural behaviour when exposed to fire. This is because of two reasons. First is the material gets really weak when heated, second is it is really easy to heat, this last part again because of two things: moleculair structure and thin profiles, which mean little material for a big surface. Wood is a natural isolator, metal a natural conductor.

On top of this, most steel structures work as one big element. Take out one little piece and the entire thing will collapse, wood and brick structures don't behave like this (until one of the walls fall down ofcourse). Take out one wooden beam and the rest will stay in place. (This is not entirely true because most of the time the floors connect the beams:) if you want a real fireproof building, use concrete, without the use of steel reinforcement)

btw, I think we better focus on SL, this RL discussion isn't helping a lot of people...

Josh Susanto wrote:

I was again being a bit facetious. But trailers do seem to be a good balance between efficiency and familiarity. Plus they're modular and portable, so maybe SL could benefit from having more of them, at least as long as there are still no physicalized tornado scripts.

I thought everything in SL was easily portable, it's the only place I know where you can put a castle in your backpack.

Josh Susanto wrote:

Of course. And "I'm worried my house will look too expensive" is a concern I hear all day, every day in SL. What was I thinking?

Yes I'm wondering what you ARE thinking. You just said so yourself, low rendercost builds can look expensive and vice versa.

Josh Susanto wrote:

No. I meant, what is the point of using what appear to be traditional material in SL if they are already used in ways that utterly ignore their RL physical limitations? Why not use something that has no clear correspondence to RL physical limits? If our eyes are really not sure what it is or how it was produced, it stands to seem less implausible than unstudded walls made of infinitely thin brick. If it takes less data, too, so much the better.

Well there's a big difference between modelling on a computer and actually building it. The task for a 3D artist is to make something look believable, trigger someones brain to fill in the gaps without making that obvious. Sometimes that means a wall without thickness is no issue. As long as there's no door or window in it and the sides aren't exposed, who will notice? I do like some realism, I don't like 10cm flat floors that span 100 meter, but I seem to be one of few on this matter. If your brain doesn't recognize something (like you just said) there might not even be a reason to fill in gaps. Agreed.

Josh Susanto wrote:

Mesh domes, due to curvature, would seem to be going in the opposite direction from the tetra idea. OTOH, the more boxes you don't use because you're using tetras, the more data you'll be able to use for domes.

There seems to be some RL/SL confusion on my part or on yours... Anyway, a dome as you used as example earlier is made out of tetrahedrons in the first place...just a whole lot of them. And as I said in an earlier post, any curved double sided plane can be constructed out of tetrahedrons. (if you want some thickness on it, otherwise you can use triangles)

Josh Susanto wrote:

They won't connect very will if I can´t just push them into each other arbitrarily and leave them there, no.

Why would I be unable to do that with mesh tetras?

Again..RL/SL confusion.... in SL you ofcourse can.

Kwakkelde Kwak · December 18, 2011

Josh Susanto wrote:

OR, I can just become better at things like remembering the interior angles of complex geometric solids.

Changing a single element on a uniform object like that will force you to change everything to keep it uniform. There is no point in remembering anything.

Josh Susanto wrote:

The sad part is that there doesn't currently seem to be any data savings to running a sim in monochrome. Just being able to go there as an automatically decolorized AV in a decolorized space would be interesting.

I recently read you can now upload 8 bit textures. I'm guessing SL turns them into 24 bit ones though. If they stay 8 bit, you can save data by using monochrome textures, otherwise you are right.

Josh Susanto wrote:

NOW you've hurt my feelings.

Get over it:)

Josh Susanto wrote:

Not always for the best reasons, though. My SLM listings say "better than mesh" simply because more people can still see sculpts. It's opportunistic subjectivism.

I wasn't referring to your listings.

Sculpts can be preferred when you want animated objects, although I'd rather have rigged mesh without the need of an avatar to attach it to. Also when making huge items sculpts can be preferred. I know this is not fair render/upload/primcostwise. What the best reasons are is rather subjective, althoug I am in agreement with you on this point.

Josh Susanto wrote:

I can probably be a lot more selective than SL's sculpt rendering system happens to be about which verts should render and which ones are a waste of data.

I am pretty sure you can be yes. Making your own LODs can really make a difference, both in looks and datause. This is really a win-win, well unless you haev little time to spare to do it, then it's a win-win-lose....

Josh Susanto wrote:

>

As Chosen would say: A sculpt is a sculpt is a sculpt.

Except when it's mesh.

>Whether it's 64x64, 128x128 or 1024x1024, the number of triangles on your screen would be the same.

Except that I have produced my sculpts at higher resolution, seen them rendered at higher resolution outside of SL, and maintained the same higher level of resolution in the data I have loaded to SL, even if SL has no use for most of it. Moreover, I have imported with the idea of later export in mind.

>As I said above, changing to mesh won't save you anything, not renderwise anyway. I don't know if they would be transferred between servers and viewers any slower or faster.

Understood.

No exceptions here. A sculpt is a (stitched) plane with slightly more than 2000 faces. Changing the resolution doesn't change the SL object (unless you make it too big and lose the lossless...). Changing to mesh without welding or deleting any vertices won't change te SL object. As soon as you do the latter, you are no longer working on a sculpt.

I thought you understood, but going by your "exceptions" I am starting to think you are rather taking my word for it than really understanding it.

Josh Susanto wrote:

Yes. The tricky part is going to be removing the correct ones by some means that doesn't take hours per item.

That's why I've asked about some possible function that removes data heirarchically in inverse correlation to how much curvature will be lost in the process.

Yes it can be very timeconsuming by hand (can be, doesn't have to be, all depending on your object and your skills), probably not worth the efford to most people. 3dmax has a function called "MultiRes" which does exactly what you describe: identifying angles then remove as many as you want, starting with the smallest..uhm biggest angle, the flattest anyway. Blender has a function called "Decimate" I think, not sure if it does the exact same thing, but it's similair. If I were you, I'd post a seperate question on the forum. I'm sure a lot of people will skip these long posts.

Bear in mind these functions really screw up your UV map.

Drongle McMahon · December 18, 2011

"This would mean the sculpts that have blanks are effectively MORE renderfriendly than ones that use all the pixels"

Yes, if blanks means collapsed faces (to make sharp edges, preserve shape etc.) because there is a function that removed all those "collapsed" (technically called degenerate) triangles before they are sent to the gpu for rendering. This gain is not (and is unlikely to be, according to the developers) accounted for in the display weight. So sculpties with collapsed faces are being treated a bit unfairly.

"On the other hand, the blank space adds useless data that needs to be sent between servers and viewers and I guess the CPU needs to work harder to turn the sculpt map into something that can be rendered."

In the case of flat space, where vertices are not contributing to the shape, that is true. They are wasteful. For sculpties they may be necessary to get the intended stretching of a texture. For the equivalent mesh, they can be removed because the texture stretching can be controlled by varying the UV mapping. As far as data download is concerned, the basic data per vertex is much less for a sculpty (24 bits) than for a mesh (at least 128 bits, multiplied up for sharp edges, plus the triangle lists indexing them). Both are compressed and the compression is very dependent on details.

Kwakkelde Kwak · December 18, 2011

Drongle McMahon wrote:

In the case of flat space, where vertices are not contributing to the shape, that is true. They are wasteful. For sculpties they may be necessary to get the intended stretching of a texture. For the equivalent mesh, they can be removed because the texture stretching can be controlled by varying the UV mapping. As far as data download is concerned, the basic data per vertex is much less for a sculpty (24 bits) than for a mesh (at least 128 bits, multiplied up for sharp edges, plus the triangle lists indexing them). Both are compressed and the compression is very dependent on details.

I didn't mean vertices not contributing to the shape, yet in the middle of a surface. I ment the collapsed ones.

I am guessing SL sends around the sculpt map data, all of it, between servers and viewer, rather than the object to be rendred by the GPU. But in this case it's even easier to remove them when converted to mesh.

Thanks for explaining the part on rendering...

Drongle McMahon · December 18, 2011

Yes, the bits/vertex are for the sculpt map data, and compared with the mesh streaming data. On second thoughts, the sculpt map download, for a standard 64x64 map is 96 bits/vertex, because 3/4 of the pixels are unused. However, if you make all the unused pixels the same colour, then they will compress very well, which will compensate. Needless to say, people generally do'nt do that, even when the maps are generated by sculpty-specific software.

Kwakkelde Kwak · December 18, 2011

That sounds very interesting, hadn't I given up on sculpt building altogether with mesh here... Did you ever try to color 3/4 of the map the same way? If so, what pixel out of the 4 is assigned to the sculpt vertice?

Josh Susanto · December 18, 2011

>Since it worked from a location other than your desktop, I have to assume something is unusually configured on your machine.

Possibly, but I don't think so.

It's essentially the same desktop loading bug I saw with other Windows versions of programs I saw 15 years ago. It just never would have occurred to me that it wouldn't have been totally resolved by now, and would be affecting users of newer programs.

It was actually one of the reasons I became a fanatic Apple user until "the incident" in 2007 finally changed my mind. But the way a lot of Apple users think is that, if you've been working with something and you're still working with it, the desktop is a pretty normal and obvious place to hold it while it's being worked-on. The idea of repeatedly putting something into a storage file in order to make it accessible for work just seems completely backwards to me.

>Larger prims get "undercharged", compared to smaller ones.

Because the charge is the same for both? That makes sense, as an "undercharge", but doesn't it also mean that small prims can be "overcharged"? Megaprims, and that fact that everyone's avatars are extra big probably both serve to cloud this issue, no?

>That's good, because I seriously doubt there could EVER be a market for a single triangle. It's analogous to putting a single letter on a piece of paper, and trying to sell it in a book store.

I've actually sold several copies of a default plywood box with the permissions conspicuously shut off. I even got some reviews. Practically anything will sell eventually, provided that the marketing is right.

>Once again, you seem so focused on the semantics that you've apparently missed the point.

If the point is that I can avoid distortion under either definition, that's a point I have not missed. I just think that the terminology, as applied, begs the question; not exactly your fault, though.

>Josh, when you will accept the fact that nothing I've ever shown you, or ever will show you, will cause you to lose any of the abilities you already have? The whole point is for you to have MORE control, not less.

I agree that's potentially true. But since I just discovered I'll need a different mouse to use some of Blender's functions, I'm again wondering how many hoops I'll have to jump through even to get the results with Blender than I'm already getting somewhere else.

>Well, what if a particular texture detail you want to emphasize happens to fall in between two vertices instead of directly on one of them.

Good question. That's the main reason I've been loading sculpts at 128 instead of 64, so that more control can be taken later with the same data, by by some means. If there's a cleaner and more conclusive solution, I will start using it.

>If the UV's are locked, you have no way of correcting for that. However, if the UV's are adjustable, as is the case with every non-sculpty mesh model in the world, you can make the proper corrections very easily.

So what is the kind of default resolution available with Blender? One vert per surface pixel? something like that? My mushroom loaded at less than that, and it was only a 128x128 sculpt.

>By the way, notice that in the version on the left, the bricks look rounded over while in version on the right, they look flat-faced. That's because I softened the edge normals on the left one, and hardened the edge normals on the right one. Normals are another thing you have no control over with sculpties, but which you can employ to great effect with meshes.

Now THAT's interesting. How do the edge normals ultimately affect data costs?

>Assuming I've done my job properly, you'll never see a texture edge at all, on any model, whether it's a soccer ball or anything else. To know what's what, you'd have to look at the texture itself, and the UV map.

Of course, but if I could find it, how would I find it?

>I'm not sure what you're saying here. I think your definition of "vertex" might be a bit off.

The verts are the points at the corners of the triangles, no? If they do not correspond to any difference in the planar angles of the tangent triangles, they're often wasted as data, are they not?

>No, it's not overstated at all, and what you're describing here is NOT UV mapping. Again, because you don't yet have any experience with it, you're not yet equipped to understand. You're making inaccurate assumptions based on other experiences you have had that, while seemingly similar to you, really are not related to the actual subject at hand.

Are you telling me that your real model consists not only of assigned verts, and not only of some larger number of unassigned potential verts, but of some infinite number of verts? Or are you telling me that the model is resolved at some larger number of data points that allows us to speak of them as if they are continuous? How is what you're telling me different from these things? If your precision really consists of deciding which parts of the shape need definition and which parts do not, that's not essentially different from what I describe. It's just a lot less clumsy.

>Sorry, but no, you're not being clear at all. Vertices can never be "not married" to the shape of the model. For all intents and purposes, they ARE the shape.

Much clearer, thanks. I'm using the terms vert and UV point interchangeably, because, for me, they're the essentially the same. Where they would be different, I still maintain there's no infinite number of verts that would allow absolute control in assigning UV points. Or is there?

>UV points are what determine the relationship the texture has with the surface. As I tried to explain before, every vertex is represented on the texture canvas by one, if not several, UV points. Each of those points can be anywhere you want it to be on the canvas. If you want uniform, even spacing, like on a sculpty, you can have that. If you want something less restrictive, you can have that, too. You can do it any way you want.

I understand you're talking about more precision. But I still maintain that this is not completely different from what I've been doing. I can push most of the shape resolution to one end of a cylinder, for example, without changing the underlying shape. But the only advantages to that in my current case would be that the more resolved end would allow more surface pixels than the corresponding region on the opposite end, or could be used as a template for more refined relief effects on the more resolved end. It's an inefficient, roundabout way of doing things, yes, but the principle is not essentially different from what you describe so far. BTW: Have you seen my block sculpt that causes the seams on all surface textures to disappear?

>I get what you're saying, but it's so far removed from what UV mapping really is, it's effectively unrelated.

The base models I've been working with are up to 256 data points per axis, 1024 data points total. Are you working with twice that much resolution? 10 times as much 100? What exactly?

>I mapped the sphere to be symmetrical across the equator.

Yes, and I didn't realize that because you neither mentioned it, nor showed it in the graphic.

>If it makes you feel better, here it is, remapped to bring the corners to the middle:

Can you bring the corners to the middle of one end without shifting the texture back to the original position or anything approximating the original position? What happens to the opposite end of the original sphere you showed me if you applied the modified texture I provided, but without equatorial symmetry or some similar compensatory effect applied? For that matter, what does the opposite end of the original sphere look like if you just don't apply the equatorial symmetry to that, or shift the texture 180 degrees?

>This took just an extra minute, to chop up the map, and rearrange it. Alternatively, I could have left the map intact, and offset the texture placement by 50% in each direction, and the end result would have been the same.

That's even more not what I asked for, sorry. Don't worry, though. When I have finally performed the experiment myself, I will post all the data and show the results.

>Yes, and that's a problem because?

It's not necessarily a problem in every case. But people don't necessarily want all spheroids to mirror at the equator. Moreover, it's an effect I can already quite easily produce with Sculptypaint should anyone happen to contact me and complain than my landscaping rocks aren't symmetrical. Until then I don't have any such products ready for such an emergency. I'm a bit of a risk-taker, I guess.

>It's perfectly normal to have unused canvas space on a UV map. It happens more often than not. It's best to minimize that wherever possible, of course. But it's not a problem to have some. In fact, it's usually advantageous.

As true as that may be, it's not really an effective demonstration of what I had asked to have demonstrated, at least as being anything different from what's already available to me as an effect. I realize I should have mentioned eliminating puckers specifically without creating artificial-looking symmetry. I just wouldn't have imagined that being offered as a new solution to the problem, since it's a solution I already choose not to use.

>Drongle has shown one method for doing that. There are millions more. I just opted not to do it for what I thought would be a simple demonstration that would have been over and done with the moment you saw it. I never envisioned that we'd be going back and forth about it for a week. I shoudln't have to example every possible applied permutation just for you to accept that an applicable principle is indeed a principle, and is indeed applicable.

Indeed. I think we're probably both sorry that I didn't realize I would need to more clearly specify what I would need to see.

>We never discussed projecting anything.

I think I used the word "wrapped". Sorry for the inconsistency. I don't see mirrored duplication of a circular portion as being "wrapped", although it could be construed as "projection", which you have actually noted is the term I hadn't used earlier.

The discussion seems to get off track with the response to the part below, which I have now underlined, making it more conspicuous than in the original:

12-15-2011 05:41 AM

"But the pucker does still exist somewhere if you're wrapping a square onto a sphere. You may just not be able to spot it because of the compensation you describe. If the real point is that that's always going to be good enough, I will probably have to agree with that once I've tested it personally.

Meanwhile, could you reproduce the shown mapping with the below alternate texture and show me the opposite pole?"

The shown mapping is only on one end of the sphere. If the opposite pole is identical, that would seem to eliminate any reason for showing it. I'm sorry that I didn't ask the question in a way that explained why the opposite pole might be important.

>What we described was eliminating puckers via rearranging the UV map.

Yes, I see that now. I just confused because I tried to ask for one thing, and you quite unintentionally provided something different, apparently not understanding my reasons for asking to see the opposite end. I acknowledge that your solution quite probably works as a solution for the problem as you see it. It just isn't a solution I would want to use, practically ever. We both seem to have been confused here. Please, for the sake of anyone else reading this, let's agree to find a way to close the question from both ends. For my part, I recognize that, by some means at least, it is not strictly necessary to produce a detectable pucker. Now if you'll just show me the other other end of that sphere...

>No, you couldn't. Moving polygons around is NOT the same thing as moving UV's around. Until you accept that fact, you will remain hopelessly lost.

It would be a waste texture AND polygons, as opposed to being just a waste of texture. I get it. These things are different.

>What part of "symmetrical across the equator" wasn't clear?

You didn't mention this property of the object until:

12-15-2011 01:23 PM - last edited on 12-15-2011 01:37 PM

I didn't ask you not to apply it because I neither saw nor read that you had already applied it.

I also made the mistake of assuming you wouldn't want to make a symmetical rock.

I recognize this error of interpretation on my part.

Drongle McMahon · December 18, 2011

Here are two sculties bmade with the first two scfulpt maps shown below (at 4x magnification, originals are are actually 64x64). You can see that they are identical. Numbering from bottom left, starting at 0, it's the even numbered pixels that matter, except for number the last, number 63, which also counts if the dimension is unstitched.

However, I may have to retract what I was saying about compression. I have added a third possible map below, which uses duplication of the significant pixels instead of the interpolation of the lefmost (the original).

I had based my ideas about compressibility from png (lossless) files. These gave 4392, 3040 and 1863 bytes. However, SL uses jpeg2000. Using the jpeg2000 plugin from Infranview (again lossless) gave 4792, 8338 and 5454 for the same maps. Now the jpeg2000 in SL may be completely different, but unless it is, this means that jpeg2000 compresses the interpolated version best, even though it has more different pixel values (someone please exp[lain that!). Even png does better with duplicated near neighbours instead of the one where 3/4 of the pixels are identical, although it does both of those better than the interpolated versions. It would be nice if we could get the actual compressed image data sizes from the viewer. Anyone know how?

Drongle McMahon · December 18, 2011

Concerning precision and resolution, of both vertexes in space and of their mapped positions in the texture space: In Blender etc. I imagine these are stored as 32 bit floating point numbers, giving 24 bits of significant binary digits (about one in 16,000,000 accuracy). What appears in the Collada file depends on the exporter. For the one I use, all these numbers are given to five decimal places, giving an accuracy of one in 100,000 for a size of 1.

However, whatever is in the file, the format used for streaming to and from the SL servers uses 16 bit integers (plus a scaling factor) giving an accuracy of one in 65536th part of the object/texture dimension (much of it redundant for 1024 maximum texture, of course). In contrast, the accuracy of vertex positioning available for sculpties is one in 256, as you aware.

Since sculpty texture positions are immutable, there is little point in discussing their accuracy, but their separation depends on the oblongness of the map. It can be as small as one part in 256 of the texture dimension for the longer dimension of an 8x512 oblong map. It is one in 32 for a square 64x64 or bigger map.

However you look at it, accuracy and resolution are one aspect where mesh has very substantial advantages over sculpties, although there may be few applications where this difference is crucial.

leliel Mirihi · December 18, 2011

Drongle McMahon wrote:

Now the jpeg2000 in SL may be completely different, but unless it is, this means that jpeg2000 compresses the interpolated version best, even though it has more different pixel values (someone please exp[lain that!).

Easy, jpeg & jpeg2k were designed to compress photographs of the real world. In the real world you almost never see large blocks of solid color, there are all ways gradients of color from lighting variations, imperfections in the material and surface, and random noise from the camera or your eyes. So jpeg sacrifices the uncommon case so it can better optimize the common case. Try comparing jpeg2k vs. png on a high res photo.

Josh Susanto · December 19, 2011

>Apart from the fact I'd like to keep calling it an intersection, not "effectively a vert", you are right.

I think we're on the same page with that. It's a point of articulation or angular definition which does not require the dedication of data cost that another one might by virtue of actually being a vert. Yes?

>But this principle is also the case for any other 3D geometry. You can intersect boxes, spheres, cylinders, anything. A tetrahedron has no advantages over any other shape in this respect. See the shape below, it's constructed out of only four cubes:

I see that. But if we do something similar with twice as many tetras, we can get quite a few more intersections for the same or lesser data cost. No? Practical applicability does not necessarily, follow, I know. But this is the basic math question that needs to precede the practical applicability question.

<< I can't seem to post the picture, also ate half my post..grrr

Here's the link: polyhedron>>

I see it, thanks.

>Some constraints or design challenges are exactly the same in SL and RL.

Viewing constraints as challenges is creative thinking. Are you sure we really want to go there?

>My point is building with boxes is faster and easier than with any other shape.

I think igloos might be faster and easier.

Maybe we should just make bigger and more complex igloos?

>Imagine your desk being built out of tetrahedrons.

Sure. I can make a more functional desk with 2 tetras than with a box.

The box offers a more regular top surface, but it also has no place to put my legs.

As I double the supply of each of these parts, I continue getting a more consistent control return for data on the 2 tetras than from the box. I can only put each box in one position at one angle. Per data, the number of additional design options for the tetras increases exponentially as compared to those for the box. Adding or subtracting one tetra is also addition or subtraction by a smaller increment than with a box. Again, this is basically a math question, rather than a practical question. But since the desk with 2 tetras is already more practical than the desk with one box, there would have to be some kind of special black swan threshold to be passed in order to reverse the effect in spite of the math. When you find that black swan, please let me know.

>At the same "bounding box" or "extreme dimensions"or however you want to call it, on such a desk you wouldn't be able to fit more than your monitor and keyboard/mouse.

And the bounding box matters because I need a 64 meter desk?

>You however can't push the two tetrahedrons into eachother without losing the square surface.

I can still get more desk area with 3 tetras than with a box and tetra, including the square area. More tetras and fewer boxes actually, eventually, means more total rectangular desk area even if we want it all to be rectangular. If we don't, boxes don't offer the counter-advantage of more greatly facilitating non-rectangular desk surfaces.

>If you stop thinking in prims and start thinking in "least amount of data", you would probably end up with a pyramid upside down, that has 5 vertices and 6 triangles.

Really? I'll have to think about that some more.

>I know this is effectively the same as joining two tetrahedrons and removing the hidden geometry,

Bingo.... I think.

>but the thinking process behind it makes more sense. You need to ask yourself: "what do I want?" Then you need to build that with as little data as possible. If the answer to the question is: "I want to build with tetrahedrons", you build with those. if the answer is "I want to use as little data to construct something that looks like it could exist in RL", you certainly don't build with tetrahedrons.

I'm not convinced that most people are effectively using boxes in a manner appreciably different from the way you've described the potential use of tetras. But, OK, maybe they are.

>More data to make something look less expensive?

I was being facetious. My point was that if tetras look like they would be really expensive in RL, that's not necessarily a downside in RL. If people in SL are strictly designing buildings they could potentially afford or be allowed to build in RL, then tetras are probably to be avoided. But they also need to rethink a bunch of other stuff I see in SL buildings that, far from being expensive or impractical, is downright impossible.

>If you want something that looks cheap in SL, I can think of many many examples, if you need to use the extra data to accomplish that, then that is what you do.

I already do that, ironically. A lot of my rock walls are probably not up to safety code and ought not to be used by anyone who can afford to replace them. And yet they also use a lot of data, really.

>As I said above, "using as little dataas possible " should be your starting point then, not "using tetrahedrons".

Agreed. I only suggest more tetras as a possible shortcut to needing less data, assuming people can figure out how to make that work as a shortcut. I'm confident that I can, and I'm confident that you also can at some point, if not immediately.

>On a sidenote, lots of loadbearing constructions in RL are "microscopically thin". You need to let gravity work in your favour and make good use of the tensile strength of the used material. Think cables... For dividers, think curtains...

Understood. But they still have to hang on something, generally. Most of SL's walls micro walls have no framing of any kind, either. Such materials might be used commonly in the future, but on that same basis, I might again suggest tetras instead. Even if they are micro-thin, they can include their own framing by being pressurized with an inert gas mixture.

>There's this rather famous challenge where you need to make the highest tower possible with a sheet of A4 paper and a roll of tape (both virtually flat). Sometimes there's the extra challenge of it having to be able to keep the weight of a soda can. You'd be amazed how high it can get.

I'll look into it, but not before I think it through on my own.

>Now I am confused why you brought up the dome in the first place, I thought it was because that used tetrahedrons, ones that DO NOT intersect.

If I recall correctly, I'm not actually the one who first brought up domes. I mentioned using tetrahedrons underwater and in space. I understand why domes are used there now, but that's no reason to use them compulsively in SL.

(Sculpts that waste data have a lot of space on them which is flat or almost flat. I see that with oblongs that have a blank spot at the end. Probably those are the most obvious thing to replace with mesh. The only ones I've made, though, are baked down from 16 cylinders, so they use all the available shape data to produce shape information.)

>I'm still not quite sure on this myself. As far as I know the graphics card only renders visible (normals facing the screen) triangles. The SL render cost for a sculpt is based on the number of vertices though, and in a sculpt, those are virtually set ( There's a very small difference in number of vertices on normal and the different oblong sculpts). I think the rendercost SL will show you, is based on this set number for vertices, not on the number of faces that need to be rendered on screen. (SL rendercost is an estimation, GPU rendercost is real). This would mean the sculpts that have blanks are effectively MORE renderfriendly than ones that use all the pixels. On the other hand, the blank space adds useless data that needs to be sent between servers and viewers and I guess the CPU needs to work harder to turn the sculpt map into something that can be rendered.

Even if both these things are true, there would simply be contextual trade-offs in the rendering question. That data is wasted is absolutely clear, whether the trade-off is contextually applicable or not.

>If anyone can tell me more about this process, please do.

I would also like to have better information on this. But we can all see the dead spots on the ends of oblongs, if they are there. I have so far seen no reason not to put something in there.

>I think Frank Lloyd used more walls than you will find in most dome structures.

Wooden walls, yes. And a ceiling that fire crawls across on its way up.

>Why you didn't see any of the domes collapse, is probably because you've never seen on on fire, which was what I ment.

True.

>btw, I think we better focus on SL, this RL discussion isn't helping a lot of people...

Again, true. We're not really disagreeing all that much, and it's about things that aren't pertinent to the main discussion.

>I thought everything in SL was easily portable, it's the only place I know where you can put a castle in your backpack.

Precisely. If an idea is to correlate SL building constraints with RL building constraints, we can better justify the portability with trailers than with castles.

(Of course. And "I'm worried my house will look too expensive" is a concern I hear all day, every day in SL. What was I thinking?)

>Yes I'm wondering what you ARE thinking. You just said so yourself, low rendercost builds can look expensive and vice versa.

I meant that as sarcasm. I've never heard anyone complain that their SL house looks or will look too expensive, much less mention they'd like to use more data to get it looking cheap or run-down. They are buying things from me that do that, in effect, but I think that's mostly for dungeons and tombs and whatnot, based on what people tell me, anyway.

>Well there's a big difference between modelling on a computer and actually building it.

No kidding?

>The task for a 3D artist is to make something look believable, trigger someones brain to fill in the gaps without making that obvious. Sometimes that means a wall without thickness is no issue. As long as there's no door or window in it and the sides aren't exposed, who will notice?

I will. I'm not sure with what consistency, but really damned often. More than anything, I get the feeling that the 2nd floor will collapse under me. Not that this scares me, literally, but I'm reasonably uncomfortable with the effect. I rarely go to houses or other buildings, anywhere, for just such reasons. I feel like I'm going to knock the thing over if I make one wrong move. And when it doesn't happen, it's almost more unnerving. Like waiting for the other shoe to drop.

>I do like some realism, I don't like 10cm flat floors that span 100 meter,

I find those to be weird, but less weird, depending on the implied material.

>but I seem to be one of few on this matter. If your brain doesn't recognize something (like you just said) there might not even be a reason to fill in gaps. Agreed.

If people want to keep using one-sided materials and such, I can't really stop them. I just wouldn't want to compound the problem unnecessarily if using more tetras and fewer boxes doesn't require such an extra leap of tolerance to the unreal.

That's just me, though. Not everyone has to agree with me. But where one person tends to perceive things as I do, a certain percentage of others almost inevitably will. They deserve their preferred type and degree of realism.

Josh Susanto · December 19, 2011

I'll respond to a few other things, eventually.

In the meantime I'd like to illustrate that making puckers not happen, specifically as shown earlier in this thread is utterly possible without blender or anything similar.

I can naturally think of some stingingly sarcastic comments to make about the pictures below, but Chosen has been too helpful to deserve that.

Chosen Few · December 19, 2011

Josh Susanto wrote:

Because the charge is the same for both? That makes sense, as an "undercharge", but doesn't it also mean that small prims can be "overcharged"? Megaprims, and that fact that everyone's avatars are extra big probably both serve to cloud this issue, no?

I would have to say yes, smaller prims probably do get overcharged. I'd also argue that geometrically simple prims like cubes get overchaged, compared with more complex ones like toruses.

Simple meshes, and small meshes, can have a weight of less than one, but prims cannot. If two meshes each have a weight of 0.5, you can link them together, and the total weight will equal 1. You can never link two prims together to equal just one.

Josh Susanto wrote:

But since I just discovered I'll need a different mouse to use some of Blender's functions, I'm again wondering how many hoops I'll have to jump through even to get the results with Blender than I'm already getting somewhere else.

A three button mouse is a standard requirement for most 3D modeling software. Most PC's come standard with a three button mouse these days. Come to think of it, It's pretty hard to find a mouse anywhere that doesn't have at least three buttons (except maybe the Apple store). I find it surprising you don't have one.

For what it's worth, I use an eight button mouse on my desktop, and a five button mouse on my laptop. I also tend to work with my Wacom tablet a lot, which has three buttons on the stylus. I have these assigned to replicate the three main mouse buttons. There are four buttons on each side of the tablet itself. I have three of these mapped to ctrl, alt, and shift, so that all the basic camera control functions are covered, right on the tablet, for the majority of applications.

Josh Susanto wrote:

Good question. That's the main reason I've been loading sculpts at 128 instead of 64, so that more control can be taken later with the same data, by by some means. If there's a cleaner and more conclusive solution, I will start using it.

And if a particular detail also does not fall within 128 lines of resolution, what then? Increase the resolution again? Where does it end?

The point is you should never have to be in such a position in the first place. You should have entirely fluid, unimpeded control over exactly how things work with everything you create. Sculpties, by definition, just don't afford you that.

Josh Susanto wrote:

So what is the kind of default resolution available with Blender? One vert per surface pixel? something like that? My mushroom loaded at less than that, and it was only a 128x128 sculpt.

You're still letting your sculpty-only experience color your perceptions. UV maps are resolution-independent. It's a fundamentally different methodology than what you're used to.

Josh Susanto wrote:

Now THAT's interesting. How do the edge normals ultimately affect data costs?

Soft normals are marginally cheaper than hard ones. Simply put, soft normals have one vector, and hard normals have two. Light hitting an edge with hard normals can bounce away in two distinct directions, which is what makes the edge appear sharp. When the normal is soft, however, the light bounces off the edge in just one direction. This has the effect of making the two faces on either side of the edge appear to grade smoothly from one to the next.

If you want specifics on the math, Drongle would be better person to ask than I.

Josh Susanto wrote:

Of course, but if I could find it, how would I find it?

As I said, you'd need to examine the texture, the UV map, or both. You're not going to see a seam on the model unless I want you to.

Josh Susanto wrote:

The verts are the points at the corners of the triangles, no? If they do not correspond to any difference in the planar angles of the tangent triangles, they're often wasted as data, are they not?

Yes, vertices are the points at the corners of the triangles that make up the structure of any polygonal surface. And yes, a vertex smack in the middle of a flat surface can be a waste of data.

Sometimes there's good reason for the presence of such a vertex, though, so we can't speak entirely in absolutes on that.

Josh Susanto wrote:

If your precision really consists of deciding which parts of the shape need definition and which parts do not, that's not essentially different from what I describe. It's just a lot less clumsy.

It's not different in the sense that we're both ultimately facing decisions about shape and color. But the paradigms from which we're each facing them are entirely different, as are the options open to us for handling them. Case in point, those bricks in my previous example. They simply couldn't be made as a sculpty (unless you alter the texture).

Because sculpties are where your only experience has been, your thinking is somewhat limited to what fits inside their particular box. I'm trying to encourage you to break down those walls, and look at these questions from an entirely different point of view. It's understandable that that's not likely to come naturally, which is why I keep saying you'll understand once you've had more experience. You will.

Josh Susanto wrote:

Much clearer, thanks. I'm using the terms vert and UV point interchangeably, because, for me, they're the essentially the same.

Exactly. With sculpties, the relationship is locked, so yeah, they're essentially the same thing. With arbitrary mesh, the relationship can be anything you want it to be.

Josh Susanto wrote:

Where they would be different, I still maintain there's no infinite number of verts that would allow absolute control in assigning UV points. Or is there?

The vertices themselves are less important in this context than what happens in between them. So, it's never about having or not having an infinite number of vertices. It's about the fact that any UV point can be placed anywhere on the texture canvas, with an infinite degree of freedom. Thus, any amount of pixels can exist between any two vertices.

Also, one vertex can be assigned more than one UV point.

Josh Susanto wrote:

understand you're talking about more precision.

It's not just about more precision. It's also about a fundamentally different approach to concepts such as precision and imprecision than you've yet experienced.

Also, one vertex can be assigned more than one UV point.

Josh Susanto wrote:

But I still maintain that this is not completely different from what I've been doing. I can push most of the shape resolution to one end of a cylinder, for example, without changing the underlying shape. But the only advantages to that in my current case would be that the more resolved end would allow more surface pixels than the corresponding region on the opposite end, or could be used as a template for more refined relief effects on the more resolved end. It's an inefficient, roundabout way of doing things, yes, but the principle is not essentially different from what you describe so far.

With a sculpty, you can only do that kind of "pushing" by moving the vertices themselves, which means you ARE changing the shape. The fact that it still outwardly appears cylindrical is superfluous.

However, if you can adjust the UV map, then you can push the texture around any way you want, while leaving the vertices right where they are. You want to pack more of the texture in one area than another, simply expand the distance between the corresponding UV points for that area. The model itself can stay exactly as it is.

You can also place two entirely different parts of the texture right next to each other on the model. For an example of this which you're already familiar with, take a look at the avatar skin/clothing templates. (The word "template" is actually a misnomer, by the way. They are UV maps.) Areas of the texture that are very far apart from each other are mapped to faces that are right next to each other on the model. That's something you can never do with sculpties, no matter how much you move the vertices around.

Josh Susanto wrote:

BTW: Have you seen my block sculpt that causes the seams on all surface textures to disappear?

Nope.

Josh Susanto wrote:

The base models I've been working with are up to 256 data points per axis, 1024 data points total. Are you working with twice that much resolution? 10 times as much 100? What exactly?

Again, it's not about any fixed resolution. You're barking up entirely the wrong tree.

Josh Susanto wrote:

Can you bring the corners to the middle of one end without shifting the texture back to the original position or anything approximating the original position?

I'm not sure I understand the question. The orignal position was the state the texture was in before you moved the middle to the corners. Therefore, moving the corners back to the middle IS the original position. What exactly is it you're asking me to do? Can you draw it, if you can't explain it?

Josh Susanto wrote:

What happens to the opposite end of the original sphere you showed me if you applied the modified texture I provided, but without equatorial symmetry or some similar compensatory effect applied?

It can look like anything you want it to look like. The amount of "effects" is infinite. It all depends how clever you want to be with the UV arrangement.

Josh Susanto wrote:

For that matter, what does the opposite end of the original sphere look like if you just don't apply the equatorial symmetry to that, or shift the texture 180 degrees?

If I use the same mapping, but rotate the texure 180 degrees, then the "where's the pucker" would simply appear 90 degrees t how it presently does.

As for what would happen if I hadn't made it symmetrical, there's no one way to answer that. The possibilities are infinite.

I'm going to leave the rest of your latest questions/comments alone for now, because they're basically saying the same thing over again a few times. The point is when you get into UV mapping, you'll discover a whole new world of endless possibilities that had previously been off limits to you. Have fun with it.

Problem creating oblong sculpties

Recommended Posts

Link to comment

Share on other sites

Top Posters In This Topic

Popular Days

Top Posters In This Topic

Popular Days

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Please sign in to comment

Announcements

Linden Lab

Tilia

Second Life

Connect With Us

Partner With Us